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

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。

詳細な計画

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

準備

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

大規模な移行の課題

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

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

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

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

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

IT 共有サービス

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

設定の更新

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

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

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

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

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

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

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