SREの仕事 ― 問題発見から恒久対応、そして結果観察まで

はじめに

これまで3つの記事で、Jenkins EFS問題を追いかけてきました。

第1話: JenkinsがじわじわGitクローンできなくなっていった話 - 問題発見と応急処置
第2話: プロビジョンドスループットで1万円使った反省 - コストとの向き合い方
第3話: 問題の発火は1/26、でも根本原因は1/13にあった - 根本原因の発見

そして今日、対策後の結果が出ました。

正直、ここまで綺麗に効果が出るとは思っていませんでした。グラフを見たとき、「ああ、読み通りだったんだ」とすっと腑に落ちる感覚がありました。

この記事では、対策後の結果報告と、この一連の対応から見えてきたSREの仕事のプロセスについて書きます。

対策後の結果：劇的な改善

第3話で、Shared Libraryのキャッシュ設定を有効化しました。その後のEFSスループット利用率のグラフがこちらです。

EFSスループット利用率グラフ - 対策前後の劇的な変化

対策前（左側 06:00-12:00頃）:

スループット利用率が100%に達するスパイクが頻発
ほぼ常時高負荷状態
赤い警告ゾーン（75%）を大きく超えている

対策後（12:00以降）:

スループット利用率が劇的に低下し、安定
ベースラインはほぼ0%に近い
3時間ごとに規則的な小さなスパイク（最大60%程度）
設定通りの動作

3時間ごとのスパイクは、Shared Libraryのキャッシュ更新チェック（Refresh time: 180分）によるものです。つまり、想定通りに動いているということです。

スループットモード変遷の全記録

ここで、一連の対応で経た5つのスループットモード変遷を整理しておきます。

タイムライン

graph LR
    A[バースト<br/>元の設定] -->|1/27 緊急対応| B[プロビジョンド<br/>300 MiB/s]
    B -->|1/28 コスト対策| C[Elastic<br/>Throughput]
    C -->|1/29 検証| D[プロビジョンド<br/>10 MiB/s]
    D -->|今後の予定| E[バースト<br/>復帰予定]

各モードの詳細とコスト

モード	期間	コスト	判断理由
バースト	～1/27	ストレージのみ	通常運用
プロビジョンド 300 MiB/s	1/27（26時間）	約$69	緊急対応：調査作業の実行を確保
Elastic Throughput	1/28-1/29（約1日）	約$8	コスト削減：使用量課金
プロビジョンド 10 MiB/s	1/30～現在	約$2.3/日	効果検証：低コストで安定運用
バースト（予定）	近日中	ストレージのみ	恒久対応：元の設定に復帰

なぜElastic Throughputから変更したのか

実は、Elastic Throughputは「意外とコストがかかる」という発見がありました。

1日の使用で約$8。これは1ヶ月換算で約$240（約3.5万円）です。

一方、プロビジョンド10 MiB/sなら約$72/月（約1万円）で済みます。現在の使用パターン（平均スループット数%、最大60%程度）であれば、10 MiB/sで十分です。

ただし、これはあくまで検証期間中の設定です。最終的にはバーストモードに戻す予定です。

仮説の検証と修正

第3話で立てた仮説を検証します。

当初の仮説

使い捨てエージェント方式への変更（1/13）が、メタデータIOPSを激増させたのではないか

この仮説は部分的に正しかったが、主犯ではなかったというのが結論です。

実際の主犯

Shared Libraryのキャッシュが無効化されていたこと（以前から存在）

キャッシュを有効化しただけで、スループット利用率がほぼ0%に落ち着きました。つまり、Shared Libraryの毎ビルドごとのフルフェッチが、圧倒的にメタデータIOPSを消費していたということです。

使い捨てエージェント方式の影響

では、使い捨てエージェント方式は関係なかったのか？

そうではありません。使い捨てエージェント方式への変更は、Burst Creditの枯渇を早めた要因の一つだと考えています。

Shared Libraryキャッシュ無効化（以前から） → 毎ビルドでController側のメタデータIOPS消費
使い捨てエージェント方式（1/13～） → 毎ビルドでエージェント側のメタデータIOPS消費
年始の開発加速 → ビルド回数増加

この3つが重なり、1/13から急速にBurst Creditが枯渇し、2週間後の1/26に症状が顕在化しました。

Shared Libraryキャッシュの無効化だけなら、もう少しゆっくりとクレジットが減少していたかもしれません。使い捨てエージェント方式への変更が、最後の一押しになったと考えるのが妥当でしょう。

SREの仕事の流れ

この一連の対応を振り返ると、SREの仕事には明確なプロセスがあることがわかります。

graph TD
    A[問題発見] --> B[緊急対応]
    B --> C[影響の最小化]
    C --> D[根本原因調査]
    D --> E[仮説・検証]
    E --> F{根本原因<br/>特定?}
    F -->|No| E
    F -->|Yes| G[恒久対応]
    G --> H[効果測定]
    H --> I[振り返り・<br/>知見共有]

1. 問題発見（1/27 朝）

症状：Jenkinsが重い、Gitクローン失敗、504エラー
メトリクス確認：EFSスループット利用率100%
所要時間：約30分

この段階では「何が起きているか」を把握することが重要です。

2. 緊急対応（1/27 午前）

判断：プロビジョンドスループット300 MiB/sへ変更（翌日実施）
目的：調査作業の継続を確保
トレードオフ：高コスト vs 調査・開発継続

緊急時の判断は、「最悪のシナリオを回避する」ことが最優先です。コストは後から説明できますが、開発停止による損失は取り返しがつきません。

3. 影響の最小化（1/27 午後）

定期クリーンアップジョブの作成
tmp_pack_*の削除計画
再発防止策の実装

応急処置と並行して、再発防止策を講じます。

4. 根本原因調査（1/27-1/30）

第1段階：tmp_pack_*の蓄積を発見
第2段階：Burst Credit Balanceのグラフ分析で1/13が起点と判明
第3段階：Shared Libraryキャッシュ無効化を発見

正直ここで詰まりました。tmp_pack_*を見つけた時点で「これが原因だ」と思ったのですが、実際には症状の一部でしかありませんでした。

グラフを時系列で見直すことで、真の根本原因に辿り着けました。

5. 恒久対応（1/30）

Shared Libraryキャッシュの有効化
Refresh time: 180分に設定
スループットモードの最適化検討

根本原因が特定できれば、対応はシンプルです。

6. 効果測定（1/30-）

スループット利用率の劇的な改善を確認
3時間ごとのスパイクは想定通り
継続的な観察が必要

対応が正しかったかどうかは、結果が証明してくれます。

7. 振り返り・知見共有（本記事）

コスト判断の反省（Elastic Throughputを知らなかった）
複合的な原因の理解
組織への知見還元

ここが意外と肝です。問題を解決して終わりではなく、「なぜそうなったか」「どう判断したか」を言語化し、次に活かすことが重要です。

残された課題と今後

短期的な課題

1. バーストモードへの復帰

現在はプロビジョンド10 MiB/sで運用していますが、最終的にはバーストモードに戻す予定です。

戻す前に確認すべきこと:

Burst Credit Balanceが十分に回復しているか
新しいtmp_pack_*が生成されていないか
クリーンアップジョブが正常に動作しているか

2. 監視体制の強化

これは完全に反省点です。今回の問題は、適切な監視があれば早期発見できたはずです。

設定すべきアラート:

EFSスループット利用率 > 75%
Burst Credit Balance < 閾値（要検討）
ストレージ容量の異常増加

3. クリーンアップジョブの継続運用

定期クリーンアップジョブは作成しましたが、実際にtmp_pack_*が削除されているかを定期的に確認する必要があります。

長期的な検討事項

1. 使い捨てエージェント方式の見直し

現在は使い捨てエージェント方式を継続していますが、メタデータIOPSへの影響は無視できません。

検討の余地がある選択肢:

エージェントのライフサイクルを少し長くして、複数ジョブで再利用
EFS上のGitキャッシュを全エージェントで共有
S3にキャッシュを配置し、起動時に同期

コストとパフォーマンスのバランスをどう取るか。これは次の課題です。

2. EFSの使い方の見直し

そもそも、JenkinsのワークディレクトリをEFSに置くことが最適なのか、という根本的な問いもあります。

代替案:

EBSベースのストレージに移行
重要なデータのみEFSに配置
S3とEFSの使い分け

ただし、これは大きなアーキテクチャ変更になるため、慎重な検討が必要です。

まとめ：SREの仕事とは何か

振り返ってみると、今回の対応を時系列で並べてみて、気づいたことがありました。

技術的な学び

EFSメタデータIOPSの特性
- 小さいファイルの大量操作が致命的
- ストレージ容量よりファイル数が重要
- Burst Creditの管理が鍵
Jenkinsキャッシュの仕組み
- Shared Libraryキャッシュの重要性
- Refresh timeの設定バランス
- キャッシュ無効化の隠れたコスト
スループットモードの選択
- Elastic Throughputは万能ではない
- 使用パターンに応じた最適化
- コスト試算の重要性

プロセスとしての学び

でも、もっと大事なのは「どう判断したか」です。

緊急時の判断:

完璧な情報がなくても決断する
最悪のシナリオを回避することを最優先
トレードオフを明確にする

調査のアプローチ:

症状だけでなく、グラフを時系列で見る
仮説を立てて検証し、違ったら次の仮説へ
「正直ここで詰まりました」を認める

説明責任:

コストは後から説明できる
判断プロセスを言語化する
失敗も含めて共有する

この3つが、今回の対応から得た最大の学びです。

迷ったときはより難しい方を

最後に、個人的な話になりますが。

Elastic Throughputという選択肢を知らなかったこと。これは明らかに知識不足でした。$64の差は大きいです。

でも、「調査を続けられる環境を確保する」という判断自体は間違っていなかったと思っています。知らなかったことは反省しますが、判断のプロセスは次に活かせます。

迷ったときはより難しい方、成長できる方を選ぼう――これは私がいつも大切にしている考え方です。

今回の対応も、楽な方を選べば「Jenkinsを止めて週末に調査」という選択肢もありました。でも、「稼働を継続させながら調査する」という難しい方を選んだからこそ、緊急対応・コスト判断・根本原因特定という一連のプロセスを経験できました。

$69の授業料は高かったかもしれません。でも、それ以上の学びを得られたと思っています。

この記事は、以下の3つの記事の続編です: