タスク 1: 最初の検出を実行し、移行戦略を検証する

大規模な移行プロジェクトにおけるポートフォリオ評価の最初のステップは、現在持っている情報、ビジネスおよび技術上の推進要因、および既に行われている移行戦略の決定を理解することです。ポートフォリオ評価の結果は、移行メタデータ、ウェーブプラン、移行戦略を移行ワークストリームに継続的にフィードすることです。収集された情報に基づいてギャップを分析し、次のステップを決定します。分析とタスクをすでに完了している場合は、このプレイブックの一部のセクションをスキップできます。このタスクは、以下のステップで構成されます。

• ステップ 1: 検出データを検証する

• ステップ 2: ビジネスと技術の推進要因を特定する

• ステップ 3: 移行戦略を検証する

• ステップ 4: 移行パターンを検証する

ステップ 1: 検出データを検証する

準備フェーズでは、最初のポートフォリオ評価を完了した可能性があります。完了している場合は、その検出データを移行フェーズで再利用できます。そうでない場合は、心配しないでください。このプレイブックでは、大規模な移行をサポートするために必要なものについて説明します。

大規模な移行には、通常、大量のデータがあります。例えば、次のようなものがあります。

• ソースサーバー、アプリケーション、データベースに関するメタデータ

• 設定管理データベース (CMDB) からの IT ポートフォリオに関する情報

• 現在の状態と依存関係をよりよく理解するのに役立つ検出ツールからのデータ

• ターゲット AWS リソースのメタデータ

メタデータのタイプについて

以下は、大規模な移行をサポートするために必要となる 3 つの主なメタデータタイプです。

• ソースポートフォリオメタデータ — ソースポートフォリオメタデータは、ソースサーバー、アプリケーション、データベースに関するメタデータです。メタデータは、既存の CMDB、検出ツール、またはアプリケーション所有者から取得できます。このメタデータタイプの包括的なリストはここにあります。以下に例をいくつか示します。

  • [Server name] (サーバー名)

  • サーバーの IP アドレス

  • サーバーオペレーティングシステム (OS)

  • サーバーストレージ、CPU、メモリ、1 秒あたりの入出力オペレーション (IOPS)

  • アプリケーション名

  • アプリ所有者

  • pplication-to-application 依存関係

  • ビジネスユニット

  • pplication-to-server マッピング

  • pplication-to-database マッピング

  • データベースのタイプとサイズ

  • ストレージタイプとサイズ

  • 依存関係メタデータ

  • パフォーマンスと使用状況のデータ

• ターゲット環境メタデータ — これは、サーバーをターゲット環境に移行するのに役立つメタデータタイプです。ターゲット環境を決定する必要があります。このメタデータの一部は、検出ツールから取得できます。このメタデータタイプの例を次に示します。

  • ターゲットサブネット

  • ターゲットセキュリティグループ

  • ターゲットインスタンスタイプ

  • ターゲット AWS Identity and Access Management (IAM) ロール

  • ターゲット IP アドレス

  • ターゲット AWS アカウント ID

  • ターゲット AWS リージョン

  • ターゲット AWS サービス

  • ターゲットアプリケーションアーキテクチャの設計

• ウェーブプランニングメタデータ — ウェーブプランニングメタデータは、移行の管理に役立つメタデータタイプです。このメタデータタイプの例を次に示します。

  • ウェーブ ID

  • ウェーブ開始時刻

  • ウェーブカットオーバー時間

  • ウェーブ所有者

  • Wave から application/server/database/move グループへのマッピング

検出データを検証する

決定を行う前に、現在の検出データを理解することが重要です。移行のこの段階では、すべての情報が揃っていない可能性があります。このプレイブックは、メタデータ要件を定義し、メタデータを効率的に収集するのに役立ちます。現在利用可能なメタデータとその場所を特定するために、次の質問を自問してください。

• Migration Evaluator などのツールを使用して移行評価を実施しましたか？

• AWS Application Discovery Service や Flexera One Cloud Migration and Modernization などの検出ツールを環境にデプロイしましたか？

• IT ポートフォリオ up-to-date に関する情報が最も多い CMDB はありますか？

• 準備段階で最初のポートフォリオ評価を完了しましたか？

• 最初のウェーブプランニングは完了しましたか？

• 最初のターゲット環境設計は完了していますか？

• 各メタデータタイプのソースは何ですか？

• すべてのメタデータにアクセスできますか？

• すべてのメタデータにどのようにアクセスしますか？

• メタデータにアクセスするプロセスを文書化していますか？

ステップ 2: ビジネスと技術の推進要因を特定する

ビジネスとテクノロジーの推進要因は、各アプリケーションの高レベルの移行戦略とパターンを検討するときに重要です。移行に固有のドライバーを理解する必要があります。移行戦略を検証し、アプリケーションマッピングルールを定義するときは、これらのビジネスドライバーと技術ドライバーを使用します。

一般的なビジネス推進要因

ビジネスドライバーは、契約の有効期限切れ、急速な成長、予算など、大規模な移行を計画する際に考慮する必要があるビジネス目標や制限に関連する要因です。一般的なビジネス推進要因は次のとおりです。

• データセンターの終了 — できるだけ早くクラウドに移行する必要があります。例えば、データセンター契約の有効期限が近づいています。

• 運用コストとリスクを軽減する — オンプレミス環境の運用に関連するコストやリスクを軽減したいと考えています。

• 柔軟性 — ビジネスの未来の変化に備えるには、戦略的方向性としてクラウドに移行する必要があります。

• ビジネスの成長 — 開発とイノベーションを迅速に加速したり、急速な成長に対応したりできる必要があります。

• データをインテリジェントに使用する — 企業の成長を予測し、顧客の行動に関するインサイトを提供できるクラウドベースの人工知能、機械学習、モノのインターネット (IoT) を活用したいと考えています。

• セキュリティとコンプライアンスの向上 – クラウド AWS インフラストラクチャに既に組み込まれているコンプライアンスプログラムを活用する必要があります。または、データに対する脅威の可能性を警告できるソフトウェアベースのセキュリティツールを活用する必要があります。

• リソースの可用性 — リソースが限られているか、内部エクスペリエンスが限られていると、変更なしでアプリケーションを移動する戦略を選択する可能性があります。

一般的なテクニカルドライバー

技術的要因は、現在のアーキテクチャなど、大規模な移行を計画する際に考慮する必要がある技術的な目標や制限に関連する要因です。一般的な技術要因は次のとおりです。

• ハードウェアまたはソフトウェア end-of-support – ハードウェアまたはソフトウェアはライフサイクルの終了に近づいているため、ベンダーがサポートしなくなったため、更新する必要があります。

• テクノロジー統合 — グローバルインフラストラクチャにアクセスできるため、アプリケーションを迅速かつ戦略的にスケーリングできます。グローバルサービスとインフラストラクチャを活用して、迅速にグローバル化できます。

• ストレージとコンピューティングの制限 — データセンターにはより多くのストレージやサーバー用の容量がないため、拡張する別の場所を見つける必要があります。

• スケーラビリティと回復性の要件 — アプリケーションに過去にダウンタイムが発生しており、クラウドを使用して目標復旧時点 (RPO) と目標復旧時間 (RTO) を改善したいと考えています。

• アプリケーションアーキテクチャのモダナイズ — クラウドを活用し、アプリケーションをクラウドネイティブに変更したいと考えています。

• パフォーマンスの向上 – ピーク時にはアプリケーションのパフォーマンスが低下します。需要に合わせて自動的にスケールアップとスケールダウンを行います。

ランブックを更新する

1. ポートフォリオプレイブックテンプレート で、アプリケーションの優先順位付け用のランブックテンプレート (Microsoft Word 形式) を開きます。

2. 「ビジネスドライバーと技術ドライバー」セクションに、大規模な移行プロジェクトで特定したドライバーを記録します。

3. アプリケーションの優先順位付けランブックを保存します。

ステップ 3: 移行戦略を検証する

大規模な移行には、移行戦略の選択が不可欠です。選択した移行戦略が組織の期待、制限、要件を満たしていることを確認する必要があります。利用可能な移行戦略の詳細については、AWS 「大規模な移行用ガイド」を参照してください。

準備フェーズまたは最初のポートフォリオ評価中に移行戦略を選択した可能性があります。このステップでは、ビジネスドライバーと技術ドライバーを使用して、ポートフォリオの移行戦略を選択して検証します。

移行戦略は、ポートフォリオの評価と移行の開始が続くにつれて変更される可能性があります。この段階では、ポートフォリオの一般的な分布を各移行戦略に理解することを目標としています。移行戦略の選択は、次のステップで詳細な移行パターンを検証する上で重要です。

移行戦略を選択して検証する

ポートフォリオを評価し、移行戦略を次のように選択します。

1. 前のステップで特定したすべての技術的およびビジネス上の推進要因を確認し、ビジネスニーズに基づいて推進要因に優先順位を付けます。

2. 各ビジネスドライバーと技術ドライバーを移行戦略にマッピングします。次の表は例です。

   優先度	ビジネスドライバーまたはテクニカルドライバー	移行戦略
   1	指定された日付までにデータセンターを終了する	できるだけ多くのアプリケーションをリホストし、リホストが不可能な場合にのみリプラットフォームとリファクタリングを行います。
   2	運用コストとリスクを軽減する	移行を高速化するには、できるだけ多くのアプリケーションをリホストします。
   3	ハードウェアまたはソフトウェア end-of-support	サポートされているアプリケーションをリホストし、クラウド内の新しいハードウェアやソフトウェアではサポートされていないアプリケーションをリプラットフォームします。
   4	リソースの可用性	AWS Managed Services (AMS) にリホストして、運用オーバーヘッドを削減します。

3. 各ビジネスドライバーとテクニカルドライバーを比較検討し、ポートフォリオを大まかに評価することで、各移行戦略間でアプリケーションをどのように分散すべきかを推定します。ドライバー間で競合が発生するのは一般的です。プロジェクトの利害関係者は協力して、競合を解決するための最終決定を行う必要があります。以下は、ポートフォリオを各移行戦略に分散する方法の例です。

   • リホスト – 60%

   • リプラットフォーム – 15%

   • 廃止 – 10%

   • 保持 – 5%

   • 再購入 – 5%

   • リファクタリング – 5%

ポートフォリオに高レベルの移行戦略を選択するまでは、移行を続行しないでください。

ランブックを更新する

1. アプリケーションの優先順位付けランブックを開きます。

2. 「移行戦略」セクションに、アプリケーションワークロードが 7 つの移行戦略にどのように分散されているかを記録します。例:

   • リホスト – 60%

   • リプラットフォーム – 15%

   • 廃止 – 10%

   • 保持 – 5%

   • 再購入 – 5%

   • リファクタリング – 5%

3. アプリケーションの優先順位付けランブックを保存します。

ステップ 4: 移行パターンを検証する

移行パターンについて

移行パターンは、移行戦略、移行先、および使用される移行アプリケーションまたはサービスの詳細を示す反復可能な移行タスクです。例としては、 を使用した Amazon Elastic Compute Cloud (Amazon EC2) へのリホストがあります AWS Application Migration Service。一般的な移行パターンでは、以下の AWS サービスとソリューションが頻繁に参照されます。

• AWS App2Container

• AWS Application Migration Service (AWS MGN)

• AWS CloudFormation

• AWS Database Migration Service (AWS DMS)

• AWS DataSync

• Amazon Elastic Compute Cloud (Amazon EC2)

• Amazon Elastic Container Service (Amazon ECS)

• Amazon Elastic File System (Amazon EFS)

• AWS クラウド移行ファクトリーソリューション

• Amazon Relational Database Service (Amazon RDS)

• AWS Schema Conversion Tool (AWS SCT)

• AWS Transfer Family

移行戦略の選択と同様に、移行パターンは前の段階で既に特定されている可能性があります。ただし、それらを検証し、パターンが定義され、文書化されていることを確認する必要があります。次の表に、一般的な移行戦略とパターンを示します。

ID	方針	パターン
1	リホスト	Application Migration Service または Cloud Migration Factory を使用して Amazon EC2 にリホストする
2	リプラットフォーム	AWS DMS および を使用した Amazon RDS へのリプラットフォーム AWS SCT
3	リプラットフォーム	を使用した Amazon EC2 へのリプラットフォーム AWS CloudFormation 注記 CloudFormation テンプレートは、 に新しいインフラストラクチャを構築します AWS クラウド。
4	リプラットフォーム	AWS DataSync または を使用して Amazon EFS にリプラットフォームする AWS Transfer Family
5	リプラットフォーム	AWS App2Containerにリプラットフォームする
6	リプラットフォーム	エミュレータを使用してメインフレームサーバーまたはミッドレンジサーバーを Amazon EC2 にリプラットフォームする
7	リプラットフォーム	Amazon EC2 での Windows から Linux へのリプラットフォーム
8	リタイア	アプリケーションを廃止します。
9	Retain	オンプレミスで保持する
10	再購入	SaaS の再購入とアップグレード
11	リファクタリングまたはリアーキテクト	アプリケーションの再構築

ランブックを更新する

この時点で、ポートフォリオレベルでパターンを定義します。このプレイブックの後半では、各アプリケーションを対応する移行パターンにマッピングします。

1. アプリケーションの優先順位付けランブックを開きます。

2. 「移行パターン」セクションで、特定して検証した移行パターンを記録します。各パターンに一意の ID を割り当て、そのパターンの移行戦略を書き留めます。

3. アプリケーションの優先順位付けランブックを保存します。

移行パターンは、進行するにつれて変更される可能性があることに注意してください。移行戦略とパターンは、新しい情報を見つけたり、ワークロードの範囲を変更したり、新しい AWS サービスを使用することを決定したりしたときに後で変更することができます。

タスク終了基準

移行戦略とパターンを大まかなポートフォリオの観点からまだ特定していない場合は、次のタスクに進む前に、技術チームと協力してそれらを定義することを強くお勧めします。ポートフォリオの評価とウェーブプランニングは、移行戦略とパターンの理解に依存します。続行する前に、移行パターンの包括的なリストを用意する必要はありません。新しいパターンを追加したり、戦略を調整したりできます。

次のタスクを完了したら、次のタスクに進みます。

• 最新の検出データにアクセスして理解できます。

• 移行のビジネスおよび技術上の推進要因を特定しました。

• ビジネスおよび技術上の推進要因に基づいて、移行戦略を選択し、検証しました。

• 移行パターンを選択し、検証しました。

• アプリケーションの優先順位付けランブックに以下を記録しました。

  • ビジネスドライバーと技術ドライバー

  • 移行戦略

  • 移行パターン