異種データベースの 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 上で稼働する配送追跡システムを Amazon Aurora PostgreSQL へ移行しようとしています。データ量は約 20 TB あり、PL/SQL で書かれたストアドプロシージャやトリガーが多数存在します。事業部門はカットオーバー時のアプリケーション停止を 30 分以内に収めることを条件としています。オンプレミスと AWS の間には 1 Gbps の AWS Direct Connect 接続が既に確立されています。この要件を満たす移行方式はどれですか。
A AWS Schema Conversion Tool でスキーマとストアドプロシージャを PostgreSQL 用に変換し、自動変換できなかった箇所を手動で修正したうえで、AWS Database Migration Service のフルロード + 変更データキャプチャ (CDC) タスクを実行して継続的に同期させ、レプリケーションラグが十分小さくなった時点でアプリケーションの接続先を切り替える B Oracle RMAN で取得した完全バックアップを AWS Snowball Edge で Amazon S3 に送り、そのバックアップファイルを Aurora PostgreSQL クラスターへリストアしてから、差分のアーカイブログを適用する C AWS Database Migration Service のフルロードのみのタスクを週末のメンテナンス時間帯に実行し、完了後にアプリケーションの接続先を Aurora PostgreSQL に変更する D Aurora PostgreSQL で Babelfish を有効化して既存の Oracle 用アプリケーションコードとストアドプロシージャを変更せずに接続させ、データ本体は AWS DataSync でコピーする
解説を読む（正解: A） 異種データベース移行では、スキーマやコードの変換と、データそのものの移送という 2 つの課題を分けて考えます。AWS Schema Conversion Tool (SCT) はテーブル定義、インデックス、ビュー、PL/SQL などをターゲットエンジンの構文へ自動変換し、自動変換できない箇所をアクションアイテムとして報告するため、手作業の量を事前に見積もれます。データの移送は AWS Database Migration Service (DMS) が担当し、フルロードで既存データをコピーしたあと変更データキャプチャ (CDC) でソース側の更新を継続的に反映し続けます。ソースを停止せずに同期を維持できるので、切り替えはレプリケーションラグが十分小さくなった瞬間に接続先を変更するだけで済み、停止時間を数分から数十分に抑えられます。したがって A が要件を満たします。B は Aurora PostgreSQL が Oracle の RMAN バックアップ形式を読み込めないため、そもそも成立しません。C はフルロードのみのため 20 TB の転送とアプリケーション停止が同じ時間帯に重なり 30 分では終わらず、CDC がないので転送中に発生した差分も取り込めません。D の Babelfish は SQL Server の T-SQL と TDS プロトコルに対する互換レイヤーであって Oracle 互換ではなく、また AWS DataSync はファイルやオブジェクトの転送サービスであり、リレーショナルデータベースの論理レプリケーションには利用できません。