タスク 4: アプリケーションの詳細なプロセスを定義する

アプリケーションの優先順位付けのルールとプロセスを確立したら、各アプリケーションの優先順位を絞り込むのに役立つアプリケーションの詳細な演習を実行します。アプリケーションのディープダイブは、優先度が最も高いものから低いものの順に、一度に 1 つのアプリケーションで実行します。複数のポートフォリオチームを持つプロジェクトの場合、各チームは異なるアプリケーションに対して同時にアプリケーションのディープダイブを実行できます。

詳細な分析中に、アプリケーションの移行の複雑さに影響する依存関係などの予期しない問題が発生する可能性があります。この場合、将来のアプリケーションのより正確な複雑さスコアを得るために、前のステップで定義した複雑さスコア基準を変更し、それに応じてスコアシートを更新する必要があります。その後、新しい複雑さスコアを使用してアプリケーションの優先順位を更新できます。

このタスクは、次のステップで構成されます。

• ステップ 1: アプリケーションワークショッププロセスを定義する

• ステップ 2: アプリケーションマッピングプロセスを定義する

• ステップ 3: (オプション) アプリケーションターゲットの状態を定義する

• ステップ 4: アプリケーションのディープダイブプロセスを完了する

ステップ 1: アプリケーションワークショッププロセスを定義する

ワークショッププロセスは、アプリケーションのディープダイブに対する最も効率的なアプローチの 1 つです。このプロセスを使用して、ステークホルダー、アプリケーション所有者、ポートフォリオチームと協力してアプリケーションを評価および分析します。目標は、アーキテクチャ、ビジネス目的、依存関係、環境など、アプリケーションの現在の状態を明確に把握することです。次に、アプリケーションのサイズと複雑さに関するこの詳細情報を使用して、アプリケーションのターゲット状態を設計します。

各ワークショップは通常 1～8 時間かかりますが、複雑性の高いアプリケーションではさらに時間が必要になる場合があります。また、リソースの可用性、好み、アプリケーションのサイズと複雑さに応じて、ワークショップを複数の会議に分割することもできます。

期待される成果を特定する

アプリケーションワークショップを実施する前に、課題を設定し、ワークショップの期待される成果、またはワークショップで収集する必要がある情報を定義する必要があります。これにより、ワークショップ参加者はワークショップの準備をし、会議を目標に維持し、ワークショップの最後までに、アプリケーションの優先順位付け、ウェーブプラン、移行に必要なすべての情報を確実に得ることができます。

期待される結果の標準セットを定義し、アプリケーションの優先順位付けランブックに文書化することをお勧めします。ワークショップを準備するときは、標準的な期待される結果を使用し、特定のアプリケーションに新しい結果を追加します。

アプリケーションワークショップで期待される成果の標準セットを次のように定義します。

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

2. 「アプリケーションワークショップの期待される成果」セクションで、アプリケーションワークショップの期待される成果の標準セットを確立します。ワークショップを準備するときは、アプリケーションの特定のニーズに合わせてカスタマイズできます。

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

4. アプリケーションの優先順位付けランブックで期待される成果を維持します。アプリケーションワークショップを実施してポートフォリオ評価とウェーブプランニングを続けると、新しい期待される成果を特定したり、既存の成果を絞り込んだりできます。

以下は、アプリケーションワークショップで期待される成果の例です。

優先度	アプリケーションワークショップの期待される成果
1	関連するサーバー、依存関係、環境、アプリケーション層など、アプリケーションの現在のアーキテクチャを明確に理解します。
2	チームは、ターゲットアーキテクチャの設計をサポートするためにメタデータを収集しました。次のメタデータが必要です。 ターゲット AWS アカウント ID ターゲット AWS リージョン ターゲットサブネット ターゲットセキュリティグループ
3	アプリケーション所有者のアンケートは完了し、すべての主要な質問に回答します。
4	チームは、ユーザーガイド、アプリケーションアーキテクチャドキュメント、テストドキュメント、設計ドキュメント、アプリケーションプログラミングインターフェイス (API) ドキュメントなど、すべてのアプリケーションドキュメントを収集しました。

アプリケーションワークショップルールを定義する

アプリケーションワークショップを実施する前に、ワークショップを管理するルールを定義する必要があります。一般的なルールには、ワークショップの長さ、ワークショップで必要になるツール、考慮すべきスケジュール上の考慮事項や期限などがあります。これにより、会議を目標に維持し、ワークショップで行われた決定が移行スケジュールに沿って行われるようにします。

アプリケーションワークショップルールは、アプリケーションの優先順位付けランブックに文書化することをお勧めします。

アプリケーションワークショップルールを次のように定義します。

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

2. 「アプリケーションワークショップルール」セクションで、ワークショップを管理するルールを定義します。

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

4. アプリケーションの優先順位付けランブックのルールを維持します。アプリケーションワークショップを実施してポートフォリオ評価とウェーブプランニングを続けると、新しいルールを特定したり、既存のルールを絞り込んだりできます。

アプリケーションワークショップのルールの例を次に示します。

優先度	ワークショップルール
1	ワークショップは、火曜日と木曜日のセッションごとに最大 2 時間スケジュールする必要があります。
2	12 月 1 日から 1 月 15 日の間、インフラストラクチャのフリーズが予定されています。
3	移行ツールの実践的なワークショップがあります。
4	データセンター契約は 3 月 31 日に期限切れになります。ペナルティやコストのかかる契約延長を避けるため、ワークロードは 3 月 31 日までに退避する必要があります。
5	生体認証アプリケーションと時間および出席アプリケーションは保持されます。

アプリケーションワークショッププロセスを定義する

アプリケーションワークショップを実施するための標準プロセスを定義することが重要です。これにより、一貫したエクスペリエンスが保証され、ワークショップ参加者への期待が設定されます。これにより、ワークショップの効率が向上します。

アプリケーションワークショッププロセスには 3 つの段階があります。

• ワークショップの準備 – ワークショップの準備は、セッションがスムーズに進み、参加者が期待される内容を把握するのに役立ちます。ワークショップの準備をするには、アジェンダを作成し、期待される成果を定義し、参加者、ツール、ワークショップで必要な情報を特定し、ワークショップをスケジュールします。少なくとも 1 週間前にワークショップをスケジュールすると、チームはカレンダーをブロックし、ワークショップの準備をし、有用な情報を収集する時間を確保できます。

• ワークショップを実施する – ワークショップを実施するときは、ディスカッションをアジェンダの項目に限定し、期待される成果を達成するようにします。役に立ちますが、アジェンダには含まれていないと思われるトピックに注意してください。ワークショップを記録すると便利です。

• ワークショップの結果を確定する – ワークショップの後、チームはアプリケーションの現在の状態と、優先順位付けと移行に影響を与える可能性のある潜在的な問題点、リスク、課題、ブロッカーを明確に理解する必要があります。ワークショップ後の一般的なタスクには、アプリケーションの優先順位の変更、アプリケーションの将来の状態のドラフト、次のワークショップに役立つ可能性のある期待される結果、ルール、またはプロセスの変更を含むランブックの更新が含まれます。

アプリケーションの優先順位付け用のランブックテンプレートには、アプリケーションワークショップの準備、実施、最終化のための標準的なstep-by-stepのプロセスが含まれています。アプリケーションワークショッププロセスを次のように定義します。

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

2. アプリケーションワークショッププロセスセクションで、ユースケースのニーズに合わせて標準プロセスを変更します。

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

4. アプリケーションの優先順位付けランブックでプロセスを維持します。アプリケーションワークショップを実施する際、このプロセスに加えたい変更を特定できます。

ステップ終了条件

• ワークショップのアジェンダと、ワークショップのサポートに必要なリソースとアーティファクトを定義しました。

• ワークショップの期待される成果を定義し、ワークショップで収集する必要がある情報を特定しました。

• ワークショッププロセスのトライアルを実施し、アプリケーションのマッピングをサポートし、ターゲットの状態を設計するために必要な情報を用意しました。

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

  • アプリケーションワークショップの期待される成果

  • アプリケーションワークショップルール

  • アプリケーションワークショッププロセス

ステップ 2: アプリケーションマッピングプロセスを定義する

アプリケーションマッピングは、各アプリケーションを移行パターンに割り当てるプロセスであり、 で特定して検証しますステップ 4: 移行パターンを検証する。このステップでは、アプリケーションの評価に使用するルールを定義します。次に、各アプリケーションの評価に使用するプロセスを定義します。各アプリケーションを移行パターンのユースケースにマッピングすることで、移行ツール、移行を完了するために必要なスキル、移行パターンの複雑さを特定できます。

必ずしもアプリケーションを 1 つのパターンに移行するとは限りません。同じアプリケーションに複数のパターンが必要になる可能性がある場合の詳細については、このセクションのアプリケーションマッピングプロセスを定義する後半の「」を参照してください。

アプリケーションマッピングルール

アプリケーションマッピングルールは、アプリケーションを評価し、適切な移行パターンを特定するのに役立ちます。各ルールは、アプリケーションとパターンの一致基準を評価するために使用する必要がある情報で構成されます。

ポートフォリオプレイブックテンプレートでは、アプリケーションの優先順位付け用のランブックテンプレートに、アプリケーションマッピングルールを文書化するためのセクションが含まれています。プロセスを次のように定義します。

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

2. 「アプリケーションマッピングルール」セクションで、アプリケーションマッピングルールを定義します。

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

4. アプリケーションの優先順位付けランブックのルールを維持します。

次の表に、アプリケーションマッピングルールの例を示します。

注記

この表のパターン IDsと名前は、 のサンプルパターンに対応していますステップ 4: 移行パターンを検証する。アプリケーションの優先順位付けランブックで定義したパターン IDs と名前を使用します。

優先度	マッピングルール
1	使用率データまたはモニタリングツールを使用して、アプリケーションがゾンビアプリケーションかアイドルアプリケーションかを特定します。アプリケーションがゾンビまたはアイドル状態のアプリケーションの場合は、パターン 8: アプリケーションを廃止し、アプリケーションスタック内のサーバーをシャットダウンします。
2	このアプリケーションをクラウドに移行するとビジネス価値が生まれるかどうかを確認します。通常、オンプレミスでのみ使用され、時間や出席申請など、ブランチや地理的な場所間で共有されないアプリケーションは、クラウドに移行する必要はありません。このアプリケーションを移行してもビジネス価値が得られない場合は、パターン 9: オンプレミスで保持を選択します。
3	アプリケーションのオペレーティングシステム (OS) が AWS、 AWS 、移行サービス、ベンダー、またはリホスト移行ツールでサポートされているかどうかを確認し、次の操作を行います。 OS がサポートされている場合は、パターン 1: Application Migration Service または Cloud Migration Factory を使用して Amazon EC2 にリホストするを選択します。 OS がサポートされていない場合は、パターン 3: を使用して Amazon EC2 にリプラットフォーム AWS CloudFormationするを選択します。
4	アプリケーションに Software as a Service (SaaS) バージョンまたは同等のバージョンがあるかどうかを特定し、この新しいプラットフォームに移行することの利点とコストを評価します。これらの基準が満たされた場合は、パターン 10: 再購入して SaaS にアップグレードするを選択します。
5	オンプレミスの Oracle データベースを Amazon RDS for Oracle に移行する、オンプレミスの MySQL データベースを Amazon Aurora MySQL 互換エディションデータベースに移行するなど、アプリケーションのオンプレミスデータベース (複数可) をクラウド内の同種サービスに移行できるかどうかを特定します。これらの基準が満たされた場合は、パターン 2: AWS DMS と を使用して Amazon RDS にリプラットフォーム AWS SCTします。
6	アプリケーションが Microsoft .NET Core (.NET 5 または .NET 6)、Java、PHP、または別のオープンソースプログラミング言語を使用しているかどうか、およびアプリケーションが Microsoft Windows Server でホストされているかどうかを確認します。リプラットフォームのコストが正当かどうかを評価します。これらの条件が満たされた場合は、パターン 7: Amazon EC2 で Windows から Linux へのリプラットフォームを選択します。
7	アプリケーションが依存しているオンプレミスのローカルファイルストレージと共有ファイルストレージを特定し、移行に含める必要があるかどうかを判断します。ローカルファイルストレージと共有ファイルストレージを移行する必要がある場合は、パターン 4: AWS DataSync または を使用して Amazon EFS にリプラットフォームする AWS Transfer Familyを選択します。
8	アプリケーションのサーバーが IBM AS/400 や Apache Spark などのメインフレームサーバーかミッドレンジサーバーかを特定し、アプリケーションがエミュレータと互換性があることを確認します。これらの基準が満たされている場合は、エミュレータを使用してメインフレームまたはミッドレンジサーバーを Amazon EC2 にリプラットフォームするパターン 6 を使用します。
9	これがレガシーアプリケーション、モノリシックアプリケーション、メインフレームベースのアプリケーションのいずれで、その制限によりビジネスの需要を満たせないかを特定します。例えば、アプリケーションがスケーリング可能か、関連アプリケーションと統合可能か、またはコストが高く保守が困難かを特定します。アプリケーションがこれらの基準のいずれかを満たしている場合は、パターン 11: アプリケーションの再構築を選択します。

アプリケーションマッピングプロセスを定義する

アプリケーションを移行パターンにマッピングする場合は、検出チームにアプリケーションの検出データをリクエストすると便利です。このデータには通常、推奨される移行パターン (R パターンまたは R スコアと呼ばれることもあります）、使用率情報、アプリケーションの依存関係、評価で使用できるその他の情報が含まれます。このアプリケーションを詳しく調べるときに、以前に特定した移行パターンを変更する場合があります。

データを取得したら、アプリケーションを で特定したビジネス基準と技術基準と比較できますステップ 2: ビジネスと技術の推進要因を特定する。アプリケーションの優先順位付けランブックにドライバーを記録しました。基準に照らしてアプリケーションを評価すると、アプリケーションに複数の移行パターンを選択したり、コスト、スケジュール、またはその他の制限に基づいてパターンを排除したりする可能性があります。

以下は、1 つのアプリケーションで複数の移行パターンを使用する必要があるビジネスドライバーの例です。オンプレミスの SQL Server データベースを Amazon DynamoDB に移行したいが、データセンターの契約が期限切れになるため、ビジネスは提案されたスケジュールよりも早く移行してリプラットフォームしたいと考えています。このビジネスドライバーに対処するには、アプリケーションの移行計画を 2 パターンのアプローチに修正します。まず、アプリケーションをクラウドにリホストして、データセンターから削除します。後で、アプリケーションがクラウドに置かれたら、提案されたスケジュールに従って再プラットフォームできます。

また、アプリケーションが複数の階層で構成されるアプリケーションである n 階層アプリケーションであるかどうかを検討する必要があります。アプリケーション層は、アプリケーションの水平レイヤーをホストする物理サーバーのグループです。N 層アプリケーションは、各層が異なる戦略を必要とする場合があり、異なるウェーブでアプリケーション層を移行することを選択できるため、より複雑になります。例えば、プレゼンテーション、ビジネスサービス、データベース階層で構成されるアプリケーションがある場合、階層ごとに異なるパターンをマッピングできる可能性があります。

次に、アプリケーションの優先順位付けランブックで定義したアプリケーションマッピングルールに対してアプリケーションを評価します。詳細については、このセクションの前アプリケーションマッピングルール半の「」を参照してください。

アプリケーションを 1 つ以上のパターンにマッピングしたら、この決定を確認してアプリケーション所有者に確認します。アプリケーション所有者は選択したパターンを確認し、移行の計画と実行に役立ちます。現時点では、アプリケーション所有者は経験に基づいてインサイトを提供したり、移行で予想される問題を共有したりすることもできます。

アプリケーションを 1 つ以上の移行パターンにマッピングし、アプリケーション所有者にパターンを確認したら、アプリケーション、パターン ID、パターン名、および関連するドライバーをアプリケーションの優先順位付けランブックのアプリケーションマッピングテーブルに記録します。

ポートフォリオプレイブックテンプレートでは、アプリケーションの優先順位付け用のランブックテンプレートに、アプリケーションマッピングの標準的なstep-by-stepプロセスが含まれています。プロセスを次のように定義します。

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

2. アプリケーションワークショッププロセスセクションで、ユースケースのニーズに合わせて標準プロセスを変更します。

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

4. アプリケーションの優先順位付けランブックでプロセスを維持します。

次の表は、アプリケーションマッピングテーブルの例です。アプリケーションの優先順位付け用に提供されている Runbook テンプレートには、アプリケーションマッピングプロセスの結果を記録できる空のテーブルが含まれています。

注記

この表のパターン IDsと名前は、 のサンプルパターンに対応していますステップ 4: 移行パターンを検証する。アプリケーションの優先順位付けランブックで定義したパターン IDs と名前を使用します。

アプリケーション名	パターン ID	パターン名	対処されたビジネスドライバーと技術ドライバー
企業ウェブサイト	1	Application Migration Service または Cloud Migration Factory を使用して Amazon EC2 にリホストする	データセンターの終了 運用コストの削減
HR システム	8	アプリケーションを廃止します。	運用コストの削減
時間と出席申請	9	オンプレミスで保持する	運用コストの削減 リスクと影響の軽減
PO システム	3	を使用した Amazon EC2 へのリプラットフォーム AWS CloudFormation	テクノロジー統合 ストレージとコンピューティングの制限 ハードウェアとソフトウェアのend-of-life セキュリティとコンプライアンスの向上
CRM システム	10	SaaS の再購入とアップグレード	運用コストの削減 テクノロジー統合 ハードウェアとソフトウェアのend-of-life 開発、イノベーション、成長を加速する
固定アセットシステム	7	Amazon EC2 での Windows から Linux へのリプラットフォーム	運用コストの削減
ERP ファイルストレージ	4	AWS DataSync または を使用して Amazon EFS にリプラットフォームする AWS Transfer Family	ストレージとコンピューティングの制限
台帳システム	6	エミュレータを使用してメインフレームまたはミッドレンジサーバーを Amazon EC2 にリホストする	データセンターの終了 テクノロジー統合 セキュリティとコンプライアンスの向上 ハードウェアとソフトウェアのend-of-life ストレージとコンピューティングの制限 アプリケーションアーキテクチャのモダナイズ
総台帳	11	アプリケーションの再構築	運用コストの削減 テクノロジー統合 セキュリティとコンプライアンスの向上 ハードウェアとソフトウェアのend-of-life ストレージとコンピューティングの制限 アプリケーションアーキテクチャのモダナイズ スケーラビリティと耐障害性 開発、イノベーション、成長を加速する

AWS Migration Hub 戦略の推奨事項について

説明したアプリケーションマッピングプロセスに加えて、 の Strategy Recommendations 機能を使用してAWS Migration Hub、推奨される戦略をリファレンスとして取得できます。この機能は、ポートフォリオ分析を自動化し、アプリケーションの移行とモダナイゼーション戦略を推奨できるように設計されています。

Strategy Recommendations は、ランタイム環境を決定し、依存関係を処理するために、オンプレミスアプリケーションを分析します。ソースコードとデータベースを分析に含めることを選択できます。移行速度、ライセンスコスト、運用コストの削減などのビジネス目標に優先順位を付けます。Strategy Recommendations は、収集された情報を優先順位の高い目標に照らして評価し、アプリケーションの移行とモダナイズのための実行可能なパスを推奨します。次に、ビジネスとレコメンデーションを確認し、レコメンデーション戦略がビジネスおよび技術基準を満たしていることを確認します。

ステップ終了基準

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

  • アプリケーションマッピングルール

  • アプリケーションマッピングプロセス

• 1 つ以上のproof-of-concept (POC) アプリケーションを使用して、マッピングルールとプロセスを検証しました。

ステップ 3: (オプション) アプリケーションターゲットの状態を定義する

このステップでは、アプリケーションのターゲット状態または To-Be 状態をドキュメント化するために使用する属性とプロセスを定義します。ターゲットの状態は、移行後のターゲットクラウド環境でのアプリケーションの動作です。ターゲット環境は、ターゲットプラットフォームまたはサービスやビジネス要件によって異なります。ターゲット環境は、 AWS クラウド または AWS Managed Services (AMS) です。

ターゲットの状態を定義すると、プロジェクトマネージャー、移行コンサルタント、アーキテクト、アプリケーションオーナー、ステークホルダーが効果的にコラボレーションできるようになります。このプロセスを使用することで、チームは事前に問題を特定して解決し、ターゲット状態環境をより効率的に実装できます。

一部のアプリケーションでは、このステップはオプションです。移行するアプリケーションがスタンドアロンまたは低複雑さの場合は、このステップをスキップできます。リホストなど、アプリケーションを変更しない移行戦略では、このステップを必要としない場合があります。ただし、リプラットフォームや再構築など、より複雑な移行戦略の場合は、移行を開始する前にターゲットの状態を定義する必要があります。

このワークショップでは、アプリケーションの現在の状態を詳細に理解できるため、ワークショップを完了した後にターゲット状態をドラフトすることをお勧めします。さらに、アプリケーションを移行パターンにマッピングすると、追加のインサイトが得られ、ターゲット状態の定義が必要かどうかを特定できます。例えば、Application Migration Service または Cloud Migration Factory を使用してアプリケーションをAmazon EC2 Rehost にマッピングする場合、戦略がリホストであることは特定されており、このアプリケーションのターゲット状態を定義する必要はありません。

ターゲット状態属性

ターゲット状態を定義し、アプリケーションに関する決定を行うときは、次のターゲット状態属性を考慮することをお勧めします。

• AWS Well-Architected Tool — AWS Well-Architected フレームワークに照らしてアプリケーションのターゲットの状態を確認し、クラウド内のアプリケーションのセキュリティ、パフォーマンス、耐障害性を向上させます。

• ターゲットランディングゾーン – 通常、準備フェーズの終わりまでに、パイロットアプリケーションを実行する準備ができている完全なランディングゾーンを構築しておく必要があります。ランディングゾーンは、マルチアカウントアーキテクチャ、ID とアクセスの管理、ガバナンス、データセキュリティ、ネットワーク設計、ログ記録で既に設定されている必要があります。パイロットアプリケーションを使用して、ランディングゾーンが完了したことを確認します。既存のターゲットランディングゾーンでパイロットアプリケーションを起動して実行できることを確認します。アプリケーションのランディングゾーンを変更する必要がある場合は、ランディングゾーンチームに要件を通知します。例えば、アプリケーションが別のアカウントでホストされているサービスへのアクセスを要求する場合や、仮想プライベートクラウド (VPC) への特別なルーティングを必要とする場合があります。

• 依存関係 – アプリケーションが正しく機能するために依存しているアプリケーションを特定します。例えば、アプリケーションがデータベース、ストレージ、または支払いゲートウェイや外部ウェブサービスなどのサードパーティーサービスに依存している場合や、アプリケーションが環境内の他のアプリケーションに依存している場合などです。これらの依存関係にアクセスするには、認証のためにディレクトリサービスに接続するなど、特別なルーティングまたは設定が必要になる場合があります。

• 依存アプリケーション – 正常に機能するためにアプリケーションに依存するアプリケーションを特定します。移行中のダウンタイムを防ぐために、これらのアプリケーションを再設定して更新する必要がある場合があります。

• セキュリティとコンプライアンス — セキュリティとコンプライアンスチームでターゲット環境を確認し、ギャップを特定します。アプリケーションは、複数のコンポーネント、論理レイヤー、または複数の階層で構成されます。コンプライアンス要件によっては、これらのコンポーネントの一部をターゲット環境に移行できない場合や、ワークロードを移行するときに追加のセキュリティ対策が必要になる場合があります。一般的なセキュリティおよびコンプライアンス要件は、データレジデンシー、転送中の暗号化、保管時の暗号化です。これらには、ターゲット環境で追加の設定が必要です。例えば、通信を保護するために証明書を設定する必要がある場合や、保管中のデータを保護するために暗号化キーが必要になる場合があります。また、一部のアプリケーション層がオンプレミスのままで、他の層がクラウドに移行されるように、アプリケーションに複数の移行パターンを選択する必要がある場合もあります。

• ストレージの依存関係 – アプリケーションストレージの依存関係を確認し、アプリケーションをターゲット環境に移行するとこれらの依存関係にどのような影響があるかを判断します。例えば、アプリケーションがネットワーク接続ストレージ (NAS) やストレージエリアネットワーク (SAN) などのネットワークストレージに依存している場合は、Amazon Simple Storage Service (Amazon S3) や Amazon FSx などのクラウド内のストレージサービスを計画する必要があります。また、アプリケーションの実行を維持するために、ターゲットのクラウド環境にデータを移行する方法を計画する必要があります。

• データベース – アプリケーションが使用するデータベースの移行戦略を確認します。Amazon Relational Database Service (Amazon RDS)、Amazon Aurora、Amazon DynamoDB などの新しいデータベースサービスにリプラットフォームしますか？ ターゲット環境でデータベースをリホストしますか？ 場合によっては、特にモノリシックデータベースの場合、1 秒未満のレイテンシーなどの技術要件に対処したり、特定のタイプのデータベースの機能を活用したりするために、 AWS データベースをリファクタリングする必要があります。データレジデンシーのコンプライアンス要件と同様に、どのデータをオンプレミスで保持し、どのデータをクラウドに移行する必要があるかを特定する必要があります。例えば、顧客情報用にオンプレミスのデータベーステーブルを保持する必要があり、残りのデータベースをクラウドに移行できます。

• アプリケーションコンポーネント – アプリケーションが依存するコンポーネントを確認します。ターゲット環境でサポートされていないコンポーネントにアプリケーションが依存しているかどうかを判断します。ターゲット環境がすべてのアプリケーションコンポーネントをサポートしていない場合は、問題を軽減するためにアプリケーションをリファクタリングする必要があります。例えば、コンポーネントオブジェクトモデル (COM) Interop、COM+、Windows レジストリなどの Windows 専用コンポーネントに依存する .NET Framework アプリケーションがある場合、Linux オペレーティングシステムでアプリケーションをリプラットフォームするには、アプリケーションを .NET Core にリファクタリングする必要があります。

• アプリケーション層 – アプリケーション内の層の数を特定します。アプリケーションは n 層、2 層、またはスタンドアロンですか？ 各階層の移行パターンを理解していることを確認します。例えば、アプリケーションには、ユーザーインターフェイスをホストするプレゼンテーション (またはウェブ) 階層、ビジネスサービスをホストするアプリケーション階層、データベースをホストするデータベース階層があり、各階層には異なる移行パターンが必要になる場合があります。

• ディザスタリカバリ — 目標復旧時点 (RPO) と目標復旧時間 (RTO) を含む、アプリケーションの現在および将来のディザスタリカバリ (DR) 計画を特定します。既存のオンプレミス DR プランを使用するか、クラウドで新しい DR 戦略を検討するかを決定します。詳細については、 クラウドホワイトペーパーの「ワークロードのディザスタリカバリ」の「クラウドのディザスタリカバリオプション」と AWS「目標復旧 (RTO と RPO)」を参照してください。

ターゲット状態プロセスを定義する

アプリケーションターゲットの状態を定義するには、ポートフォリオプレイブックテンプレートで利用可能な、提供されているテンプレートであるアプリケーションターゲット状態ワークシート (Excel 形式) を使用することをお勧めします。テンプレートには、使用または変更できる標準属性が含まれています。次のように、アプリケーションターゲットの状態をドキュメント化するプロセスを定義します。

1. アプリケーションターゲット状態ワークシートを開きます。

2. デフォルトの属性を確認し、ユースケースに変更を加えます。

3. ワークシートを保存します。

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

5. 「ターゲットアプリケーションの状態」セクションで、次の操作を行います。

   1. 「このプロセスを完了するタイミング」セクションで、ポートフォリオチームがアプリケーションのターゲット状態を定義する必要があるかどうかを判断するための基準を設定します。

   2. 必要に応じて属性セクションを更新します。

   3. ユースケースに応じてプロセスセクションを更新します。

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

アプリケーションターゲットの状態のサンプル

次の表は、アプリケーションターゲット状態ワークシートを使用してアプリケーションのターゲット状態を文書化する方法の例を示しています。

アプリケーション	例
ターゲットプラットフォーム	AWS クラウド
ランディングゾーン	オンプレミスディレクトリサービスへのアクセスが必要です 組織全体で複数のアカウントとサービスの管理を一元化 AWS Control Tower する必要がある
依存関係	Active Directory、支払いゲートウェイ、インベントリシステム
依存アプリケーション	なし
セキュリティ	保管中と転送中の暗号化
コンプライアンス	PCI、SOC
ストレージの依存関係	ブートドライブアタッチ、NAS、ネットワーク共有
データベース	現行: Oracle DB クラウド: Amazon RDS for Oracle
アプリケーションコンポーネント	.NET Framework 4.5
アプリケーション層	N 層 フロントエンド、ビジネスサービス、データサービスとエージェント、データベース
ディザスタリカバリ	RPO: 1 分、RTO: 5 分 現在の DR 戦略はウォームスタンバイです 任意の米国リージョンの DR

ステップ終了基準

• アプリケーションターゲット状態ワークシートで、ターゲット状態プロセスに含める属性を定義しました。

• アプリケーションの優先順位付けランブックでは、以下を実行しました。

  • ポートフォリオチームがアプリケーションのターゲット状態を定義することが予想されるタイミングの基準を確立している。

  • ユースケースに基づいてターゲット状態を定義するプロセスを更新しました。

ステップ 4: アプリケーションのディープダイブプロセスを完了する

次に、ポートフォリオのワークストリームが、このタスクで設定したワークショップ、ルール、プロセスを使用して、アプリケーションについて詳しく説明します。これは、移行の実装段階でポートフォリオワークストリームが参照するプロセスです。

アプリケーション優先順位付けランブックでこのプロセスを次のようにカスタマイズします。

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

2. 「ステージ 2: アプリケーションの詳細分析を実行する」セクションで、ユースケースと環境に応じてプロセスを変更します。

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

4. レビューのために、アプリケーションの優先順位付けランブックをチームと共有します。