本番でDEBUGログを出しっぱなしにしていたら、ログ費用が静かに膨らんでいた。
月次のコスト確認をしていて、Cloud Loggingの費用が妙に高いことに気づいた。見積もりではほぼ無料枠内で収まるはずだったのに、請求には月5万円近い金額が計上されていた。Cloud Loggingは月50GiB/月まで無料で、超えた分は$0.01/GiBで課金される。逆算すると毎月500GiB程度のログが取り込まれている計算になる。そんなに出していた覚えはなかった。
調査するとすぐに犯人が見つかった。Cloud RunとGKEにデプロイしているアプリケーションのログレベルが、本番環境でもDEBUGのままになっていた。開発中にデバッグしやすくするためにDEBUGレベルに設定したまま、リリース時に環境変数で切り替えることを忘れていた。
DEBUGレベルのログはINFOやWARNの数倍の量が出る。このサービスの場合、1回のAPIリクエストに対してSQLクエリの内容、外部API呼び出しのリクエストとレスポンスのフルボディ、キャッシュのヒット・ミス状況など10〜20行のDEBUGログが出力されていた。1日あたりのAPIリクエスト数が100万件なら、1日に1,000〜2,000万行のログが生成される。1行100バイトとして月間30〜60GB。複数のサービスで同じことが起きていたので月500GiBという数字は説明がつく。加えて、GKEのLiveness ProbeとReadiness Probeが数秒おきにHTTPリクエストを送るのだが、そのリクエストまでアプリのアクセスログに記録されていた。これだけで1インスタンスあたり1日に数万行のログが出る。
対処は3段階で行った。まず最も効果が大きかったのはログレベルの変更で、全サービスのログレベルをINFOに切り替えた。これだけで取り込み量が1/5以下に激減した。次にCloud LoggingのLog Exclusion Filterを設定して、ヘルスチェックのアクセスログを取り込まないようにした。最後に_Default LogBucketのログ保存期間をデフォルトの30日から7日に短縮した。これらを合わせた結果、ログ費用は月5万円から数千円まで下がった。アプリのデプロイチェックリストに「本番のログレベルがINFO以上になっているか確認する」という項目を追加したのは言うまでもない。ログは「多いほど良い」ではなく、必要なものだけを残す設計が重要だと実感した。