AWS認定資格 WEB問題集&徹底解説

データエンジニア-アソシエイト

正解 B問題
分野3:データ運用とサポート タスクステートメント3.4:データ品質の確保
合格に向けて、もっと深く学習する
豊富な問題と詳細なAWSサービス解説を、24時間無料でお試しいただけます
プレミアム会員機能を無料で試す ❯
問題文と選択肢
ある医療情報システムベンダーは、オンプレミスで稼働している PostgreSQL データベースを Amazon Aurora PostgreSQL に移行しようとしています。AWS DMS を用いてこの移行を担当することになったデータエンジニアは、独自の比較スクリプトを開発・運用する手間をかけずに、カットオーバー前に移行元と移行先のデータが完全に一致していることを検証する必要があります。

この要件を最も効果的に満たす方法はどれですか。
  • DMS タスクのログを Amazon CloudWatch Logs に出力し、DEBUG レベルのログを目視で確認して差異を洗い出す
  • DMS タスクでデータ検証(バリデーション)機能を有効にし、移行元と移行先のレコードを自動的に比較させる
  • DMS タスクのテーブルメトリクスで、テーブルごとの挿入・更新・削除・DDL 件数などの統計情報を確認する
  • DMS の事前移行アセスメントを実行し、タスク開始前に想定される問題を洗い出す
解説 頻出度★★★★★
この問題は、「DMS による移行 × カットオーバー前 × 全レコードの一致確認」の要件で、DMS に標準搭載されたデータ検証(バリデーション)機能を知っているかがポイント

A. DMS タスクのログを Amazon CloudWatch Logs に出力し、DEBUG レベルのログを目視で確認して差異を洗い出す

DMS のタスクログは、タスクの動作状況やエラー原因を追跡するための仕組みであり、全レコードの内容を突き合わせた結果を出力するものではありません。
DEBUG レベルのログは膨大で、医療情報システム規模のデータを目視確認するのは現実的でなく、「完全に一致している」ことの証明にはなりません
ログレベルを上げること自体がタスクの負荷とストレージコストを増やす点でも不適です。

正解

B. DMS タスクでデータ検証(バリデーション)機能を有効にし、移行元と移行先のレコードを自動的に比較させる

正解です。DMS のデータ検証を有効にすると、DMS がソースとターゲットの双方にクエリを発行し、行単位でデータを比較して不一致を報告します。結果は検証状態やレコード単位の差分として確認でき、自前の比較スクリプトを書く必要がありません。
フルロード完了直後から検証が始まり、CDC で継続的にレプリケートしている変更分も比較対象になるため、カットオーバー直前まで一致状況を追跡できます。移行やレプリケーションを行わない「検証のみのタスク」を作成することも可能です。
「データが完全に一致していることを検証する」という要件に、追加開発なしで正面から応える唯一の選択肢です。

C. DMS タスクのテーブルメトリクスで、テーブルごとの挿入・更新・削除・DDL 件数などの統計情報を確認する

テーブル統計(テーブルメトリクス)は、DMS が何件挿入・更新・削除したかというタスクの処理件数を示すもので、移行先に実際に格納された値がソースと同じかどうかは分かりません。
件数が一致していても、文字コードやデータ型の変換で値が壊れているケースは検出できません
進捗把握には有用ですが、データの一致を保証する手段としては不十分です。

D. DMS の事前移行アセスメントを実行し、タスク開始前に想定される問題を洗い出す

事前移行アセスメントは、タスクを開始するに、主キーの無いテーブルやサポートされないデータ型など移行を妨げる構成上の問題を洗い出す機能です。
実行タイミングが移行前である以上、移行後のデータが一致しているかどうかは原理的に判定できません
移行計画の品質を上げる有用な機能ですが、本問の「カットオーバー前の一致検証」という要件には応えられません。

これだけ覚える(記憶フック)
移行データの「本当に一致しているか」は DMS のデータ検証。件数統計もログも一致の証明にはならない。
正解への思考ルート 問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。
要件 判断ポイント
移行元と移行先のデータが完全に一致していることを検証したい 行単位で突き合わせて不一致を報告するのは DMS のデータ検証機能だけ
→選択肢(B)が正解
独自の比較スクリプトを開発・運用したくない DMS のタスク設定で有効化するだけ。検証のみのタスクも作成できる
→選択肢(B)が正解
検証はカットオーバー「前」に完了している必要がある 事前移行アセスメントはタスク開始前の構成チェックで、移行後のデータ一致は判定できない
→選択肢(D)を消す
件数やログで代替できるか 件数統計は処理件数を示すだけで値の正しさは分からず、DEBUG ログの目視も一致の証明にならない
→選択肢(A・C)を消す
ひっかけポイント
  • 選択肢 C のテーブル統計は「件数が合えば一致」と錯覚させるが、文字コードやデータ型変換による値の欠損・丸めは件数に現れない
  • 選択肢 D の事前移行アセスメントは名前が頼もしいが、実行タイミングが「移行前」である時点で移行後の突き合わせには使えない
  • 選択肢 A の「DEBUG ログを目視」は、そもそもログはトラブルシューティング用であり、データの一致を出力する仕組みではない
  • DMS のデータ検証はソースとターゲットの双方に追加のクエリを発行する点も押さえる。負荷を懸念する場合は検証のみのタスクを別枠で実行するなどの設計が必要
出題バリエーション 同じ知識が本番では条件を変えて出題されます。
問題文がこう変わったら 正解はこう変わる
「移行に、主キーの無いテーブルなど移行を妨げる問題を洗い出したい」 DMS の事前移行アセスメントが正解に浮上する。
「移行タスクが途中で失敗する原因を突き止めたい」 CloudWatch Logs へのタスクログ出力(デバッグログ)が正解軸に。
スキーマやストアドプロシージャを変換したい(異種 DB 間の移行)」 AWS SCT / DMS Schema Conversion が正解軸に。DMS 本体はデータの移行が役割。
「移行中のダウンタイムを最小化したい」 フルロード+CDC(継続的レプリケーション)の構成が論点に変わる。
関連サービスの解説 Amazon Aurora
AWS Database Migration Service (AWS DMS)
リファレンス この問題を解くために必要な知識を扱う公式ドキュメントです。
知識項目 公式ドキュメント
DMS のデータ検証によるソースとターゲットの突き合わせ AWS DMS データ検証 - AWS データベース移行サービス
+ 質問 / コメント
解答・解説に疑問がある場合や、よりよい解説がある場合など、お気軽にコメントください。ただし、短文コメントは表示されません。また、中傷などコメントの内容によっては、会員機能を停止させて頂きます。教え学び合える場になれば嬉しいです。(コメント投稿にはログインが必要です)
正答率 0%
No.6 解説
ある医療情報システムベンダーは、オンプレミスで稼働している PostgreSQL データベースを Amazon Aurora PostgreSQL に移行しようとしています。AWS DMS を用いてこの移行を担当することになったデータエンジニアは、独自の比較スクリプトを開発・運用する手間をかけずに、カットオーバー前に移行元と移行先のデータが完全に一致していることを検証する必要があります。

この要件を最も効果的に満たす方法はどれですか。
  • DMS タスクのログを Amazon CloudWatch Logs に出力し、DEBUG レベルのログを目視で確認して差異を洗い出す
  • DMS タスクでデータ検証(バリデーション)機能を有効にし、移行元と移行先のレコードを自動的に比較させる
  • DMS タスクのテーブルメトリクスで、テーブルごとの挿入・更新・削除・DDL 件数などの統計情報を確認する
  • DMS の事前移行アセスメントを実行し、タスク開始前に想定される問題を洗い出す

(会員限定)当問題の評価をお願いします。改善に活用します。