View a markdown version of this page

タスク 1: 最初の検出を実行し、移行戦略を検証する - AWS 規範ガイダンス
ステップ 1: 検出データを検証するステップ 2: ビジネスと技術の推進要因を特定するステップ 3: 移行戦略を検証するステップ 4: 移行パターンを検証するタスク終了条件

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

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

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

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

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

大規模な移行には通常、大量のデータがあります。たとえば、以下があるとします。

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

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

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

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

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

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

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

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

    • サーバー IP アドレス

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

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

    • アプリケーション名

    • アプリ所有者

    • Application-to-application依存関係

    • ビジネスユニット

    • Application-to-serverマッピング

    • Application-to-databaseマッピング

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

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

    • 依存関係メタデータ

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

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

    • ターゲットサブネット

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

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

    • Target AWS Identity and Access Management (IAM) ロール

    • ターゲット IP アドレス

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

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

    • ターゲット AWS サービス

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

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

    • Wave ID

    • ウェーブ開始時刻

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

    • ウェーブ所有者

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

検出データを検証する

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

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

  • Flexera One Cloud Migration や 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 へのリプラットフォーム CloudFormation

注記

CloudFormation テンプレートは、 に新しいインフラストラクチャを構築します AWS クラウド。

4

リプラットフォーム

AWS DataSync または を使用して Amazon EFS にリプラットフォームする AWS Transfer Family

5

リプラットフォーム

AWS App2Container を使用して Amazon ECS にリプラットフォームする

6

リプラットフォーム

エミュレータを使用してメインフレームまたはミッドレンジサーバーを Amazon EC2 にリプラットフォームする

7

リプラットフォーム

Amazon EC2 での Windows から Linux へのリプラットフォーム

8

リタイア

アプリケーションを廃止します。

9

Retain

オンプレミスで保持する

10

再購入

SaaS の再購入とアップグレード

11

リファクタリングまたはリアーキテクト

アプリケーションを再設計する

ランブックを更新する

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

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

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

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

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

タスク終了条件

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

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

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

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

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

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

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

    • ビジネスと技術の推進要因

    • 移行戦略

    • 移行パターン