AWS Application Migration Service を使用した移行 - AWS 規範ガイダンス
利点欠点最適なシナリオ

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

AWS Application Migration Service を使用した移行

AWS を使用するほとんどの大規模なlift-and-shift移行AWS Application Migration Service。このサービスは、直接接続されたブロックストレージデバイス (ハードドライブや SAN ドライブなど) に保存されているデータを、対応する AWSの Amazon Elastic Block Store (Amazon EBS) ストレージデバイスに移動することにより、物理レベルで機能します。基本的には、従来のバックアップ/復元手順 (ハードドライブのクローン作成) を実装しますが、ソースシステムとステージングエリアのターゲットストレージデバイス間の継続的なデータ保護 (CDP) 同期モードを実現することで、目標復旧時点 (RPO) を数秒近く、目標復旧時間 (RTO) を数分で実現します。

このブロックレベルのレプリケーション方法は、ネットワーク接続ストレージ (NAS)、ネットワークファイルシステム (NFS) 共有などの共有ドライブ、または共通インターネットファイルシステム (CIFS)/サーバーメッセージブロック (SMB) 共有をサポートしていません。移行時に移行されたシステムに直接アタッチされたブロックレベルのストレージのみをサポートします。(詳細については、SAN/NAS サポートに関する Application Migration Service のよくある質問を参照してください）。これにより、ほとんどのクラスターシステムはさまざまな実装の共有ストレージに依存するため、Application Migration Service によるレプリケーションの適用可能性が制限されます。詳細については、このページの「利点と欠点」セクションを参照してください。

ブロックレベルのレプリケーション方法では、レプリケーションエージェントをオペレーティングシステム (OS) AWS レベルでインストールする必要があり、そのエージェントは Windows または Linux オペレーティングシステムに基づく x86 プラットフォームのみをサポートします (「Application Migration Service でサポートされているオペレーティングシステム」を参照）。Non-x86プラットフォームは、この移行方法の対象外です。これには、ARM、RISC/CISC システム、PowerPC バリエーション、pSeries、iSeries、zSeries などの IBM システム、および AIX、HP-UX、Solaris、Linux for PowerPC、メインフレーム上の zLinux、その他の非 x86 アーキテクチャなどのそれぞれのオペレーティングシステムが含まれます。

AWS レプリケーションエージェントは、OS スタック内の仮想ファイルシステムデバイスドライバー* のレベルで動作し、基盤となるブロックレベルデバイス (ドライブ、ハードドライブ、直接アタッチされた SAN デバイスを含む) に書き込まれるデータブロックをキャプチャします。詳細については、以下の質問の Application Migration Service FAQ ページを参照してください。

* Wikipedia のファイルシステム、仮想ファイルシステム、デバイスドライバーの定義を参照してください。

利点

あらゆる規模のlift-and-shift移行の場合、Application Migration Service には多くの利点があります。

  • レプリケーションの設定は簡単です (急勾配の学習曲線は必要ありません）。

  • ソースマシンにエージェントをロールアウトすることで、スケーリングが高速になります。

  • クラウド移行ファクトリーを使用することで、ほとんどの手動タスクの自動化、複数のマシンの管理、移行ウェーブのオーケストレーションが可能となります。

  • これは幅広い x86 オペレーティングシステムアーキテクチャをサポートしています。

  • あらゆるタイプのソース環境 (オンプレミスデータセンター、その他のクラウド、その他) をサポートしています AWS リージョン。

  • アプリケーションに依存しないため、ソースサーバーで実行されているすべてのアプリケーションをサポートします。

  • ライセンスや購入は必要ありません。 AWS はpay-as-you-goを提供するため、長期契約や複雑なライセンスなしで、使用期間中のみサービスに対して料金を支払います。Application Migration Service は、サーバーごとに 90 日間の無料期間を提供します。これは、ほとんどの移行に十分です。詳細については、 AWS ウェブサイトのAWS Application Migration Service 「 料金表」を参照してください。

欠点

Application Migration Service などのブロックレベルのレプリケーションツールを使用すると、次のコーナーケースや考慮事項が発生する可能性があります。

  • Application Migration Service は、マウントされた共有ファイルシステムや、CIFS/SMB や NFS ファイルシステムなどの NAS などの共有ストレージデバイスをサポートしていません。NAS または共有ファイルシステムのレプリケーション方法の詳細については、「MGN レプリケーションエージェントによる NFS 共有の移行 (AWS re:Post 記事）」およびAWS 「大規模な移行における共有ファイルシステムの移行 (AWS 規範ガイダンスパターン）」を参照してください。

  • Application Migration Service は、デバイスドライバーレイヤーを介して共有ストレージを OS レベルに表現する方法に制限があるため、共有ストレージを使用するほとんどのクラスターファイルサーバーまたはデータベースクラスター設定をサポートしていません。たとえば、Storage Space Direct (S2D) オプションを使用する Microsoft SQL Server クラスターはサポートされていません。ただし、 Application Migration Service を使用して、共有ブロックストレージを持つ他のタイプのクラスター化されたシステムをレプリケートできます。 Windows Server フェイルオーバークラスター (WSFC) のフェイルオーバークラスターインスタンス (FCI) 設定の共有ストレージなど、 ブログ記事「Microsoft Windows クラスターを CloudEndure Migration AWS を使用して に移行する」で説明されているように、 外部 SAN 配列 (iSCSI 接続) から公開されるストレージ、 特定のコーナーケースでは、 および一部の Microsoft SQL Server Always On 可用性グループ (AAG) クラスターを使用します。一般的に、Application Migration Service は、移行中にストレージデバイスがサーバーに完全に存在するサーバーからのブロックレベルのデバイスのレプリケーションをサポートします。( AWS レプリケーションエージェントはサーバーにインストールする必要があり、デバイスはレプリケーションのためにエージェントに表示される必要があります）。ただし、これらのシナリオはすべて非常に具体的な手順を必要とし、カットオーバー期間が長くなります。 

  • データ変更の頻度が高いシステム (OLTP データベースなど) は、パフォーマンスやネットワーク要件が高い場合があり、移行作業が複雑になります。

  • 計画された移行期間とカットオーバー時間枠内に転送されるデータ量に対して、ネットワーク帯域幅が十分でなければなりません。これは、Application Migration Service が とは異なり、オフライン配送オプションを提供していないためですAWS Snowball。 

  • 移行には、RTO から数分以内のわずかなダウンタイムが必要です。Application Migration Service は移行プロセスの一環として EBS スナップショットを使用します。このようなスナップショットから作成された新しい EBS ディスクは、最初はパフォーマンスが低下します。データベースの読み取りパターンによっては、移行したデータベースのパフォーマンスが最大になるまでの有効なカットオーバー時間が長引く場合もあります。 

最適なシナリオ

Application Migration Service は、前の lift-and-shift移行を完全にカバーしますが、欠点はほとんどありません。このツールは、データベースクラスターなどコーナーケースの大半を処理できますが、これらのシステムに必要なカットオーバー期間が長くなり、移行要件が満たされる場合に限ります。 

以下のセクションで、2 つのシナリオについてさらに詳しく説明します。

  • 複数の移行ウェーブを伴う大規模な移行

  • ダウンタイムを最小限に抑える単一アプリケーションの移行 

複数の移行ウェーブを伴う大規模な移行

大規模な移行の例は、サイズと速度の要件を特徴とするデータセンターの終了です。また、通常、データセンターのリース契約の終了など、特定の時間制約も含まれます。この場合、アプローチは規模によって決まります。移行ウェーブは、データベースを含むアプリケーションごとに決定され、グループ分けされます。各ウェーブには特定のダウンタイム要件を伴う準備、移行、最終カットオーバーフェーズが計画されています。 

各移行ウェーブ内では、Application Migration Service のブロックレベルのレプリケーションを使用してデータベースサーバーを大規模に移動するのが最適です。ただし、別の移行アプローチが必要になる可能性のある以下の特殊なケースについては、いくつかの例外があります。

  • 大部分がクラスター化されたデータベースシステム

  • 変更率が利用可能なネットワークスループットを上回る (レプリケーションラグが発生する可能性がある) データベースシステム 

特殊なケースごとに、ダウンタイム要件と別の移行ツールを使用した場合の作業量とのトレードオフを検討してください。場合によっては、個別のツールを使用し、特定のシステムに異なるプロセスを作成するのではなく、すべてのシステムに同じ移行アプローチを使用する方がはるかに簡単です。Application Migration Service が特定のシステムのダウンタイム要件をサポートしていない場合は、「ネイティブデータベースツールを使用した移行」セクションで説明されている方法のいずれかを使用することをお勧めします。

単一アプリケーションの移行

単一アプリケーションシナリオでは、移行中のダウンタイムが最小限またはほぼゼロで済む単一のビジネスクリティカルなアプリケーション、またはそのようなアプリケーションをいくつか移行するためのきめ細かなアプローチをとります。移行の範囲は、以前の (大規模な移行) シナリオのスピードとスケールの要件とは対照的に、ビジネスの重要度とダウンタイムの要件によって異なります。アプリケーションが Application Migration Service の RTO 内でダウンタイムを許可する場合は、前述の大規模な移行と同じ方法で処理する必要があります。 

ただし、カットオーバー時間が可能な限り最小限に近づかなければならない場合、例えば、移行されたデータベースがフルパフォーマンスで動作するのに長い読み取りパターンを持ち、カットオーバーウィンドウを小さくする必要がある場合は、より詳細で詳細なアプローチを検討する必要があります。一般に、このアプローチには追加の手順と要件が必要であり、より多くの労力と時間が求められます。手順の 1 つは、データベース移行とアプリケーションサーバーの移行を切り離し、次のセクションで説明するデータベース移行ツールを使用して、ソースデータベースとターゲットデータベースの同期を維持します。同期はさまざまな方法で実行できます。各方法には利点と欠点があり、ダウンタイムの量と同期の複雑さの間に異なるトレードオフがあります。それでも、ソース環境とターゲット環境の間でデータベースを同期させておくと、データベースレイヤーとアプリケーションレイヤーのリンクを解除できます。アプリケーションサーバーが永続データをローカルに保存せず、すべてをデータベースレイヤーに渡すと仮定すると、同期によりアプリケーションレイヤーからダウンタイムの制限も削除されます。 

データベースレイヤーとアプリケーションレイヤーを切り離すと、前のシナリオのように Application Migration Service を使用してアプリケーションサーバーを移行できます。ソースシステムが稼動中で、データを処理し、それをデータベースレイヤーに保存している間に、ターゲット環境でターゲットアプリケーションサーバーを起動できます。データベースレイヤーはすでにターゲットと同期しているため、カットオーバー時間は最小限です。ネットワークの切り替えと、顧客のリクエストを古いソースシステムからターゲット環境にリダイレクトするだけで済みます。これを行うには、ブルー/グリーンデプロイのガイダンスに従って複数の方法を使用できます。通常、DNS エンドポイントの切り替え、加重 DNS ゾーンの使用、有効期限 (TTL) の DNS 伝播遅延を削減するために AWS Global Accelerator を使用、などの方法があります。