翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# タスク 4: アプリケーションのディープダイブプロセスを定義する
アプリケーションの優先順位付けのルールとプロセスの確立が完了したら、各アプリケーションの優先順位を絞り込むのに役立つアプリケーションの詳細な説明を実行します。アプリケーションのディープダイブは、優先度が最も高いものから低いものまで、一度に 1 つのアプリケーションで実行します。複数のポートフォリオチームを持つプロジェクトの場合、各チームは異なるアプリケーションに対して同時にアプリケーションのディープダイブを実行できます。
詳細な分析中に、依存関係など、アプリケーションの移行の複雑さに影響する予期しない問題が発生する可能性があります。この場合、前のステップで定義した複雑さスコア基準を変更し、それに応じてスコアシートを更新して、将来のアプリケーションのより正確な複雑さスコアを取得する必要があります。その後、新しい複雑さスコアを使用してアプリケーションの優先順位を更新できます。
このタスクは、次のステップで構成されます。
+ [ステップ 1: アプリケーションワークショッププロセスを定義する](#deep-dive-1)
+ [ステップ 2: アプリケーションマッピングプロセスを定義する](#deep-dive-2)
+ [ステップ 3: (オプション) アプリケーションターゲットの状態を定義する](#deep-dive-3)
+ [ステップ 4: アプリケーションのディープダイブプロセスを完了する](#deep-dive-4)
## ステップ 1: アプリケーションワークショッププロセスを定義する
ワークショッププロセスは、アプリケーションのディープダイブに対する最も効率的なアプローチの 1 つです。このプロセスを使用して、ステークホルダー、アプリケーション所有者、ポートフォリオチームと協力してアプリケーションを評価および分析します。目標は、アーキテクチャ、ビジネス目的、依存関係、環境など、アプリケーションの現在の状態を明確に把握することです。次に、アプリケーションのサイズと複雑さに関するこの詳細情報を使用して、アプリケーションのターゲット状態を設計します。
各ワークショップは通常 1～8 時間かかりますが、複雑性の高いアプリケーションにはさらに時間が必要になる場合があります。また、リソースの可用性、好み、アプリケーションのサイズと複雑さに応じて、ワークショップを複数の会議に分割することもできます。
### 期待される成果を特定する
アプリケーションワークショップを実施する前に、アジェンダを設定し、ワークショップの期待される成果、またはワークショップで収集する必要がある情報を定義する必要があります。これにより、ワークショップ参加者はワークショップの準備ができ、会議を目標に維持し、ワークショップの終了までに、アプリケーションの優先順位付け、ウェーブプラン、移行に必要なすべての情報を確実に取得できます。
期待される結果の標準セットを定義し、それらをアプリケーションの優先順位付けランブックに記録することをお勧めします。ワークショップを準備するときは、標準的な期待される結果を使用し、特定のアプリケーションに新しい結果を追加します。
アプリケーションワークショップで期待される成果の標準セットを次のように定義します。
1. アプリケーションの優先順位付けランブックを開きます。
1. *アプリケーションワークショップの期待される成果*セクションで、アプリケーションワークショップの期待される成果の標準セットを確立します。ワークショップを準備するときは、アプリケーションの特定のニーズに合わせてカスタマイズできます。
1. アプリケーションの優先順位付けランブックを保存します。
1. アプリケーションの優先順位付けランブックで期待される成果を維持します。アプリケーションワークショップを実施し、ポートフォリオ評価とウェーブプランニングを継続すると、期待される新しい成果を特定したり、既存の成果を改善したりできます。
以下は、アプリケーションワークショップで期待される成果の例です。
****
| 優先度 | アプリケーションワークショップの期待される成果 |
| --- | --- |
| 1 | 関連するサーバー、依存関係、環境、アプリケーション層など、アプリケーションの現在のアーキテクチャを明確に理解します。 |
| 2 | チームは、ターゲットアーキテクチャの設計をサポートするためにメタデータを収集しました。次のメタデータが必要です。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 3 | アプリケーション所有者アンケートは完了し、すべての主要な質問に回答します。 |
| 4 | チームは、ユーザーガイド、アプリケーションアーキテクチャドキュメント、テストドキュメント、設計ドキュメント、アプリケーションプログラミングインターフェイス (API) ドキュメントなど、すべてのアプリケーションドキュメントを収集しました。 |
### アプリケーションワークショップルールを定義する
アプリケーションワークショップを実施する前に、ワークショップを管理するルールを定義する必要があります。一般的なルールには、ワークショップの長さ、ワークショップで必要になる可能性のあるツール、考慮すべきスケジューリング上の考慮事項や期限などがあります。これにより、会議を目標に保ち、ワークショップで行われた決定が移行スケジュールに沿ったものになります。
アプリケーションワークショップルールは、アプリケーションの優先順位付けランブックに文書化することをお勧めします。
アプリケーションワークショップルールを次のように定義します。
1. アプリケーションの優先順位付けランブックを開きます。
1. *アプリケーションワークショップルール*セクションで、ワークショップを管理するルールを定義します。
1. アプリケーションの優先順位付けランブックを保存します。
1. アプリケーションの優先順位付けランブックのルールを維持します。アプリケーションワークショップを実施し、ポートフォリオ評価とウェーブプランニングを継続すると、新しいルールを特定したり、既存のルールを改善したりできます。
アプリケーションワークショップのルールの例を次に示します。
****
| 優先度 | ワークショップルール |
| --- | --- |
| 1 | ワークショップは、火曜日と木曜日のセッションごとに最大 2 時間スケジュールする必要があります。 |
| 2 | 12 月 1 日から 1 月 15 日の間、インフラストラクチャのフリーズが予定されています。 |
| 3 | 移行ツールの実践的なワークショップがあります。 |
| 4 | データセンター契約は 3 月 31 日に期限切れになります。ペナルティやコストのかかる契約延長を避けるため、ワークロードは 3 月 31 日までに退避する必要があります。 |
| 5 | 生体認証アプリケーションと時間および出席アプリケーションは保持されます。 |
### アプリケーションワークショッププロセスを定義する
アプリケーションワークショップを実施するための標準プロセスを定義することが重要です。これにより、一貫したエクスペリエンスが保証され、ワークショップ参加者に期待が設定されます。これにより、ワークショップの効率が向上します。
アプリケーションワークショッププロセスには 3 つのステージがあります。
+ **ワークショップの準備** – ワークショップの準備は、セッションがスムーズに進行し、参加者が期待される内容を把握するのに役立ちます。ワークショップの準備として、アジェンダを作成し、期待される成果を定義し、ワークショップに必要な参加者、ツール、情報を特定し、ワークショップをスケジュールします。少なくとも 1 週間前にワークショップをスケジュールすると、チームはカレンダーをブロックし、ワークショップの準備を整え、有用な情報を収集する時間を確保できます。
+ **ワークショップを実施する** – ワークショップを実施するときは、ディスカッションをアジェンダの項目に限定し、期待される成果を達成するようにします。役に立ちますが、アジェンダには含まれていないと思われるトピックに注意してください。ワークショップを記録すると便利です。
+ **ワークショップの結果をまとめる** – ワークショップの後、チームはアプリケーションの現在の状態と、優先順位付けと移行に影響を与える可能性のある潜在的な問題点、リスク、課題、ブロック要因を明確に理解する必要があります。ワークショップ後の一般的なタスクには、アプリケーションの優先順位の変更、アプリケーションの将来の状態の作成、次のワークショップに役立つ可能性のある期待される結果、ルール、またはプロセスの変更を含むランブックの更新が含まれます。
*アプリケーションの優先順位付け用のランブックテンプレート*には、アプリケーションワークショップの準備、実施、最終化のための標準的なstep-by-stepのプロセスが含まれています。アプリケーションワークショッププロセスを次のように定義します。
1. アプリケーションの優先順位付けランブックを開きます。
1. *アプリケーションワークショッププロセス*セクションで、ユースケースのニーズに合わせて標準プロセスを変更します。
1. アプリケーションの優先順位付けランブックを保存します。
1. アプリケーションの優先順位付けランブックでプロセスを維持します。アプリケーションワークショップを実施する際に、このプロセスに加えたい変更を特定する場合があります。
### ステップ終了基準
+ ワークショップのアジェンダと、ワークショップのサポートに必要なリソースとアーティファクトを定義しました。
+ ワークショップの期待される成果を定義し、ワークショップで収集する必要がある情報を特定しました。
+ ワークショッププロセスのトライアルを実施し、アプリケーションマッピングをサポートし、ターゲットの状態を設計するために必要な情報を取得しました。
+ アプリケーションの優先順位付けランブックに以下を文書化しました。
+ アプリケーションワークショップの期待される成果
+ アプリケーションワークショップのルール
+ アプリケーションワークショッププロセス
## ステップ 2: アプリケーションマッピングプロセスを定義する
*アプリケーションマッピング*は、各アプリケーションを移行パターンに割り当てるプロセスであり、 で特定して検証します[ステップ 4: 移行パターンを検証する](discovery.md#discovery-4)。このステップでは、アプリケーションの評価に使用するルールを定義します。次に、各アプリケーションの評価に使用するプロセスを定義します。各アプリケーションを移行パターンのユースケースにマッピングすることで、移行ツール、移行を完了するために必要なスキル、移行パターンの複雑さを特定できます。
必ずしもアプリケーションを 1 つのパターンに移行するわけではありません。同じアプリケーションに複数のパターンが必要な場合の詳細については、このセクションの[アプリケーションマッピングプロセスを定義する](#deep-dive-2-process)後半の「」を参照してください。
### アプリケーションマッピングルール
アプリケーションマッピングルールは、アプリケーションを評価し、適切な移行パターンを特定するのに役立ちます。各ルールは、アプリケーションの評価とパターンの一致基準に使用する必要がある情報で構成されます。
[ポートフォリオプレイブックテンプレート](samples/portfolio-playbook-templates.zip)では、*アプリケーションの優先順位付け用のランブックテンプレート*に、アプリケーションマッピングルールを文書化するためのセクションが含まれています。プロセスを次のように定義します。
1. アプリケーションの優先順位付けランブックを開きます。
1. *「アプリケーションマッピングルール*」セクションで、アプリケーションマッピングルールを定義します。
1. アプリケーションの優先順位付けランブックを保存します。
1. アプリケーションの優先順位付けランブックのルールを維持します。
次の表に、アプリケーションマッピングルールの例を示します。
**注記**
この表のパターン IDsと名前は、 のサンプルパターンに対応しています[ステップ 4: 移行パターンを検証する](discovery.md#discovery-4)。アプリケーションの優先順位付けランブックで定義したパターン IDs と名前を使用します。
****
| 優先度 | マッピングルール |
| --- | --- |
| 1 | 使用率データまたはモニタリングツールを使用して、アプリケーションがゾンビアプリケーションかアイドルアプリケーションかを特定します。アプリケーションがゾンビまたはアイドル状態のアプリケーションの場合は、*パターン 8: アプリケーションの廃止*を選択し、アプリケーションスタック内のサーバーをシャットダウンします。 |
| 2 | このアプリケーションをクラウドに移行するとビジネス価値が得られるかどうかを特定します。オンプレミスでのみ使用され、時間や出席アプリケーションなど、ブランチや地理的な場所間で共有されていないアプリケーションは、通常、クラウドに移行する必要はありません。このアプリケーションを移行してもビジネス価値が得られない場合は、*パターン 9: オンプレミスで保持*を選択します。 |
| 3 | アプリケーションのオペレーティングシステム (OS) が AWS、 AWS 、移行サービス、ベンダー、またはリホスト移行ツールでサポートされているかどうかを確認し、以下を実行します。[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 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 などのメインフレームサーバーかミッドレンジサーバーかを特定し、アプリケーションがエミュレータと互換性があることを確認します。これらの基準を満たしている場合は、*エミュレータを使用してパターン 6: メインフレームまたはミッドレンジサーバーを Amazon EC2 にリプラットフォームします*。 |
| 9 | これがレガシーアプリケーション、モノリシックアプリケーション、メインフレームベースのアプリケーションのいずれで、その制限によりビジネスの需要を満たせないかを特定します。例えば、アプリケーションがスケーリングできるか、関連アプリケーションと統合できるか、またはコストが高く保守が難しいかを特定します。アプリケーションがこれらの基準のいずれかを満たしている場合は、*パターン 11: アプリケーションを再設計する*を選択します。 |
### アプリケーションマッピングプロセスを定義する
アプリケーションを移行パターンにマッピングする場合、検出チームからアプリケーションの検出データをリクエストすると便利です。このデータには、通常、推奨される移行パターン (*R パターン*または *R スコア*と呼ばれることもあります）、使用率情報、アプリケーションの依存関係、および評価で使用できるその他の情報が含まれます。このアプリケーションを詳しく調べる際に、以前に特定した移行パターンを変更する場合があります。
データを取得したら、アプリケーションと、 で特定したビジネスおよび技術基準を比較できます[ステップ 2: ビジネスと技術の推進要因を特定する](discovery.md#discovery-2)。アプリケーションの優先順位付けランブックにドライバーを記録しました。基準に照らしてアプリケーションを評価すると、アプリケーションの複数の移行パターンを選択したり、コスト、スケジュール、その他の制限に基づいてパターンを排除したりする可能性があります。
以下は、1 つのアプリケーションで複数の移行パターンを使用する必要があるビジネスドライバーの例です。オンプレミスの SQL Server データベースを Amazon DynamoDB に移行したいが、データセンターの契約が期限切れになるため、ビジネスは提案されたスケジュールよりも早く移行してリプラットフォームしたいと考えています。このビジネスドライバーに対処するには、アプリケーションの移行計画を 2 パターンのアプローチに修正します。まず、アプリケーションをクラウドにリホストして、データセンターから削除します。その後、アプリケーションがクラウド内にあると、提案されたスケジュールに従ってアプリケーションを再プラットフォームできます。
また、アプリケーションが複数の階層で構成されるアプリケーションである n 階層アプリケーションであるかどうかも考慮する必要があります。*アプリケーション層は*、アプリケーションの水平レイヤーをホストする物理サーバーのグループです。N 層アプリケーションは、各層が異なる戦略を必要とする場合があり、アプリケーション層を異なるウェーブに移行することを選択できるため、より複雑になります。たとえば、プレゼンテーション、ビジネスサービス、データベース階層で構成されるアプリケーションがある場合、階層ごとに異なるパターンをマッピングできる可能性があります。
次に、アプリケーション優先順位付けランブックで定義したアプリケーションマッピングルールに対してアプリケーションを評価します。詳細については、このセクションの前半の [アプリケーションマッピングルール](#deep-dive-2-rules) を参照してください。
アプリケーションを 1 つ以上のパターンにマッピングしたら、この決定を確認してアプリケーション所有者に確認します。アプリケーション所有者は選択したパターンを確認し、移行の計画と実行に役立ちます。現時点では、アプリケーション所有者は、経験に基づいてインサイトを提供したり、移行で予想される問題を共有したりすることもできます。
アプリケーションを 1 つ以上の移行パターンにマッピングし、アプリケーション所有者にパターンを確認したら、アプリケーション、パターン ID、パターン名、および関連するドライバーをアプリケーションの優先順位付けランブックのアプリケーションマッピングテーブルに記録します。
[ポートフォリオプレイブックテンプレート](samples/portfolio-playbook-templates.zip)では、*アプリケーションの優先順位付け用のランブックテンプレート*に、アプリケーションマッピングの標準的なstep-by-stepプロセスが含まれています。プロセスを次のように定義します。
1. アプリケーションの優先順位付けランブックを開きます。
1. *アプリケーションワークショッププロセス*セクションで、ユースケースのニーズに合わせて標準プロセスを変更します。
1. アプリケーションの優先順位付けランブックを保存します。
1. アプリケーションの優先順位付けランブックでプロセスを維持します。
次の表は、アプリケーションマッピングテーブルの例です。*アプリケーションの優先順位付け用に用意されているランブックテンプレート*には、アプリケーションマッピングプロセスの結果を記録できる空のテーブルが含まれています。
**注記**
このテーブルのパターン IDsと名前は、 のサンプルパターンに対応しています[ステップ 4: 移行パターンを検証する](discovery.md#discovery-4)。アプリケーションの優先順位付けランブックで定義したパターン IDs と名前を使用します。
****
| アプリケーション名 | パターン ID | パターン名 | 対処されたビジネスおよび技術の推進要因 |
| --- | --- | --- | --- |
| 企業ウェブサイト | 1 | Application Migration Service または Cloud Migration Factory を使用して Amazon EC2 にリホストする | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| HR システム | 8 | アプリケーションを廃止します。 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 時間と出席申請 | 9 | オンプレミスで保持する | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| PO システム | 3 | を使用した Amazon EC2 へのリプラットフォーム CloudFormation | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| CRM システム | 10 | SaaS の再購入とアップグレード | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 固定アセットシステム | 7 | Amazon EC2 での Windows から Linux へのリプラットフォーム | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| ERP ファイルストレージ | 4 | AWS DataSync または を使用して Amazon EFS にリプラットフォームする AWS Transfer Family | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 台帳システム | 6 | エミュレータを使用してメインフレームまたはミッドレンジサーバーを Amazon EC2 にリホストする | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 総台帳 | 11 | アプリケーションを再設計する | [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
### ステップ終了基準
+ アプリケーションの優先順位付けランブックに以下を文書化しました。
+ アプリケーションマッピングルール
+ アプリケーションマッピングプロセス
+ 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 フレームワークに対してアプリケーションターゲットの状態を確認し、クラウド内のアプリケーションのセキュリティ、パフォーマンス、耐障害性を向上させます。
+ **ターゲットランディングゾーン** – 通常、[動員フェーズ](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/mobilize-phase.html)の終わりまでに、パイロットアプリケーションを実行する準備ができている完全なランディングゾーンを構築しておく必要があります。ランディングゾーンは、マルチアカウントアーキテクチャ、ID とアクセスの管理、ガバナンス、データセキュリティ、ネットワーク設計、ログ記録で設定済みである必要があります。パイロットアプリケーションを使用して、ランディングゾーンが完了したことを確認します。既存のターゲットランディングゾーンでパイロットアプリケーションを起動して実行できることを確認します。アプリケーションのランディングゾーンを変更する必要がある場合は、ランディングゾーンチームに要件を通知します。たとえば、アプリケーションが別のアカウントでホストされているサービスへのアクセスを必要とする場合や、アプリケーションが Virtual Private Cloud (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 戦略を検討するかを決定します。詳細については、 [クラウドホワイトペーパーの「ワークロードのディザスタリカバリ」の「ディザスタリカバリオプション](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)[」と「リカバリ目標 (RTO と RPO)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html#recovery-objectives-rto-and-rpo)」を参照してください。 * AWS*
### ターゲット状態プロセスを定義する
アプリケーションターゲットの状態を定義するには、提供されたテンプレートである*アプリケーションターゲット状態ワークシート* (Excel 形式) を使用することをお勧めします。このワークシートは、[ポートフォリオプレイブックテンプレート](samples/portfolio-playbook-templates.zip)で入手できます。テンプレートには、使用または変更できる標準属性が含まれています。アプリケーションターゲットの状態を次のように文書化するプロセスを定義します。
1. *アプリケーションターゲットの状態ワークシート*を開きます。
1. デフォルトの属性を確認し、ユースケースに変更を加えます。
1. ワークシートを保存します。
1. アプリケーションの優先順位付けランブックを開きます。
1. *ターゲットアプリケーションの状態*セクションで、次の操作を行います。
1. *このプロセスをいつ完了するか*セクションで、ポートフォリオチームがアプリケーションのターゲット状態を定義する必要があるかどうかを判断できるようにする基準を確立します。
1. 必要に応じて属性セクションを更新します。
1. ユースケースに応じてプロセスセクションを更新します。
1. アプリケーションの優先順位付けランブックを保存します。
#### アプリケーションターゲットの状態のサンプル
次の表は、*アプリケーションターゲット状態*ワークシートを使用してアプリケーションのターゲット状態を文書化する方法の例を示しています。
****
| アプリケーション | 例 |
| --- | --- |
| **ターゲットプラットフォーム** | 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. アプリケーションの優先順位付けランブックを開きます。
1. *ステージ 2: アプリケーションの詳細セクション*で、ユースケースと環境に応じてプロセスを変更します。
1. アプリケーションの優先順位付けランブックを保存します。
1. レビューのために、アプリケーションの優先順位付けランブックをチームと共有します。