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

Windows 環境の検出

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

評価

最小限の計画と自動化でも、小規模な (100 台のサーバーが関与するような) 移行を「力ずくで」実行することはできますが、この方法論を使用して 500 台以上のサーバーを移行することはできません。以下の考慮事項は、大規模移行の成功に寄与する主な要因であり、移行準備状況評価 (MRA) を使用して、焦点を当てたい考慮事項を特定できます。

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

環境内の技術的負債が多いほど、移行が難しくなります。健全なエンタープライズアーキテクチャプログラムを持つ組織は、その環境に使用するソフトウェアとシステムを最新バージョン (多くの場合、メジャーリリースの 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 など) を使用してサーバーを標準化する必要があります。

適切なデータ

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

Automation

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

詳細な計画

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

準備

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

大規模移行の課題

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

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

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

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

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

IT 共有サービス

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

設定の更新

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

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

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

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

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

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

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