DMSレプリケーションにおけるチューニング項目

はじめに

AWS DMSを使用する際、移行タスクのパフォーマンスを最適化するためにチューニングが必要な場合があります。
とくに大規模なデータベースを移行する場合、その効果はより顕著に現れます。
この記事では、AWS DMSにおけるさまざまなチューニング項目についてまとめます。

チューニング項目

レプリケーションインスタンスのCPU

AWS DMSでは、データ型の変換にCPUを消費します。また、タスクの数や並列処理の度合いによってもCPU使用率が影響を受けます。不足している場合は、タスクの処理速度に影響するため、より多くのCPU数を持つインスタンスタイプに変更することを検討しましょう。

レプリケーションインスタンスのインスタンスタイプの変更

ワークロードに応じて、適切なインスタンスファミリーを選択します。

大量の演算が必要な場合は、「コンピューティング最適化」インスタンスファミリー
メモリ負荷が大きい場合、たとえばLOBの処理が多い場合は、「メモリ最適化」インスタンスファミリー

レプリケーションインスタンスのメモリが不足すると、データはディスクに書き込まれます。ディスクからの読み取りによってレイテンシーが発生する可能性があります。この問題は、十分なメモリを備えたレプリケーションインスタンスのサイズを選択することで回避できます。

移行の実行後、レプリケーションインスタンスのCPU、解放可能なメモリ、空きストレージ、IOPS などのパフォーマンス指標をモニタリングします。収集したデータに基づいて、必要に応じてレプリケーションインスタンスのサイズを調整しましょう。

ディスクサイズ

レプリケーションインスタンスに割り当てられるストレージは、主に以下の目的で使用されます。

ロード中に収集されるログファイルの保存
キャッシュされた変更の一時的な保存

ソースシステムがビジー状態であるか、大量のトランザクションを実行する場合は、ストレージを増やす必要が生じるかもしれません。しかし、通常はデフォルトの量で十分であり、空きストレージやIOPSなどのパフォーマンス指標をモニタリングし、必要に応じてストレージサイズを小さく設定しても問題ありません。

適切なディスクサイズを設定することで、リソースを最適に活用し、余分なコストを節約できます。データ量やトランザクションの特性に応じて、柔軟に調整することが重要です。

複数テーブルの並列ロード

AWS DMSでは、複数のテーブルを並列でロードできます。デフォルトでは1度に8つのテーブルをロードする設定になっています。
ただし、この設定はパフォーマンスに影響を与える可能性があります。

レプリケーションインスタンスが大きなインスタンスタイプの場合、この設定を増やすとパフォーマンスが向上する可能性がある
一方で、設定値が大きすぎる場合は逆にパフォーマンスが低下する可能性があるため、少しずつ増やして最適なパフォーマンスに調整する
小さなインスタンスタイプの場合は、デフォルトの8つでは大きすぎる場合があるため、より小さい値に変更してパフォーマンスを測定する

この数を変更するには、AWS DMSタスクの作成、または変更を選択後、「詳細設定を使用する」を押下し「並列にロードするテーブルの最大数」の値を修正します。チューニング_複数テーブル

並列全ロード

パーティション、またはサブパーティション化されているテーブルは、parallel-load オプションを指定することで並列ロードできます。設定方法は、移行タスクのマッピングルールに以下のようにparallel-load オプションを追記します。

{
    "rule-type": "table-settings",
    "rule-id": "8",
    "rule-name": "8",
    "object-locator": {
        "schema-name": "schema-name",            
        "table-name": "table-name"
    },
    "parallel-load": {
        "type": "partitions-auto",
        "number-of-partitions": 16,
        "collection-count-from-metadata": "true",
        "max-records-skip-per-page": 1000000,
        "batch-size": 50000
    }
  }

プライマリキーインデックス、参照整合性制約、データ操作言語 (DML) トリガー

ターゲットデータベースにインデックス、トリガーおよび参照整合性制約等が存在する場合、移行パフォーマンスに影響を及ぼすことがあります。影響は、タスクが全ロードであるか、CDCであるかによって異なります。

全ロードの場合

インデックス、参照整合性制約、データ操作言語 (DML) トリガーを削除する
移行時間が重要でない場合は、全ロード前にプライマリ、セカンダリインデックスは作成可能。しかし、参照整合性制約、およびトリガーは無効化する

全ロード⁺CDCの場合

CDCフェーズ前に、セカンダリインデックスを追加することを推奨
またCDCフェーズ前に、インデックス、参照整合性制約を作成してからCDCを実行することも可能。トリガーはカットオーバー直前に有効化する

バックアップとトランザクションログを無効にする

移行先データベース毎に以下のことが推奨されているようです。

Amazon RDSに移行する場合、カットオーバーの準備ができるまでバックアップ、マルチAZを無効化する
Amazon RDS以外に移行する場合、カットオーバー後までトランザクションログを無効化する

タスクの分割

タスクのテーブルが多すぎる場合や、複数のテーブルにLOB列が含まれている場合、タスクを複数のタスクに分割することでパフォーマンスが向上する場合があります。
共通トランザクションに関与しないテーブルセットがあればタスクの分割を試してみましょう。
ただし、各タスクは独立して動作するためタスクが多すぎるとソース、ターゲットデータベースへの負荷が増加する場合があり注意が必要です。

変更処理の最適化

AWS DMSは通常トランザクションモードで動作しますが、「最適化バッチ」オプション（Batch optimized apply mode）が別に存在します。
「最適化バッチ」オプションは、トランザクションを効率的にグループ化し、バッチで適用するため効率的に動作させることができます。
しかし、「最適化バッチ」オプションの性質上、トランザクションがコミット順に反映されない場合がある点に注意が必要です。

バッチ最適化適用オプションを使用すると、ほとんどの場合、参照整合性の制約に違反します。そのため、移行プロセス中にこれらの制約をオフにし、カットオーバー プロセスの一環として再度オンにすることをお勧めします。

LOBの移行

データベース移行の際、ラージバイナリオブジェクト（LOB）データを含むタスクは、パフォーマンスが低下することがあります。
このような場合、AWS DMSタスクの設定から、以下のいずれかの移行モードを選択できます。

完全LOBモード

サイズに関係なくLOBを移行する
LOBデータのサイズを確認しないため、移行速度が低下する可能性がある
通常、数メガバイトを超えるLOBがある場合に使用され、完全LOBモード専用のレプリケーションインスタンスとAWS DMSタスクの作成が推奨される

制限付きLOBモード

制限付きLOBモードは、LOB列データの最大サイズを指定し、指定したサイズを超えるデータは切り捨てられる
データが切り捨てられた場合、ログファイルに警告が出力される
このモードを使用するとパフォーマンスが向上するが、ソース上の最大LOBサイズを特定する必要がある
最大LOBサイズが数メガバイトを超えない場合は制限付きLOBモード、超える場合は完全LOBモードを選択する
大きなLOBデータが少なければ手動による移行も検討する

インラインLOBモード

インラインLOBモードは、小さいLOB、大きいLOBの両方をレプリケーションでき、完全LOBモード、制限付きLOBモード両方のメリットを組み合わせたもの
転送する最大LOBサイズを設定し、指定されたサイズ以下はインラインで転送され、サイズ以上のデータは完全LOBモードで転送される
ただし、インラインLOBモードはフルロードフェーズのみ機能する

AWS SCTのJavaメモリオプション

AWS SCTを使用してデータベースのスキーマを変換する際に、予期せず時間がかかることがあります。とくに大規模なデータベースの場合、この問題が顕著です。
しかし、AWS SCTのJavaメモリオプションを調整することで、この問題を解決できる場合があります。

設定手順は以下の通りです。

AWS SCT画面上部の「Settings」をクリックし、「Global settings」を選択する
「JVM options」タブをクリックし、「Edit config file」を選択する
確認ウィンドウが表示されたら、「OK」をクリックする
テキストエディターが開くので、Javaのメモリ使用可能最大量（Xmx）と利用可能最小量（Xms）を示す「JavaOptions」セクションに値を追記する
AWS SCTを再起動する

この作業を行う際には、以下の点に留意してください。

AWS SCTが使用するメモリが増えるため、ローカルマシンのメモリリソースがより多く消費される可能性がある
ソースと同じネットワーク内の別マシンにAWS SCTをインストールすることが推奨される

その他、確認箇所

上記にチューニング項目をまとめましたが、それ以外でCDCにおけるレイテンシー問題の解決策が以下にまとめられています。 CDCのパフォーマンス問題が発生したら合わせて確認してみてください。

AWS Database Migration Service のレイテンシーに関する問題のトラブルシューティング
 AWS DMS タスクでソースレイテンシーが高い場合のトラブルシューティング方法を教えてください。
AWS DMS タスクの高いターゲットレイテンシーをトラブルシューティングする方法を教えてください。

まとめ

AWS DMSにおけるチューニング項目をまとめました。
レプリケーションインスタンスのハードウェアからAWS DMSのタスク設定等、さまざまなチューニング項目があり、適切に行うことで移行パフォーマンスの向上が見込めます。
移行要件が厳しい、または大規模なデータベースを移行する際にチューニングは必要になってくると思いますので、どなたかの参考になれば幸いです。