Amazon SAP-C02: レジリエンス、ディザスタリカバリ、高可用性 — 学習ガイド

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

RTOとRPOの計画：耐障害性の定量化とアーキテクチャへのマッピング

RTO (目標復旧時間) と RPO (目標復旧時点) は、コンピューティングのサイジングからレプリケーションのトポロジーに至るまで、あらゆるレジリエンスの選択を決定づけます。まず、ビジネスへの影響とダウンタイムのコストによってワークロードを分類し、それらの優先順位を測定可能な目標に変換します。ミリ秒単位のRPOは同期レプリケーションや専用のグローバルデータベースを必要とし、分から時間単位のRPOでは非同期レプリケーション、スナップショットスケジュール、またはバッチ処理によるログシッピングが許容されます。目標に合致するAWSサービスを使用します。例えば、大規模で低いRTO/RPOを実現するAmazon Aurora Multi‑AZおよびAurora Global Database、単一リージョンでの同期的な高可用性を実現するRDS Multi‑AZ、復旧とレポーティングのためのクロスリージョンリードレプリカ、そして最小限のアプリケーション変更でオンプレミスサーバーをほぼリアルタイムでレプリケーションするAWS Elastic Disaster Recovery (DRS)などです。よくある落とし穴は、最悪ケースの復旧オペレーションではなく平均的な負荷に合わせて設計してしまうことです。もう一つは、スナップショットは数分間隔になる可能性があり、アプリケーションの整合性が欠けている場合があるにもかかわらず、スナップショットだけでトランザクションシステムのRPOを満たせると想定してしまうことです。意思決定のトレードオフは明確です。同期レプリケーションはコストと書き込みレイテンシーを増加させますがRPOを低減します。非同期レプリケーションはレイテンシーとコストを削減しますが、潜在的なデータ損失を増加させます。カオステスト、計画的なフェイルオーバー、復元訓練によって計画をテストし、実際のRTO/RPOを検証し、外部認証、DNS、IPホワイトリストなどの隠れた依存関係を特定します。

マルチAZおよびマルチリージョンアーキテクチャとフェイルオーバー戦略

マルチAZアーキテクチャは、複数のアベイラビリティーゾーンに冗長なコンピューティング、ネットワーキング、ストレージを配置することでAZ障害から保護します。マルチリージョンは、リージョンレベルの障害、自然災害、または大規模なネットワーク分断に対する耐性を拡張します。コストと復旧の要件に基づいて、アーキテクチャパターン（パイロットライト、ウォームスタンバイ、アクティブ/パッシブ、またはアクティブ/アクティブ）を選択します。パイロットライトは、セカンダリリージョンで最小限のリソースを使用してコストを最小化し、フェイルオーバー時にスケールアップします。ウォームスタンバイは、スケールダウンしたサービスを実行し続けることで、より迅速な復旧を可能にします。アクティブ/アクティブは、複数のリージョンでトラフィックを処理することでRTOを最小化しますが、強力なデータレプリケーションと競合解決が要求されます。ヘルスチェックとフェイルオーバールーティングを備えたRoute 53、グローバルなトラフィック管理のためのAmazon CloudFrontまたはGlobal Accelerator、クロスリージョンレプリケーションのためのDynamoDB Global TablesやAurora Global Databaseのようなデータサービスを使用します。よくある落とし穴には、長すぎるDNS TTLに依存すること、ステートフルサービス（セッションストア、キャッシュ）のフェイルオーバーを検証しないこと、クロスリージョンのデータ転送料金やコンプライアンス上の制約を無視することが含まれます。マルチリージョンデプロイの複雑さとコストを、許容可能なダウンタイムとデータ損失とを比較検討します。迷った場合は、フェイルオーバー時間を計測・モデル化し、ビジネスケースの判断材料とします。

アプリケーションのレジリエンスパターン：ステートレス、分離、状態管理

個々のコンピュートノードに固定された状態を最小限に抑え、コンポーネントを分離（デカップリング）して部分的障害が連鎖しないようにすることで、障害を前提とした設計を行います。Application Load BalancerまたはNetwork Load Balancerの背後にあるステートレスなアプリケーションノードは、水平スケールと迅速な置き換えを可能にします。セッション状態には、スティッキーセッションよりもAmazon DynamoDBやAmazon ElastiCacheのような外部ストアを推奨します。ファイル共有には、プロトコルとパフォーマンスの要件に応じてAmazon S3、Amazon EFS、またはFSxを使用します。Amazon SQS、SNS、またはKinesisを使用した非同期パターンは、スパイクをバッファリングし、リトライを可能にし、バックプレッシャーを緩和し、フェイルオーバー中の同期的な依存関係を減らします。クライアントにサーキットブレーカー、バルクヘッド、エクスポネンシャルバックオフを実装して、障害が発生しているサブシステムを隔離します。アーキテクトが陥りがちな罠は、コールドスタートやスケールアップ時間を過小評価することです。Lambdaの同時実行数制限、Auto Scalingのクールダウン、ウォームアップ戦略はRTOに影響します。もう一つは、キャッシュを耐久性があるものとして扱うことです。キャッシュは再構築可能でなければなりません。コストとレジリエンスの選択は、バッファサイジングとレプリケーションに現れます。高いレジリエンスは、より多くの予約キャパシティやクロスリージョンレプリケーションを必要とすることが多く、コストが増加します。RTO/RPOを満たす最小限の実行可能な冗長性を選択し、同時に障害を検出・修正するための可観測性と自動化を確保します。

バックアップ、レプリケーション、ガバナンス、運用の準備

バックアップは保険です。重要なのは、一貫性、セキュリティ、保持、および回復可能性です。AWS Backup を使用して、EBS、RDS、DynamoDB、EFS、FSx にまたがるバックアップポリシーを一元管理し、地理的な回復力のためにクロスアカウント、クロスリージョンのバックアップコピーを強制します。オブジェクトデータには、S3 バージョニングをライフサイクルルールとともに有効にし、クロスリージョンでの耐久性のために S3 Replication (CRR) を使用します。データベースのネイティブバックアップ、RDS の自動スナップショット、または VSS をサポートする AWS DRS を活用して、データベースと Windows ファイルシステムのアプリケーション整合性のあるスナップショットを確保します。クロスアカウントレプリケーションと IAM の最小権限は、偶発的な削除を防ぐために不可欠です。定期的な復元演習により、IAM ロールの欠落、ネットワーキング (VPC CIDR の重複)、または外部統合に関する問題が明らかになります。Systems Manager Automation でランブックを自動化し、CloudFormation や Terraform でフェイルオーバー手順をコード化して、手動エラーを削減します。よくある落とし穴には、エクスポート機能のないポイントインタイムスナップショットのみに依存すること、カスタマーマネージドキーでバックアップを暗号化しないこと、バックアップジョブの成功を監視しないことなどがあります。規制要件と保持およびストレージのコストのバランスを取ります。古いバックアップはコスト管理のために S3 Glacier に階層化し、最近のバックアップは迅速な復元のために素早くアクセスできるようにしておきます。

実践的な問題: ユースケースシナリオ

シナリオ: グローバルなライブイベント企業である Meridian Events Inc. は、単一の AWS リージョンでチケット発行アプリケーションを実行しています。このアプリケーションは、ALB の背後にある EC2 Auto Scaling グループを使用し、1 つの AZ 内の EC2 上に 3 ノードの PostgreSQL クラスターを配置し、毎晩 EBS スナップショットを取得しています。この組織は、運用オーバーヘッドとコストを最小限に抑えながら、RTO を 10 分未満、RPO を 5 分未満に短縮する必要があります。

課題: 予測可能なフェイルオーバーと最小限のアプリケーション変更で、AZ/リージョンをまたいでデータベースのほぼ継続的な可用性と低いデータ損失を達成する。

推奨アプローチ:

Amazon RDS for PostgreSQL を Multi‑AZ 配置で設定するか、Amazon Aurora PostgreSQL with Multi‑AZ に移行し、自動化された継続的バックアップと高速スナップショットエクスポートを有効にします。適切な保持期間で自動バックアップを有効にします。
Aurora Global Database (またはセカンダリリージョンのリードレプリカへの RDS 論理/物理レプリケーション) を使用してクロスリージョンレプリケーションを追加し、地理的な RPO 目標を達成します。また、Route 53 のレイテンシーベースルーティングをヘルスチェックとともに設定し、制御されたリージョンフェイルオーバーを可能にします。
単一 AZ の EC2 PostgreSQL をマネージドサービスに置き換えてホストのメンテナンスをなくし、アプリケーションの接続ロジックをリファクタリングして、クラスターエンドポイントまたは RDS Proxy を使用して接続プーリングと高速なフェイルオーバー処理を実現します。
継続的なレプリケーション検証とランブックの自動化を実装します。Systems Manager Automation と CloudFormation テンプレートを使用して定期的なフェイルオーバードリルを実施し、リソースを迅速に再作成します。CloudWatch と SNS を介してメトリクスを計測し、アラートを実行します。

論理的根拠: マネージドの Multi‑AZ データベースサービスとクロスリージョンレプリケーションを使用することで、運用の複雑さが軽減され、厳しい RTO/RPO 目標を達成できます。自動化と定期的なドリルにより、計画が実際に機能することが保証され、RDS/Aurora は手動のフェイルオーバー手順とフェイルオーバー時間を最小限に抑えます。

← 移行とモダナイゼーション · すべてのドメイン · コスト最適化とガバナンス →

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