【セッションレポート】AWS におけるグレー障害の検出と対策（AWS-50） #AWSSummit

こんにちは。たかやまです。

2025年6月25-26に開催されたAWS Summit Japan 2025の「AWS におけるグレー障害の検出と対策」のレポートをお伝えします。

動画も公開されましたので、ぜひご覧ください！（要登録）

• AWS におけるグレー障害の検出と対策 | 動画

セッション概要

タイトル : AWS におけるグレー障害の検出と対策

グレー障害は、クラウド環境でアプリケーションのパフォーマンスに微妙な影響を与えることが多い、検出が困難な障害です。これらの障害は、システムの全体的なダウンタイムにはつながらないかもしれませんが、ユーザーエクスペリエンスの低下や潜在的なデータ損失につながる可能性があります。このセッションでは、グレー障害の特性と AWS 環境での一般的な発生シナリオを紹介します。さらに、グレー障害を効果的に検出するための技術と戦略を紹介し、Amazon CloudWatch の Contributor Insights、および複合アラームの使用方法について掘り下げます。また、グレー障害に対処するためのアプローチ、特に Application Recovery Controller を使用した Availability Zone の退避について解説します。

スピーカー :
安藤 麻衣

セッションレベル : 300

レポート内容

セッションの対象者とゴール

対象者

• リージョン、アベイラビリティゾーン、Amazon CloudWatch などの基本的知識をお持ちの方
• ユーザー体験を重視したサービス運用に携わる方
• システムの可用性とサービス品質の向上に関心のある方

ゴール

• グレー障害の特徴と影響について理解する
• グレー障害の検出方法や対応手段、障害対応訓練の方法を学ぶ

グレー障害の定義と発生シナリオ

気づきづらいユーザー体験の低下

• あるECサイトで一部のユーザーのみカート操作が失敗
• テストユーザーでは正常であり、運用チームによる動作確認では問題を再現できない
• アプリは一見正常だが、ユーザーに影響を与えている可能性がある

グレー障害とは

完全な停止ではないが、サービスの質が低下しているECサイトの例

例：User1が70ms、User2が53ms、User3が56msのレスポンス時間の場合

• 平均レイテンシー：59.66ms（閾値60ms以下で正常）
• レイテンシー閾値：60ms
• User1のみ閾値を超えているが、平均値では問題として検出されない
• ユーザーとしては明らかに影響が出ている状況

視点別のObservability

• システムの状態は誰がどこから見ているかによって異なるように見える
• 見る視点で4つの事象に分類できる
  • ALL GOOD：すべての視点で正常な状態
  • GRAY FAILURE（グレー障害）：システム全体としては正常に見えるが、一部のユーザーやアプリケーションで問題が発生
  • DETECTED FAILURE：システムとして問題を検知できている状態
  • MASKED FAILURE：問題はあるがユーザーは検知できていない状態

重要なのは、これらの認識が時間の経過とともに遷移することです。例えば、MASKED FAILUREから始まった問題が、やがてユーザーに影響が出てGRAY FAILUREに変化します。またはシステムが問題を検知してDETECTED FAILUREに移行します。

グレー障害の代表的なパターン

• 特定インスタンスで発生する部分的な障害
  • Auto Scaling Group内の複数インスタンスのうち、1台で断続的な遅延が発生
  • 他のインスタンスは正常に動作している
  • 問題のあるインスタンスでもALBのヘルスチェックは通過している
  • 失敗しているのは一部のリクエストのみ
    • 商品一覧表示：○（正常）
    • カート追加：×（失敗）
    • 注文処理：×（失敗）
• AZレベルでの品質低下
  • 特定AZ内のすべてのインスタンスで問題が発生している
  • 他のAZでは正常に動作している
  • ユーザーはリクエストの半数が遅延やエラーになる
  • 特定のAZで発生するEC2のネットワーク品質低下により、そのAZで稼働するインスタンスからデータベースへの接続が断続的に遅延
  • ALBのヘルスチェックは通過している

ヘルスチェックでは検知できないのか

前提としてヘルスチェックには2種類のチェックパターンがある。

• シャローヘルスチェック
  • サーバーとアプリケーションの状態を確認
  • TCP接続確認、HTTP 200応答確認、EC2ステータスチェック
  • 外部依存関係はチェックしない
  • 基本的な生存確認のみ
• ディープヘルスチェック
  • サーバーの状態に加え、外部依存関係も確認
  • DBへのクエリ実行やS3アクセスなども含む
  • エンドツーエンドでの機能確認が可能
  • 依存関係の問題について過剰に検知
  • 本来問題ないケースでもアラートが発生する可能性

その上で、ヘルスチェックで検出できないグレー障害のパターンは以下のようになる。

ヘルスチェックで検出できない小さなエラーの例

• あるサーバーでのエラーレート4%
• 3回連続でヘルスチェックが失敗したらアラームを発行
• 3回連続で失敗する確率は0.0064%（4% × 4% × 4% = 0.0064%）

この例では、リクエストの4%に問題が起きているが検出できず、サービス品質低下が発生している状況を示しています。エラー率が低い場合、連続してヘルスチェックが失敗する確率は非常に低くなるため、従来のヘルスチェックでは検出が困難になります。

グレー障害の検出

見えづらい問題をどう検出するか

• ヘルスチェックのような基本的な監視ではグレー障害を洗い出せない問題
• CloudWatchを活用したグレー障害の検出が重要

ここからはCloudWatchを活用したContributor Insightsと複合アラームの活用について解説になります。

Contributor Insightsの活用

Contributor Insightsの紹介の前にディメンションの概念について

• ディメンションは、メトリクスを分類するためのラベル（InstanceID等）
• ディメンションには、障害分離境界（AZ-ID等）やビジネスコンテキスト（CustomerID等）を含めることができる
• EMF（Embedded Metric Format）を使用することでログデータに直接メトリクスを埋め込むことが可能
• EMFのディメンション設定例：
  • ["AZ-ID", "CustomerID", "Region"]
  • ["AZ-ID", "Region"]
• CustomerIDのような高カーディナリティな（値の種類が非常に多い）ディメンションをどう分析するかが課題

高カーディナリティデータの分析に活用できるのがContributor Insights

• Contributor Insightsを使用することで、膨大な数の要素から重要な情報を抽出
• CloudWatch Logsの時系列データに対する上位Nのコントリビューターの分析を簡素化
• システムとアプリケーションのパフォーマンスに影響を与えている人またはものをリアルタイムに確認
• グラフ化やアラームの設定も可能
• ユースケース例
  • エラーを最も多く返すAPI/インスタンス
  • 特定のステータスコードが頻出するURL

高レイテンシーユーザーを特定する例として以下のような設定をすることで、「特定のユーザーまたは特定のインスタンスでレイテンシーが60秒を超えていないか」チェック可能

複合アラーム

• 複数のアラームの状態を組み合わせて監視
• 特定の条件の組み合わせが満たされた場合にのみアクションを実行
• AND / OR / NOT というシンプルなアラームロジックで設定
• 連携先
  • Amazon SNS
  • AWS Lambda
  • OpsCenter
  • Incident Manager
  • AWS Systems Manager

複合アラームの例

• AZ1とAZ2でAZレベルでの障害を検知
• 複合アラームを応用して特定AZの問題を検出
• AZ固有の問題を効果的に検出する方法

AZ 1で複数のインスタンスに障害が発生して、AZ 2では正常に動作している場合を検知する複合アラームの例

グレー障害への対応

グレー障害への対応の選択肢

グレー障害が発生した際の対応方法は複数あり、状況に応じて適切な手法を選択する必要があります。

対応手法	インスタンス単位	アプリケーション	ロケーション切り替え
特徴	比較的シンプルな実施手順 効果は該当リソースに限定	事前の実装と設計が必要 より柔軟な対応が可能	物理的な問題から完全な退避が可能 広範な問題に有効
実装例	インスタンスの再起動 新規インスタンスへの置き換え	グレイスフルデグラデーション サーキットブレーカー エクスポネンシャルバックオフによるリトライ等	AZのシフト リージョンフェイルオーバー

インスタンス単位の対応

• メモリリーク、CPU障害、ネットワーク問題などのインスタンス単位の障害に有効
• 新しいインスタンスに置き換えることで、解消する可能性もある
• 一方で以下に注意
  • AZ全体に影響が出ているような場合には適していない
  • 新しいインスタンス起動と初期化に時間がかかる

アプリケーションレベルでの対応

一例としてここではグレイスフルデグラデーションの実装について紹介されています。

• アプリケーションでの設定が必要だが、柔軟に対応できる
• 一部のコンポーネントが停止しても、システム全体は停止することはないように実装する
• 例として、ECサイトの主要機能は利用できるようにし、おすすめ情報などの表示されなくても問題ないサービスは機能制限するような実装が考えられる
• Amazonでもグレイスフルデグラデーションを活用している

ロケーション切り替え

ここはスピーカーの方が特にセッションとして特におさえて欲しい内容としていました。

アプローチしてのアベイラビリティゾーンの切り離し

• 問題のあるAZを一時的に切り離す
• 早急に影響回避できる効果的な手法

一方でアベイラビリティゾーンの切り離しをする際には、アベイラビリティゾーンの独立性（AZI）に注意が必要です。

• 異なるAZ間の不要な通信を防ぎ、AZ内でリソースの利用を完結させる必要がある
• AZ間のデータ転送による遅延とコストを最小限に
• AZ障害等の際、影響を受けているAZからの退避を可能にする

より詳細なAZIを実現する上での考慮点として、ELBクロスゾーン負荷分散とデータベースについて紹介されています。

• ELBのクロスゾーン負荷分散

  • 複数のAZ間でトラフィックを均等に分散する
  • デフォルトでALBは有効、NLBは無効
  • AZの独立性を重視する場合、クロスゾーン負荷分散を無効にすることで各AZ内でトラフィックが完結

• クロスゾーン負荷分散を無効にすると、各AZに均等にトラフィックが分配

• AZ間のインスタンスが不均衡な場合、インスタンス数の少ないAZのリソースに負荷

• 負荷分散の例

  • AZが2つの場合、トラフィックは50:50で分配
  • AZ1の各インスタンスは25%の負荷を受け、AZ2の各インスタンスは10%の負荷を受ける
  • 負荷のバランスを考慮して、インスタンスを配置する必要がある

• データベースの課題

  • 各AZのリードレプリカを適切に活用する
  • RDBの基本的な制約
    • ほとんどのRDBは1つのプライマリライターのみをサポート
    • プライマリインスタンスとの通信時にAZの境界を越える必要がある
    • RDS/AuroraではマルチAZフェイルオーバー機能を提供
  • リードレプリカの配置戦略
    • 各AZにリードレプリカを配置し、AZ内のレプリカエンドポイントを使用
    • どのAZのレプリカエンドポイントを使用するかはアプリケーション側で判断
    • AZ IDをデータベース識別子に含める（例：az3-read-replica.cbkdgoeute4n.us-east-1.rds.amazonaws.com）
    • AWS Cloud Mapを使用したサービス検出やAZマッピング情報を保存して参照
  • Auroraでの対策
    • ANYタイプのカスタムエンドポイントを各レプリカに設定
    • 必要に応じてレプリカをプライマリに昇格
    • カスタムエンドポイントにはAZ IDに基づいた名前をつける
    • 例：use1-az1.cluster-custom-123456789012.us-east-1-rds.amazonaws.com

Amazon Application Recovery Controller (ARC)の活用

• ARCを利用してAZ切り離しが可能

• 重要なポイントとして切り離された時に対応できるようオーバープロビジョニングが必要

  • 1つのAZで障害が発生しても残りのAZで負荷を処理できるよう、事前に十分な容量をプロビジョニング
  • 3つのAZを使用する場合の設計例
    • 各AZは通常負荷の66%で動作するようにオーバープロビジョニング
    • アプリケーションに6インスタンスが必要な場合、各AZに3インスタンス（計9インスタンス）を配置
    • 1つのAZがダウンしても、残りのAZで合計6インスタンスを維持可能

• ゾーンシフトの実行判断基準

  • すぐにゾーンシフトするべきか
    • 感覚的な判断ではなくSLA/SLIに従って実行
  • ゾーンオートシフトの活用
    • ユーザー側で明示的な設定が必要
    • （自動化された対応に不安を感じる部分も...選択肢として覚えておくとよさそう）

障害対応の訓練

AWS Fault Injection Simulator (FIS)を使った実験

FISを使った実験の流れは以下の通り

• シナリオライブラリの活用
  • FISでは事前にアプリケーションの耐障害性をテストするために適用できるイベントが定義されたシナリオライブラリが用意されている
  • AZ Availability Power interruptionではAZ電源障害の状況をシミュレートできる
• FISの復旧アクション
  • aws:arc:start-zonal-autoshiftという復旧アクションが提供されている
  • 特定のAZからのトラフィックシフトをシミュレートすることが可能
  • FISがARCのAPIを使用してリクエストを送りゾーンシフトが開始
  • AZ Availability Power Interruptionシナリオにも含まれる
• SSMドキュメントでグレー障害シミュレート
  • SSM Agentがインストールされたインスタンスで実行可能
  • グレー障害をシミュレートできるSSMドキュメントアクションの例：
    • AWSFIS-Run-Network-Latency-Sources：特定ソースとの通信にネットワークレイテンシーとジッターを追加
    • AWSFIS-Run-Network-Packet-Loss-Sources：特定ソースとの通信にパケットロスを発生
  • ドキュメントパラメータで調整可能
    • DelayMilliseconds：遅延（ミリ秒）
    • JitterMilliseconds：ジッター（ミリ秒）

レジリエンス文化の醸成

• 障害訓練は特別なイベントではなく、日常的な活動として組織に定着させる
• 障害訓練は技術チームだけでなく、プロダクトオーナーや事業部門など実際の障害時に判断を求められる関係者も含めて実施

最後に

私自身グレー障害というものを深く意識したことが正直なかったので、このセッションは非常に参考になりました。

特にELBのクロスゾーン負荷分散の部分については、これまでは「とりあえず有効化」と単純に考えていましたが、グレー障害の文脈では必ずしもそうではないことを学びました。

具体的な設定解説も多く、実際の運用設計にも役立つ内容だったと思います。

過去 re:Invent でもグレー障害についてのセッションがありました。
そちらについてこちらのブログでセッションレポートになっていますので、併せてご覧ください。

• グレー障害について理解を深める Detecting and mitigating gray failures #ARC310 #AWSreInvent | DevelopersIO

以上、たかやま(@nyan_kotaroo)でした。