トラブル解決後の仕事 ― プロビジョンドスループットで1万円使った反省

はじめに

先日、「JenkinsがじわじわGitクローンできなくなっていった話 ― EFSメタデータIOPSとの闘い」という記事を公開しました。EFSのメタデータIOPS枯渇によりJenkinsが停止し、約3時間の調査で原因を特定・対処したという内容です。

技術的には解決できたのですが、実はそこで終わりではありませんでした。

翌日、AWS Cost Explorerを開いたとき、目に飛び込んできた数字に思わず固まりました。

「$69.00」

正直、対応まずかったかな...と思いました。

この記事では、緊急対応時のコスト判断と、その後の説明責任について書きます。トラブルシューティング記事の「後始末編」です。

何が起きたか

前回の記事で書いたように、EFSのメタデータIOPS枯渇により、Jenkinsが実質停止状態になりました。月曜日の朝という最悪のタイミングです。

調査と並行してJenkinsを安定稼働させるため、私は緊急対応としてEFSのスループットモードをプロビジョンドスループット 300 MiB/s に変更しました。

この判断により：

技術的には成功でした。ただし...

コストの現実

翌日、Elastic Throughputへ設定を戻した後、ふとコストが気になりました。

プロビジョンドスループットは「高い」という知識はありました。でも、26時間程度なら大したことないだろう、と。

Cost Explorerを開いてみると：

約$69（約1万円）

26時間で、です。

もし1ヶ月このまま放置していたら、約$2,160（30万円超）になっていた計算です。すぐに戻して良かった、と安堵しつつ、同時に「もっと良い選択肢があったんじゃないか？」という疑問が湧いてきました。

EFSの料金体系を理解する

ここで改めて、EFSの料金体系をきちんと整理する必要がありました。実は緊急対応時、私はElastic Throughputという選択肢を知りませんでした。

EFSには3つのスループットモードがあります：

1. バーストスループット（元の設定）

料金: ストレージ料金のみ

ストレージ容量に応じてスループットが決まる仕組みです。1TiBあたり50 MiB/秒のベースラインがあり、クレジット制で低負荷時に貯めて、高負荷時に使います。

メリット: 追加料金なし

デメリット: クレジットが枯渇すると性能低下（今回の問題）

2. プロビジョンドスループット（緊急対応時の設定）

料金: ストレージ料金 + スループット料金

東京リージョンでは、1 MiB/sあたり約$7.2/月です。

300 MiB/sの場合：

26時間の使用では：

実測は$69だったので、おそらくベースラインスループット分が差し引かれたのでしょう。

メリット: 安定した性能、クレジット不要

デメリット: 非常に高額、使わなくても課金される

3. Elastic Throughput（知らなかった選択肢）

料金: ストレージ料金 + 実際に使用したスループット分

東京リージョンでは：

メリット: 使った分だけ課金、自動スケール

デメリット: 使用量が読めないと予算管理が難しい

より良い選択肢

改めて試算してみます。

今回のケースでは、調査中に約50GBのスループットを使ったと仮定すると：

差額: 約$64〜$66（約9,000〜9,500円）

Elastic Throughputを選択していれば、約20分の1のコストで済んだ計算です。

正直ここで詰まりました。緊急時だからこそ、冷静にコスト試算すべきだったのですが、知識不足でElastic Throughputという選択肢が頭に浮かばなかったのです。

関係者への説明

このコストについては、関係者への説明が必要です。

ただ、「失敗しました」で終わらせるのではなく、判断の背景と費用対効果をきちんと整理する必要がありました。

判断の背景

緊急対応時、私が考えていたのは以下の点です：

状況:

選択肢の検討:

判断理由:

費用対効果

開発チームを仮に10名、時給5,000円として試算すると：

回避できた損失:

発生コスト:

費用対効果: 約15倍のROI

数字で見ると、判断自体は妥当だったと言えそうです。ただし、Elastic Throughputを知っていれば、もっと低コストで同じ効果を得られたのも事実です。

報告書の作成

上記の内容を整理し、関係者向けの報告書を作成しました。

報告書では：

を明記しました。特に「判断は妥当だったが、知識不足により最適解ではなかった」という点を正直に書きました。

学びと内省

技術的な学び

内省：なぜElastic Throughputを知らなかったか

正直に振り返ると、EFSの料金体系を「何となく」しか理解していませんでした。

という漠然とした知識はあったのですが、「どのくらい高いのか」「他に選択肢はないのか」を調べていませんでした。

Elastic Throughputは2022年に発表されたモードです。つまり、私の知識が古かったわけではなく、そもそもきちんと調べていなかったのです。

緊急時だからこそ、一度立ち止まって調べる。この習慣が足りなかったと反省しています。

組織的な改善

この経験を個人の学びで終わらせず、組織全体の知見にするために：

を進めています。

まとめ

トラブルを技術的に解決できても、それで終わりではありません。

これらも含めて、エンジニアの「仕事」だと実感しました。

今回の$69（約1万円）は高い授業料でしたが、以下の価値を得られたと考えています：

もし同じ状況に遭遇したら、次は迷わずElastic Throughputを選びます。

そして、この経験が他の誰かの役に立てば、$69は決して無駄ではなかったと言えるのではないでしょうか。

関連記事

前回のトラブルシューティング記事はこちら：

JenkinsがじわじわGitクローンできなくなっていった話 ― EFSメタデータIOPSとの闘い

ある月曜の朝、Jenkinsが突然重くなり、Gitクローンが失敗するようになりました。504エラーも頻発。調査の結果、EFSのメタデータIOPSが枯渇していたことが判明。さらに、Git一時ファイルが蓄積され続けていたことが真犯人でした。約3...

Tech

SRE

参考資料