本番環境でのカオスエンジニアリングとブラストラディウス制御
オンラインゲームを運営する企業が、Amazon EKS 上のマッチメイキングサービスを 3 つのアベイラビリティーゾーンで稼働させています。設計上は 1 ゾーンの障害に耐えられるはずですが、実際にゾーン障害が起きた際にオートスケールと接続のフェイルオーバーが期待どおり動作するか検証されていません。運用チームは本番環境でゲームデーを実施したいと考えていますが、実験によって顧客影響が拡大した場合は即座に実験を停止したいと考えています。この要件に最も適した方法はどれですか。
解説を読む（正解: D）
カオスエンジニアリングの要点は、障害を意図的に注入して仮説を検証すると同時に、影響範囲 (ブラストラディウス) を制御し、危険な兆候が出たら即座に実験を打ち切れることです。AWS Fault Injection Service (FIS) はこの両方をマネージドに提供します。実験テンプレートでは、どのリソースにどの障害アクションを適用するかをターゲットとアクションで宣言し、アベイラビリティーゾーンの停電を模擬するようなシナリオも実行できます。さらに停止条件として CloudWatch アラームを指定でき、エラー率やレイテンシーが閾値を超えるとアラーム状態を検知して実験が自動的に停止し、注入された障害が巻き戻されます。実験の実行は CloudTrail に記録され、IAM で権限も制御できます。よって D が正解です。A は障害注入自体は可能ですが、自動停止も自動巻き戻しもなく、人手の監視に依存するため本番環境での実施はリスクが高すぎます。B は設定変更による擬似的な障害であり、実際のゾーン障害で起こる接続断や API 呼び出しの失敗を再現できず、手作業での切り戻しは復旧遅延を招きます。C の Well-Architected Tool は設計上のギャップを机上で洗い出す有用なレビュー手法ですが、実際の挙動を検証する障害シナリオ演習の代替にはなりません。
障害注入実験の自動実行と自動中止
請求管理 SaaS を提供する企業が、Amazon ECS on AWS Fargate のサービス群と Aurora PostgreSQL クラスターを 3 つのアベイラビリティーゾーンに配置しています。信頼性チームは四半期に一度、担当者が手書きのスクリプトでタスクを落とすゲームデーを実施していますが、手順に再現性がなく、実験中に顧客影響が出ても気付くのが遅れるという問題を抱えています。今後は AZ 障害やタスク停止のシナリオを毎週スケジュール実行し、事前に定義したエラー率やレイテンシーのしきい値を超えた時点で実験を即座に中止したいと考えています。運用負荷を最小限に抑えてこれを実現する方法はどれですか。
解説を読む（正解: A）
カオスエンジニアリングは、あらかじめ定義した障害を制御された形で注入し、システムが想定どおりに回復するかを本番に近い条件で検証する手法です。AWS Fault Injection Service (AWS FIS) はこの実験をマネージドに実行するサービスで、実験テンプレートに「どのリソースに」「どの障害アクションを」「どの順序で」注入するかを宣言的に定義できます。最大の特徴が停止条件 (ストップコンディション) で、CloudWatch アラームを関連付けておくと、そのアラームが ALARM 状態になった瞬間に FIS が実験を自動的に中止し、注入中の障害を巻き戻します。したがって A は、AZ 障害や ECS タスク停止のシナリオを再現性のあるテンプレートとして資産化でき、エラー率やレイテンシーのしきい値超過を検知した時点で自動停止できるため、要件を過不足なく満たします。EventBridge Scheduler から実験を開始すれば、週次実行のためのサーバーも不要です。B は自作スクリプトの保守が必要なうえ、中止の判断が人間の目視に依存するため「しきい値超過で即座に中止」という要件を満たせず、運用負荷もむしろ増えます。C の AWS Config はリソース構成が準拠しているかを評価する仕組みであり、障害を注入して回復性を検証する目的には使えません。D はタスク数を 0 にするだけで AZ 障害時の挙動を再現できず、CloudFormation のロールバックは即時性が保証されないため、実験の自動中止機構としては機能しません。
アベイラビリティーゾーン障害の回復性を安全に検証する
人事管理 SaaS を 3 つのアベイラビリティーゾーンにまたがる Application Load Balancer、EC2 Auto Scaling グループ、Amazon Aurora で運用しています。設計上は 1 つの AZ が全損しても稼働し続けるはずですが、実際に検証したことは一度もありません。四半期ごとのゲームデーで、本番と同一構成のステージング環境に対して「特定 AZ のインスタンス群が同時に到達不能になる」状況を再現し、Auto Scaling の補充と Aurora のフェイルオーバーの挙動を計測したいと考えています。ただし、影響が想定を超えて拡大した場合には、あらかじめ定義した条件で実験を即座に中断し、元の状態へ戻せることが必須です。最も適切なアプローチはどれですか。
解説を読む（正解: A）
AWS Fault Injection Service (FIS) は、カオスエンジニアリングの実験を安全かつ再現可能に実施するためのマネージドサービスです。実験テンプレートには、注入する障害の種類 (インスタンスの停止や終了、AZ 単位のネットワーク到達不能化、API のエラー / スロットリング注入、Aurora のフェイルオーバー誘発など) を表すアクション、対象リソースを絞り込むターゲット、そして CloudWatch アラームに紐付いた停止条件を宣言的に定義します。実験の実行中にアラームが ALARM 状態になると FIS は直ちに実験を停止して注入した障害を元に戻すため、影響の拡大を機械的に抑止できます。実験の実行権限は IAM で制御でき、実行履歴も残るため、監査可能なゲームデーの土台になります。したがって A が要件を満たします。B の手作業によるインスタンス一括終了には自動的な停止条件がなく、影響範囲の制御も再現性もありません。C のネットワーク ACL 変更でも擬似的な遮断は可能ですが、中断の判断と操作がすべて人手に依存するため反応が遅れ、ルールの消し忘れという運用リスクを抱えるうえ、Aurora の内部フェイルオーバーを狙って誘発することもできません。D は負荷試験であり、AZ 障害時の回復性を検証するものではないため、そもそも目的が異なります。