はじめに

AWS DMSを使用したデータ移行時、失敗したレコードがawsdms_validation_failures_v1に記録される問題に直面することがあります。特に、継続的にデータベース間のデータ同期を行う場合、これらの問題を無視し続けることはできず、適切なデータの補正作業が必要となります。

本記事では、この課題を解決するために構築したシステムの概要を紹介します。データ不整合の修正と再同期のプロセスを詳しく解説し、同じ問題を抱えるエンジニアの方々に役立つ情報を提供します。

問題の背景

`awsdms_validation_failures_v1`とは？

AWS DMSが移行に失敗したレコードを記録するシステムテーブルです。このテーブルには以下のような情報が格納されます：

table_name: 失敗が発生したテーブル名
column_name: 問題の発生したカラム名
error_message: 詳細なエラーメッセージ

詳細はAWSドキュメントの「制御テーブルタスク設定」「トラブルシューティング」で確認できます

主な移行失敗の原因

LOB設定の問題
データ型の不一致
CDC中のエラー

詳細はAWSドキュメントの「AWS DMS のソースデータベースとターゲットデータベース間のデータ不一致の問題をトラブルシューティングするにはどうすればよいですか?」で確認できます

解決策の概要

解決方法

データの不整合を解決する方法として、テーブル全体をフルロードして再同期する方法があります。しかし、この方法は、テーブル全体のデータ量に対して修復が必要なレコードが少ない場合には、非効率でコストが高くなる可能性があります。

こうした非効率なケースに対応するために、個別レコードを対象とした修復システムを構築しました。このシステムを利用することで、不整合データの修復を自動化し、効率的かつ迅速にデータを同期できるようになります。

システム構成

システムの概要

自動補正アプリケーションがawsdms_validation_failures_v1を定期的にチェック
awsdms_validation_failures_v1を解析し、検証エラーが発生したSourceTableとTargetTableの当該レコード解析する
TargetTableに対して、修正クエリーを発行する
awsdms_validation_failures_v1の処理結果をApp_logTableに書き込む

修正方法の詳細はAWSドキュメントの「トラブルシューティング」で確認できます

システム構築の詳細

使用技術

Java : 自作するアプリケーションの開発言語
Argo Workflows : アプリケーションを定期実行できる環境

自動補正アプリケーションの機能説明

このアプリケーションは、awsdms_validation_failures_v1テーブルを参照し、データ不整合が発生したレコードの原因や状況を確認します。その後、アプリケーションがこれらのレコードを解析し、ソーステーブル（SourceTable）とターゲットテーブル（TargetTable）の内容を比較して、適切にターゲットテーブルのレコードを修復します。

修復が完了すると、DMSの検証処理によって再度レコードが確認され、問題が解消されたことを確認できます。

重要なポイント

データ補正後もawsdms_validation_failures_v1のレコードは削除されないため、アプリケーションが同じレコードを再処理しないようにする必要があります。
修復済みのレコードを記録する「ログテーブル」を設けることで、同じレコードを繰り返し修正することを防止します。

DMS検証の詳細はAWSドキュメントの「AWS DMS データ検証」で確認できます

所感

AWS DMSには、データの検証機能と、その結果をawsdms_validation_failures_v1に記録する機能が提供されています。しかし、不正データを再同期するための機能は用意されていないため、独自のアプリケーションを作成し、補正処理を実装する必要があります。

補正処理の実装形式は複数考えられますが、今回の実装では処理がある程度複雑になることを見越して、AWS Lambdaのような簡易的な環境は利用せず、複雑な処理に対応可能な開発環境と言語を選択しました。

また、補正処理が単一テーブルに対する処理であったため、アルゴリズムを確定させた後は、SourceTableとTargetTableのDDLをもとに、アプリケーションのソースコードを自動生成する仕組みも構築することができました。