Amazon Web Services ブログ
AWS DMS 拡張モニタリングを使用したリソース配分とパフォーマンス分析を理解する
本投稿は、Suchindranath Hegde と Mahesh Kansara と Balaji Baskar による記事 「Understanding resource distribution and performance analysis using AWS DMS enhanced monitoring」を翻訳したものです。
AWS Database Migration Service (AWS DMS) を使用する際、レプリケーションの遅延、タスクの停滞、リソースのボトルネックが発生する可能性があります。そのため、根本原因を迅速に特定することが重要になる場合があります。
AWS DMS は Amazon CloudWatch メトリクスを提供していますが、時には複数のタスクにわたって情報を関連付ける必要があります。統合されたビューがないと、問題解決が遅れる可能性があります。ここで 拡張モニタリングダッシュボード が価値ある機能となります。
拡張モニタリングダッシュボードは、データベース移行タスクとレプリケーションインスタンスの重要なメトリクスを可視化する包括的なモニタリングツールです。タスクとレプリケーションインスタンスという 2 つの主要なビューを提供し、直感的な画面とウィジェットを通じて、さまざまなパフォーマンスメトリクス、リソース使用率、ステータス情報を表示します。
この AWS DMS の画面は、追加コストなしで利用できます。
この投稿では、拡張モニタリングダッシュボードをどのように使用できるかがわかるようないくつかのユースケースについて紹介します。
拡張モニタリングダッシュボードの概要
このセクションでは、拡張モニタリングダッシュボードで利用可能な様々なビューの内訳を説明します。
次のスクリーンショットでは、us-east-1 AWS リージョンで構成されたリソースの数と、CloudWatch Alerms および Service Health のセクションを確認できます。
また、タスクステータスセクションを見て、タスクのステータスの内訳を確認することもできます。
さらに、以下のスクリーンショットに示すように、ログストリームにアクセスすることで CloudWatch ログを詳細に調査できます。
次のセクションでは、顧客とのやり取りに基づいたユースケースを紹介し、拡張モニタリングダッシュボードの使用方法を説明します。
リソース配分の分析を理解する
各タスクを専用のレプリケーションインスタンスで実行することも、単一のレプリケーションインスタンスで複数の AWS DMS タスクを実行することもできます。様々なタスク設定やカスタマイズがマイグレーションにどのように影響するかを理解することは、AWS DMS レプリケーションがワークロードを処理できるように適切にプロビジョニングされていることを確認するのに役立ちます。拡張モニタリングダッシュボードを使用すると、様々な AWS DMS タスク間のメモリ配分を理解し、タスクの移動をして別のレプリケーションインスタンスにワークロードを分散させるか、タスクを変更してワークロードを統合するかを選択できます。
これを説明するために、dms.r6i.large の レプリケーションインスタンスを起動し、既存のデータを移行し、継続的な変更をレプリケートする (訳者注 : 新しいナビゲーションの場合 「移行および複製」) オプションを使用して、異なるタスク設定を持つ 3 つの AWS DMS タスクを作成しました。
次のスクリーンショットは、タスク dmstaskflcdc が他の 2 つのタスクと比較してより多くのメモリを消費していることを示しています。この情報を基に、タスク dmstaskflcdc を専用のレプリケーションインスタンスに移動するか、同じインスタンスクラスでより多くのタスクを実行することを前提にして基盤となるレプリケーションインスタンスをスケールアップするか、を判断することができます。
パフォーマンスのトラブルシューティング
CloudWatch メトリクスを比較する際、移行中の問題点を理解し、トラブルシューティングをするためにウィジェットを追加できます。
これを説明するために、Amazon Relational Database Service (Amazon RDS) for SQL Server から Amazon Kinesis へ データ変更のレプリケーション (訳者注 : 新しいナビゲーションの場合 「複製のみ」) オプションを使用して AWS DMS タスクを作成しました。
タスクの実行中に、ソースにデータを挿入したところ、CloudWatch ログに次のようなメッセージが表示されました：
この警告は、ターゲットがソースでのデータの取り込み速度に追いつけていないことを示しています。
これをより深く理解するために、タスクメトリクス に関連するウィジェット (CDCLatencyTarget、CDCLatencySource、CDCChangesDiskTarget) を追加して、変更が AWS DMS レプリケーションインスタンスの基盤となるストレージに蓄積され、コミットを待っている状態であることを確認することができます。
考えられる原因の 1 つは、Kinesis Streams に十分なシャードがプロビジョニングされていなかったことです。
Kinesis のシャード数を増やすと、再びほぼリアルタイムにレプリケーションされることが確認できます。
パフォーマンスのベンチマーク
さまざまなタスクにわたってベンチマークを実行し、指標を比較して、変化がパフォーマンスに反映されているかどうかを確認できます。たとえば、次の例は、RDS for SQL Server インスタンスのテーブルから Amazon Aurora PostgreSQL 互換エディション のクラスターに 6,000 万レコードを移行する際の、フルロード移行に関係する CloudWatch メトリクスを示しています。
2 つのタスクを比較しました：デフォルト設定の dmsfullloadtest と、MaxFullLoadSubTasks を 16 に設定した dmsfullloadtest-2 です。
これにより、MaxFullLoadSubTasks 設定がフルロード中のスループットにどのような影響を与えるかを理解することができます。
次のスクリーンショットは、デフォルト設定で dmsfullloadtest タスクが 1 秒あたり 235,722 行のスループットを達成したことを示しています。
しかし、dmsfullloadtest-2 タスクの MaxFullLoadSubTasks 数を 16 に増やすと、スループットは 515,599 行/秒に大幅に向上しました。
このベンチマークのエクササイズでは、AWS DMS 構成を最適化してフルロードで移行中のパフォーマンスを最大化するのに役立つ、強化されたモニタリングダッシュボードの価値を示しています。
まとめ
この投稿では、拡張モニタリングを使用できるいくつかのユースケースについて説明しました。拡張モニタリングを使用することで、既存の AWS DMS モニタリング設定を補完し、モニタリングをより適切に制御し、タスクとレプリケーションインスタンスのモニタリングに関する重要なメトリクスの可視性を得ることができます。
詳細については、拡張モニタリングダッシュボードをご参照ください。