「GCPの中に閉じてるから通信費はかからない」という思い込みが罠だった。
サービスリリース前に、インフラ費用の見積もりをかなり丁寧にやった。Cloud Runのコンピュート費用、Cloud SQLのインスタンス費用、ストレージ費用、Memorystoreの費用。全部計算してスプレッドシートにまとめ、月額15万円という数字を出して予算が承認された。3ヶ月後の請求は28万円だった。
差分の13万円のほぼ全てがegress費用だった。見積もりにegress費用を一切含めていなかったのだ。「データはGCPの中に閉じているから通信費はかからない」という、今思えば根拠のない思い込みのまま進めてしまった。
実態を調べると、主な発生源はCloud Storageからのデータ転送だった。ユーザーがアップロードしたプロフィール画像や添付ファイルをGCSに保存し、それをAPIレスポンス経由でフロントエンドに返す実装になっていた。画像1枚あたり平均500KB、サービス全体で1日あたり数十万回のダウンロードが発生していた。これがGCS→Cloud Run→インターネットという経路でそのままegress課金される。東京リージョンのインターネット向けegress料金は$0.085/GBなので、月間数TB単位の転送が続けば十数万円になるのは必然だった。
もう一つの発生源はリージョン間の通信だった。ログ集計のためにasia-northeast1以外のBigQueryプロジェクトにデータを送っていた部分があり、これもリージョン間egress料金として積み上がっていた。
まず取り組んだのはCloud CDNの導入だ。GCSをCDNのオリジンに設定し、静的ファイルはCDN経由で配信するように変更した。プロフィール画像や添付ファイルはあまり変化しないコンテンツなので、キャッシュヒット率は85%前後まで上がった。CDN経由のegress料金はオリジン直接配信より安く、さらにキャッシュにヒットした分はCloud RunへのリクエストもGCSへのアクセスも発生しないため、コンピュート費用の削減にもなった。結果としてegress費用は導入前の約1/3に抑えられた。次のプロジェクト以降は、見積もりの段階でデータフローを図に起こし、GCPの外に出るデータ量を明示的に計算するようにしている。egress費用はサービスの成長とともに線形に増えていく費用なので、見落としたときのインパクトが大きい。