運用しているWebサービスで、インフラのアラート対応に追われる週末を過ごしました。 原因は画像配信のルーティングに利用していた「Cloudflare Workers」のリクエスト数が無料枠の上限に達してしまったことでした。

今回は、上限エラーを解消するために複数のアーキテクチャを比較検証し、最終的に「あえてインフラ構成の根本解決を見送り、月額5ドルの課金で凌ぐ」という判断に至るまでのプロセスをまとめます。

課題 (Situation / Task)

現在のシステムでは、ユーザーがアップロードした画像などのメディアファイルをGoogle Cloud Storage (GCS) に保存し、Cloudflareをプロキシとしてカスタムドメイン（例: cdn.example.com）で配信しています。

GCSの仕様上、カスタムドメインで直接配信（CNAMEレコードを向けるだけ）を行うには、「GCSのバケット名」と「ドメイン名」を完全に一致させる必要があります。

GCS導入の経緯上バケット名（例: example-media-bucket）とドメイン名が異なっていたため、Cloudflare Workersを使用して、リクエストがGCSへ向かう直前にバックグラウンドで以下の書き換え処理を行っていました。

• Hostヘッダーの書き換え: storage.googleapis.com に上書き
• パスの書き換え: 先頭にバケット名を付与（例: /img/1.jpg → /example-media-bucket/img/1.jpg）

順調に稼働していたものの、サービスへのアクセス増加に伴い、ついにWorkersの無料プランの上限（10万リクエスト/日）に抵触し始めました。このままでは画像配信にエラーが発生するため、早急な対策が必要な状態でした。

解決策の検証 (Action)

上限問題を回避し、今後のスケールに耐えうる構成にするため、3つの代替アーキテクチャを検証しました。

案1: Cloudflareの標準機能（Origin Rules / Transform Rules）への移行

Workersを廃止し、Cloudflareの標準機能だけで書き換えを行えば、実行回数による追加課金はかかりません。パスの書き換えは Transform Rules で簡単に実現できました。 しかし、Origin Rules でHostヘッダーを外部ドメイン（storage.googleapis.com）に書き換えようとしたところ、現在のCloudflareの契約プランでは仕様により制限されており、エラーとなってしまいました。

案2: GCP側にロードバランサ（Cloud CDN）を導入する

GCP側に外部HTTP(S)ロードバランサを構築し、既存のバケットをバックエンドに指定する構成です。ドメイン不一致の問題は解決し、Cloudflare側は単なるDNSとして機能させることができます。 しかし、ロードバランサの稼働には固定費（月額約$18 ＋ データ処理費用）が恒久的に発生するため、現在のトラフィック規模に対しては割高なランニングコストがネックになりました。

案3: ドメイン名と一致するGCS新バケットを作成する（根本解決）

cdn.example.com という名前の新バケットを作成し、データを全量移行する最もクリーンなアプローチです。 しかし、運用環境の都合上、現在はGCPを代理店経由で利用しており、名前にピリオドが許可されていない、代理店を経由して「Google Search Consoleでのドメイン所有権確認」ができない等、実運用に乗せるのが困難であることがわかりました。 根本解決にはGCPを直接契約へ移管する（別プロジェクトへの移行）必要があり、検証と移行作業を行っている間にWorkersの無料プランの上限に抵触し、事故になる懸念がありました。

結果と最終的な意思決定 (Result)

上記の検証結果と、直近のGCSの利用料金（月額数千円程度）を天秤にかけた結果、 「Cloudflare Workersを有料プラン（Paidプラン：月額$5〜）へアップグレードする」 という選択をしました。

• コストパフォーマンス: 月額$5（約800円）で1,000万リクエスト/月までカバーでき、超過しても100万リクエストごとに$0.30。現在のトラフィックなら基本料金に余裕で収まり、案2のロードバランサ固定費よりも圧倒的に安上がりです。
• リスクと工数: アプリケーション側の改修やデータ移行を一切行わず、即日で上限エラーのリスクをゼロにできました。

今後の展望

技術的な理想を言えば、案3の「ドメイン名と一致するバケットの作成（GCP直接契約への移行）」がインフラとして最も美しい形です。代理店マージンを排除できるため、中長期的にはコストメリットも出ます。

しかし、「今」その移行工数をかけるのは、投資対効果が見合いません。 まずは月額800円の「保険代」でWorkersを使って当面を凌ぎ、今後サービスの画像データがさらに増加し、GCSのインフラ費用が月額数万円規模にまで拡大したタイミングで、改めて「GCP直契約への移行とWorkersの完全廃止」をインフラ最適化プロジェクトとして提案したいと考えています。

技術的負債を焦って返すのではなく、「コストと移行工数を計算した上で、あえて今はお金を払って延命する」という判断も、実運用においては一つの戦略として大切かもしれないと考えた週末でした。Cloudflareのコストパフォーマンスの高さにも感心しました。