- 公開日
- 最終更新日
EKS の障害対応を Step Functions + Bedrock で自動化してみた
この記事を共有する
目次
こんにちは、パーソル＆サーバーワークスの高橋です。
今回は EKS で障害が発生した際に、検知→情報収集→AI 分析→通知→承認→対処までを自動で行うワークフローを構築してみました。構成と検証結果を共有します。
前提
本記事では構成と検証結果にフォーカスしており、CloudFormation テンプレートや Lambda のコードなど、構築手順の詳細については割愛しています。
「こういう仕組みが作れる」「実際に動かすとこうなる」というイメージを掴んでいただければ幸いです。
はじめに
EKS を運用していると、Pod 異常やノード障害が発生した際に以下の作業を人手で行う必要があります。
| # | 作業 | 内容 |
|---|---|---|
| 1 | 調べる | kubectl get pods, kubectl describe 等で状態確認 |
| 2 | 推測する | ログ確認、過去事例の参照から原因を推測 |
| 3 | 対処する | Pod restart, rollout restart 等を実行 |
この「1. 調べる」「2. 推測する」の部分を自動化できないかと考え、Step Functions + Bedrock (Claude) を使ったワークフローを構築しました。
対処（3）についても、人間の承認を挟んだ上で自動実行できる仕組みにしています。
今回作ったもの
CloudWatch Alarm をトリガーに、Step Functions が起動し、Lambda で EKS の情報を収集 → Bedrock (Claude) で原因分析 → SNS でメール通知 → 承認後に自動対処、という一連のフローです。
| サービス | 役割 |
|---|---|
| Amazon EKS | コンテナ実行基盤（ノード 2台、Pod 複数） |
| Amazon CloudWatch | メトリクス監視・アラーム |
| Amazon EventBridge | アラーム発火をトリガーに Step Functions を起動 |
| AWS Step Functions | ワークフロー全体のオーケストレーション |
| AWS Lambda | 情報収集・分析・通知・承認コールバック・対処の実行（5つ） |
| Amazon Bedrock (Claude Sonnet 4.6) | AI による障害原因分析 |
| Amazon SNS | メール通知 |
| Amazon API Gateway | 承認/却下のコールバック受け口 |
構成図
今回ハンズオンした全体構成図になります。
ワークフローの流れ
| ステップ | 実行者 | 内容 |
|---|---|---|
| 1 | EKS | Pod 異常が発生する |
| 2 | CloudWatch | Alarm が ALARM 状態に変化 |
| 3 | EventBridge | ルールが発火し、Step Functions を起動 |
| 4 | Lambda① | EKS に接続し、Pod/Node の状態を取得 |
| 5 | Lambda② | 収集した情報を Bedrock (Claude) に渡して原因を分析 |
| 6 | Lambda③ | 分析結果 + 承認/却下リンク付きのメールを送信 |
| 7 | 人間 | メールの承認リンクをクリック |
| 8 | Lambda④ | 承認コールバック受信 → Step Functions を再開 |
| 9 | Lambda⑤ | 承認を受けて自動対処を実行（Pod restart 等） |
| 10 | Lambda③ | 対処結果をメールで通知 |
Step Functions のフロー設計
Step Functions で全体のフローを定義しています。Bedrock の分析結果に含まれる「重要度（severity）」に応じて分岐します。
| 重要度 | 動作 |
|---|---|
| critical | 通知のみ（自動対処は行わず、人間が手動で対応） |
| high / medium / low | 通知 → 承認待ち → 承認されたら自動対処を実行 |
承認待ちには waitForTaskToken を使っています。メール内のリンクをクリックするまで Step Functions が一時停止し、1時間以内に承認がなければタイムアウトで終了します。
エラーハンドリングも組み込んでおり、Lambda の実行失敗時はリトライ後に通知、承認が却下された場合は「却下されました」のメールを送信して終了します。
参考：Step Functions の概要
検証
テスト環境
| 項目 | 内容 |
|---|---|
| リージョン | ap-northeast-1 |
| EKS クラスター | ノード 2台 (t3.medium, マルチ AZ) |
| 正常 Pod | nginx x3, httpd x2, worker x2（計 7 個） |
| エラー Pod | 5 パターンを投入 |
投入したエラー Pod
意図的に異常を起こす Pod を5種類用意しました。
| Pod 名 | エラー種別 | 内容 |
|---|---|---|
| crash-loop-test | CrashLoopBackOff | 起動直後にクラッシュし再起動を繰り返す |
| image-pull-error-test | ImagePullBackOff | 存在しないイメージを指定 |
| oom-kill-test | OOMKilled | メモリ制限 32Mi に対し 200MB 確保しようとする |
| pending-test | Pending | 存在しないノードセレクタを指定 |
| resource-hungry-deployment | Pending | CPU 4コア要求でノード容量を超過 |
結果①: アラーム発火 → ワークフロー自動起動
CloudWatch Alarm が ALARM 状態になると、EventBridge 経由で Step Functions が自動起動しました。人間が何もしなくても、障害検知からワークフロー起動までが自動で行われます。
結果②: Bedrock (Claude) による障害分析
Lambda が EKS から Pod/Node の状態を収集し、Bedrock (Claude Sonnet 4.6) がリアルタイムで原因を分析しました。
| 項目 | 分析結果 |
|---|---|
| 障害概要 | test-workloads 名前空間で複数の障害が同時発生。CrashLoopBackOff・ImagePullBackOff・リソース不足によるスケジューリング失敗が確認されている |
| 推定原因 | 4つの独立した原因が同時発生（コンテナ異常終了、OOM Kill、存在しないレジストリ参照、リソース要求過大） |
| 重要度 | HIGH |
| 推奨アクション | 10件の具体的な対処案（ログ確認、メモリ制限修正、イメージ名修正、リソース削減、スケールダウン等） |
メールには分析結果に加えて「✅ 承認する」「❌ 却下する」のリンクが含まれています。
参考：メールは以下の文面になります。
メールの要約：
| セクション | 内容 |
|---|---|
| AI 分析結果 | CrashLoopBackOff、ImagePullBackOff、OOMKilled、Pending が同時発生。4つの独立した原因を特定 |
| 推定原因 | ①コンテナが起動直後に異常終了 ②OOM Kill によるメモリ超過 ③存在しないレジストリを参照 ④リソース要求がノード容量を超過 |
| 推奨アクション（10件） | ログ確認、メモリ制限修正、イメージ名修正、リソース削減、スケールダウン、ResourceQuota 設定など |
| 承認リンク | ✅ 対処を承認する（自動実行される） / ❌ 対処を却下する（手動対応） |
参考：Step Functions の状態は「WaitForApproval」で承認・却下が押下されるのを待っている状態です。
結果③: 承認フロー
メールの「✅ 承認する」リンクをクリックすると、ブラウザに承認完了画面が表示されました。
API Gateway → Lambda④ → Step Functions (SendTaskSuccess) の流れで、Step Functions が再開します。
参考：承認を押下すると、Step Functions の状態が完了します。
結果④: 自動対処の実行
承認後、Lambda⑤ が実行され、対処結果がメールで通知されました。
今回は Bedrock が auto_executable: false（自動実行不可）と判断したため、実際の対処はスキップされました。これは安全設計として意図した動作です。
Lambda⑤ には以下の安全ガードを実装しています。
| 安全ガード | 内容 |
|---|---|
| auto_executable チェック | AI が「自動実行可能」と判断したものだけ実行 |
| risk チェック | risk が high のアクションはスキップ |
| namespace チェック | kube-system 等のシステム namespace は対象外 |
| 承認必須 | 人間の承認なしでは絶対に実行されない |
参考：以下のように完了通知が届きます。
完了通知メールの要約：
| 項目 | 内容 |
|---|---|
| 対処アクション数 | 10件 |
| 実行された | 0件 |
| スキップされた | 10件 |
| スキップ理由 | Bedrock が auto_executable: false と判断（設定ミスの根本修正は人間が行うべきと判断） |
今回のエラーは「yaml の設定ミス」が原因のため、Pod restart では根本解決にならないと AI が正しく判断し、自動実行をスキップしています。人間がマニフェストを修正する必要があるケースです。
結果⑤: Step Functions の実行状態
Step Functions コンソールで各ステップの成功/失敗がビジュアルに確認できます。各ステップをクリックすると入出力の JSON も見られるので、デバッグがしやすいです。
自動化の範囲について
商用環境で「AI にどこまで任せるか」は慎重に判断する必要があります。今回の設計では以下の方針としました。
| 対象 | 自動化レベル |
|---|---|
| 情報収集 (kubectl 相当) | 完全自動 |
| 原因分析 (Bedrock) | 完全自動 |
| 通知 | 完全自動 |
| 対処 (Pod restart 等) | 承認必須 |
| critical な障害 | 通知のみ（対処は人間が行う） |
「情報収集と分析は自動、対処は人間が判断」という線引きにすることで、人間がやる作業の大部分（何が起きてるか調べる、原因を推測する）を自動化しつつ、安全性を担保しています。
まとめ
| 確認できたこと | 詳細 |
|---|---|
| 一連のフローの自動化 | 検知→情報収集→AI 分析→通知→承認→対処まで自動で実行できた |
| AI による原因分析 | Bedrock (Claude) が原因の推定と対処案の提示を自動で行った |
| 安全な承認フロー | waitForTaskToken で人間の承認を挟むことで商用でも安全に運用できる |
| 可視化 | Step Functions でフロー全体がビジュアル化され、状況が一目瞭然 |
「何が起きているか調べる」作業を AI に肩代わりさせる。これだけでも運用負荷はかなり下がると感じました。
この記事がどなたかの参考になれば幸いです。
この記事は私が書きました
高橋 憲太
記事一覧パーソル＆サーバーワークスの高橋です。 猫も犬も好きです。
