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

Windows 環境検出

Windows Server AWS Application Migration Service、Linux、その他の x86 ベースのオペレーティングシステムとそのワークロードを に移行するなど、現在利用可能なテクノロジー AWS を使用すると、かなり簡単です。ただし、これらのワークロードを適切に動作させ、大規模に実行するには、さまざまな課題があります。このセクションは、Microsoft ワークロードを迅速かつ安全、スムーズに移行できる移行に関する考慮事項を特定することを目的としています。

評価

最小限の計画と自動化で小規模な移行 (100 台のサーバーを含む移行など) を「ブルートフォース」することはできますが、この方法を使用して 500 台以上のサーバーを移動することはできません。以下の考慮事項は、大規模な移行を成功させる主な要因であり、MRA (Migration Readiness Assessment) を使用して、焦点を当てる検討領域を特定できます。

エンタープライズアーキテクチャ

環境内のテクノロジー負債が多いほど、移行は困難です。正常なエンタープライズアーキテクチャプログラムを持つ組織は、環境を現在および最新バージョンのソフトウェアとシステム (多くの場合、メジャーリリースの N および N -1 バージョン) に制限するよう努めています。これにより、考慮する必要があるシナリオの数を減らすだけでなく、新しいリリースの進歩も活用できます。例えば、Windows Server 2012、Windows Server 2008、および古いバージョンの Windows Server は、Windows Server 環境では、現在のバージョンよりも自動化が徐々に困難になります。古いバージョンやサポートされていないバージョンでも、ライセンスはより困難です。

標準化と設定管理

環境の標準化も考慮すべきもう 1 つの要素です。手動で構築され、維持されている環境を持つ組織は、ペットのようになります。各システムは一意であり、標準化されたイメージ、Infrastructure as Code (IaC)、または継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用して構築した場合よりも、はるかに多くの設定の組み合わせがあります。

例えば、個々のサーバーを手動で移行するのではなく、移行時に IaC または CI/CD を使用して一般的なウェブサーバーを再構築するのがベストプラクティスです。また、データベース、ファイル共有、リポジトリなどのデータストアにすべての永続データを保存することもベストプラクティスです。システムが IaC または CI/CD を使用して再構築されない場合は、少なくとも設定管理ツール (Puppet、Chef、Ansible など) を使用して、使用しているサーバーを標準化する必要があります。

良いデータ

優れたデータは、移行を成功させるための重要な要素でもあります。現在のサーバーとそのメタデータに関する正確なデータは、自動化と計画に不可欠です。適切なデータがないと、移行を計画する際の難易度が高くなります。良いデータの例として、サーバー、サーバー上のアプリケーション、バージョンのあるサーバー上のソフトウェア、CPUs 数、メモリ量、ディスク数の正確なインベントリなどがあります。ウェーブプランナーが計画に必要なデータや、移行プロセスの自動化の一環として使用する予定のデータをキャプチャすることをお勧めします。

Automation

大規模な移行には自動化が不可欠です。自動化の例としては、エージェントのインストール、.NET や PowerShell などの自動化に必要なユーティリティのソフトウェアバージョンの更新、 AWS Systems Manager エージェント (SSM エージェント）、Amazon CloudWatch エージェント AWS などの のソフトウェアのロードや更新、または の実行に必要なその他のバックアップや管理ソフトウェアなどがあります AWS。

詳細な計画

詳細な計画の作成と管理は、大規模な移行にも不可欠です。1 週間に 50 台のサーバーを何週間も移行するには、明確に定義された計画が必要です。効果的な計画には以下が含まれます。

準備

準備フェーズでは、移行計画時に考慮できるように、組織の複雑さやバリエーションをできるだけ多く発見することが重要です。理想的には、カットオーバーメンテナンスウィンドウ中にこのような複雑さやバリエーションに対処し、フェイルバックを防ぐことができます。

大規模な移行の課題

移行の失敗は、アプリケーションが新しい環境にカットオーバーされ、移行メンテナンスウィンドウ内でパフォーマンス要件または機能要件を満たせない場合に発生します。これにより、アプリケーションは元の場所にフェイルバックされます。さらに、そのアプリケーションに依存する他のすべてのアプリケーションもフェイルバックする必要があります。失敗した移行は、アプリケーションの再スケジュールが必要なため、現在のウェーブだけでなく、将来のウェーブにも影響を与える傾向があります。

レイテンシーの影響を受けやすい依存関係

移行が失敗する主な理由は、レイテンシーの影響を受けやすい依存関係です。レイテンシーの影響を受けやすい依存関係を特定しないと、パフォーマンスの問題が発生し、許容できない応答時間やトランザクション時間が発生する可能性があります。

例えば、アプリケーションは頻繁に相互に通信し、両方が同じデータセンターにある場合、ミリ秒未満の応答時間を必要とするため、通常、データベースとアプリケーションサーバーを同時にクラウドに移動します。データベースのみをクラウドに移動すると、これらのトランザクションに数秒のレイテンシーが発生し、アプリケーションのパフォーマンスに大きな影響を与える可能性があります。これは、相互に大きく依存しており、適切に動作するために同じデータセンターにある必要があるアプリケーションにも当てはまります。

したがって、アプリケーションの依存関係を理解して対処することは、移行を計画する際に最も重要です。相互に依存するアプリケーションとサービスは、一緒に移行できるように識別する必要があります。

IT 共有サービス

ワークロードがクラウドに置かれたら、機能し、適切かつ安全に維持されるために、さまざまなサービスが必要です。これには、ランディングゾーン、ネットワークとセキュリティの境界、認証、パッチ適用、セキュリティスキャナー、IT サービス管理ツール、バックアップ、踏み台ホスト、その他のリソースが含まれます。これらのサービスがないと、ワークロードが正しく動作せず、元の場所にフェイルバックすることを強制される可能性があります。

設定の更新

ほとんどの場合、ワークロードをクラウドに移行した後、ワークロードが適切に機能するように、いくつかの設定変更を行う必要があります。これらの設定変更は、多くの場合、ワークロードの次の依存関係に関連付けられます。

適切な設定更新を行わないと、ワークロード、そのユーザー、およびその依存システムが相互に通信できなくなる可能性があります。停止時間内にこれらの問題を解決することは可能ですが、現時点での変更には時間がかかる場合や、時間内に満たすことができない変更レコードが必要になる場合があります。

アプリケーションの機能テスト

大規模な移行のもう 1 つの課題は、アプリケーションの機能テストの必要性です。多くの組織は、レイテンシーの影響を受けやすい依存関係、IT 共有サービス、または必要な設定更新を特定するためにアプリケーションチームに依存しているため、これは特に重要です。理想的には、アプリケーションチームは、カットオーバーメンテナンスウィンドウ中に実行できるテストプランを記述または自動化して、アプリケーションが許容可能なパフォーマンスで完全に機能していることを検証します。カットオーバーメンテナンスウィンドウを最小限に抑えるには、テストを 30 分以内に完了できる必要があります。

アプリケーションの依存関係検出用のツール

移行を成功させるには、アプリケーション間の依存関係を決定することが重要です。レイテンシーの影響を受けやすい依存関係と接続設定項目の両方を検出します。マーケットプレイスには、 (エージェントおよびエージェントレスツール) や Cloudamize AWS Application Discovery Service (エージェントベースのツール) など、依存関係を検出するためのツールがいくつかあります。

アプリケーション依存関係検出用のツールを選択するときは、次の点を考慮してください。