View a markdown version of this page

移行計画を立てる - AWS 変換
ワークフロー

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

移行計画を立てる

AWS Transform for VMware 内の移行計画ジョブステップは、大規模な移行を計画するための共同チャットベースのエクスペリエンスです。 AWS Transform エージェントは AWS 、規範ガイダンスを適用して、オンプレミスデータの分析から最終的な移行ウェーブプランまで、顧客をガイドします。

オンプレミスデータ検出ジョブが正常に完了すると、 AWS Transform は検出データを使用してアプリケーションを移行ウェーブにグループ化します。 AWS Transform は、サーバーの分析とスコープ、アプリケーションへのグループ化、移動グループの生成、移行ウェーブの構築のステップをガイドします。オンプレミス環境を分析するときは、 AWS Transform がインストール済みソフトウェアをどのように分析したかをよりよく理解するために質問できます。たとえば、サーバーの依存関係やネットワークアーキテクチャなどです。

AWS 変換は、アプリケーショングループとウェーブ内のスコープ調整をサポートします。検出データはいつでも再アップロードでき、 AWS Transform は新しいレコードを自動的に処理、複製解除し、既存のデータとマージします。新しく検出された依存関係やインフラストラクチャの追加など、変更が検出されると、 AWS Transform は影響を受ける依存関係グループにフラグを付け、ウェーブプランの調整に関する推奨事項を提供します。移行計画では、非構造化テキストデータを活用して計画プロセスを強化することもできます。

移行計画には 4 つの段階があります。

  • スコープと分析では、検出データを確認し、ソフトウェアとネットワーク環境について質問し、移行の対象となるリソースを決定できます。

  • グループアプリでは、ホスト名分析、ネットワークの依存関係、ビジネスルールなどに関するビジネスルールと技術ルールを組み合わせて提供することで、移行計画でインフラストラクチャをアプリケーションにグループ化できます。アプリケーションのインベントリが既にある場合、移行計画では代わりにそのインベントリを使用できます。

  • 移動グループの生成では、移行計画に技術要件とビジネス要件を提供して、一緒に移動する必要があるアプリケーションを決定できます。技術的な依存関係には、データベース、メッセージキュー、または複数のアプリケーション間で共有されるその他のリソースが含まれます。ビジネスと運用の依存関係には、ビジネスの重要性、RPO と RTO、データセンターの場所、アプリケーション所有者が含まれます。

  • 最後に、ビルドウェーブでは、タイムラインと優先順位に関する移行計画のコンテキストを提供して、移行できるウェーブ計画を構築できます。優先順位スコア、移動グループサイズ、ユーザー数、アプリケーションの複雑さなどの要因に基づいて、ウェーブに含める移動グループを選択できます。

Migration Planning の用語:

  • 移行ウェーブは、一緒に移行される論理グループです。移行ウェーブは、1 つ以上の移動グループで構成されます。

  • 移動グループは、一緒に移動する必要がある共依存アプリケーションのセットです。共有データベースなどの技術的な依存関係がある場合や、共有ビジネス機能のサポートなどのビジネス依存関係がある場合があります。

  • 依存関係はシステム間の関係です。依存関係には、次のようないくつかのタイプがあります。

    • システムが依存関係なしでは動作しない、クリティカルまたはハードな依存関係。この一般的な例は、データベース、他のアプリケーション、またはサービスに依存するアプリケーションです。

    • ソフト依存関係。システムのオペレーションには重要ではありません。一般的な例としては、個別に移行できるレイテンシーの影響を受けない依存関係などがあります。

    • 非技術的な依存関係には、ビジネス、組織、運用、コンプライアンスの依存関係が含まれます。これらは、組織とその優先順位に関連する依存関係です。例としては、ビジネス機能の共有や組織の所有権などがあります。

ワークフロー

移行計画はインタラクティブで反復的なワークフローです。戻ると、いつでも前のステップを変更できます。一般的な移行計画ワークフローは次のとおりです。

  1. 移行計画は、利用可能な検出データを要約することから始まります。利用可能なデータを確認し、いつでも検出ステップに戻って追加のデータを提供します。

  2. スコープと分析のステップでは、オンプレミス環境について質問して、収集したデータを検証できます。質問の例は次のとおりです。

    1. オペレーティングシステム別にサーバーを一覧表示する

    2. オンプレミスのネットワークトポロジを要約する

    3. 環境で実行されている最も一般的なテクノロジーを一覧表示します。

  3. 環境の分析中に、移行対象外のサーバーを特定した場合、それらのリソースを除外するように AWS Transform に指示できます。これには、次のような例があります。

    1. ホスト名にレガシーを持つすべてのサーバーを削除する

    2. 10.0.2.0/24 サブネット内のすべてのサーバーを削除する

    3. 2022 より前のバージョンの Windows を実行しているすべてのサーバーを削除する

  4. 環境を十分に探索し、移行範囲を決定したら、 AWS Transform に次の移行計画ステップに移行するように指示できます。

  5. 次のステップは、アプリケーションのグループ化です。サーバーが既にアプリケーションにマッピングされている場合は、そのマッピングを使用するように AWS Transform に指示し、このステップをスキップできます。アプリケーションが事前に定義されていない場合は、アプリケーションを定義する技術ロジックとビジネスロジックを提供できます。 AWS Transform はアプリケーションのグループ化プロセスをガイドし、サーバーをアプリケーションに効果的にグループ化するために提供できるデータポイントを提案します。オンプレミスアプリケーションに関して提供できる情報が多いほど、 AWS Transform はより効果的にサーバーをアプリケーションにグループ化できます。十分な情報を提供したら、 AWS 変換にアプリケーションのグループ化を実行するように指示できます。

  6. アプリケーションのグループ化が実行されたら、アプリケーショングループを確認します。変換には、次のような必要な変更を加える AWS ように指示できます。

    1. サーバーの example-server を application-5 に移動する

    2. application-5 "HR App Test Environment" の名前を変更する

    3. IIS Dev Farm からすべての Linux サーバーを削除する

  7. アプリがグループ化されたら、 AWS 変換に次のステップに進むように指示します。

  8. 次のステップは移動グループ化です。移動グループ化ステップでは、一緒に移動する必要があるアプリケーションを特定します。技術的依存関係と非技術的依存関係に関するコンテキストを提供します。 AWS Transform はプロセスをガイドし、アプリをグループ化するために提供できるデータポイントを提案します。この段階では、いくつかの考慮事項があります。

    1. 移動グループのターゲットサイズはどのくらいですか?

    2. 開発、テスト、製品などの環境をアプリごとに組み合わせるか、分割するか。

    3. ネットワークの依存関係をどのように考慮しますか? すべての依存関係は重要ですか、または一部の依存関係はソフト依存関係と見なされ、移動グループ間で分割できますか?

  9. 移動グループ化のルールを指定したら、移動グループ化戦略を実行するように AWS Transform に指示します。その後、移動グループを確認して変更できます。移動グループを確認したら、最終的な移行計画ステップに移行するように AWS Transform に指示できます。

  10. ウェーブプランニングは、移行計画の最後のステップです。このステップでは、移動グループを移行ウェーブにグループ化し、それらのウェーブに優先順位を付けます。ウェーブプランニングステップ内で、 AWS Transform は、移動グループをウェーブにグループ化し、それらのウェーブに優先順位を付けるために必要なビジネスの優先順位付けを提供する方法を説明します。ウェーブプランニングにおける考慮事項は次のとおりです。

    1. 各移動グループのビジネス重要度

    2. 各移動グループの移行タイムラインとタイムライン

    3. 各移動グループに関連するリスク

    4. ウェーブごとに移行するサーバーの数

  11. ウェーブにグループ化する方法に関する十分なガイダンスを提供したら、ウェーブ計画を実行するように AWS Transform に指示します。その後、ウェーブを確認して変更することができます。

  12. ウェーブプランを確定したら、移行計画を完了して実行に移すことができます。いつでも移行計画に戻って、計画を絞り込み、反復することができます。

  13. ウェーブごとに、移行戦略を割り当てることができます。リホスト (サーバーを Amazon EC2 に移行) とコンテナ化 (ソースコードをコンテナ化し、Amazon Elastic Container Service または Amazon Elastic Kubernetes Service にデプロイ) です。戦略コンテナ化するウェーブを割り当てると、 AWS Transform は移行の実行中にそのウェーブのソースコードコンテナ化ワークフローを実行します。詳細については、「ソースコードのコンテナ化」を参照してください。7Rs フレームワーク全体で AWS推奨戦略を割り当てる前に取得するには、「」を参照してください移行戦略 (7R) の推奨事項。 7Rs