SAP-C02-026 · 理解確認
理解確認:AWS Elastic Disaster RecoveryによるDR設計
単一選択 14 / 複数選択 2 / 穴埋め 0 · 16問
この理解確認の目的
AWS DRSを採用する要件から、継続的レプリケーション、復旧サイト、復旧オーケストレーション / 検証、フェイルオーバー、ポイントインタイム復旧、フェイルバックまでをシナリオで判断できるか確認します。
企業はオンプレミス VMware上の既存業務システムをAWSへDR化したい。アプリケーションアーキテクチャを大幅に変更せず、データ損失を小さくし、DR用完全コンピューティングを平常時から常時稼働させず、災害時にはAWS上でサーバーを短時間で起動したい。最も適切な候補はどれか。
B. マルチサイト アクティブ/アクティブへアプリケーションを全面再設計する
C. AWS Elastic Disaster Recoveryでサーバーデータを継続レプリケーションする
D. 復旧リージョンに完全キャパシティのアプリケーションスタックを常時稼働する
答えと解説
答え:C
既存サーバーアーキテクチャを維持しながら継続的ブロックレプリケーションを行い、必要時にEC2を起動する要件にAWS DRSが合います。
AWS DRSで短いRPOを狙う仕組みとして最も正確なものはどれか。
B. 送信元サーバーから毎時間スナップショットを作成して復旧リージョンへコピーする
C. 復旧用EC2を完全キャパシティで常時稼働してファイルシステムを定期同期する
D. アプリケーショントランザクションログだけをAWS Backupへ継続的エクスポートする
答えと解説
答え:A
AWS DRSはブロックレベルの初期同期後、送信元ボリュームへの変更を継続的にステージング領域へレプリケーションします。
送信元サーバーのレプリケーション状態は正常だが、復旧訓練で起動したEC2がアプリケーションネットワークへ接続できなかった。データレプリケーションには問題がない。最初に確認すべき設計はどれか。
B. レプリケーションサーバーのインスタンスタイプを大きくし、ステージング領域のスループットを増やして復旧インスタンスのサブネット接続を修復する
C. 送信元サーバーのディスク書き込み率を下げ、レプリケーション遅延を減らすことで復旧インスタンスのセキュリティグループ接続を正常化する
D. 復旧インスタンスのEC2起動テンプレートに設定したサブネットやセキュリティグループを確認し、復旧サイト側ネットワーク設定を修正する
答えと解説
答え:D
レプリケーション用ステージング領域と復旧サイトは別責任です。復旧インスタンスのサブネット / セキュリティグループなど起動設定を確認します。
データベース、ディレクトリサービス、アプリケーションサーバーの順に起動依存がある20台のサーバーをAWS DRSで保護している。DR訓練と本番復旧で依存順序と手順間の待機を再現したい。最も適切なのはどれか。
B. AWS Step FunctionsからDRS APIを個別に呼び出す独自オーケストレーションを構築する
C. DRS起動後アクションだけでサーバー間の起動順序を制御する
D. AWS DRSのリカバリプランでサーバーをグループ化し、定義した順序と待機時間で実行する
答えと解説
答え:D
現在のAWS DRSのリカバリプランは相互依存するサーバーを定義順序と待機時間で訓練 / 復旧するための機能です。
復旧インスタンスの起動後、プロセス、ボリューム、ネットワーク、HTTP/HTTPS応答を確認してからトラフィックフェイルオーバーを判断したい。復旧手順を自動化する設計として最も適切なのはどれか。
B. 復旧インスタンスの状態が実行中なら即時フェイルオーバーする
C. DRS起動後アクションで検証を実行し、復旧訓練でも同じ手順を検証する
D. ステージング領域のレプリケーションサーバーへアプリケーションヘルスチェックを設定する
答えと解説
答え:C
起動後アクションではSSMを利用した各種検証を自動化できます。訓練で同じ復旧手順を事前検証することでRTOと復旧準備状態を確認できます。
災害が発生し、AWS DRSで復旧インスタンスを起動してアプリケーション検証も成功した。しかしユーザートラフィックはまだプライマリ環境へ向いている。次に必要な運用はどれか。
B. Amazon Route 53などのトラフィック管理で本番トラフィックを復旧環境へ切り替える
C. 復旧インスタンスをステージング領域サブネットへ戻して待機させる
D. 復旧インスタンスからプライマリへの逆方向レプリケーションを開始してからユーザートラフィックを切り替える
答えと解説
答え:B
AWS DRSの復旧は復旧インスタンスの起動です。本番トラフィックのフェイルオーバーはDRS外部のトラフィック管理で実行します。
送信元環境でデータ破損が発生し、その変更はAWS DRSのレプリケーション先にも反映された。破損発生前の状態でアプリケーションを復旧する必要がある。最も適切なのはどれか。
B. ステージング領域のレプリケーションサーバーディスクを本番利用する
C. 破損発生前のポイントインタイムを選択して復旧インスタンスを起動する
D. 復旧リージョンで新しい送信元サーバーを作成して初期同期を開始する
答えと解説
答え:C
最新状態が破損済みなら、保持されている破損前のポイントインタイムを選択して復旧します。
災害中はAWS上の復旧インスタンスで業務を継続し、新しいトランザクションデータが書き込まれた。その後オンプレミスプライマリが復旧したためプライマリへ戻したい。最も適切な流れはどれか。
B. プライマリへ古いバックアップを復元し、復旧環境を停止する
C. 復旧インスタンスをステージング領域へ移しプライマリから初期同期をやり直す
D. 復旧側の最新データをプライマリへレプリケーションして同期・検証した後、トラフィックをプライマリへ戻す
答えと解説
答え:D
フェイルバックでは復旧サイトで発生した最新データをプライマリへ反映し、同期と検証後にトラフィックを戻します。
AWS DRSで継続的レプリケーションを利用しているが、大量バッチ処理中に送信元サーバーの書き込み率が急増し、レプリケーション遅延が継続的に増えている。ビジネス要件はRPO 30秒以内である。最も適切な判断はどれか。
B. 帯域幅とステージング領域性能を確認し、レプリケーションが書き込み量に追従できるか検証する
C. 復旧ポイント保持期間を長くすればレプリケーション遅延を解消できる
D. 復旧インスタンスのインスタンスタイプだけを大きくする
答えと解説
答え:B
継続的レプリケーションでも送信元書き込み率をレプリケーションスループットが下回れば遅延が増加します。ネットワーク、レプリケーションサーバー、ステージングストレージなどを確認し、実効RPOを満たせることを検証します。
データベースアプリケーションはトランザクションデータの一部をメモリ上に保持し、まだディスクへフラッシュしていない。その瞬間に送信元サーバーが停止し、AWS DRSの復旧ポイントから復旧した。最も適切な理解はどれか。
B. DRSがデータベーストランザクションログを解析して未コミットデータまで復旧する
C. メモリ上の未書き込みデータもブロックレプリケーションによって必ず復旧される
D. 継続的レプリケーションでは必ずアプリケーション整合性のある復旧になる
答えと解説
答え:A
AWS DRSはブロックレベルのクラッシュ整合性復旧を基本とします。メモリ上だけに存在しディスクへ書き込まれていないデータまで自動的に保護する仕組みではありません。
AWS DRSのレプリケーション状態は正常で、ビジネス要件はRTO 20分である。RTO達成を最も適切に確認する方法はどれか。
B. ステージング領域のEBS容量と使用率だけを監視し、十分な空き容量があればエンドツーエンド復旧時間も満たすと判断する
C. 送信元サーバーの平均CPU使用率から復旧時間を推定し、CPUが低ければ訓練なしでもRTO 20分達成と判断する
D. 復旧訓練で復旧インスタンス起動、OS ブート、アプリケーション検証までの実時間を測定し、RTO達成を検証する
答えと解説
答え:D
正常レプリケーションだけではRTO達成を証明できません。復旧訓練で復旧インスタンスの起動からアプリケーション検証まで実測し、復旧目標を確認します。
企業はAWS DRSを利用して送信元サーバーを復旧リージョンのステージング領域へ継続レプリケーションしている。新しい要件として、災害発生直後から復旧リージョンが追加サーバー起動を待たずにアプリケーショントラフィックを処理できることが追加された。最も適切な判断はどれか。
B. DRSのステージング領域と本番稼働可能なスタンバイは別物なので、ウォームスタンバイ等の常時稼働環境も比較する
C. 継続的レプリケーションを有効にすればステージング領域が本番トラフィックを処理できる
D. ポイントインタイム復旧を有効にすれば追加サーバー起動なしで即時処理できる
答えと解説
答え:B
AWS DRSはマネージドレプリケーション / 復旧サービスであり、ステージング領域は本番稼働可能なスタンバイではありません。障害直後からトラフィックを処理する要件ならウォームスタンバイ等のアーキテクチャパターンも比較します。
AWS DRSで復旧サイトからプライマリへフェイルバックする。送信元環境がオンプレミスの場合とAWS内の場合について最も適切な理解はどれか。
B. オンプレミスとAWS内ではフェイルバック / 逆方向レプリケーションの仕組みが異なる場合があるが、最新データをプライマリへ同期してから切り戻す原則は共通である
C. AWS内フェイルバックでは復旧インスタンスとプライマリが同じクラウド上にあるためデータ同期は不要で、トラフィックだけプライマリへ戻せばよい
D. オンプレミス送信元へはAWS DRSからデータを戻せないため、フェイルバックする場合は必ず新しいオンプレミスサーバーを手作業で再構築する
答えと解説
答え:B
送信元環境によってフェイルバックの具体的仕組みは異なります。一方、復旧中に発生した最新データをプライマリへ戻し検証後にトラフィックを切り戻す原則は共通です。
AWS DRSを使ったエンドツーエンドRTOを評価する際、復旧ジョブの開始からビジネスサービス再開までに含めるべき時間を4つ選択してください。
B. OS ブートとアプリケーション起動時間
C. ソースコード リポジトリのコミット数
D. アプリケーション検証の時間
E. 本番トラフィックを復旧環境へ切り替える時間
F. AWSアカウント作成から現在までの日数
答えと解説
答え:A / B / D / E
RTOはDRSがEC2を起動する時間だけではありません。ボリューム/インスタンス準備、OS/アプリケーション起動、検証、トラフィックフェイルオーバーまでビジネスサービス復旧に必要なエンドツーエンド時間で評価します。
AWS DRSの現在復旧モードについて正しいものを4つ選択してください。
B. Fastはクロスプラットフォーム互換性を最大化するために必ず完全変換を実行する
C. Fastは変換プロセスを省略し、レプリケート済みスナップショットから直接復旧インスタンスを起動して復旧時間を短縮する
D. FastはAWS間DRなど、送信元サーバーがAWS互換ドライバー / 設定を持つシナリオで有力な候補になる
E. Optimalは変換を省略するモードであり、Fastより復旧時間短縮を最優先する
F. Fast復旧モードを利用するにはAWS Replication Agent 6.42.20以降が必要である
答えと解説
答え:A / C / D / F
Optimalはデフォルトの完全変換モードです。Fastは変換を省略してレプリケート済みスナップショットから直接起動し、AWS互換性が確保されたAWS間シナリオなどで復旧時間短縮に利用できます。FastにはAWS Replication Agent 6.42.20以降が必要です。
AWS Elastic Disaster Recovery(AWS DRS)で復旧インスタンスを起動した後、社内固有の検証スクリプトとアプリケーション初期化処理を自動実行したい。事前定義された起動後アクションだけでは要件を満たせない。最も適切な設計はどれか。
B. レプリケーションサーバーのユーザーデータへアプリケーション初期化処理を書き込み、復旧インスタンスへ自動継承させる
C. 復旧スナップショットへシェルスクリプトを直接埋め込み、ボリューム作成時に自動実行されるよう設定する
D. DRSのレプリケーションエージェントをアプリケーション初期化用エージェントとして再設定し、復旧後の処理を実行させる
答えと解説
答え:A
AWS DRSの起動後アクションはAWS Systems Managerを利用し、事前定義アクションに加えてカスタム SSM ドキュメントを使った処理も構成できます。これにより復旧インスタンス起動後の独自検証や初期化を自動化できます。