異種データベースの RDS への移行ツール選定 ある地方自治体が、庁内で運用している 20 個のオンプレミスデータベースを Amazon RDS へ移行する計画を立てています。データベースエンジンは Oracle、Microsoft SQL Server、MySQL が混在しており、住民記録システムなど一部のデータベースには独自に作り込んだスキーマと大量のストアドプロシージャが含まれています。移行後は別のエンジンで稼働させる可能性もあるため、事前に互換性を評価する必要があります。
この移行のために自治体が実行する必要がある手順の組み合わせはどれですか。2 つ選択してください。
A AWS Migration Evaluator を使用してソースデータベースを分析し、変換が必要なストアドプロシージャを特定する。 B AWS Application Migration Service を使用してソースデータベースを分析し、変換が必要なストアドプロシージャを特定する。 C AWS Schema Conversion Tool (AWS SCT) を使用してソースデータベースを評価し、ターゲットエンジンに合わせて変更が必要なオブジェクトを特定する。 D AWS Database Migration Service (AWS DMS) を使用して、ソースデータベースのデータを Amazon RDS へ移行する。 E AWS DataSync を使用して、ソースデータベースのデータを Amazon RDS へ転送する。
判定する 複数選択問題です (正解 2 つ)。選んでから判定してください。
解説を読む（正解: C、D） 異なるデータベースエンジンをまたぐ移行では、スキーマの変換とデータの移行という 2 つの作業をそれぞれ専用のツールで行うのが AWS の標準的な進め方です。AWS Schema Conversion Tool (AWS SCT) はソースデータベースのスキーマ、ビュー、ストアドプロシージャ、関数などを解析して評価レポートを生成し、ターゲットエンジンへ自動変換できる部分と手作業が必要な部分を明示します。カスタムスキーマと大量のストアドプロシージャを抱える本問では、C が移行前に不可欠な手順です。実データの移動には AWS Database Migration Service (AWS DMS) を使い、フルロードと変更データキャプチャによってソースを稼働させたまま Amazon RDS へ移行できるため、D も必須となります。A の AWS Migration Evaluator は、オンプレミス環境の使用状況を収集して AWS 移行後のコストとサイジングを試算するためのツールであり、データベースオブジェクトの互換性は評価しません。B の AWS Application Migration Service はサーバーをブロックレベルで複製してそのまま EC2 上へリホストするためのツールで、スキーマやストアドプロシージャを解析する機能は持ちません。E の AWS DataSync はファイルシステムやオブジェクトストレージ間でファイルを転送するサービスであり、稼働中のリレーショナルデータベースを整合性を保ったまま移行する用途には使えません。
クロスアカウントでの Oracle から PostgreSQL への無停止移行 損害保険会社が、保険金請求システムのバックエンドである Amazon RDS for Oracle データベースを、別の AWS アカウントに新設する Amazon RDS for PostgreSQL の DB インスタンスへ移行する計画を立てています。ソリューションアーキテクトは、ダウンタイムを発生させず、移行に要する時間を最小限に抑える戦略を設計しなければなりません。移行戦略では、既存のデータと移行中に発生するすべての新規データの両方を複製する必要があり、移行完了時点で移行先のデータベースは移行元と同一の内容になっている必要があります。すべてのアプリケーションは、RDS for Oracle DB インスタンスへの接続先として Amazon Route 53 の CNAME レコードを使用しています。RDS for Oracle DB インスタンスはプライベートサブネットに配置されています。これらの要件を満たす手順の組み合わせはどれですか。3 つ選択してください。
A 移行先アカウントに新しい RDS for PostgreSQL DB インスタンスを作成します。AWS Schema Conversion Tool (AWS SCT) を使用して、データベーススキーマを移行元から移行先へ移行します。 B AWS Schema Conversion Tool (AWS SCT) を使用して、移行元データベースのスキーマと初期データを含む新しい RDS for PostgreSQL DB インスタンスを移行先アカウントに作成します。 C 2 つの AWS アカウントの VPC 間で VPC ピアリングを構成し、移行先アカウントから双方の DB インスタンスへ接続できるようにします。各 DB インスタンスにアタッチされたセキュリティグループを設定し、移行先アカウントの VPC からデータベースポートへのトラフィックを許可します。 D 移行元 DB インスタンスを一時的にパブリックアクセス可能に変更し、移行先アカウントの VPC から接続できるようにします。各 DB インスタンスにアタッチされたセキュリティグループを設定し、移行先アカウントの VPC からデータベースポートへのトラフィックを許可します。 E 移行先アカウントの AWS Database Migration Service (AWS DMS) を使用して、移行元から移行先への全ロードと変更データキャプチャ (CDC) の移行タスクを実行します。移行完了後、CNAME レコードを移行先 DB インスタンスのエンドポイントに向けて変更します。 F 移行先アカウントの AWS Database Migration Service (AWS DMS) を使用して、移行元から移行先への変更データキャプチャ (CDC) のみの移行タスクを実行します。移行完了後、CNAME レコードを移行先 DB インスタンスのエンドポイントに向けて変更します。
判定する 複数選択問題です (正解 3 つ)。選んでから判定してください。
解説を読む（正解: A、C、E） 異なる AWS アカウント間で Oracle から PostgreSQL へ移行する場合、データベースエンジンが異なるため、スキーマの変換とデータの移行をそれぞれ別の仕組みで実施する必要があります。AWS Schema Conversion Tool (AWS SCT) はテーブル定義、ビュー、ストアドプロシージャ、データ型といったスキーマオブジェクトを変換する役割を担うため、まず移行先アカウントに空の RDS for PostgreSQL インスタンスを作成し、SCT でスキーマを移行します。次に、移行元 DB がプライベートサブネットに配置されていることから、2 つのアカウントの VPC を VPC ピアリングで接続し、双方のセキュリティグループでデータベースポートの通信を許可して、移行先アカウントに配置する AWS DMS のレプリケーションインスタンスが両方の DB に到達できるようにします。最後に、既存データを一括で移す全ロードと、移行中に発生する変更を継続的に追随させる変更データキャプチャ (CDC) を組み合わせた DMS タスクを実行し、移行元と移行先が同期した時点で Route 53 の CNAME レコードを移行先エンドポイントへ切り替えれば、ダウンタイムなしでカットオーバーできます。誤りの選択肢について、B の AWS SCT はスキーマ変換ツールであり、DB インスタンスを新規作成したり初期データを移行したりする機能は持たないため、この手順は成立しません。D は移行元 DB を一時的にパブリックアクセス可能にする案ですが、プライベートサブネットに配置した設計意図を損ない、インターネットへの不要な露出を生むため不適切です。F は CDC のみのタスクであり、タスク開始時点より前に存在していた既存データがコピーされないため、移行先が移行元と同一にならず要件を満たしません。
Oracle から Aurora PostgreSQL への停止時間最小の移行 動画配信サービスを運営するメディア企業が、データセンターの Oracle Database (約 12 TB) を Amazon Aurora PostgreSQL 互換エディションへ移行する計画です。このデータベースには視聴履歴の集計に使う PL/SQL のストアドプロシージャとパッケージが多数含まれています。ビジネス要件として、移行作業中も本番サービスは停止できず、最終的なカットオーバーで許容される停止時間は 30 分以内です。ソリューションアーキテクトが推奨すべき手順はどれですか。
A Aurora PostgreSQL で Babelfish を有効化し、既存の Oracle アプリケーションを変更せずにそのまま接続させる B AWS DMS のタスクだけを作成し、スキーマとストアドプロシージャの変換も DMS に任せて一括で Aurora PostgreSQL に移行する C Oracle Data Pump で 12 TB のダンプを出力し、AWS Snowball Edge で Amazon S3 に運んだうえで Aurora PostgreSQL にインポートする D AWS Schema Conversion Tool (AWS SCT) でスキーマと PL/SQL コードを変換し、変換できなかった部分を手動で修正したうえで、AWS DMS のフルロード + 変更データキャプチャ (CDC) タスクで継続レプリケーションを行い、レプリケーションラグが十分小さくなった時点で短時間の停止を挟んでアプリケーションを切り替える
解説を読む（正解: D） 異機種間 (ヘテロジニアス) のデータベース移行は「スキーマとコードの変換」と「データの移送」という 2 つの独立した作業に分解して考えます。AWS SCT はソースの DDL、データ型、ビュー、ストアドプロシージャ、ファンクションを解析してターゲットの方言へ変換し、自動変換できなかった箇所を評価レポートとして提示するため、手作業の対象を事前に把握できます。一方 AWS DMS はテーブルデータの移送を担い、フルロードで既存データをコピーした後、CDC でソースのトランザクションログを読み取り続けて差分を適用します。この仕組みにより本番を稼働させたままターゲットを追随させられ、ラグがほぼゼロになった瞬間に書き込みを止めて接続先を切り替えるだけで済むため、停止時間を数分から数十分に抑えられます。したがって D が正解です。B は誤りで、DMS が移送するのは主にテーブルとそのデータであり、ストアドプロシージャ、パッケージ、トリガー、シーケンスといったスキーマオブジェクトのコード変換は行いません。この用途のために SCT が別サービスとして提供されています。C はオフラインのダンプ&リストア方式であり、ダンプ取得からインポート完了までソースを凍結する必要があるため 30 分の停止時間要件を到底満たせません。さらに Oracle Data Pump の形式は Aurora PostgreSQL が直接読み込めるものではありません。A も誤りです。Babelfish for Aurora PostgreSQL は Microsoft SQL Server の TDS プロトコルと T-SQL に対する互換レイヤーであり、Oracle の SQL*Net や PL/SQL には対応していません。