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

はじめに

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

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

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

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

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

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

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

対策後（12:00以降）:

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

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

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

タイムライン

各モードの詳細とコスト

なぜ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の枯渇を早めた要因の一つだと考えています。

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

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

SREの仕事の流れ

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

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

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

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

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

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

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

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

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

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

5. 恒久対応（1/30）

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

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

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

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

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

残された課題と今後

短期的な課題

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

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

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

2. 監視体制の強化

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

設定すべきアラート:

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

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

長期的な検討事項

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

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

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

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

2. EFSの使い方の見直し

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

代替案:

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

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

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

技術的な学び

プロセスとしての学び

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

緊急時の判断:

調査のアプローチ:

説明責任:

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

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

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

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

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

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

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

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

関連記事

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

関連書籍

今回のようなインフラ運用やトラブルシューティングについてさらに学びたい方におすすめの書籍です。