Amazon DOP-C02: 高可用性、レジリエンス、災害復旧 — 学習ガイド

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS DevOps Engineer Professional DOP-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

AWSにおける高可用性と災害復旧は、コンポーネント、アベイラビリティーゾーン (AZ)、またはリージョンレベルの障害発生時におけるダウンタイム (RTO) とデータ損失 (RPO) を削減することに重点を置いています。マルチAZ設計は、データ損失なし、かつサービスへの影響を最小限に抑えながらAZ障害を吸収します。一方、マルチリージョン設計は、リージョン規模の障害や大規模イベントに対応します。アクティブ/アクティブ、アクティブ/パッシブ (ウォームスタンバイ)、パイロットライトといった戦略の選択は、ビジネス上のRTO/RPO目標、一貫性の要件、およびコストによって決まります。これらの目標を達成するには、DNSルーティング、コンピューティングの伸縮性、ロードバランシング、データベースのレプリケーション/フェイルオーバー、レプリケーション/バージョニングを備えた耐久性の高いオブジェクトストレージ、集中バックアップ、そして障害注入による継続的な耐障害性検証にわたる、一貫した設計が必要です。

RTO/RPOとインテリジェントルーティングのためのアーキテクチャ

マルチAZとマルチリージョン:

• マルチAZ: ロードバランサーの背後にある異なるAZの少なくとも2つのサブネットに、冗長化されたインスタンスを配置します。同期レプリケーションを備えたマネージドデータベース (RDS Multi-AZ, Aurora Multi-AZ/クラスター) を使用します。同期ストレージの場合、RPOは通常ゼロです。RTO目標は、数分未満 (Aurora) から数分 (RDS Single-Instance Multi-AZのフェイルオーバー) の範囲です。
• マルチリージョン: リージョン間の分離と低レイテンシーで最小のRTOを実現するアクティブ/アクティブ、またはコスト最適化されたDRのためのウォームスタンバイ/パイロットライトを選択します。データレプリケーションはRPOを満たす必要があります。例えば、非同期DBレプリカ、Aurora Global Database (一般的なRPOは1秒未満)、DynamoDBグローバルテーブル (マルチリージョン、マルチアクティブ)、およびSLAで保証されたレプリケーションのためのオプションのReplication Time Control (RTC) を備えたS3クロスリージョンレプリケーション (CRR) などです。

Route 53のルーティングポリシーとヘルスチェック:

• フェイルオーバールーティング: 同じ名前に対してプライマリとセカンダリの2つのレコードを作成します。プライマリにヘルスチェックを関連付けるか、ALB/NLBへのエイリアスの場合は「Evaluate Target Health (ターゲットの正常性を評価)」を使用します。障害発生時、トラフィックはセカンダリに切り替わります。DNSキャッシュの遅延を減らすためにTTLを低く (例: 60秒) 保ち、ヘルスチェックのステータスをCloudWatchアラームで監視します。
• レイテンシーベースルーティング: 測定されたレイテンシーが最も低いリージョンにユーザーをルーティングします。各レコードにヘルスチェックを関連付け、正常なエンドポイントのみがトラフィックを受信するようにします。必要に応じて結果整合性/強い整合性をサポートするマルチリージョンスタックおよびリージョンデータストアと組み合わせます。
• 加重ルーティング: カナリアリリース、A/Bテスト、または「トリクル」方式のDR準備 (例: 継続的に1%をセカンダリへ) をサポートするために、トラフィックをパーセンテージで分割します。ヘルスチェックと組み合わせることで、異常な重み付けが除外されるようにします。リージョンからの退避中にトラフィックを移行するために、徐々に重み付けをシフトさせます。
• ヘルスチェック: HTTP(S)/TCPエンドポイントまたはCloudWatchアラームを監視します。ALB/NLBエイリアスの場合、「Evaluate Target Health (ターゲットの正常性を評価)」を有効にして、ターゲットグループの正常性を継承します。ヘルスチェックのエンドポイントは、真の準備状態 (依存関係への到達可能性、マイグレーションの適用状況など) を反映するように設計します。ステートフルなアプリケーションでは、部分的にしか正常でないインスタンスへのルーティングを避けるため、依存関係 (データベース、キャッシュ) のチェックを含めます。

目標別の耐障害性パターン:

• 低RPO、グローバルで数分未満のRTO: Route 53のレイテンシーベースルーティングとヘルスチェックを使用したアクティブ/アクティブ構成、リージョンローカルのステートレスコンピューティング、DynamoDBグローバルテーブルまたはAurora Global Database、重要なオブジェクトに対するRTC付きのS3 CRR。
• 中程度のRPO (15分以下)、RTO 4時間以下: スケールダウンしたセカンダリを持つウォームスタンバイ、非同期DBレプリカ (RDSクロスリージョンリードレプリカまたはAurora Global)、Route 53フェイルオーバールーティング、フェイルオーバー時にスケールアップして昇格させるためのランブックまたは自動化。
• コスト最適化されたDR: コアデータサービスのみのパイロットライト、呼び出し時にアプリケーション層をスケールアウトするためのInfrastructure as Code、RPOはレプリケーションの頻度によって決定、RTOはプロビジョニング時間とデータのキャッチアップによって決定。

Elastic Load BalancingとAuto Scaling

Elastic Load Balancing:

• Application Load Balancer (ALB): レイヤー7、ホスト/パスベースのルーティング、WebSocket/HTTP/2、統合されたWAF、ターゲットグループのCookieによるスティッキネス、リクエストベースのヘルスチェック。スケールインやデプロイ中にターゲットを正常にドレイン（切り離し）するために、クロスゾーン負荷分散と登録解除の遅延（コネクションドレイニング）を使用します。バックエンドのウォームアップが不均一な場合に備え、スロースタートと外れ値検出を設定します。
• Network Load Balancer (NLB): レイヤー4、超低レイテンシー、静的IP/Elastic IP、TLSパススルー/終端、送信元IPの維持、長寿命接続のサポート。TCP/UDPプロトコル、高スループットのワークロード、またはクライアントIPの可視性が必須の場合に使用します。ヘルスチェックは、設定に応じてレイヤー4/7でTCP/HTTP/HTTPSを使用します。
• コネクションドレイニング（登録解除の遅延）: 処理中のリクエストが完了できるように、適切な遅延（例: 60～300秒）を設定します。ユーザーの中断を避けるため、デプロイやAuto Scalingの終了イベントがこの遅延を尊重するようにします。

Auto Scalingグループ:

• スケーリングポリシー:
  • ターゲット追跡スケーリング: メトリクス（CPUUtilization、ALB RequestCountPerTarget）をターゲット値に維持します。これはWeb/APIフリートにとって最もシンプルで適応性の高いポリシーです。
  • ステップスケーリング: メトリクスがしきい値を超えたときに、定義されたステップでスケールします。予測可能なパターンのバーストトラフィックに役立ちます。
  • スケジュールされたスケーリング: 既知のイベント（セール、ローンチなど）に備えて事前にスケールし、コールドキャパシティを回避します。
  • 予測スケーリング: オプションで、日次/週次のパターンに対してMLを使用して需要を予測します。
• ライフサイクルフック: Launching:WaitとTerminating:Waitにより、インスタンスの準備完了と終了処理をゲート（一時停止）できます。フックを使用して以下を実行します:
  • インスタンスがサービスインする前にブートストラップ（SSM Automation、ユーザーデータの完了、AMIのハイドレーション）します。
  • 根本原因分析のために、終了前にログやアーティファクトを収集します。
  • 準備完了シグナル（例: cfn-signal）の確認が必要な、ブルー/グリーンまたはインプレースデプロイメントを調整します。
• ウォームプール: スケールアウトのレイテンシーを大幅に削減するために、ASGにアタッチされた状態で、事前に初期化されたインスタンスを停止（Stopped）または実行中（Running）の状態に保ちます。ウォームプールは、時間のかかるブートストラップステップ（大規模なパッケージのインストール、モデルのダウンロードなど）と相性が良いです。最小ウォームキャパシティと再利用ポリシーを設定します。ライフサイクルフックのLaunching:Waitと組み合わせ、アプリの準備完了チェックが成功した場合にのみフックを完了させることで、一貫したカットオーバー時間を確保します。
• 耐障害性の設定: スポットインスタンスのためのキャパシティの再分散、複数のインスタンスタイプ/割り当て戦略、ターゲットグループのヘルスと連動したヘルスチェック、およびヘルスガードレール付きの安全なローリングアップデートのためのインスタンスの更新を有効にします。

データ層の耐障害性、レプリケーション、バックアップ

リレーショナルデータベース:

• RDS Multi-AZ: 異なるAZのスタンバイに同期レプリケーション。自動フェイルオーバーにより、DNSエンドポイントがスタンバイに更新されます。これにより、AZ障害やインスタンス障害から保護され、RPO ≈ 0、RTOは通常数分です（Multi-AZスタンバイを持つSingle-AZ DBインスタンスの場合）。新しいMySQL/PostgreSQL向けのMulti-AZ DBクラスターは、複数の読み取り可能なスタンバイを持ち、より高速なフェイルオーバーを提供します。
• リードレプリカ: 読み取りスケーリングとDRのための非同期レプリケーション。DRにはクロスリージョンリードレプリカを使用します。昇格は手動（またはランブック/サーバーレス関数で自動化）で、RPO > 0が発生します。binlogまたは論理レプリケーションが正しく設定され、レプリケーションラグが監視されていることを確認します。
• Aurora: Aurora Multi-AZ（クラスター）は、複数のAZにレプリカを持つ共有ストレージを使用します。フェイルオーバーは通常1分未満です。Aurora Global Databaseは、ストレージベースの物理レプリケーションをセカンダリリージョンに提供し、一般的なRPOは1秒未満、RTOは1分未満です。データ損失ゼロの移行にはマネージド計画フェイルオーバーを、災害イベントには計画外フェイルオーバーを使用します。ライター/リーダーエンドポイントがトポロジーを抽象化します。アプリケーションはバックオフ付きのリトライを実装する必要があります。

オブジェクトストレージとDR:

• S3バージョニング: 上書き/削除から保護し、CRRをサポートするためにバージョニングを有効にします。ライフサイクルポリシーを設定して、古いバージョンをより安価なストレージに移行し、適切な保持期間を設定します。
• S3 Cross-Region Replication (CRR): 送信元と送信先の両方でバージョニングが必要です。レプリケーション用のIAMロールを使用します。バケットがクロスアカウントの場合、送信先バケットポリシーに、送信元ロールにs3:ObjectOwnerOverrideToBucketOwnerとput権限を許可する設定を追加します。KMSで暗号化されたオブジェクトの場合、ロールに送信元キーでのkms:Decryptと送信先キーでのkms:Encryptを許可します。以下の点を考慮します:
  • 99.9%のオブジェクトを15分以内にレプリケートするためのReplication Time Control (RTC)と、そのメトリクス/アラート。
  • 必要に応じた削除マーカーのレプリケーションと所有権の制御。
  • 既存オブジェクトのためのS3 Batch Replication。
  • SLAのためのレプリケーションメトリクスと通知。
• DynamoDB: マルチリージョン/マルチライターの低レイテンシーと高可用性のためにグローバルテーブルを使用します。または、リカバリのためにPITRとオンデマンドバックアップを有効にします。

AWS Backupによる集中バックアップ:

• バックアッププラン: スケジュール（CRON）、バックアップウィンドウ、ライフサイクル（コールドストレージへの移行、保持期間）、および他のリージョン/アカウントへのコピアクションを定義します。ポリシー主導のカバレッジのために、タグまたはARNでリソースを割り当てます。
• バックアップボールト: 独立したKMS暗号化キーとアクセスポリシーを持つ論理的なコンテナ。WORM（Write-Once, Read-Many）の不変性とランサムウェア耐性のある体制のために、AWS Backup Vault Lockを有効にします。影響範囲（ブラスト半径）を縮小するために、クロスアカウントのボールトコピーを使用します。
• クロスアカウントバックアップ: Organizationsでは、一貫したガバナンスのためにメンバーアカウントにバックアップポリシーを適用します。中央のバックアップアカウントからのコピー/リストアを許可するように、ボールトのアクセスポリシーを設定します。RTOを測定し、ランブックを検証するために、自動化されたリストア訓練を定期的に実行します。
• 統合: EBS、EC2、RDS/Aurora、DynamoDB、EFS、FSxなどを保護します。スケジュールと保持期間を規制上のRPO/RTOに合わせ、必要に応じてアプリケーション整合性のある静止（SSMの事前/事後スクリプト）と調整します。

カオスエンジニアリングとAWS Fault Injection Simulator (FIS)

カオス実験は、HA (高可用性) およびDR (災害復旧) のメカニズムが設計どおりに動作することを検証します。AWS FISは、ガードレールを備えた制御された障害をオーケストレーションします。

• 実験テンプレートは、アクション (例: ASG内のEC2インスタンスの一定割合を停止または再起動する、SSM経由でCPUまたはメモリのストレスを注入する、インスタンスにネットワークレイテンシー/パケットロスを追加する、EKSポッドを強制終了する、ECSタスクを停止する、RDS/Auroraのフェイルオーバーをトリガーする) とターゲット (リソースタグ、ARN) を定義します。
• 安全制御: CloudWatchアラームの停止条件、時間制限、タグ/フィルターによる影響範囲 (blast radius) の制約、および事前チェックを指定します。まず非本番環境で実行し、次に厳格なガードレールとビジネス上の承認を得て本番環境で実行します。
• 可観測性: KPI (エラー率、テールレイテンシー、キューの経過時間、レプリカラグ) を計測し、Auto Scalingの反応、ロードバランサーのヘルスチェックの収束、Route 53のフェイルオーバー、データベースの昇格、サーキットブレーカーの動作など、自動化された応答を検証します。
• 継続的なレジリエンス: 実験をパイプライン/ゲームデーに統合し、設定のドリフトによってレジリエンスが損なわれるのを防ぎます。Parameter StoreやAppConfigを使用して、機能の有効/無効を切り替えるトグルや安全なロールアウトの調整を行います。

実践的な問題シナリオ

Expedia Groupは、グローバルな旅行検索APIを運用しています。このAPIは、北米とヨーロッパのユーザーに低レイテンシーを維持しつつ、重要な予約データに対して60秒未満のRTOとほぼゼロのRPOを提供する必要があります。チームは、時折発生するリージョン規模のサービス低下 (brownout) やデプロイに起因する不安定性に直面しており、監査人からはクロスアカウントのイミュータブル (不変) なバックアップと文書化されたDR訓練が要求されています。

ステップバイステップのアプローチ:

1. マルチリージョン、アクティブ/アクティブ構成のスタックを確立

• us-east-1とeu-west-1に、複数のAZにまたがるステートレスなAPIスタックをALBの背後にデプロイします。ヘルスチェックとエイリアスレコードの「ターゲットのヘルスを評価 (Evaluate Target Health)」を使用したRoute 53のレイテンシーベースルーティングを使用します。これにより、低レイテンシーのルーティングと、エンドポイントが異常な場合の自動的なリージョン回避が実現します。

2. グローバルで低RPOのデータストア

• 予約データとセッションデータを、us-east-1をプライマリ、eu-west-1をセカンダリとするAmazon Aurora Global Database (MySQL互換) に移行します。一般的なRPOは1秒未満、RTOは1分未満であり、障害時の目標を達成します。アプリケーション設定でクラスターエンドポイントとリーダーエンドポイントを使用し、リトライ/バックオフを実装してフェイルオーバーを許容します。

3. レジリエントなスケーリングと正常な移行

• 両リージョンで、ALBのRequestCountPerTargetに対するAuto Scalingのターゲット追跡を設定し、最小キャパシティを確保します。主要なイベント中の10倍のトラフィック急増を吸収できるサイズのウォームプールと、アプリケーションの準備完了チェックが成功するまで登録を遅延させるライフサイクルフックのLaunching:Waitを追加します。ALBの登録解除の遅延を120秒に設定し、スケールインやデプロイ中に処理中のリクエストを維持します。

4. 耐久性のあるオブジェクトのDR

• 旅行日程表ドキュメントのために、us-east-1からeu-west-1へのS3バージョニングとRTC付きCRRを有効にします。両リージョンで専用のレプリケーションIAMロールとKMSキーを使用し、ソース側でkms:Decrypt、デスティネーション側でkms:Encryptを許可します。RTCのメトリクスとアラートにより、レプリケーションSLAに対する信頼性が得られます。

5. カナリアおよびフェイルオーバーのためのDNS制御

• Route 53の加重レコード (eu-west-1へ常に1%のフロー) を追加し、セカンダリパスを継続的に使用します。これをヘルスチェックと組み合わせることで、スタンバイが本番環境に対応可能であることを保証し、危機が発生する前にドリフトを検出します。

6. 一元化されたイミュータブルなバックアップ

• セキュリティチームが所有するバックアップアカウントに、Vault LockとKMS CMKを使用したAWS Backupボールトを作成します。組織レベルのバックアップポリシーを定義し、RDS、DynamoDB、EFS、EBSの日次バックアップとクロスアカウントコピーをスケジュールします。Backup_Frequencyタグによってリソースを割り当てます。これにより、ランサムウェアへの耐性と職務の分離が実現します。

7. 自動フェイルオーバーのオーケストレーション

• Auroraプライマリの障害シグナルを検出するEventBridgeルールを実装し、セカンダリリージョンを昇格させてParameter Storeに保存されているアプリケーションエンドポイントを更新するLambda関数を呼び出します。アプリケーションは起動時にエンドポイントをロードし、接続エラー時に更新することで、手動のステップを最小限に抑えます。

8. AWS FISによるカオス検証

• ASGインスタンスの10%を終了させる、SSM経由でEC2に150msのレイテンシーと1%のパケットロスを注入する、AuroraのフェイルオーバーをトリガーするといったFIS実験テンプレートを作成します。p95レイテンシーとエラー率に関するCloudWatchアラームの停止条件で保護します。月次でゲームデーを実行し、Route 53のフェイルオーバー速度、ASGの復旧、ALBのヘルスチェックの収束、Aurora昇格のRTOを検証します。

これらのサービスを選択した理由:

• Route 53のレイテンシーベースおよび加重ルーティングは、最適なユーザーレイテンシーと、DR準備のための制御されたトラフィックシェーピングの両方を提供します。
• ALBと、ウォームプールおよびライフサイクルフックを備えたASGは、コールドスタートのペナルティやユーザーの中断なしに、迅速で正常なスケーリングを保証します。
• Aurora Global Databaseは、最小限のアプリケーション変更で、リージョンをまたいでほぼゼロのRPOと1分未満のRTOを独自に満たします。
• S3バージョニングとRTC付きCRRは、重要なアーティファクトに対して、監査可能でSLAに裏付けられたレプリケーションを提供します。
• クロスアカウントボールトとVault Lockを備えたAWS Backupは、コンプライアンス要件に沿った、イミュータブルで一元管理されたバックアップを作成します。
• AWS FISは、安全で自動化された障害注入を提供し、レジリエンス体制を継続的に証明し、設定のドリフトがDR計画を損なうのを防ぎます。

← コンテナとサーバーレスオペレーション · すべてのドメイン · イベント駆動アーキテクチャと自動化 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →