「3億円の家を建てる」という目標に向けて、コツコツと資産を積み上げている最中、現場でとんでもない事件が起きました。
結論から言うと、アプリのログ出力設定ミスにより、開発環境の利用料が1ヶ月で数十万円規模にまで爆増したのです。。。
実は以前、下記の記事で「コスト管理は気を付けましょう」とドヤ顔で解説していたのですが……（笑）
まさに「紺屋の白袴」。インフラエンジニアとして、この痛恨のミスを「高い授業料」で終わらせないために、原因と対策を技術的な視点から総括します。
1. 事件の発覚：Azureからの「不穏な通知」
ある朝、メールボックスに届いたのは、設定していたコストアラートの通知でした。
「まあ、検証でリソース動かしてるしな」と軽く考えてポータルを開いた瞬間、背筋が凍りました。グラフは垂直に近い角度で右肩上がり。そこには、個人開発（あるいは小規模な検証）ではお目にかかれないような、数万〜数十万円単位の請求予定額が表示されていたのです。
原因は明白。Log Analytics（App Insights）へのデータインジェクション（取り込み量）が異常値を示していました。
2. なぜログだけでこれほど高騰したのか？（原因分析）
調査の結果、いくつかの負の連鎖が重なっていることが判明しました。
- ログレベルのミス: 開発環境でデバッグ効率を優先し、ログレベルを
Verbose（最詳細）に固定したままデプロイしていたこと。 - ループ内での過剰出力: 特定のポーリング処理やリトライ処理の中で、1秒間に数百回単位で構造化ログを吐き出し続けていたこと。
クラウドの恐ろしさは「リソース（計算資源）」だけでなく、「データ量」そのものが課金対象になるという点です。まさに「チリも積もれば山となる」を物理的に体験しました。
3. インフラエンジニアとしてのデバッグと対策
このミスを二度と繰り返さないために、インフラ側の構成変更と、アプリ側への改善依頼という両面で対策を講じました。
① アプリ側への「ログ出力抑制」を依頼
根本原因はアプリの挙動にあるため、開発チームへ即座にフィードバックを行いました。
- 不要なループ内ログの削除: デバッグ目的で埋め込んだままになっていた高頻度なログ出力を停止。
- 構造化ログのスリム化: 1ログあたりのペイロードを最小限に抑え、必要な情報のみをパッチで当てるよう修正を依頼しました。
②Log Analytics の「日次上限」設定
万 が一の暴走に備え、Log Analytics ワークスペース側で 「1日あたりのデータ取り込み上限（Daily Cap）」 を設定。これにより、今回のような異常なインジェクションが発生しても、被害を最小限に食い止められるようにしました。
③ アラート戦略の見直し
コストアラートを「予算の80%」といった点での監視だけでなく、「前日比での急増」を検知するメトリックアラートを追加。異常の早期発見を仕組み化しました。
4. 「3億円の家」への道のりにおける「大赤字」
今回の数十万円という出費は、正直に言って痛いです。配当金生活や鎌倉への移住計画という壮大な目標を掲げている身として、この「設計ミスによるサンクコスト」は猛省すべき点です。
しかし、これも現場で戦うインフラエンジニアとしてのリアル。教科書通りの構築では学べない、クラウドの「牙」を肌で感じることができました。
「ログは資産だが、設計を誤れば負債になる」
今回の授業料を糧に、より堅牢でコスト効率の高いインフラ構成を追求していきます。皆さんも、ログの「出しすぎ」にはくれぐれもご注意ください！
コメント