レプリケーションインスタンス用に最適なサイズを選択する

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

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

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

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

考慮すべき要素

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

• Database MIDR

  データ量は、全負荷時のパフォーマンスを最適化するためのタスク構成を決定するのに役立ちます。たとえば、2 つの 1 TB スキーマでは、テーブルを 500 GB の 4 つのタスクに分割し、それらをparallel 実行できます。可能な並列処理は、レプリケーションインスタンスで使用可能な CPU リソースによって異なります。そのため、データベースとテーブルのサイズを理解して、全負荷時のパフォーマンスを最適化することをお勧めします。実行できるタスクの数を判断するのに役立ちます。

• 大きなオブジェクト

  マイグレーションスコープに存在するデータ型は、パフォーマンスに影響する可能性があります。特に、ラージオブジェクト (LOB) はパフォーマンスとメモリ消費量に影響します。LOB 値を移行するには、2 AWS DMS つのステップに分かれます。まず、LOB AWS DMS 値のない行をターゲットに挿入します。次に、行を LOB AWS DMS 値で更新します。これはメモリに影響を与えるため、ソース内の LOB 列を特定してそのサイズを分析することが重要です。

• 負荷頻度とトランザクションサイズ

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

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

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

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

一般的な問題

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

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

• レプリケーションインスタンスに割り当てられるディスクサイズは、必要以上に小さくてもかまいません。ディスクサイズは、メモリ内のデータがこぼれたときに使用されます。また、タスクログの保存にも使用されます。最大IOPSもそれに依存します。

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

ベストプラクティス

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

1. ワークロードのサイズを決めて、それがコンピュータを大量に消費するのかメモリを大量に消費するのかを判断します。これに基づいて、レプリケーションインスタンスのクラスとサイズを決定できます。

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

   • タスクの数とスレッドの数は CPU 消費量に影響します。MaxFullLoadSubTasks全負荷運転中は、8 個以上使用しないでください。

2. 全負荷時に負荷が高い場合は、レプリケーションインスタンスに割り当てられるディスク容量を増やしてください。これにより、レプリケーションインスタンスは割り当てられた最大 IOPS を使用できます。

前述のガイドラインは、考えられるすべてのシナリオを網羅しているわけではありません。レプリケーションインスタンスのサイズを決定する際に、特定のユースケースの詳細を検討することが重要です。

前述のテストでは、CPU とメモリはワークロードによって異なることが示されています。特に、LOB はメモリに影響し、タスク数または並列処理は CPU に影響します。移行が実行されたら、レプリケーションインスタンスの CPU、空きメモリ、空きストレージ、および IOPS を監視します。収集したデータに基づいて、必要に応じてレプリケーション インスタンスのサイズを増減することができます。