AWS DMSを介したS3データレイクへのリレーショナルDBマイグレーション、パートI

AWS

AWS Database Migration Serviceは、関係データベース、NoSQLデータベース、データウェアハウス、およびすべての他の種類のデータストアを効率的かつ安全にAWS Cloudまたはクラウドとオンプレミスのセットアップ間で移行するクラウドサービスです。DMSは、Oracle、MS SQL Server、MySQL、Postgres SQL、Amazon Aurora、AWS RDS、Redshift、S3など、複数の種類のソースおよびターゲットデータベースをサポートしています。

データ移行中の観察

私たちは、オンプレミスのOracle、MS SQL Server、MySQL、Postgres SQL、およびMongoDBからのデータソースを使用して、AWS S3データレイクとAWS Redshift内のデータウェアハウスを設計および作成しました。これらのソースからAWS S3に初期のフルロードおよび日次の増分データ転送のためにAWS DMSを使用しました。

この連載では、異なる関係データベースの実際のデータ移行中に直面したさまざまな課題を説明したいと思います。

1. ソースでの修正日が適切に設定されていない

AWS DMSは、ソースデータベースからのフルロードと変更データキャプチャに使用されます。AWS DMSは、トランザクションログに基づいて変更されたレコードをキャプチャしますが、適切に更新された修正日の列は、重複排除ロジックの適用やS3のターゲットでの指定された行の最新の修正されたレコードを抽出するのに役立ちます。

変更されたデータがテーブルに利用できない場合や適切に更新されない場合、AWS DMS は変換ルールのオプションを提供して、ソースデータベースからデータを抽出する際に新しい列を追加する機能を提供します。ここで、AR_H_CHANGE_SEQ ヘッダーを使用して、ソースデータベースからの一意の増分番号として値を持つ新しい列を追加するのに役立ちます。この増分番号は、タイムスタンプと自動増分番号で構成されたソースデータベースから取得されます。

以下のコード例は、ターゲットに DMS_CHANGE_SEQ という新しい列を追加し、ソースからの一意の増分番号を持たせます。これは、最初の16桁がタイムスタンプで、次の19桁がデータベースによって増分されたレコードID番号を持つ35桁の一意の番号です。

JSON

{

    "rule-type": "transformation",

    "rule-id": "2",

    "rule-name": "2",

    "rule-target": "column",

    "object-locator": {

        "schema-name": "%",

        "table-name": "%"

    },

    "rule-action": "add-column",

    "value": "DMS_CHANGE_SEQ",

    "expression": "$AR_H_CHANGE_SEQ",

    "data-type": {

        "type": "string",

        "length": 100

    }

}

2. ソースとしての Oracle のサプリメンタルログの有効化

ソースデータベースとしての Oracle の場合、継続的な変更をキャプチャするためには、AWS DMS がソースデータベースで最小限のサプリメンタルログを有効にする必要があります。これにより、リドログに追加情報と列が含まれ、ソースでの変更を特定するのに役立ちます。

サプリメンタルログは、主キー、一意のキー、列のセット、またはすべての列に対して有効にできます。すべての列のサプリメンタルログは、ソースデータベースのテーブルのすべての列をキャプチャし、ターゲットの AWS S3 レイヤーで完全なレコードを上書きするのに役立ちます。

すべての列の補足ログを取得すると、テーブルのすべての列がログに記録されるため、リドゥログのサイズが増加します。それに伴い、追加情報を考慮してリドゥログとアーカイブログを適切に設定する必要があります。

3. ソースとターゲットデータベース間のネットワーク帯域幅

オンプレミスのソースからの初期フルロード（Oracle、MS SQL Serverなど）はうまく機能し、大部分の時間で変更データキャプチャも行われました。

特定の月の大部分の時間帯では、中程度の数のトランザクションがありましたが、ビジネスデイの終わりのプロセス、日々の真夜中以降、月末の活動を除きました。この時間帯にDMSマイグレーションタスクが同期していないか、失敗していることを観察しました。

ログ内のソース、ターゲット、およびレプリケーションインスタンスのメトリクスを確認し、以下の観察結果を見つけました：

CDCLatencySource – ソースエンドポイントからキャプチャされた最後のイベントとAWS DMSインスタンスの現在のシステムタイムスタンプとの間のギャップ（秒単位）。
CDCIncomingchanges – ターゲットに適用されるのを待っている時点での変更イベントの合計数。これは、早朝の調整活動中にゼロから数千に増加します。
CDCLatencySource – ソースエンドポイントからの最後のイベントとAWS DMSインスタンスの現在のシステムタイムスタンプとの間の間隔、秒単位。これは、毎日の深夜の調整作業中に0から数千秒、10〜12K秒まで増加します。この値は月末の作業中に40Kになりました。

さらなるログの分析および他のメトリクスのレビューにより、次のことが観察されました：

AWS DMSメトリクスNetworkReceiveThroughputは、顧客データベースとDMSトラフィックの両方に対するDMSレプリケーションインスタンスへの受信トラフィックを理解するためのものです。これらのメトリクスは、ソースデータベースとDMSレプリケーションインスタンス間にある場合のネットワーク関連の問題を理解するのに役立ちます。

観察された結果、ネットワーク受信スループットが最大で30MB/s、すなわち250Mb/sになっていた。これは、ソースとAWS間のVPN接続によるもので、他のアプリケーションと共有されていました。

この問題の最終的な結論は、ソースとターゲットデータベース間の接続が成功したデータ移行のためには重要であるということです。実際のデータ移行の前に、オンプレミスまたは他のクラウドソースデータベースとAWS環境間に十分な帯域幅が設定されていることを確認する必要があります。

AWS Site-to-Site VPNやOracle Cloud Infrastructure（OCI）Site-to-Site VPN（Oracle AWS）などのVPNトンネルを使用すると、最大1.25 Gbpsのスループットが得られます。これは、小規模なテーブルの移行やDMLトラフィックの少ないテーブルの移行には十分です。
大規模なデータ移行で、テーブルごとに高いトランザクション数がある場合は、AWS Direct Connectを検討するべきです。これにより、1 Gbps、10 Gbpsなどの帯域幅をサポートする専用のプライベート接続を作成するオプションが提供されます。

結論

これは、リレーショナルデータベース移行の課題に関する複数部構成シリーズのパートIです。AWS DMSを使用したこれらの課題および実装された解決策の多くは、データベース移行プロセス中に発生する可能性があり、これらの解決策を参照することができます。

Source:
https://dzone.com/articles/relational-databases-migration-to-aws-environment