はじめに
先日、「JenkinsがじわじわGitクローンできなくなっていった話 ― EFSメタデータIOPSとの闘い」という記事を公開しました。EFSのメタデータIOPS枯渇によりJenkinsが停止し、約3時間の調査で原因を特定・対処したという内容です。
技術的には解決できたのですが、実はそこで終わりではありませんでした。
翌日、AWS Cost Explorerを開いたとき、目に飛び込んできた数字に思わず固まりました。
「$69.00」
正直、対応まずかったかな...と思いました。
この記事では、緊急対応時のコスト判断と、その後の説明責任について書きます。トラブルシューティング記事の「後始末編」です。
何が起きたか
前回の記事で書いたように、EFSのメタデータIOPS枯渇により、Jenkinsが実質停止状態になりました。月曜日の朝という最悪のタイミングです。
調査と並行してJenkinsを安定稼働させるため、私は緊急対応としてEFSのスループットモードをプロビジョンドスループット 300 MiB/s に変更しました。
この判断により：
- ✅ Jenkins環境の稼働継続を確保
- ✅ 約3時間で根本原因を特定
- ✅ 恒久対策を実施
技術的には成功でした。ただし...
コストの現実
翌日、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の場合：
- 300 × $7.2 = $2,160/月（約30万円）
26時間の使用では：
- $2,160 × (26/720) ≈ $78
実測は$69だったので、おそらくベースラインスループット分が差し引かれたのでしょう。
メリット: 安定した性能、クレジット不要
デメリット: 非常に高額、使わなくても課金される
3. Elastic Throughput（知らなかった選択肢）
料金: ストレージ料金 + 実際に使用したスループット分
東京リージョンでは：
- 読み込み: $0.04/GB
- 書き込み: $0.07/GB
メリット: 使った分だけ課金、自動スケール
デメリット: 使用量が読めないと予算管理が難しい
より良い選択肢
改めて試算してみます。
今回のケースでは、調査中に約50GBのスループットを使ったと仮定すると：
| モード | 26時間のコスト | 備考 |
|---|---|---|
| バースト | $5.6（月額分） | クレジット枯渇で調査不可 |
| プロビジョンド | $69 | 実際に選択 |
| Elastic | $3.5〜$5 | 知らなかった |
差額: 約$64〜$66（約9,000〜9,500円）
Elastic Throughputを選択していれば、約20分の1のコストで済んだ計算です。
正直ここで詰まりました。緊急時だからこそ、冷静にコスト試算すべきだったのですが、知識不足でElastic Throughputという選択肢が頭に浮かばなかったのです。
関係者への説明
このコストについては、関係者への説明が必要です。
ただ、「失敗しました」で終わらせるのではなく、判断の背景と費用対効果をきちんと整理する必要がありました。
判断の背景
緊急対応時、私が考えていたのは以下の点です：
状況:
- 月曜日朝、Jenkins全停止
- 開発チーム全員のビルドが実行不可
- 原因特定に3時間かかる見込み
選択肢の検討:
| 選択肢 | メリット | デメリット | 判断 |
|---|---|---|---|
| バーストモード継続 | コスト増なし | クレジット枯渇で調査すら困難 | ❌ 不可 |
| プロビジョンド 300 MiB/s | 確実な性能確保 調査作業が可能 |
高コスト | ✅ 採用 |
| Elastic Throughput | 使用量課金で安価 自動スケール |
知識不足により選択肢に入らず | - |
判断理由:
- システム停止による開発チーム全体への影響を最小化
- 調査作業（find, du等）の実行に安定したI/O性能が必要
- 翌日には設定変更可能な見込み
- ビジネス継続性を最優先
費用対効果
開発チームを仮に10名、時給5,000円として試算すると：
回避できた損失:
- 待機時間削減: 3時間 × 10名 = 30人時
- 時給換算: 30人時 × 5,000円 = 150,000円
- デプロイ遅延による機会損失: 算定困難だが無視できない
発生コスト:
- プロビジョンドスループット: 10,000円
費用対効果: 約15倍のROI
数字で見ると、判断自体は妥当だったと言えそうです。ただし、Elastic Throughputを知っていれば、もっと低コストで同じ効果を得られたのも事実です。
報告書の作成
上記の内容を整理し、関係者向けの報告書を作成しました。
報告書では：
- 障害の概要と影響範囲
- 緊急対応の判断プロセス
- コスト発生の内訳
- 費用対効果の評価
- 今後の改善策と再発防止策
を明記しました。特に「判断は妥当だったが、知識不足により最適解ではなかった」という点を正直に書きました。
学びと内省
技術的な学び
Elastic Throughputの有効性
- スパイク対応に最適
- 使用量課金で予測可能なコスト
- 今後の第一選択肢として運用
緊急時こそコスト試算
- 「とりあえず動かす」だけでは不十分
- 選択肢とコストインパクトを比較する習慣
- 知らないオプションがあるかもしれない、と疑う
監視体制の強化
- EFSメトリクスの定常監視
- ストレージ容量だけでなくファイル数・IOPS監視
- 早期検知による予防保守
内省：なぜElastic Throughputを知らなかったか
正直に振り返ると、EFSの料金体系を「何となく」しか理解していませんでした。
- バーストモード = 無料
- プロビジョンドモード = 高い
という漠然とした知識はあったのですが、「どのくらい高いのか」「他に選択肢はないのか」を調べていませんでした。
Elastic Throughputは2022年に発表されたモードです。つまり、私の知識が古かったわけではなく、そもそもきちんと調べていなかったのです。
緊急時だからこそ、一度立ち止まって調べる。この習慣が足りなかったと反省しています。
組織的な改善
この経験を個人の学びで終わらせず、組織全体の知見にするために：
知識共有
- 本記事を社内外へ公開
- AWS コスト最適化の勉強会開催検討
ドキュメント化
- トラブルシューティング手順書の整備
- コスト試算を含む意思決定フローの明文化
監視・アラート
- EFS使用量の可視化
- スループット利用率75%超過でアラート設定
を進めています。
まとめ
トラブルを技術的に解決できても、それで終わりではありません。
- コストの説明責任
- 判断プロセスの振り返り
- 組織への知見の還元
これらも含めて、エンジニアの「仕事」だと実感しました。
今回の$69（約1万円）は高い授業料でしたが、以下の価値を得られたと考えています：
- EFSの料金体系への深い理解
- 緊急時の意思決定プロセスの改善
- 組織全体での知見共有
もし同じ状況に遭遇したら、次は迷わずElastic Throughputを選びます。
そして、この経験が他の誰かの役に立てば、$69は決して無駄ではなかったと言えるのではないでしょうか。
関連記事
前回のトラブルシューティング記事はこちら：
/ja/tech/sre/jenkins-efs-metadata-iops-issue