レプリケーションインスタンス向けの最適なサイズの選択 - AWS データベース移行サービス
考慮すべき要素一般的な問題ベストプラクティス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

レプリケーションインスタンス向けの最適なサイズの選択

適切なレプリケーション インスタンスの選択は、ユースケースのいくつかの要因によって異なります。レプリケーション インスタンスリソースの使用方法を理解しやすいように、次の説明をご参照ください。全ロード + CDCタスクの一般的なシナリオについて説明します。

全ロードタスク中に、 はテーブルを個別に AWS DMS ロードします。デフォルトでは、一度に 8 つのテーブルがロードされます。 は全ロードタスク中にソースへの継続的な変更を AWS DMS キャプチャするため、変更は後でターゲットエンドポイントに適用できます。変更はメモリにキャッシュされます。使用可能なメモリがなくなると、変更はディスクにキャッシュされます。テーブルのフルロードタスクが完了すると、 はキャッシュされた変更をターゲットテーブルに AWS DMS すぐに適用します。

テーブルのキャッシュされた変更がすべて適用されると、ターゲットエンドポイントはトランザクション上一貫性のある状態になります。この時点で、ターゲットは最後にキャッシュされた変更に関してソースエンドポイントと同期しています。 AWS DMS その後、 はソースとターゲットの間で継続的なレプリケーションを開始します。そのために、 はソーストランザクションログから変更オペレーション AWS DMS を受け取り、トランザクションの整合性のある方法でターゲットに適用します。（このプロセスでは、バッチ最適化適用が選択されていないことを前提としています）。 は、可能であれば、レプリケーションインスタンスのメモリを介して継続的な変更を AWS DMS ストリーミングします。それ以外の場合、 はターゲットに適用できるようになるまで、レプリケーションインスタンスのディスクに変更を AWS DMS 書き込みます。

レプリケーション インスタンスが変更処理をどのように処理するか、およびそのプロセスでメモリがどのように使用されるかについて、何らかの制御があります。変更処理のチューニング方法の詳細については、「変更処理のチューニング設定」をご参照ください。

考慮すべき要素

メモリとディスク容量は、ユースケースに適したレプリケーションインスタンスを選択する際の重要な要素です。レプリケーションインスタンスを選択するために分析すべきユースケースの特徴について次に説明します。

  • データベースとテーブルのサイズ

    データ量は、フルロードパフォーマンスを最適化するためのタスクの設定を決定するうえで役立ちます。例えば、1 TB スキーマが 2 つある場合、テーブルをパーティション化して 500 GB の 4 つのタスクの分割して、それらを並列で実行できます。考えられる並列処理は、レプリケーションインスタンスで使用できるCPUリソースによって異なります。このため、フルロードパフォーマンスを最適化するには、データベースのサイズとテーブルのサイズを把握することをお勧めします。これにより、実行できるタスクの数を判断できます。

  • ラージオブジェクト

    移行の範囲内のデータ型がパフォーマンスに影響を及ぼす場合があります。特に、大きなオブジェクト (LOBs) はパフォーマンスとメモリ消費量に影響します。LOB 値を移行するために、 は 2 ステップのプロセス AWS DMS を実行します。まず、 はLOB値なしで行をターゲット AWS DMS に挿入します。2 つ目は、行を LOB値で AWS DMS 更新します。これはメモリに影響するため、ソース内のLOB列を特定し、そのサイズを分析することが重要です。

  • ロード頻度とトランザクションのサイズ

    ロード頻度と 1 秒あたりのトランザクション (TPS) は、メモリ使用量に影響します。TPS または データ操作言語 (DML) アクティビティの数が多いと、メモリの使用率が高くなります。これは、変更がターゲットに適用されるまで が変更をDMSキャッシュするためです。中にCDC、これによりスワップ (メモリオーバーフローによる物理ディスクへの書き込み) が発生し、レイテンシーが発生します。

  • テーブルキーと参照整合性

    テーブルのキーに関する情報によって、データの移行に使用するCDCモード (バッチ適用またはトランザクション適用) が決まります。通常、トランザクションの適用はバッチの適用よりも遅くなります。長時間実行されるトランザクションの場合、多くの変更を移行する必要がある可能性があります。トランザクション適用を使用する場合、バッチ適用と比較して、変更を保存するためにより多くのメモリが必要になる AWS DMS 場合があります。プライマリキーなしでテーブルを移行すると、バッチ適用は失敗し、DMSタスクはトランザクション適用モードに移行します。中にテーブル間で参照整合性がアクティブになるとCDC、 はデフォルトでトランザクション適用 AWS DMS を使用します。トランザクション適用と比較したバッチ適用の詳細については、DMS「バッチ適用機能を使用してCDCレプリケーションパフォーマンスを向上させるにはどうすればよいですか？」を参照してください。

このようなメトリクスを使用して、レプリケーションインスタンスをコンピューティング最適化またはメモリ最適化する必要があるかを判断します。

一般的な問題

移行中にレプリケーションインスタンスでのリソースの競合の原因となる次のとおりの一般的な問題に直面する場合があります。レプリケーションインスタンスメトリクスの詳細については、「レプリケーションインスタンスのメトリクス」を参照してください。

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

  • レプリケーションインスタンスに割り当てられるディスクサイズは、必要となるより小さいサイズでも構いません。ディスクサイズは、メモリ内のデータがオーバーフローした場合や、タスクログの保存にも使用されます。最大値はそれにもIOPS依存します。

  • 複数のタスクまたは並列処理の高いタスクを実行すると、レプリケーションインスタンスのCPU消費に影響します。これにより、タスクの処理が遅くなり、レイテンシーが発生します。

ベストプラクティス

レプリケーションインスタンスのサイジングを行う際は、次の 2 つの最も一般的なベストプラクティスの採用を検討します。詳細については、「AWS Database Migration Service のベストプラクティス」を参照してください。

  1. ワークロードのサイジングを行い、コンピューティング集約型であるか、メモリ集中型であるかを判断しておきます。これに基づいて、レプリケーションインスタンスのクラスとサイズを決定できます。

    • AWS DMS はメモリLOBs内の を処理します。この操作にはかなりの量のメモリが必要です。

    • タスクの数とスレッドの数は、CPU消費に影響します。フルロード操作中は MaxFullLoadSubTasks の使用を最大 8 に抑えます。

  2. フルロード中のワークロードが高い場合は、レプリケーションインスタンスに割り当てられるディスク容量を増やします。これにより、レプリケーションインスタンスはIOPS割り当てられた最大値を使用できます。

上記のガイドラインは考えられるすべてのシナリオをカバーしているわけではありません。レプリケーションインスタンスのサイジングを行う際は、特定のユースケースの詳細を考慮することが重要です。

前述のテストでは、 CPUとメモリはワークロードによって異なります。特に、メモリLOBsに影響し、タスク数または並列処理が に影響しますCPU。移行の実行後、レプリケーションインスタンスIOPSの CPU、解放可能なメモリ、空きストレージ、 をモニタリングします。収集したデータに基づいて、必要に応じてレプリケーション インスタンスのサイズを増減することができます。