Amazon Web Services ブログ
AWS Application Migration Service 使用時のレプリケーションボトルネックを特定する
多くの企業はオンプレミスのワークロードを AWS にリホスト (リフトアンドシフト) し、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを実行することから始めます。リホストする簡単な方法は、クラウドネイティブな移行サービスである AWS Application Migration Service (AWS MGN) を使用することです。
移行を効率化および迅速化するには、幅広いアプリケーションで機能する、再利用可能な自動化された移行方法を使用します。Application Migration Service は、アプリケーションを AWS にリホストするための推奨される移行サービスになります。
このブログ記事では、Application Migration Service を使用する際のサーバーレプリケーション速度に影響するボトルネック発生箇所について説明します。また、これらのボトルネックを特定する方法、対応手順を説明します。
Application Migration Serviceを使用した移行の概要
図 1 は、ソースサーバーから AWS でホストされているレプリケーションインスタンスへのエンドツーエンドのデータレプリケーションフローを示しています。この図では、データフロー内の潜在的なボトルネック箇所が分かるように、黒いひし形で示しています。
図1.AWS Application Migration Serviceを使用する際のデータフロー (黒いひし形は潜在的なボトルネックを示します)
ベースライン テスト
ベースラインのレプリケーション速度を測定するには、ターゲット のAWS リージョンとソースワークロードに最も近いリージョンの間で検証テストを行うことをお勧めします。たとえば、ソースワークロードがローマのデータセンターにあり、ターゲットリージョンがパリの場合、eu-south-1 (ミラノ) と eu-west-3 (パリ) の間でテストを実行します。これにより、レプリケーションは AWS バックボーン上で行われるため、理論上の帯域幅の上限を得ることができます。ターゲットリージョンが既にソースワークロードに最も近いリージョンである場合は、同じリージョン内からテストを実行します。
ネットワーク接続
オンプレミスの場所と AWS リージョンの間の接続を確立する方法はいくつかあります。
- Public internet
- VPN
- AWS Direct Connect
このセクションは、1.Public internetと2.VPNに関するものです。レプリケーション速度の問題に直面した場合、最初に検討すべきはネットワーク帯域幅です。内部ネットワーク内のソースマシンから速度テストを実行して、インターネットへの帯域幅を計算します。一般的なテストプロバイダーには、Cloudflare、Ookla、Googleなどがあります。これはインターネットへの帯域幅であり、AWS への帯域幅ではありません。
次に、データセンター内からのネットワークの経路情報を確認するには、traceroute
(Linux) または tracert
(Windows) を実行します。(ハードウェアの制限または構成が原因で) 異常な、または帯域幅を調整している可能性のあるネットワーク ホップを特定します。
Security Sockets Layer (SSL) のカプセル化を考慮しながら、データセンターとデータレプリケーションに使用されている AWS サブネット間の最大帯域幅を測定するには、SSL bandwidth tool を使用します。 (図 1 を参照)
移行元のストレージI/O
次にレプリケーションのボトルネックを調査する領域は、移行元のストレージです。サーバーの基盤となるストレージが競合のポイントになる可能性があります。ストレージの読み取り速度が上限に達している状況では、データレプリケーション速度に影響します。ストレージのI/O利用率が非常に高い場合、Application Migration Serviceによるブロックレプリケーションに影響する可能性があります。ストレージ速度を測定するには、次のツールを使用できます。
- Windows: WinSAT (または AS SSD Benchmar などの他サードパーティツール)
- Linux:hdparm
Application Migration Serviceを使用して移行を開始するときは、ソースストレージでの読み取り/書き込み操作を減らすことをお勧めします。
Application Migration Service レプリケーションサーバーのインスタンスサイズ
EC2 レプリケーションサーバーのインスタンスサイズもレプリケーション速度に影響する可能性があります。デフォルトのインスタンス サイズ (t3.small) を使用することをお勧めしますが、初回データ同期を高速化するなどのビジネス要件がある場合は、サイズを大きくすることができます。注:より大きなインスタンスを使用すると、コンピューティングコストが増加する可能性があります。
一般的なレプリケーションサーバーのインスタンスサイズ変更には、次のものがあります。
- 移行元のディスク数が 26本 未満: インスタンス タイプを m5.large に変更します。必要に応じて、インスタンス タイプを m5.xlarge 以上に増やします。
- 移行元のディクス数が 26 本 以上 (もしくは、m5 インスタンス タイプをサポートしていない AWS リージョンのサーバー): インスタンス タイプを m4.large に変更します。必要に応じて、m4.xlarge 以上に増やします
注:レプリケーションサーバーのインスタンスサイズを変更しても、データレプリケーションには影響しません。
データレプリケーションは変更したインスタンスタイプを使用して、中断したところから自動的に再開されます。
Application Migration Service Elastic Block Store レプリケーションボリューム
各ソースサーバー内の各ディスクで使用される Amazon Elastic Block Store (Amazon EBS) ボリュームタイプは、そのソースサーバーの設定でカスタマイズできます (ステージングディスクタイプの変更)。
デフォルトでは、500 GiB 未満のディスクはマグネティック HDD ボリュームを使用します。AWS のベストプラクティスでは、ビジネス上の必要がない限り、デフォルトの Amazon EBS ボリュームタイプを変更しないことをお勧めします。ただし、レプリケーションを高速化することを目的する場合、デフォルトの EBS ボリュームタイプの変更をします。
次の 2 つのオプションから選択できます。
- 低コストのスループット最適化 HDD (st1) オプションでは、低速になりますが、安価なディスクを利用します。
-
- このオプションは、次のような場合に検討してください。
- コストを低く抑えたい
- 頻繁に更新されない大容量ディスク
- 初期同期処理にどれくらいの時間がかかるかは気にしない
- このオプションは、次のような場合に検討してください。
- 高速な汎用 SSD (gp2) オプションでは、高速になりますが、高価なディスクを利用します。
-
- このオプションは、次のような場合に検討してください。
- 移行元のサーバーに書き込み速度の速いディスクがある、または一般的に高速のパフォーマンスが必要な場合
- 初期同期処理をスピードアップしたい
- スピードにもっとお金を払っても構わないと思っている
- このオプションは、次のような場合に検討してください。
ソースサーバーの CPU
データレプリケーション用にソースマシンにインストールされる Application Migration Service エージェントは、ほとんどの場合、CPUコアを1つ使用します (エージェントスレッドは複数のCPUコアにスケジュールできます)。CPUコア使用率が最大に達すると、これがレプリケーション速度の制限になる可能性があります。
CPUコア使用率を確認する方法:
- Windows: タスクマネージャーを起動し、「パフォーマンス」タブをクリックします。CPUグラフ(現在はコアの平均が表示されています)を右クリックし、[グラフの変更] > [論理プロセッサ] を選択します。これにより、個々のコアとその現在の使用率が表示されます (図2)。
図2.論理プロセッサの CPU 使用率
Linux: htop
をインストールし、ターミナルから実行します。htop
コマンドは、Application Migration Service/CE プロセスを表示し、CPU とメモリの使用率を示します。(これはマシン全体のものです)。CPUバーをチェックして、CPUが限界に達しているかどうかを判断できます (図3)。
図3.AWS Application Migration ServiceプロセスのCPU 使用率を評価
まとめ
この投稿では、Application Migration Service を使用する際のサーバーのレプリケーション速度に影響するボトルネック発生箇所について説明しました。移行中にこれらの重要な領域を調べて、レプリケーション速度を最適化できるかどうかを判断することをお勧めします。
関連情報
TAGS: Management & Governance, Management Tools, Migration & Transfer Services
この記事の翻訳はソリューションアーキテクトの須山健吾が担当しました。原文はこちらです。