Amazon Web Services ブログ

AWS DMS は、R4 タイプのインスタンスをサポートするようになりました。適切なインスタンス AWS DMS 移行を選択できます

AWS Database Migration Service (AWS DMS)　でAmazon EC2 の R4 メモリに最適化されたインスタンスのサポートをお知らせ致します。これらのインスタンスには、より多くのメモリとより高いネットワーク帯域幅があり、高いスループットとメモリ集約的な操作を必要とする移行をサポートするのに役立ちます。

ここには、DMS でサポートされているインスタンスの一覧が表示されます。

DMS が新しいインスタンスクラスをサポートするようになったので、どのインスタンスクラスを選択するのか迷うかもしれません。

状況に適したインスタンスクラスはどれですか？

この質問に答える前に、各インスタンスクラスを DMS でどのように使用できるかを見てみましょう：

  • T2インスタンス：軽負荷のために設計されており、時折パフォーマンスが急上昇します。このインスタンスクラスを使用して、DMS について学習し、小さな断続的なワークロードの移行をテストすることをお勧めします。
  • C4インスタンス：クラス最高のCPU性能を備えた計算集約型ワークロード向けに設計されています。DMSは、特に異機種間の移行やレプリケーション（たとえば、Oracle からPostgreSQL へ）を実行する場合、CPUを集中的に使用することがあります。C4インスタンスは、これらの状況に適しています。
  • R4インスタンス：メモリ集約型ワークロード用に設計されています。これらのインスタンスには、vCPUあたりのメモリが含まれます。DMS を使用するハイスループットトランザクションシステムの継続的な移行やレプリケーションは、時には大量のCPUとメモリを消費することがあります。R4インスタンスは、これらの状況に適しています。

これらの点を念頭に置いて、AWS DMS を使用して移行を実施する際に、C4 および R4 タイプのインスタンスが要件に適合できるかどうかを理解するための例をいくつか紹介します。

フルロードフェーズでの R4 の利点

以前のブログ記事で議論したように、PostgreSQL は、コンマ区切り値（CSV）ファイルを使用して値が引き渡されるターゲットエンジンです。この場合、DMS は移行を開始するときに次のことを行います：

  1. DMS は、ソーステーブルからレプリケーションインスタンスメモリにデータをアンロードして、データを含む CSV ファイルを準備します。この CSV ファイルのサイズは、パラメータ maxFileSize に依存します。
  2. DMS は CSV ファイルをディスクに保存し、COPYコマンドを使用してデータを PostgreSQL にプッシュします。

このタイプの移行を実行する場合、maxFileSize 値を大きくするとスループットが大幅に向上します。私たちは、maxFileSize の最大が1,048,576KB（1.1 GB）まで向上し、移行速度が大幅に改善されていることを実際に確認しました。バージョン 2.x 以降、DMS ではこのパラメータを 30 GBに増やすことが可能になりました。

次の図に、より大きな maxFileSize 設定を使用して、データベースに対してフルロードを実行した場合の、C4.4Xlarge インスタンスのメモリ使用率を示しています。

約 30 分後、メモリが枯渇しました：

[TARGET_LOAD] E：ロードコマンドの実行に失敗しました。メモリを割り当てることができません。 [12]（csv_target.c：1038）

前述のテストから、より多くのテーブルでより大きな maxFileSize を使用すると、より多くのメモリが必要であると結論づけることができます。これは、複数のテーブルに対して、テーブルデータが、レプリケーションインスタンスメモリーに並列にアンロードされているために発生します。

これに対して、R4.4xlarge インスタンスで同じ設定で同じ移行を実施しました。インスタンスには、これに匹敵する C4インスタンス（c4.4xlarge）の 4 倍のメモリが付属しています。したがって、より小さなテーブルのいくつかをより速く完了させ、より大きなテーブルが余分なメモリを使用して移行を完了できるようにします。

私たちの環境で、このテストに使用した maxFileSize が増加したことを考慮し、ここではフルロードのみのテストの概要を示します：

  • c4.4xlarge（デフォルト maxFileSize） – 約 3.6 テラバイトのデータのフルロードは、約 3 日と12 時間後に完了しました。
  • c4.4xlarge と maxFileSize が 1.1 GB に増加しました – タスクはメモリ不足のために失敗しました。
  • maxFileSize の r4.4xlarge は、1.1 GB に増加しました。約 2 日と 6 時間で、約 3.6 テラバイトのデータが完全にロードされました。

結論として、注目すべきは、R4 インスタンスよりも速く巨大なテーブルのクロスエンジンを移行する場合は、R4 インスタンスクラス（特にフルロードフェーズの場合）を使用することができるという点です。この提案は、MySQL ベースのエンジンや PostgreSQL ベースのエンジン、Amazon Redshift などの特定のターゲットエンジンにのみ適用されます。Amazon CloudWatch 監視を使用した簡単なテスト移行をすることにより、移行作業でより多くのメモリが必要かどうかがわかります。

進行中のレプリケーションフェーズにおける R4 の利点

例に入る前に、DMS エンジンの Change Data Capture（CDC）内部を見てみましょう。

フルロード + CDC タスク（バルクロードと進行中のレプリケーション）を実行しているとします。この場合、タスクには、メタデータやその他の情報を格納する独自の SQLite リポジトリがあります。DMS がフルロードを開始する前に、次の手順が実行されます：

  1. DMSは、ソースエンジンのトランザクションログから、移行するテーブルに対する変更のキャプチャを開始します（これらをキャッシュされた変更と呼びます）。フルロードが完了すると、キャッシュされたこれらの変更が収集され、ターゲットに適用されます。キャッシュされた変更の量に応じて、これらの変更は、最初に収集されるメモリから直接設定しきい値まで適用できます。また、ディスクから適用して、メモリに保持できないときに変更が書き込まれるようにすることもできます。
  2. キャッシュされた変更が適用されると、デフォルトでDMSはターゲットインスタンスに対してトランザクション適用を開始します。

適用されキャッシュされた変更フェーズと進行中のレプリケーションフェーズでは、DMS は 2 つのストリームバッファを使用します ― 1 つは着信データ用で、もう 1 つは送信データ用です。DMS はソーターと呼ばれる重要なコンポーネントも使用します。ソーターは別のメモリバッファです。ソーターコンポーネントの 2 つの重要な用途（他にもあります）：

  1. すべてのトランザクションを追跡し、関連するトランザクションのみを送信バッファに転送するようにします。
  2. トランザクションは、ソースと同じコミット順で転送されます。

ご覧のとおり、このアーキテクチャでは DMS の CDC 用に 3 つの重要なメモリバッファがあります。これらのバッファのいずれかがメモリ不足に陥った場合、移行でパフォーマンス上の問題が発生し、障害が発生する可能性があります。

このアーキテクチャーには、1 秒あたりのトランザクション数が多い（TPS）負荷の高いワークロードを接続すると、R4 インスタンスによって提供される余分なメモリーが役に立つことがわかります。R4 インスタンスを使用すると、多数のトランザクションをメモリに保持し、進行中のレプリケーション中にメモリ圧の問題を防ぐことができます。現在進行中のレプリケーションに、R4 インスタンスを使用する必要があるかどうかを判断するためのヒントをいくつか紹介します：

  1. 公開された CloudWatch メトリックを使用してメモリ使用率を確認します。これには、空きメモリが表示され、インスタンスやレプリケーションタスクのメモリ使用率を確認できます。高い場合は、ベストプラクティスを参照して、メモリ使用率が考慮されているかどうかを確認してください。
  2. データベース移行のデバッグに関するthree-part seriesを確認し、必要なデバッグを行います。
  3. 私たちは、一部のワークロードが、CDC フェーズで CPU バインディングよりもメモリに拘束されていることを確認しています。これが、あなたのワークロードに当てはまる場合は、C4 から R4 へのインスタンスクラスを削除して、メモリを増やし、コストを節約することができます。たとえば、R4.2xlarge は C4.4xlarge よりも安く、CDC で使用できるメモリが増えます。
  4. メモリが枯渇していないか確認します。DMS タスク CloudWatch Logs で、メモリ枯渇ログメッセージを簡単に見ることができます。たとえば、次のようになります： 
    [TARGET_LOAD] E：ロードコマンドの実行に失敗しました。メモリを割り当てることができません。 [12]（csv_target.c：1038）
  5. 空きメモリの CloudWatch アラームを追加すると、メモリ使用量が多い場合に通知がされるため、必要に応じてさらに多くのメモリを持つインスタンスクラスを使用できます。

 

これらの手順を実行し、タスクが正当に多くのメモリを必要とする場合は、R4 インスタンスクラスへの切り替えを検討してください。

結論として、R4 タイプのインスタンスのサポートを開始することに興奮しています。これらを使用して、大きなトランザクションの多いワークロードのスループットを向上させることができるからです。R4 インスタンスは、オブジェクトやコードの変換など、移行の他の複雑な部分にさらに集中するのに役立ちます。さらに、単一の大きな R4 DMS インスタンスに複数のタスクを配置することもできます。これは、特定の時点で複数の小さなインスタンスを複数のタスクに使用する場合に比べて、コストとオーバーヘッドを削減できることを意味します。

コメント欄にメモを記入してください。できるだけ早くご返信させていただきます。DMSの新しいメモリー最適化インスタンス・クラスを使用して、楽しい移行作業を！

著者について

Arun Thiagarajan は、アマゾン ウェブ サービスの Database Migration Service (DMS) & Schema Conversion Tool (SCT) チーム でデータベースエンジニアを務めています。 彼は、データベースの移行に関する課題に取り組み、お客様と緊密に協力して DMS サービスの真の可能性を実現するのを支援しています。DMS と SCT を使用して 100 種類のデータベースを AWS クラウドに移行するのを手伝ってくれました。