aws-service-chaos-research

AWS サービス固有のカオスおよび HA テストに関する調査

特定の AWS サービス向けに、包括的なカオスエンジニアリングおよび高可用性テストのシナリオを生成します。シナリオライブラリを最優先するアプローチを採用します。まず、構成済みの複合シナリオについて、最新の FIS シナリオライブラリのドキュメントを読み、次に list-actions で個別の FIS アクションを照会し、最後に詳細なドキュメント調査で補足します。

出力言語のルール

ユーザーの会話の言語を判定し、すべての出力に同じ言語を使用してください。

• 中国語の入力 → 中国語で出力
• 英語の入力 → 英語で出力
• 混在している場合 → 優勢な言語に従う

前提条件

必要なツール（各グループから少なくとも 1 つ）：

FIS シナリオライブラリ（グループ A — ドキュメントベースで常に利用可能）：

• aws___read_documentation — FIS シナリオライブラリのページを直接読み取ります（シナリオはコンソールでのみ利用でき、CLI からは照会できないため、最新のドキュメントを読むことだけがシナリオを見つける方法です）

FIS アクションの検出（グループ B — 以下の優先順位で使用）：

1. AWS CLI aws fis list-actions — ユーザーのリージョンにおける FIS アクションの確定的なリアルタイム一覧
2. aws___search_documentation — CLI を利用できない場合の代替として、FIS アクションのリファレンスページを検索します

ドキュメント調査（グループ C）：

• aws___search_documentation — AWS 公式ドキュメントを検索します
• aws___read_documentation — ドキュメントページ全体を読み取ります
• aws___recommend — 関連ページを見つけます

ドキュメント調査には、上記の AWS Knowledge MCP ツールのみを使用してください。 ドキュメント調査に SearXNG やその他のウェブ検索ツールを使用しないでください。

ワークフロー

重要 — すべての AWS Knowledge MCP 呼び出しを順次実行してください： aws___search_documentation、aws___read_documentation、aws___recommend へのすべての呼び出しは、1 回ずつ順番に実行する必要があります。複数の MCP リクエストを並列で送信しないでください。aws-knowledge-mcp-server には厳しいレート制限があり、同時リクエストは「Too many requests」エラーで拒否されます。 次のリクエストを送信する前に、各リクエストの完全な応答が返るまで待ってください。これは以下のすべてのステップ（ステップ 2、4b、4c、5a、5b）に適用されます。

失敗時の再試行： MCP 呼び出し（特に aws___read_documentation）でレート制限エラー（「Too many requests」）やその他の一時的なエラーが返された場合は、再試行の間に 5 秒待ち、最大 10 回まで再試行してください。10 回すべて失敗した場合に限り、そのリクエストをスキップしてください。

複数サービスのリクエスト： ユーザーが複数のサービス（例：「EKS、RDS、MSK、ElastiCache」）について尋ねた場合は、1 サービスずつ処理してください。次のサービスに進む前に、1 つのサービスについてすべての調査手順（ステップ 2～5）を完了してください。複数のサービスについて並行して調査を開始しないでください。レート制限が発生します。 シナリオライブラリの取得（ステップ 2）はすべてのサービスを対象とするため、1 回だけ実行すれば十分です。サービスごとの手順（ステップ 3～5）は、各サービスについて順番に繰り返す必要があります。

ステップ 1：対象サービスを特定する

ユーザーのメッセージから対象の AWS サービスを抽出し、対象リージョンを判定します。

リージョンの検出

FIS アクションは AWS のリージョンによって異なる場合があります。us-east-1 では利用できても、ap-southeast-1 ではまだ利用できないアクションもあります。サービスキーワードの解決はリージョンに依存するため、必ず最初に対象リージョンを特定してください。

検出順（最初に当てはまるものを使用）：

1. ユーザーが明示的に指定 — 例：「us-west-2」、「東京リージョン」、「ap-northeast-1」
2. 文脈から推定 — リソース ARN や、以前の会話で言及されたリージョン
3. AWS CLI のデフォルトを確認 — aws configure get region を実行して、設定済みのデフォルトリージョンを取得
4. ユーザーに確認 — 上記のいずれでもリージョンが特定できない場合は、次のように尋ねます。 「対象の AWS リージョンを教えてください。FIS アクションとシナリオはリージョンによって異なる場合があります。」

後続の手順で使用するため、特定したリージョンを TARGET_REGION として保存します。

サービスキーワードの解決

FIS アクション ID は aws:<service>:<action> の形式です。ユーザーの入力を 正しい FIS サービスキーワードに対応付けるには、最新の FIS アクション一覧から動的に検出します。

aws fis list-actions --region TARGET_REGION | jq '.actions[].id' | awk -F':' '{print $2}' | sort -u

これにより、そのリージョンで FIS がサポートするサービスキーワードの確定リストが返されます （例：ebs、ec2、ecs、eks、elasticache、fis、network、rds、s3、ssmなど）。 ユーザーが指定したサービス名をこのリストと照合します。たとえば、ユーザーが 「Aurora」と言った場合は rds に、「Kubernetes」と言った場合は eks に対応付けます。

AWS CLI を使用できない場合は、AWS サービス名を小文字にし、 スペースとハイフンを削除してキーワードを導き出します（例：「ElastiCache」→ elasticache）。

サービスが曖昧な場合は、ユーザーに確認してください（例：「RDS MySQL と Aurora MySQL のどちらですか？」）。

ユーザーがデプロイアーキテクチャについて言及した場合は、それも特定します。

• Multi-AZ、Multi-Region、Single-AZ
• リードレプリカ、Global Tables、クロスリージョンレプリケーション
• これは、関連するシナリオに影響します

ステップ 2：FIS シナリオライブラリの取得（シナリオライブラリ優先）

このステップを最優先してください。 FIS シナリオライブラリには、複数の障害注入アクションを組み合わせて現実的な障害シミュレーションを実行する、AWS が選定した複合シナリオが用意されています。これらは、レジリエンスをテストする方法についての AWS 独自の推奨事項を反映しているため、最も有益な出発点です。

シナリオライブラリのシナリオはコンソール専用であり、AWS CLI や API から一覧表示したり、クエリしたりすることはできません。シナリオを見つけるには、最新のドキュメントを読むしかありません。

references/search-queries.md の「FIS Scenario Library Pages (Always Fetch)」に記載されているシナリオライブラリのページを取得します。概要ページと、対象サービスに関連する詳細なシナリオページの両方を読みます。ページは一度に 1 つずつ、順番に読んでください。次のページに進む前に、各 aws___read_documentation の呼び出しが完了するのを待ちます。

シナリオのドキュメントから、関連する各シナリオについて以下を抽出します。

• シナリオ名と説明
• シナリオが組み合わせて実行するサブアクション
• 対象サービスに関連するサブアクション
• 特定のリソースを対象にするために必要なリソースタグ
• デフォルトの継続時間（中断フェーズ＋復旧フェーズ）
• 前提条件や制限事項
• 停止条件の推奨事項

判断：どのシナリオが該当しますか？

ドキュメントを読んだ後、各シナリオの関連性を分類します。

関連性	基準
直接関連	シナリオに、サービスを明示的に対象とするサブアクションが含まれる（例：AZ Power Interruption の「Failover RDS」）
間接関連	シナリオが、そのサービスが依存するインフラに影響する（例：ネットワーク障害は、VPC ベースのあらゆるサービスに影響する）
関連なし	シナリオが対象サービスに実質的な影響を与えない

直接関連するシナリオと間接関連するシナリオの両方を出力に含めます。

ステップ 3：FIS アクションのクエリ

シナリオライブラリの調査後、個別の FIS アクションをクエリし、複合シナリオでは網羅されていない可能性のある、サービス固有の障害注入機能を確認します。

パス A：AWS CLI が使用可能な場合（推奨）

ステップ 3a：対象リージョンのすべての FIS アクションを取得します：

aws fis list-actions --region TARGET_REGION --query 'actions[].{id:id, description:description}' --output json

TARGET_REGION をステップ 1 で特定したリージョン（例：us-east-1）に置き換えます。 リージョンが特定できない場合は、CLI のデフォルトを使用するため --region を省略します。ただし、結果はデフォルトリージョンを反映しており、他のリージョンでは異なる可能性があることをユーザーに警告してください。

ステップ 3b：対象サービスで絞り込みます — 一覧全体から、id にステップ 1 の検索キーワードが含まれるアクションを探します：

aws fis list-actions --region TARGET_REGION --query 'actions[?starts_with(id, `aws:KEYWORD:`)].{id:id, description:description}' --output json

アクションのプレフィックスが異なっていても、説明内でサービスに言及している場合があるため、説明フィールドも確認してください。

ステップ 3c（任意）：横断的なアクションを収集します — これらはサービスに間接的な影響を与えます。ネットワーク、API、またはインフラストラクチャレベルのフォールトインジェクションテストによってユーザーのサービスにメリットがある場合は含めてください：

aws fis list-actions --region TARGET_REGION --query 'actions[?starts_with(id, `aws:network:`) || starts_with(id, `aws:fis:inject`) || starts_with(id, `aws:ssm:`) || starts_with(id, `aws:ec2:stop`) || starts_with(id, `aws:ec2:terminate`)].{id:id, description:description}' --output json

横断的なアクションと有用な場面：

• aws:network:disrupt-connectivity — VPC ベースのあらゆるサービスで有用です
• aws:network:disrupt-vpc-endpoint — PrivateLink 経由でアクセスするサービスで有用です
• aws:fis:inject-api-internal-error — AWS API の失敗に対するアプリの処理をテストするのに有用です
• aws:fis:inject-api-throttle-error — バックオフ／再試行ロジックのテストに有用です
• aws:fis:inject-api-unavailable-error — グレースフルデグラデーションのテストに有用です
• aws:ec2:stop-instances / terminate-instances — EC2 上で実行されるサービスで有用です
• aws:ssm:send-command / start-automation-execution — カスタムの障害スクリプトに有用です

横断的なアクションを含めるかどうかは、状況によって異なります：

• 含める：サービスが EC2 上で実行される場合、VPC ネットワークを使用する場合、またはユーザーがインフラストラクチャレベルの障害テストに関心がある場合
• 省略する：ユーザーがサービス固有の障害のみに注目している場合、またはサービスが完全マネージド型で、ユーザーがアクセスできるインフラストラクチャレイヤーがない場合

パス B：AWS CLI が使用できない場合

FIS アクションのリファレンスドキュメントを検索します：

aws___search_documentation(
  search_phrase="AWS FIS actions [SERVICE_NAME] fault injection",
  topics=["reference_documentation"],
  limit=10
)

次に、FIS アクションのリファレンスページを読みます：

aws___read_documentation(
  url="https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html",
  max_length=10000
)

判断ポイント：FIS アクションは見つかりましたか？

見つかったサービス固有のアクション数を数えます（横断的なアクションは除外します）。

• はい（サービス固有のアクションが 1 つ以上見つかった） -> ステップ 4（FIS 拡張パス）に進みます
• いいえ（サービス固有のアクションが 0 件） -> ステップ 5（ドキュメントのみのパス）に進みます

ステップ 4：FIS 拡張パス

FIS に対象サービス用のネイティブアクションがある場合は、シナリオライブラリの調査結果と、FIS アクション固有の詳細を組み合わせます。

4a: FIS アクションをテストシナリオに整理する

各 FIS アクションをテストシナリオに対応付けます。references/output-template.md の「FIS Native Fault Injection Scenarios」テーブル形式を使用します。

重要 — Scenario Library の重複排除（テーブル作成前に必ず適用）： サービスごとのテーブルに FIS アクションを記載する前に、そのアクション ID が Step 2 で特定した Scenario Library の複合シナリオのサブアクションとして登場しているかどうかを確認します。重複のよくある例：

• aws:rds:failover-db-cluster — AZ Power Interruption のサブアクション
• aws:elasticache:replicationgroup-interrupt-az-power — AZ Power Interruption のサブアクション
• aws:eks:pod-network-latency — AZ Application Slowdown のサブアクション
• aws:eks:pod-network-packet-loss — Cross-AZ Traffic Slowdown のサブアクション
• aws:ec2:stop-instances — AZ Power Interruption のサブアクション

ルール：

1. アクションが Scenario Library のサブアクションである場合も、サービスごとのテーブルには記載し、「HA Verification Purpose」列に以下を追記します： 「（{Scenario Name} のサブアクションでもあります。Scenario Library セクションを参照）」
2. サービス固有の FIS アクションがすべて Scenario Library のサブアクションである場合（例： ElastiCache には AZ Power Interruption でカバーされる replicationgroup-interrupt-az-power のみがある場合）、「FIS Native Fault Injection Scenarios」サブセクション全体を省略し、次の内容に置き換えます：

   {SERVICE} の FIS ネイティブアクションはすべて、Scenario Library の複合シナリオでカバーされています。詳細については、Scenario Library and Cross-Cutting セクションを参照してください。

シナリオを障害ドメインごとにグループ化します：

1. Instance/Task Level — 個別リソースの障害
2. Storage Level — ディスク／ボリュームの障害または性能低下
3. Network Level — 接続の中断
4. AZ Level — アベイラビリティーゾーンの障害シミュレーション
5. Region Level — クロスリージョンのフェイルオーバー
6. API/Control Plane — AWS API エラー

Scenario Library との相互参照： 各 FIS アクションについて、Step 2 で特定した Scenario Library の複合シナリオのサブアクションとしても登場するかどうかを確認します。該当する場合は、「HA Verification Purpose」列に注記を追記します（例：「AZ Power Interruption のサブアクションでもあります。Scenario Library セクションを参照」）。サービス固有の FIS アクションがすべて Scenario Library シナリオのサブアクションである場合は、「FIS Native Fault Injection Scenarios」サブセクション全体を省略し、次の注記に置き換えます：「このサービスの FIS ネイティブアクションはすべて、Scenario Library の複合シナリオでカバーされています。Scenario Library and Cross-Cutting セクションを参照してください。」

4b: サービス固有の機能で補強する

一部のサービスには、FIS 以外にも組み込みの障害注入機能があります。次を検索します （順番に実行し、検索結果ページを読む前に検索が完了するのを待ちます）：

aws___search_documentation(
  search_phrase="[SERVICE_NAME] fault injection testing failover simulation",
  topics=["general", "reference_documentation"],
  limit=10
)

見つかった場合は、references/output-template.md のテーブル形式を使用して「Service Built-in Fault Injection」セクションを追加します。

4c: ドキュメントを詳しく調査する

「FIS-Enriched Path」の references/search-queries.md にある検索クエリを使用します。 5 件のクエリをすべて順番に（一度に 1 件ずつ）実行します。検索後、関連性の高い上位 3～5 件のページを1 ページずつ読み、最も関連性の高いページで aws___recommend を使用して情報を探します。複数の read リクエストや recommend リクエストを並行して送信してはいけません。

Step 5: ドキュメントのみのパス（FIS アクションがない場合）

FIS に対象サービスのネイティブアクションがない場合は、包括的なドキュメント調査に切り替えます。Step 2 の Scenario Library の調査結果は引き続き適用されます。

5a: ドキュメントを詳しく検索する

「Documentation-Only Path」の references/search-queries.md にある検索クエリを使用します。 6 件のクエリをすべて順番に（一度に 1 件ずつ、それぞれの完了を待って）実行します。

5b：主要なページを読み、関連コンテンツを見つける

統合した検索結果から、references/search-queries.md の優先順位に従って、関連性の高い上位5ページを読みます。ページは一度に1ページずつ読み、次の aws___read_documentation 呼び出しは、前の呼び出しが完了するまで待ってから実行してください。次に、サービスのメインドキュメントページで aws___recommend を使い、関連コンテンツを見つけます。

すべてのページから、以下を抽出します。

• サービスで発生し得る障害モード
• 組み込みのHAメカニズム（自動フェイルオーバー、レプリケーションなど）
• 公式ガイドに記載されているテスト手法
• テスト中に確認すべきモニタリング項目／メトリクス

5c：代替テスト手法をまとめる

references/output-template.md の「Testing Methods (No Native FIS Actions)」セクションの形式を使用し、間接的なFISアクションとAWS API／コンソールの手法を両方含めます。

ステップ6：出力をまとめ、ローカルファイルに保存する

レポートの全文をターミナルに出力する代わりに、ローカルのMarkdownファイルに直接書き込みます。以下のファイル命名規則を使用してください。

TIMESTAMP=$(TZ=Asia/Shanghai date +%Y-%m-%d-%H-%M-%S)
SERVICE_SLUG=$(echo "{SERVICE_NAME}" | tr '[:upper:]' '[:lower:]' | tr ' :/' '-')
# File name: ${TIMESTAMP}-${SERVICE_SLUG}-chaos-research.md

複数のサービスを対象とする場合は、サービスごとに1つのファイルを生成します。

• ${TIMESTAMP}-rds-chaos-research.md
• ${TIMESTAMP}-eks-chaos-research.md
• など

references/output-template.md で定義されている正確な形式に従ってレポートの内容をまとめ、ファイルに保存します。レポートには、以下のセクションをこの順序で含めます。

1. エグゼクティブサマリー — リージョン、FISのサポート状況、主要な推奨事項の概要
2. シナリオライブラリと横断的な項目 — シナリオライブラリの複合シナリオを最優先し、横断的なアクションは任意の補足として記載します。このセクションはサービスごとのセクションより前に配置します。
3. サービスごとのセクション — 各セクションに、FISシナリオ（{SVC}-# のテストIDを使用。例：EKS-1、Redis-1）、組み込みの手法、推奨テストシナリオのマトリックス、環境に関する所見、中止条件を含めます。
4. 推奨テスト優先順位（統合版） — サービスごとのセクションにあるテストIDを参照します。説明全文を重複して記載しないでください。同じ表のシナリオライブラリシナリオですでに扱われている場合は、FISアクションを別途記載しないでください。
5. 実装のベストプラクティス — 定常状態、DNS／接続、影響範囲
6. 参考資料 — 実際の検索結果または閲覧したページに含まれるURLのみ
7. 次のステップ — 実行可能な次のステップを3～4件

保存後、ターミナルには簡潔な概要を出力し、以下のみを記載します。

• 生成したレポートのファイルパス
• 対象サービスとリージョン
• 見つかったFISアクションの数（サービス固有と横断的なもの）
• 特定したシナリオライブラリシナリオの数
• 推奨テスト優先順位の上位3項目

重要なガイドライン

• 必ず最初にシナリオライブラリを確認します。 FIS シナリオライブラリは、AWS が独自に選定したレジリエンステストのシナリオです。ほかのことを始める前に、必ず最新のシナリオライブラリのドキュメントを読みます。これらはドキュメントベース（コンソール専用）であり、CLI からクエリすることはできません。
• リージョンは重要です。 FIS アクションをクエリする前に、必ず対象リージョンを特定します。FIS アクションの利用可否はリージョンによって異なります。AWS CLI には必ず --region を指定し、出力ではリージョンを明記します。
• FIS アクションをでっち上げないでください。 アクションが存在しない場合は、その旨を明確に伝えます。フォールバック手順は、FIS が対応していないサービスのために用意されています。
• リンクをでっち上げないでください。 実際の検索結果、または参照した既知のドキュメントページにある URL のみを含めます。
• サービスを具体的に示します。 すべての推奨事項で、対象となる特定のサービス、その HA メカニズム、および具体的なメトリクスに言及します。
• 複数のサービスにまたがるアクションは補足情報として任意です。 価値がある場合は含めますが、まずはサービス固有のアクションとシナリオライブラリのシナリオに焦点を当てます。
• ドキュメント調査には AWS Knowledge MCP のみを使用します。 SearXNG やその他のウェブ検索は使用しないでください。aws___search_documentation、aws___read_documentation、aws___recommend を使用します。
• 複数のトピックを検索します。 異なる topics 値（general、reference_documentation、troubleshooting）を順に使用します。
• 関連情報の発見には aws___recommend を使用します。 重要なページを読んだ後に aws___recommend を呼び出し、キーワード検索では見つからない関連コンテンツを探します。
• MCP リクエストを並列で送信しないでください。 aws___search_documentation、aws___read_documentation、aws___recommend の呼び出しは、すべて必ず一度に 1 つずつ実行します。次のリクエストを送信する前に、各リクエストの応答を待ちます。並列呼び出しを行うと、aws-knowledge-mcp-server で「Too many requests」エラーが発生します。これは失敗の最も一般的な原因です。すべての手順で必ず徹底してください。
• 失敗した場合は最大 10 回まで再試行します。 MCP 呼び出しがレート制限または一時的なエラーで失敗した場合は、5 秒待ってから再試行します。スキップする前に最大 10 回まで繰り返します。
• 言語に従います。 出力はユーザーとの会話と同じ言語にします。