SAPワークロードの移行とモダン化の加速
ある金融サービス企業が、オンプレミスで稼働する自己管理型のMicrosoft SQL Server 2016（容量4TB、ストアドプロシージャ・ビュー・トリガー・二次インデックスを多用、一部テーブルにBLOB列を含む）を、Aurora PostgreSQL互換エディションへ移行する。本番システムは24時間稼働しており、業務停止は最大でも数分しか許容されない（near-zeroダウンタイム要件）。オンプレミスとAWS間は1GbpsのDirect Connectで接続済みである。移行後はソースとターゲットのデータ整合性を客観的に確認する必要がある。これらの要件を満たす移行アプローチとして最も適切なものはどれか。
AAWS SCTでスキーマとストアドプロシージャ等のオブジェクトを変換してAurora PostgreSQLに適用し、DMSタスクを全ロード＋継続的レプリケーション(CDC)で構成する。ソースSQL ServerでMS-CDCを有効化し、DMSのデータ検証を有効にしてカットオーバーする
✓ 正解
ヘテロジニアス移行ではSCTでスキーマ・プロシージャを変換する必要があり、全ロード＋CDCで初期コピー後の変更を継続同期するため停止時間を最小化できる。CDCの前提であるMS-CDCをソースで有効化し、データ検証で整合性も担保でき、全要件を満たす。
BAWS SCTでスキーマを変換して適用し、DMSタスクを全ロードのみで実行する。全ロード完了後にアプリケーションを停止して一括でカットオーバーし、その間に発生した差分は手動SQLで反映する
全ロードのみではカットオーバーまでに発生する更新が反映されず、停止して手動SQLで差分を反映する方式は長い停止時間と人的ミスを招く。near-zeroダウンタイム要件を満たせないため不適切である。
CAWS SCTは使わずDMSのみで実施し、ターゲットスキーマはDMSに自動生成させる。DMSタスクを全ロード＋CDCで構成し、データ検証を有効化してカットオーバーする
DMSが自動生成するターゲットスキーマは基本的なテーブルとPKのみで、ストアドプロシージャ・ビュー・二次インデックス・制約は移行されない。SCT省略ではアプリが動作せず、本シナリオには不適切である。
DSQL Serverのネイティブ完全バックアップ(.bak)をS3へ転送し、Aurora PostgreSQLへリストアして初期データを移行する。以降の差分はDMSのCDCで継続同期してカットオーバーする
SQL Serverの.bakはエンジン固有形式で、異種DBであるAurora PostgreSQLにはリストアできない。ネイティブバックアップ/リストアは同一エンジン間でのみ有効で、この移行経路自体が成立しない。
解説
異種データベース移行ではAWS SCTでスキーマやストアドプロシージャ等のオブジェクトを変換し、AWS DMSで全ロード＋継続的レプリケーション(CDC)を構成するのが定石。CDCにはソースSQL Serverでのトランザクションログ(MS-CDC)有効化が前提で、これにより初期コピー後の更新を同期し続け、カットオーバー時の停止時間を最小化できる。DMSのデータ検証で行単位の整合性も客観的に確認できる。
選択肢のAWS DMS(全ロードのみ)は、移行中に発生した更新が反映されず、手動差分反映が長い停止と人的ミスを招くためnear-zero要件を満たせない。
選択肢のDMS自動スキーマ生成は、テーブルとPKのみ作成しプロシージャ・ビュー・二次インデックスを移行しないためアプリが動作しない。
選択肢のSQL Serverネイティブ.bakは、異種エンジンであるAurora PostgreSQLにはリストアできない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →