翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Discovery アクセラレーションと初期計画
このポートフォリオ評価の最初の段階では、ポートフォリオレベルでデータを取得して分析する最初のステップに焦点を当てます。主な目的は、ビジネスドライバーを特定し、アプリケーションとインフラストラクチャから一般的なデータを収集して、ポートフォリオの初期ビューを取得することです。このデータには、[「データ要件](understanding-initial-assessment-data-requirements.md)」セクションで説明されているように、アプリケーション名、環境、製品バージョン、重要度、パフォーマンス値などの高レベルの技術的属性とビジネス属性が含まれます。この段階を完了することは、プロジェクトの範囲を理解し、初期移行候補を特定し、ビジネスケースを通知する上で重要です。
## このステージの主な結果
+ 文書化されたビジネス推進要因、成果、目標、技術指針の原則。
+ アプリケーションとインフラストラクチャの初期インベントリ、および特定されたデータギャップ。これは、さらに段階的に反復および改良されるポートフォリオの初期ビューです。
+ 方向性のあるビジネスケースと移行にかかる推定コスト。
+ 初期移行候補のリスト (3 つのアプリケーションなど）。
+ 次のステップを定義します。
# 初期評価データ要件について
データ収集にはかなりの時間がかかり、どのデータが必要でいつ必要かが明確でない場合、簡単にブロックされる可能性があります。重要なのは、このステージの結果には、少なすぎるデータと多すぎるデータのバランスを理解することです。このポートフォリオ評価の初期段階に必要なデータと忠実度レベルに焦点を当てるには、データ収集に反復的なアプローチを採用します。
## データソースとデータ要件
最初のステップは、データソースを特定することです。まず、データ要件を満たすことができる組織内の主要な利害関係者を特定します。これらは通常、サービス管理、運用、キャパシティプランニング、モニタリング、サポートチームのメンバー、およびアプリケーション所有者です。これらのグループのメンバーとの作業セッションを確立します。データ要件を伝え、データを提供できるツールと既存のドキュメントのリストを取得します。
これらの会話をガイドするには、次の一連の質問を使用します。
+ 現在のインフラストラクチャとアプリケーションのインベントリはどの程度正確で最新ですか? たとえば、会社設定管理データベース (CMDB) の場合、ギャップがどこにあるかはわかっていますか?
+ CMDB (または同等のもの) を更新するアクティブなツールとプロセスはありますか? その場合、どのくらいの頻度で更新されますか? 最新の更新日はいつですか?
+ CMDB などの現在のインベントリには、application-to-infrastructure間のマッピングが含まれていますか? 各インフラストラクチャアセットはアプリケーションに関連付けられていますか? 各アプリケーションはインフラストラクチャにマッピングされていますか?
+ インベントリには、各製品のライセンスとライセンス契約のカタログが含まれていますか?
+ インベントリには依存関係データが含まれていますか? サーバーからサーバー、アプリケーションからアプリケーション、アプリケーション、サーバーからデータベースへの通信データが存在することに注意してください。
+ 環境では、アプリケーションとインフラストラクチャの情報を提供できる他のどのようなツールを利用できますか? データソースとして使用できるパフォーマンス、モニタリング、管理ツールが存在することに注意してください。
+ アプリケーションやインフラストラクチャをホストするデータセンターなど、さまざまな場所は何ですか?
これらの質問に回答したら、特定されたデータソースを一覧表示します。次に、忠実度レベルまたは信頼レベルをそれぞれのレベルに割り当てます。ツールなどのアクティブなプログラムソースから最近 (30 日以内) 検証されたデータは、最高レベルの忠実度を持ちます。静的データは忠実度が低く、信頼度が低いと見なされます。静的データの例として、ドキュメント、ワークブック、手動で更新された CMDBs、プログラムで管理されていないその他のデータセット、または最終更新日が 60 日を超えているデータセットなどがあります。
次の表のデータ忠実度レベルを例として示します。前提とそれに関連するリスクに対する最大の許容度の観点から組織の要件を評価し、適切な忠実度レベルを決定することをお勧めします。表では、組織の知識とは、文書化されていないアプリケーションとインフラストラクチャに関する情報を指します。
| **データソース** | **忠実度レベル** | **ポートフォリオカバレッジ** | **コメント** |
| --- |--- |--- |--- |
| の専門知識 | 低 - 正確なデータの最大 25%、75% の想定値、またはデータが 150 日以上経過している。 | 低 | 重要アプリケーションに焦点を当てた希少 |
| Knowledge base | 中低 - 正確なデータの 35～40%、65～60% の想定値、またはデータが 120～150 日経過しています。 | 中 | 手動で管理され、詳細レベルに一貫性がない |
| CMDB | 中 - 正確なデータの約 50%、約 50% の想定値、またはデータが 90～120 日経過しています。 | 中 | 混合ソースからのデータ、複数のデータギャップを含む |
| VMware vCenter のエクスポート | 中～高 - 正確なデータの 75～80%、25～20% の想定値、またはデータが 60～90 日経過しています。 | 高 | 仮想化された資産の 90% をカバー |
| アプリケーションパフォーマンスのモニタリング | 高 - ほぼ正確なデータ、約 5% の想定値、またはデータが 0～60 日経過しています。 | 低 | 重要な本番稼働システムに限定 (アプリケーションポートフォリオの 15% をカバー) |
次の表は、各アセットクラス (アプリケーション、インフラストラクチャ、ネットワーク、移行) に必要なデータ属性とオプションのデータ属性、特定のアクティビティ (インベントリまたはビジネスケース）、およびこの評価ステージで推奨されるデータ忠実度を示しています。テーブルでは、次の略語を使用します。
+ R、必須
+ (D)、ディレクティブビジネスケースの場合、総所有コスト (TCO) の比較とディレクティブビジネスケースに必要
+ (F)、TCO 比較に必要な全方向性ビジネスケースと、移行とモダナイゼーションのコストを含む方向性ビジネスケースの場合
+ O、オプション
+ 該当なし、 は該当なし
**アプリケーション**
| **属性名** | **説明** | **インベントリと優先順位付け** | **ビジネスケース** | **推奨される忠実度レベル (最小)** |
| --- |--- |--- |--- |--- |
| 一意の識別子 | たとえば、アプリケーション ID などです。通常、既存の CMDBs またはその他の内部インベントリと管理システムで使用できます。一意の IDs組織で定義されていない場合は必ず作成することを検討してください。 | R | R (D) | 高 |
| アプリケーション名 | このアプリケーションが組織で認識される名前。必要に応じて、市販の (COTS) off-the-shelf ベンダーと製品名を含めます。 | R | R (D) | やや高い |
| COTS ですか? | はいまたはいいえ。商用アプリケーションか内部開発か | R | R (D) | やや高い |
| COTS 製品とバージョン | 商用ソフトウェア製品名とバージョン | R | R (D) | 中 |
| 説明 | プライマリアプリケーション関数とコンテキスト | R | O | 中 |
| 緊急性 | 例えば、戦略アプリケーションや収益を生み出すアプリケーション、重要な機能のサポートなど | R | O | やや高い |
| タイプ | データベース、顧客関係管理 (CRM)、ウェブアプリケーション、マルチメディア、IT 共有サービスなど | R | O | 中 |
| 環境 | 例: 本番稼働前、本番稼働前、開発、テスト、サンドボックス | R | R (D) | やや高い |
| コンプライアンスと規制 | ワークロードに適用されるフレームワーク (HIPAA、Sox、PCI-DSS、ISO、SOC、FedRAMP など) と規制要件 | R | R (D) | やや高い |
| 依存関係 | 内部および外部のアプリケーションまたはサービスへのアップストリームとダウンストリームの依存関係。運用要素 (メンテナンスサイクルなど) などの非技術的な依存関係 | O | O | やや低い |
| インフラストラクチャマッピング | アプリケーションを構成する物理アセットや仮想アセットへのマッピング | O | O | 中 |
| ライセンス | 商品ソフトウェアライセンスタイプ (Microsoft SQL Server Enterprise など) | O | R | やや高い |
| Cost | ソフトウェアライセンス、ソフトウェアオペレーション、メンテナンスのコスト | 該当なし | O | 中 |
**インフラストラクチャ**
| | | | | |
| --- |--- |--- |--- |--- |
| **属性名** | **説明** | **インベントリと優先順位付け** | **ビジネスケース** | **推奨される忠実度レベル (最小)** |
| 一意の識別子 | たとえば、サーバー ID などです。通常、既存の CMDBs またはその他の内部インベントリと管理システムで使用できます。一意の IDs組織で定義されていない場合は必ず作成することを検討してください。 | R | R | 高 |
| ネットワーク名 | ネットワーク内のアセット名 (ホスト名など) | R | O | やや高い |
| DNS 名 (完全修飾ドメイン名、または FQDN) | [DNS 名] | O | O | 中 |
| IP アドレスとネットマスク | 内部 IP アドレスおよび/またはパブリック IP アドレス | R | O | やや高い |
| アセットタイプ | 物理サーバーまたは仮想サーバー、ハイパーバイザー、コンテナ、デバイス、データベースインスタンスなど。 | R | R | やや高い |
| 製品名 | 商用ベンダーと製品名 (VMware ESXi、IBM Power Systems、Exadata など) | R | R | 中 |
| オペレーティングシステム | 例: REHL 8、Windows Server 2019、AIX 6.1 | R | R | やや高い |
| 設定 | 割り当てられた CPU、コア数、コアあたりのスレッド数、合計メモリ、ストレージ、ネットワークカード | R | R | やや高い |
| 使用率 | CPU、メモリ、ストレージのピークと平均。データベースインスタンスのスループット。 | R | O | やや高い |
| ライセンス | 商品ライセンスタイプ (RHEL Standard など) | R | R | 中 |
| は共有インフラストラクチャですか? | はいまたはいいえ。認証プロバイダー、モニタリングシステム、バックアップサービス、および同様のサービスなどの共有サービスを提供するインフラストラクチャサービスを示します。 | R | R (D) | 中 |
| アプリケーションマッピング | このインフラストラクチャで実行されるアプリケーションまたはアプリケーションコンポーネント | O | O | 中 |
| Cost | ハードウェア、メンテナンス、オペレーション、ストレージ (SAN、NAS、オブジェクト）、オペレーティングシステムライセンス、ラックスペースの共有、データセンターのオーバーヘッドなど、ベアメタルサーバーのフルロードコスト | 該当なし | O | やや高い |
**ネットワーク**
| | | | | |
| --- |--- |--- |--- |--- |
| **属性名** | **説明** | **インベントリと優先順位付け** | **ビジネスケース** | **推奨される忠実度レベル (最小)** |
| パイプのサイズ (MB/秒）、冗長性 (Y/N) | 現在の WAN リンク仕様 (例: 1000 Mb/秒冗長) | O | R | 中 |
| リンク使用率 | ピーク使用率と平均使用率、アウトバウンドデータ転送 (GB/月) | O | R | 中 |
| レイテンシー (ミリ秒) | 接続された場所間の現在のレイテンシー。 | O | O | 中 |
| Cost | 1 か月あたりの現在のコスト | 該当なし | O | 中 |
**移行**
| | | | | |
| --- |--- |--- |--- |--- |
| **属性名** | **説明** | **インベントリと優先順位付け** | **ビジネスケース** | **推奨される忠実度レベル (最小)** |
| リホスト | 各ワークロード (人日) の顧客とパートナーの労力、1 日あたりの顧客とパートナーのコスト率、ツールコスト、ワークロード数 | 該当なし | R (F) | やや高い |
| リプラットフォーム | 各ワークロードの顧客とパートナーの労力 (人日）、1 日あたりの顧客とパートナーのコスト率、ワークロードの数 | 該当なし | R (F) | やや高い |
| リファクタリング | 各ワークロードの顧客とパートナーの労力 (人日）、1 日あたりの顧客とパートナーのコスト率、ワークロードの数 | 該当なし | O | やや高い |
| リタイア | サーバー数、平均廃止コスト | 該当なし | O | やや高い |
| ランディングゾーン | 既存の (Y/N)、必要な AWS リージョンのリスト、コストの再利用 | 該当なし | R (F) | やや高い |
| 人と変化 | クラウド運用と開発でトレーニングするスタッフ数、1 人あたりのトレーニングコスト、1 人あたりのトレーニング時間のコスト | 該当なし | R (F) | やや高い |
| 時間 | 対象範囲内のワークロード移行期間 (月) | O | R (F) | やや高い |
| 並列コスト | 移行中に現状のコストを削除できる時間枠とレート | 該当なし | O | やや高い |
| 移行中に AWS 製品やサービス、およびその他のインフラストラクチャコストが導入される時間枠とレート | 該当なし | O | やや高い |
## 検出ツールの必要性の評価
組織には検出ツールが必要ですか? ポートフォリオ評価には、アプリケーションとインフラストラクチャに関する信頼性の高いup-to-dateデータが必要です。ポートフォリオ評価の初期段階では、仮定を使用してデータギャップを埋めることができます。
ただし、進捗状況に応じて、忠実度の高いデータにより、移行計画を正常に作成し、ターゲットインフラストラクチャを正しく推定してコストを削減し、メリットを最大化できます。また、依存関係を考慮し、移行の落とし穴を回避する実装を有効にすることで、リスクを軽減します。クラウド移行プログラムにおける検出ツールの主なユースケースは、以下を通じてリスクを軽減し、データの信頼性を高めることです。
+ 自動またはプログラムによるデータ収集により、検証済みで信頼性の高いデータが得られる
+ データの取得速度の加速、プロジェクトの速度の向上、コストの削減
+ 通常 CMDBs では利用できない通信データや依存関係など、データの完全性のレベルが向上
+ 自動アプリケーション識別、TCO 分析、予測実行率、最適化レコメンデーションなどのインサイトの取得
+ 信頼性の高い移行ウェーブプランニング
システムが特定の場所に存在するかどうかが不明な場合、ほとんどの検出ツールはネットワークサブネットをスキャンし、ping または Simple Network Management Protocol (SNMP) リクエストに応答するシステムを検出できます。すべてのネットワークまたはシステム設定で ping または SNMP トラフィックが許可されるわけではありません。これらのオプションについて、ネットワークチームや技術チームと話し合います。
アプリケーションポートフォリオの評価と移行のさらなる段階は、正確な依存関係マッピング情報に大きく依存します。依存関係マッピングは、 に必要な AWS インフラストラクチャと設定 (セキュリティグループ、インスタンスタイプ、アカウントの配置、ネットワークルーティングなど) を理解します。また、同時に移動する必要があるアプリケーション (低レイテンシーネットワーク経由で通信する必要があるアプリケーションなど) のグループ化にも役立ちます。さらに、依存関係マッピングは、ビジネスケースを進化させるための情報を提供します。
検出ツールを決定するときは、評価プロセスのすべての段階を考慮し、データ要件を予測することが重要です。データギャップはブロック要因になる可能性があるため、将来のデータ要件とデータソースを分析してそれらを予測することが重要です。フィールドの経験上、ほとんどの停止した移行プロジェクトには、スコープ内のアプリケーション、関連するインフラストラクチャ、およびそれらの依存関係が明確に識別されないデータセットが限られています。この識別の欠如は、誤ったメトリクス、決定、遅延につながる可能性があります。up-to-dateデータを取得することは、移行プロジェクトを成功させるための最初のステップです。
*検出ツールを選択する方法*
市場内のいくつかの検出ツールは、さまざまな機能と機能を提供します。要件を検討してください。また、組織に最適なオプションを決定します。移行用の検出ツールを決定する際の最も一般的な要因は次のとおりです。
*セキュリティ*
+ ツールデータリポジトリまたは分析エンジンにアクセスするための認証方法は何ですか?
+ データにアクセスできるユーザーと、ツールにアクセスするためのセキュリティコントロールは何ですか?
+ ツールによるデータ収集方法 専用の認証情報が必要ですか?
+ ツールがシステムにアクセスしてデータを取得するには、どのような認証情報とアクセスレベルが必要ですか?
+ ツールコンポーネント間でのデータ転送方法
+ このツールは、保管中および転送中のデータ暗号化をサポートしていますか?
+ データは環境内外の 1 つのコンポーネントに一元化されていますか?
+ ネットワークとファイアウォールの要件は何ですか?
セキュリティチームが検出ツールに関する早期の会話に関与していることを確認します。
*データ主権*
+ データはどこに保存および処理されますか?
+ ツールは Software as a Service (SaaS) モデルを使用していますか?
+ 環境の境界内にすべてのデータを保持する可能性はありますか?
+ データが組織の境界を離れる前に、データをスクリーニングできますか?
データレジデンシー要件の観点から、組織のニーズを考慮してください。
*アーキテクチャ*
+ どのようなインフラストラクチャが必要で、どのような異なるコンポーネントが必要ですか?
+ 複数のアーキテクチャを利用できますか?
+ このツールは、エアロックされたセキュリティゾーンへのコンポーネントのインストールをサポートしていますか?
パフォーマンス
+ データ収集がシステムに与える影響
*互換性と範囲*
+ このツールは、私の製品とバージョンのすべてまたはほとんどをサポートしていますか? ツールドキュメントを確認して、サポートされるプラットフォームをスコープに関する現在の情報と照らし合わせて確認します。
+ ほとんどのオペレーティングシステムはデータ収集に対応していますか? オペレーティングシステムのバージョンがわからない場合は、検出ツールのリストを、サポートされているシステムの範囲が広いものに絞り込もうとします。
*収集方法*
+ ツールでは、各ターゲットシステムにエージェントをインストールする必要がありますか?
+ エージェントレスデプロイをサポートしていますか?
+ エージェントとエージェントレスは同じ機能を提供しますか?
+ 収集プロセスとは
*特徴*
+ 利用可能な機能は何ですか?
+ 総所有コスト (TCO) と推定 AWS クラウド 実行率を計算できますか?
+ 移行計画をサポートしていますか?
+ パフォーマンスを測定しますか?
+ ターゲット AWS インフラストラクチャを推奨できますか?
+ 依存関係マッピングを実行しますか?
+ どのレベルの依存関係マッピングが提供されますか?
+ API アクセスを提供しますか? (たとえば、データを取得するためにプログラムでアクセスできますか?)
強力なアプリケーションとインフラストラクチャの依存関係マッピング機能を持つツールと、通信パターンからアプリケーションを推測できるツールを検討してください。
*コスト*
+ ライセンスモデルとは
+ ライセンスの料金はいくらですか?
+ 料金は各サーバーの料金ですか? 階層料金ですか?
+ オンデマンドでライセンスできる機能が限られているオプションはありますか?
検出ツールは、通常、移行プロジェクトのライフサイクル全体で使用されます。予算が限られている場合は、少なくとも 6 か月を検討してください。ただし、検出ツールがない場合、通常、手動作業と内部コストが増加します。
*サポートモデル*
+ デフォルトでは、どのレベルのサポートが提供されますか?
+ サポートプランはありますか?
+ インシデント対応時間はどれくらいですか?
*プロフェッショナルサービス*
+ ベンダーは検出出力を分析するためのプロフェッショナルサービスを提供していますか?
+ このガイドの要素について説明できますか?
+ ツール \$1 サービスの割引やバンドルはありますか?
**ヒント**
検出ツールを検索して評価するには、[検出、計画、推奨事項](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/)のサイトを使用します。
*検出ツールの推奨機能*
複数のツールからのデータのプロビジョニングと時間の経過に伴う組み合わせを回避するには、検出ツールで次の最小機能をカバーする必要があります。
+ **ソフトウェア** – 検出ツールは、実行中のプロセスとインストールされたソフトウェアを特定できる必要があります。
+ **依存関係マッピング** – ネットワーク接続情報を収集し、サーバーと実行中のアプリケーションのインバウンドとアウトバウンドの依存関係マップを構築できる必要があります。また、検出ツールは、通信パターンに基づいてインフラストラクチャのグループからアプリケーションを推測できる必要があります。
+ **プロファイルと設定の検出** – CPU ファミリー (x86、PowerPC など）、CPU コア数、メモリサイズ、ディスク数とサイズ、ネットワークインターフェイスなどのインフラストラクチャプロファイルをレポートできる必要があります。
+ **ネットワークストレージ検出** – ネットワーク接続ストレージ (NAS) からネットワーク共有を検出してプロファイリングできる必要があります。
+ **パフォーマンス** – CPU、メモリ、ディスク、ネットワークのピーク使用率と平均使用率をレポートできる必要があります。
+ **ギャップ分析** — データ量と忠実度に関するインサイトを提供できるはずです。
+ **ネットワークスキャン** – ネットワークサブネットをスキャンし、不明なインフラストラクチャアセットを検出できる必要があります。
+ **レポート** – 収集と分析のステータスを提供できる必要があります。
+ **API アクセス** – 収集されたデータにアクセスするためのプログラムによる手段を提供できる必要があります。
*考慮すべき追加機能*
+ **TCO 分析**により、現在のオンプレミスコストと予測 AWS コストのコストを比較できます。
+ リホスト**およびリプラットフォームシナリオにおける Microsoft SQL Server および Oracle システムのライセンス分析と最適化の推奨事項**。
+ **移行戦略の推奨事項** (検出ツールは、現在のテクノロジーに基づいてデフォルトの移行 R タイプの推奨事項を作成できますか?)
+ **インベントリのエクスポート** (CSV または同様の形式)
+ **適切なサイズのレコメンデーション** (たとえば、推奨されるターゲット AWS インフラストラクチャをマッピングできますか?)
+ **依存関係の視覚化** (たとえば、依存関係マッピングをグラフィカルモードで視覚化できますか?)
+ **アーキテクチャビュー** (たとえば、アーキテクチャ図を自動的に作成できますか?)
+ **アプリケーションの優先順位付け** (移行の優先順位付け基準を作成するために、アプリケーション属性とインフラストラクチャ属性に重みや関連性を割り当てることはできますか?)
+ **ウェーブプランニング** (推奨されるアプリケーションのグループや移行ウェーブプランを作成する機能など)
+ **移行コストの見積もり** (移行作業の見積もり)
*デプロイに関する考慮事項*
検出ツールを選択して調達したら、以下の質問を検討して、ツールを組織にデプロイするチームとの会話を促進します。
+ サーバーまたはアプリケーションはサードパーティーによって運用されていますか? これにより、チームが関与し、従うプロセスが指示される可能性があります。
+ 検出ツールをデプロイするための承認を取得するための大まかなプロセスは何ですか?
+ サーバー、コンテナ、ストレージ、データベースなどのシステムにアクセスするための主な認証プロセスは何ですか? サーバー認証情報はローカルですか、それとも一元管理されていますか? 認証情報を取得するプロセスは何ですか? システムからデータを収集するには、認証情報が必要です (コンテナ、仮想サーバーまたは物理サーバー、ハイパーバイザー、データベースなど）。特にこれらのアセットが一元化されていない場合、各アセットに接続するための検出ツールの認証情報を取得するのは難しい場合があります。
+ ネットワークセキュリティゾーンの概要は何ですか? ネットワーク図は利用できますか?
+ データセンターでファイアウォールルールをリクエストするプロセスは何ですか?
+ データセンターの運用 (検出ツールのインストール、ファイアウォールリクエスト) に関連する現在のサポートサービスレベルアグリーメント (SLAs) は何ですか?
# ビジネスドライバーと技術ガイドの原則
## ビジネスドライバー
組織が既にクラウドへの移行を決定しているか、その決定に近づいているかにかかわらず、クラウド移行のビジネス推進要因を定義して文書化すると、移行の理由が明確になります。理由が文書化されたら、移行対象とその移行方法を定義できます。このアクティビティは重要です。次のステップを知らせ、ガイドするために、プロセスのできるだけ早い段階で行うことをお勧めします。
ディスカッションに参加すべきステークホルダーを特定し、推進要因を文書化します。通常、組織内の CxOs、シニアマネージャー、主要なテクノロジーリーダー、および独自の顧客です。顧客がこの議論に参加する可能性は低いですが、組織内の 1 人以上の人物が顧客の見解と目標を表すように指定することをお勧めします。
ビジネスドライバーは、結果が達成されたかどうかを検証するために、移行ジャーニー全体で測定できるメトリクスにリンクする必要があります。会社の戦略的目標と年次レポートは、出発点となります。
クラウドへの移行の結果として、既存のメトリクスと予測されたメトリクスに基づいて、会社のありたい場所に会話を集中させます。目標とビジネス成果を考慮します。また、クラウド導入の増加に伴う成功について考えてみましょう。
次に、各ドライバーの重要度レベルを確立します。優先順位は何ですか? 予想される利点は何ですか? メリットはビジネス目標と成果にどのように役立ちますか? アプリケーションポートフォリオ評価の文脈では、回答は移行するワークロードに優先順位を付け、技術的な指針を確立するのに役立ちます。ただし、ビジネスドライバーは移行プログラム全体を定義し、影響します。
## テクニカルガイドの原則
テクニカルガイド原則は、ポートフォリオ評価の後半段階で移行戦略の選択に役立ちます。現在のステージでは、それらを特定することに重点を置いています。
指針の原則は、ビジネス目標と成果から導き出される一般的なテクノロジー関連およびアプローチ関連の意思決定として確立できます。
例えば、ある企業にはコスト削減の主な目標があり、望ましい成果は 6～12 か月で特定の日付までにオンプレミスデータセンターを閉鎖することです。結果としての指針となる原則は、可能な限りリホストまたは再配置移行戦略を使用して、すべてのアプリケーションをクラウドにリフトアンドシフトすることです。この場合、lift-and-shiftアプローチは短期的な移行成果を加速します。アプリケーションがオンプレミスデータセンターの外に移動した後、移行されたワークロードを最適化またはモダナイズするための主要なビジネスドライバーに集中できます。
テクニカルガイドの原則を確立するには、まずビジネス推進要因を分析します。ビジネス目標と成果を達成するテクノロジーとテクニックのリストを特定します。次に、リストを絞り込み、適合性または好みに基づいて関連性の順序を割り当てて、望ましい結果を達成します。
移行の計画と実行に関わる人々に指針を文書化し、伝えます。原則と実際の実装の間の懸念と潜在的な競合を強調します。
次の表は、ビジネスドライバーと技術ガイドの原則の例を示しています。
| **ビジネスドライバー** | **結果** | **メトリクス** | **テクニカルガイドの原則** |
| --- |--- |--- |--- |
| イノベーションを加速します。 | 競争力の向上、ビジネスの俊敏性の向上 | 1 日または 1 か月あたりのデプロイ数、四半期ごとにリリースされた新機能、顧客満足度スコア、実験数 | マイクロサービスと DevOps 運用モデルを使用してアプリケーションの差別化をリファクタリングし、新機能の俊敏性と市場投入までの時間を短縮します。 |
| 運用コストとインフラストラクチャコストを削減します。 | 需要と供給が一致する伸縮自在なコストベース (使用した分の支払い) | 時間の経過に伴う支出の変動 | 1. インフラストラクチャの適切なサイズ設定でアプリケーションをリホストします。2. 使用率が低い、または使用していないアプリケーションを廃止します。 |
| 運用の耐障害性を高めます。 | 稼働時間を改善し、平均復旧時間を短縮 | SLAs、インシデントの数 | 1. アプリケーションを最新のサポートされているオペレーティングシステムバージョンにリプラットフォームします。2. 重要なアプリケーションに高可用性アーキテクチャを実装します。 |
| データセンターを終了します。 | 6～12 か月以内の日付によるデータセンター閉鎖 | サーバー移行の速度 | Cloud Migration Factory ソリューションを使用してアプリケーションをリホストします。 |
| オンプレミスのままで、俊敏性と耐障害性を高めます。 | オンプレミスを維持しながら競争力と稼働時間を改善 | 1 日または 1 か月あたりのデプロイ数、四半期あたりの新機能リリース数、SLAs、インシデント数 | 1. 機能をクラウドに拡張することで、システムをモダナイズします。2. のリホストまたはリプラットフォームを評価します AWS Outposts。 |
# データ収集の開始
データ収集は、アプリケーションとインフラストラクチャからメタデータを収集するプロセスです。このプロセスは、評価のすべての段階で反復されます。各ステージでは、データ量と忠実度が増加します。この段階では、初期インベントリの確立に役立つ一般的なデータを収集することに重点を置いています。インベントリは、方向性のあるビジネスケースを作成し、初期移行候補を特定するために使用されます。
現在のデータソースを特定したら、できるだけ多くのシステムから情報を収集することをお勧めします。詳細については、このステージ[のデータ要件](understanding-initial-assessment-data-requirements.md)を参照してください。
このアプローチには、現在のポートフォリオビューと、アプリケーションとサービスに関する組織の知識の更新に役立つ利点があります。また、何を移動させるかを決定するのにも役立ちます。推奨されるアプローチは、設定管理データベース (CMDB) 出力や情報技術サービス管理 (ITSM) システムなどの既存のデータを確認することです。次に、データ収集の対象となるアセットのリストを作成します。組織で移行の対象範囲と対象外の範囲が完全に明確である場合は、対象範囲内のシステムにデータ収集を制限することがあります。
ポートフォリオを構築するときは、アプリケーションとその環境またはソフトウェアリリースのライフサイクルを考慮してください。例えば、顧客関係管理 (CRM) アプリケーションを識別し、テスト環境、開発環境、本番稼働環境を指定する代わりに、3 つのアプリケーション (CRM-Test、CRM-Dev、CRM-Prod など) を一覧表示します。または、CRM 名を使用しますが、各環境に一意の ID を割り当て、データリポジトリに個別のレコードとして表示します。これは、これらの環境の移行を個別に計画および追跡するのに役立ちます。たとえば、非本番環境を最初に移行できます。環境に従ってアプリケーションのインスタンスを一覧表示することで、移行を明確に管理および管理できます。
データ収集中に、どのアプリケーションまたはサーバーが特定のデータセンターまたはソースロケーションにあるかが不確実な場合があります。このような場合、既存の管理ツールからベアメタルリストとハイパーバイザーリストを取得すると便利です。たとえば、ハイパーバイザーに接続して、データ収集の対象となる仮想マシンのリストを取得できます。
既存のデータソースを組み合わせると、初期出力が不完全になる可能性があることに注意してください。重要なのは、このステージ[のデータ要件](understanding-initial-assessment-data-requirements.md)と既存のソースから何を取得できるかという点でギャップ分析を実行することです。完全性の割合とデータ忠実度レベルを対比することが重要です。低忠実度ソースからのより高い完全性レベルには、分析の欠陥につながる可能性のあるいくつかの仮定が含まれます。この評価段階では最大データ忠実度は必要ありませんが、データソースは少なくとも中～中程度の忠実度にすることをお勧めします。これらの数値を、データギャップを埋めるための仮定の使用を含め、組織のリスク許容度と照らし合わせます。
ギャップ分析は、作業しているデータの量と品質を理解するのに役立ちます。この分析は、方向性のあるビジネスケースを作成し、移行のアプリケーションに優先順位を付けるために実行する必要がある前提のレベルを確立するのにも役立ちます。検出ツールは、ギャップを埋め、忠実度の高いデータを収集するのに役立ちます。データの信頼性を高め、移行の成果を加速させるには、できるだけ早く検出ツールをデプロイすることをお勧めします。新しいツールの内部調達、セキュリティ、実装プロセスが完了するまでに数週間または数か月かかる可能性があるため、早期のアクションも重要です。
この段階では、コミュニケーションプランまたはケイデンスとスコープ変更制御メカニズムを確立することをお勧めします。これにより、ステークホルダーが事前に計画を立て、リスクを軽減できるように、ステークホルダーに最新情報を伝えることができます。明確なコミュニケーションの重要な要素は、アプリケーションポートフォリオと関連インフラストラクチャの信頼できる単一のソースを定義することです。複数の記録システム、アプリケーション、インフラストラクチャのリストを保持しないでください。バージョニングとオンラインコラボレーションをサポートするデータを 1 か所 (データベース、ツール、スプレッドシートなど) に保持し、所有者を割り当てます。
# 優先順位付けと移行戦略
移行計画の主な要素は、優先順位付け基準を確立することです。この演習のポイントは、アプリケーションを移行する順序を理解することです。戦略は、優先順位モデルを進化させるために反復的かつ段階的なアプローチを取ることです。
## アプリケーションの優先順位付け
この評価ステージでは、初期基準を確立して、低リスクおよび低複雑さのワークロードを優先することに重点を置いています。これらのワークロードは、パイロットアプリケーションに適しています。初期移行で低リスクで複雑さの低いワークロードを使用すると、リスクが軽減され、チームは経験を積むことができます。これらの基準は、移行ウェーブプランの作成時にビジネスの推進要因に合わせて、さらなる評価段階で進化します。
初期基準では、クラウドでサポートされているインフラストラクチャで実行され、非本番環境から実行される、少数の依存関係を持つアプリケーションを優先する必要があります。たとえば、開発環境またはテスト環境で 0～3 個の依存関係をそのままリホストできるアプリケーションです。これらの基準は、クラウド導入の成熟度と信頼度のレベルに応じて、パイロットアプリケーションと、最初と 2 番目の移行ウェーブを定義するために有効です。
*使用する初期基準の決定*
最初のワークロードの優先順位付けに使用するデータポイントを 2～10 個選択します。これらのデータポイントは、最初のアプリケーションとインフラストラクチャのインベントリから取得されます ([データ収集](initiating-data-collection.md)セクションを参照）。
次に、各データポイントの可能な値ごとにスコアまたは重みを定義します。例えば、環境属性が選択され、可能な値が本番、開発、テストの場合、各値にスコアが割り当てられ、数値が大きいほど優先度が高くなります。オプションですが、各データポイントに重要度または関連性の乗数を割り当てることをお勧めします。このオプションのステップでは、より重要なことを強調する高レベルの差別化要因を提供します。これにより、値にスコアを割り当てる際に繰り返し基準を一致させることができます。
次の表は、最初のいくつかの移行ウェーブで低リスクのシンプルなアプリケーションを優先する戦略に基づいて、属性の選択例とその値の割り当てを示しています。
| **属性 (データポイント)** | **使用できる値** | **スコア (0～99)** | **重要性または関連性の乗算係数** |
| --- |--- |--- |--- |
| 環境 | テスト | 60 | 高 (1x) |
| 開発 | 40 |
| 本番稼働 | 20 |
| ビジネスの重要性 | 低 | 60 | 高 (1x) |
| 中 | 40 |
| 高 | 20 |
| 規制またはコンプライアンスフレームワーク | なし | 60 | 高 (1x) |
| FedRAMP | 10 |
| オペレーティングシステムのサポート | クラウド対応 | 60 | 中高 (0.8x) |
| クラウドではサポートされていません | 10 |
| コンピューティングインスタンスの数 | 1 ～ 3 | 60 | 中高 (0.8x) |
| 4-10 | 40 |
| 11 以上 | 20 |
| 移行戦略 | リホスト | 70 | 中 (0.6x) |
| リプラットフォーム | 30 |
| リファクタリングまたは再設計 | 10 |
アプリケーション間の主要な差別化要因として機能する属性を必ず選択してください。そうしないと、条件によって多くのワークロードが同じ優先度を共有します。モデルを適用したら、結果のランキングの上部と下部を見て、同意するかどうか確認することをお勧めします。一般的に同意しない場合は、ワークロードのスコアリングに使用した基準を再確認できます。
ランキングを取得したら、ポートフォリオ全体のスコアの分布を確認します。スコア自体は関係ありません。重要なのはスコアの差です。たとえば、上位の合計スコアが 8,000 で、下位スコアが 800 であることがわかります。結果のスコアをヒストグラムとしてプロットして、分布が良好であることを確認することを検討してください。理想的なディストリビューションは、非常に優先度の高いワークロードと非常に優先度の低いワークロードがいくつかあり、標準のベル曲線のようになります。アプリケーションの大部分は中間のどこかにあります。
初期の優先順位付けのもう 1 つの重要な側面は、クラウドの早期導入者になることに関心を示す内部チームまたはビジネスユニットを含めることです。これらは、特に初期に特定のアプリケーションを移行するためのビジネスサポートを取得するためのかなりの手段になる可能性があります。組織でその場合は、上の表にビジネスユニット属性を含めます。アプリケーションを進んで進めるビジネスユニットに高いスコアを割り当てます。ビジネスユニット属性を使用すると、これらのアプリケーションがリストの先頭に表示されます。
結果のランキングに同意したら、上位 5～10 のアプリケーションを選択します。これらは、最初のアプリケーション移行候補になります。3～5 個のアプリケーションを確認するようにリストを絞り込みます。これにより、詳細なアプリケーション評価を実行する際に、的を絞ったアプローチを取ることができます。詳細については、[「優先順位付けされたアプリケーションの評価](prioritized-applications-assessment.md)」を参照してください。
## 移行用の R タイプの決定
各アプリケーションおよび関連するインフラストラクチャの移行戦略を決定することは、移行速度、コスト、および利点のレベルに影響します。ビジネスドライバー、技術指針、優先順位付け基準、ビジネス戦略など、バランスの取れた要素の組み合わせに基づいて戦略を決定することが重要です。
これらの要因によって、ビューが競合することがあります。例えば、移行の主な要因はイノベーションと俊敏性です。同時に、コストを迅速に削減する必要がある場合があります。範囲内のすべてのアプリケーションをモダナイズすると、長期的にコストを削減できますが、事前により大きな投資が必要になります。この場合、1 つのアプローチは、リホストやリプラットフォームなど、労力の少ない戦略を使用してアプリケーションを移行することです。これにより、短期間で迅速な効率とコスト削減を実現できます。次に、コスト削減を後の段階でアプリケーションのモダナイズに再投資し、さらなるコスト削減を実現します。
ただし、すべてのアプリケーションの完全なリホストから始めると、モダナイゼーションのより大きな利点が遅れます。重要なのは、ビジネス戦略アプリケーションがモダナイゼーションに優先され、他のアプリケーションを最初にリホストまたはリプラットフォームしてからモダナイズできるように、移行戦略のバランスを見つけることです。
*アプリケーションの移行戦略を決定する方法*
この評価段階では、移行戦略の選択をガイドするための初期モデルを組み込むことに重点が置かれています。初期アプリケーションの移行戦略を検証するには、モデルをビジネスドライバーと優先順位付け基準と組み合わせて使用します。デシジョンツリーのデフォルトのロジックは、スコープの初期処理を決定するのに役立ちます。ツリーでは、リファクタリングやリアーキテクトなどの最も複雑なアプローチは、戦略的ワークロード用に予約されています。
![\[このガイドで説明する 6 R の決定プロセス。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/application-portfolio-assessment-guide/images/6Rs-DecisionTree-baseModel.png)
この図のカスタマイズ可能な [draw.io](https://github.com/jgraph/drawio-desktop/releases) バージョンは、*[添付ファイル](#attachments)*セクションで入手できます。
初期モデルの最初のステップは、ツリーの上部にあるビジネスドライバーを、組織が定義したドライバーで更新することです。次に、アプリケーション全体ではなくアプリケーションコンポーネントにツリーを適用します。たとえば、3 つのコンポーネント (フロントエンド、アプリケーションレイヤー、データベース) を持つ 3 層アプリケーションの場合、各コンポーネントはツリーを個別に転送し、特定の戦略とパターンを割り当てる必要があります。これは、場合によっては、特定の階層をリホストまたはリプラットフォームし、他の階層をリファクタリング (リアーキテクト) する必要があるためです。
独立したコンポーネントを割り当てることで、関連するインフラストラクチャの移行戦略を定義できます。インフラストラクチャ戦略は、サポートするアプリケーションコンポーネントと同じ戦略でも、異なる戦略でもかまいません。たとえば、新しいオペレーティングシステムを搭載した新しい仮想マシンにリプラットフォームされるアプリケーションコンポーネントは、リプラットフォーム戦略に従い、それをホストする現在の仮想マシンは廃止されます。インフラストラクチャの移行戦略は、アプリケーションコンポーネント用に選択された戦略に基づいて計算されます。
決定木を使用して移行戦略を確立する前に、いくつかのアプリケーションでロジックをテストし、一般的に結果に同意するかどうかを確認します。6 Rs 決定ツリーは、その正確性を判断するために必要な分析を置き換えないガイドです。ツリーロジックは、特定のケースに適用されない場合があります。これらのケースを例外として扱い、ツリーロジックを変更するのではなく、オーバーライドの理論的根拠を文書化して、ツリーによって駆動される決定を上書きします。これにより、管理が困難になる可能性のある複数の決定木バージョンを防ぐことができます。一般的なガイダンスでは、ツリーはワークロードの少なくとも 70～80% に対して有効である必要があります。残りは例外があります。この評価段階でのツリーロジックの調整は、初期モデルの確立に焦点を当てる必要があります。さらなる反復と改良は、[ポートフォリオ分析や移行計画](portfolio-analysis-migration-planning.md)など、後の段階で行われます。
## アタッチメント
[attachment.zip](samples/attachment.zip)
# 方向性のあるビジネスケースの作成
ビジネス全体のステークホルダーは、その過程の各ステップで変革のためのビジネスケースを理解し、受け入れる必要があります。
初期段階では、プログラムの計画と確立に必要なリソースを確保できるように、移行プログラムから十分な潜在的な価値をすばやく示すことが重要です。方向性のあるビジネスケースは、早期に収集できる限られたデータで、説得力のあるビジネス価値を達成するための合理的な信頼を提供するように設計されています。
プログラムが確立されると、ビジネスケースがさらに発展します。詳細なケースにより、精度が向上し、プログラムの価値をより完全に把握し、計画の優先順位を把握できます。組織が購入する計画されたビジネス成果を定義および定量化し、プログラムガバナンスオフィスがプログラムを運営し、その成果を測定するためのベースラインを設定します。
## 方向性のあるビジネスケースの範囲の修正
方向性のあるビジネスケースは通常、2～4 週間以内に迅速に組み立てられます。コアチームを確立し、必要に応じて AWS パートナーを関与させ、少なくとも[優先順位付けされたアプリケーション評価](prioritized-applications-assessment.md)、[ポートフォリオ分析、移行計画](portfolio-analysis-migration-planning.md)の各段階を完了できるように、十分な信頼を生み出す必要があります。
通常、ポートフォリオの移行をサポートする方向性のあるビジネスケースは、次のいずれかとして作成されます。
+ 現状のインフラストラクチャ環境と移行後の AWS のサービス アーキテクチャの単純*総所有コスト (TCO)*** **の比較。比較は、特定のワークロードボリュームの予想される実行率の差を示しています。
+ 移行コストを含む への移行と現状維持** **のための純現在価値 (NPV)、投資収益率 (ROI)、ペイバック期間、変更された内部収益率 (MIRR) AWS 、3～5 年間のキャッシュフロー分析を示すビジネスケース。
方向性のあるビジネスケースの範囲は通常、次のいずれかに制限されます。
+ インフラストラクチャテクノロジーコストの比較
+ インフラストラクチャテクノロジーと運用コストの比較
一般的に、ポートフォリオが大きいほど、開発の少ないケースが必要になります。これは、結果に大きな影響を与えることなく、より広範な仮定を行うことができるためです。ポートフォリオを小さくすると、変更の影響が大きくなるため、詳細が必要になります。
まず、基本インフラストラクチャのコスト比較を構築します。次に、続行する前に、比較が十分に説得力があるかどうかを判断します。通常、400 台を超えるサーバーのポートフォリオは、運用から 3 年以内 AWS、または 5 年以内の 250 台のサーバーで、インフラストラクチャのコスト削減だけでもプラスのビジネスケースになりますが、これは異なる場合があります。より小さなポートフォリオの場合は、より詳細な情報が必要になる場合があります。
逆に、移行範囲の合計が約 5 ワークロードまたは 50 サーバー未満でない限り、回復力の向上やビジネスの俊敏性から派生した値など、この段階で他のビジネス価値のコンポーネントを調べることはめったに役に立ちません。
## フォーカス値ドライバー
インフラストラクチャテクノロジーの TCO 比較では、現状のインフラストラクチャコストのモデルと、同等のパフォーマンスと可用性でワークロードを実行するために必要な部品 AWS のサービス 表の基本モデルを比較します。多くの最適化を行うことができます。ただし、この段階では、評価が容易で、通常は TCO を約 30% 削減できるため、次のリストに重点が置かれています。これは先に進むのに十分です。
+ **コンピューティングの伸縮性 – **8x5 (24% の使用）、10x5 (30%)、または 10x6 (36%) を実行している開発サーバーや UAT サーバー、2% で実行されているディザスタリカバリ (DR) サーバーなど、使用量が 100% ではないサーバーを、使用時にのみ請求されるオンデマンドサービスにマッピングします。
+ **削減計画による調達** – コストを最大 75% 削減するための適切な削減計画を使用して、本稼働サーバーやその他のサーバーを高い使用率 (36% 超) で調達する計画を立てます。オプションには、1 年契約と 3 年契約があり、割引を強化するために前払いレベルが異なります。
+ **ゾンビの削除** – CPU 使用率が 2% 未満のサーバーを特定し、不要になったことを確認して、コスト分析から削除します。
+ **コンピューティングの適切なサイズ**設定 — CPU とメモリの使用率の時系列データを使用して、各サーバーに必要なコンピューティング能力とメモリを評価します。次に、適合する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを選択します。
+ **リレーショナルデータベース管理システム (RDBMS) ライセンスの適切なサイズ設定** – データベースサーバーでコンピューティングの適切なサイズ設定を行った後、RDBMS ライセンスのニーズを再評価し、Bring Your Own License (BYOL) と Procuring license from を比較し AWS、Amazon Relational Database Service (Amazon RDS) の可能性を調べて削減額を増やします。
+ **ストレージ** – 必要な合計ストレージボリュームを適切なサイズに設定し、ポートフォリオ全体の 1 秒あたりの入出力オペレーション (IOPS) のニーズを特定します。SLAs とコストが異なるオブジェクトストレージに移動できる量を決定します。
## データのニーズ
[「初期評価データ要件を理解する](understanding-initial-assessment-data-requirements.md)」の表は、方向性のあるビジネスケースの各部分の構築に必要なデータと、必須かオプションかを示しています。
ケースを構築するには、初期計画データとコストデータのインフラストラクチャサブセットが必要です。含めるインフラストラクチャを特定する方法は、ビジネス目標によって異なります。
+ プログラムの目的は、特定のアプリケーションを移行してモダナイズすることである場合は、共有されるインフラストラクチャを考慮して、アプリケーションが必要とするものに基づいてインフラストラクチャポートフォリオを構築します。
+ リースの有効期限が切れるデータセンターから移行するなど、プログラムの目的がインフラストラクチャ中心である場合、インフラストラクチャの TCO 比較にアプリケーションマッピングは必要ありません。
オプションとしてマークされたデータ (サーバーの CPU やメモリのピーク使用率など) は通常、標準ベンチマーク値に置き換えることができます。これについては、 AWS パートナーまたは AWS プロフェッショナルサービスにお問い合わせください。または、ポートフォリオの一部で利用可能なデータポイント (ハイパーバイザーによって収集されたデータなど) から値を推定することもできます。ポートフォリオが大きいほど、より正確です。
## インフラストラクチャの TCO 比較の構築
インフラストラクチャの TCO 比較を構築するには、ツールが不可欠です。[AWS プロフェッショナルサービス](https://aws.amazon.com/professional-services/)または [AWS パートナーは](https://aws.amazon.com/migration/partner-solutions/)、特により広範な移行プロセスを支援するためにそれらを関与させる予定がある場合は、あらゆる種類の方向性のケースを支援できます。
以下の操作に使用できるツールがあります。
+ インベントリデータを収集します。
+ 使用率データを収集します。
+ インフラストラクチャのコストベンチマークデータをそのまま正確に提供します。
+ ゾンビを特定して削除します。
+ 適切なサイズ評価を行います。
+ 購入オプションを推奨します。
+ ソフトウェアライセンスオプションを比較します。
+ シンプルなグラフィカルなキャッシュフロー分析を生成します。
からの[移行評価者](https://aws.amazon.com/migration-evaluator/) AWS は 1 つのオプションです。これらすべての機能を**無料のマネージドサービスとして提供します。Migration Evaluator **は、 AWS アカウントマネージャーまたは AWS Migration Competency Partner を通じて、またはオンラインでリクエストを送信[することでリクエスト](https://pages.awscloud.com/Migration-Evaluator-request.html)できます。Migration Evaluator は、インフラストラクチャテクノロジーの TCO 比較を迅速に作成するためのポイントソリューションとして特別に設計されています。
主な利点:
+ 無料
+ ツールベースの検出が制限されているインベントリデータのエージェントレス検出または手動設定
+ デプロイ、設定、データ収集、ベースケースの構築、または方向性のあるビジネスケースを支援するための専用サポート
+ SaaS オペレーションの利便性はありますが、顧客ネットワーク内でデータ収集を完全に実行して、分析エンジンにロードする前にスクラブをサポートできます。
+ Microsoft ライセンスの適切なサイズ設定に対する強力なサポート
+ 完全なデータエクスポート機能
主な制限事項:
+ x86 アーキテクチャサーバーのみを評価する (Windows および Linux)
+ ベンチマークをそのままコストデータとして設定またはキャリブレーションする限定オプション
+ モデリングオペレーションのコスト最適化はサポートされていません
+ 移行コストモデリングのサポートなし
+ TCO 比較以外のビジネスケースの構築を直接サポートしていない
アプリケーションスタックや相互依存関係検出などのポートフォリオ検出および分析機能に商用検出ツールを使用することにした場合、通常、インフラストラクチャの TCO 比較も行われます。ポートフォリオの検出と評価のためのツールの使用に関するガイダンスについては、[「検出ツールの必要性の評価](understanding-initial-assessment-data-requirements.md#discovery-tooling)」を参照してください。市場をリードするツールの主な機能を確認して比較するには、[「検出、計画、推奨事項の移行ツール](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/)」を参照してください。
## 運用コスト最適化の構築
IT 運用の生産性向上は、多くの場合、移行に大きな価値をもたらします。アマゾン ウェブ サービスでビジネス価値を生み出すためのビジネスの促進と組織変革に関する国際データ株式会社 (IDC) のホワイトペーパーによると、移行後 AWS、IT 運用スタッフの生産性は平均 62% 向上します。 [https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)ただし、これらの利点を方向性のあるケースにサイジングして含めるには、2 つの課題があります。
まず、生産性の向上の全範囲を評価するには、広範なデータ収集が必要であり、[詳細なビジネスケース](detailed-business-case.md)に適しています。この課題は、単純なベンチマークデータを使用してより簡単に評価およびサイズ設定できるが、それでも大きな利点を示すいくつかの要素に焦点を当てることで解決できます。
第 2 に、コスト削減のソースとして生産性に焦点を当てると、主要な顧客ステークホルダーとプログラムメンバーの間に懸念と否定が生じる可能性があります。メリットがどのように実現されるか、それが影響を受ける人々にとって何を意味するかを明確にしてください。このような問題は、チームの役割を強化するだけであることを明確にすることで回避できます。
+ 移行プログラムには、内部運用スタッフを開発して新しい役割に移行するためのトラックが含まれています。例えば、DevSecOps チームに参加してコードオートメーションとしてインフラストラクチャを構築し、チームの成長を促進するオートメーションをテストします。
+ メリットは、オペレーションのアウトソーシング契約の範囲を変更およびサイズ変更することで実現できます。これにより、内部スタッフがより価値の高いアクティビティに集中できるようになります。
考慮すべきオペレーション変換に基づいて、このビジネスケース要素を構築するアプローチ:
+ 既存の社内運用チームがある場合は、チームメンバーのスキルを高め、期待される生産性の向上を示します。
+ または、現在の運用ソリューションから AWS Managed Services (AMS) または AWS パートナーが提供する代替マネージドサービスに移行します。
最初の変換では、ケースに含めることができる生産性の向上について控えめに財務見積もりを取得するには、以下をお勧めします。
1. 特にサーバー管理オペレーションの生産性に焦点を当てます。運用作業の大部分を占める傾向があり、より簡単に評価でき、後でより簡単に検証できます。
1. 各フルタイム同等の (FTE) 従業員が管理できるサーバー数のベンチマークに基づいて、必要な人員配置を計算します。オンプレミスでは、この数は約 150 サーバーです。 AWS上のサーバーは約 400 台です。
1. これらのメトリクスを EC2 インスタンスの数と比較したオンプレミスサーバーの数に適用します。
1. 節約した時間を運用チーム全体のブレンドコスト率で乗算します。
その後、結果をいずれかの方法で確認するには、結果を次の表に示すロール (IDC ホワイトペーパー [Fostering Business and Organizational Transformation to Generate Business Value with Amazon Web Services](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) から取得したデータ) による平均生産性の向上を大幅に上回らないことを確認します。
| **ロール** | **効率の向上** |
| --- |--- |
| IT インフラストラクチャ管理 | 62% |
| IT サポート | 59% |
| アプリケーション管理 | 43% |
| データベース管理 | 19% |
| アプリケーション開発 | 25% |
2 番目の変換では、対象範囲内のポートフォリオの現在の総オペレーションとサポートコストを、検討中のマネージドサービスのコストと直接比較することで、運用コストの削減を追加できます。
マネージドサービスのコストを取得するには、 AWS 提案された部品 AWS 表、サービスレベルの選択 (Plus または Premium)、および AMS パッケージ (AMS Accelerate または AMS Advanced) をアカウントマネージャーまたは[AWS Managed Services パートナー](https://aws.amazon.com/managed-services/partners/)に提供します。これにより、変換されたソリューションの :AWS のサービス コンポーネントのマネージドサービスの合計コストが提供されます。同様に、独自のパラメータに基づいて独自のマネージドサービスパッケージを提供する AWS パートナーから料金を取得できます。
## 完全な方向性のビジネスケースへの拡張
一般的に、完全な方向性のビジネスケースを構築するには、IT 生産性要素の有無にかかわらず TCO 比較を構築し、すべての移行とモダナイゼーションのコストを見積もります。次に、migrate-and-modernizeのシナリオのペアとt-migrate-and-modernizeシナリオのペアをカバーするキャッシュフローを作成します。
最も基本的なケースは、移行t-migrate-and-modernizeシナリオが現在の状況であり、migrate-and-modernizeシナリオには次の特性がある 1 組のシナリオの準備です。
+ トランザクションボリューム、コンピューティング、ネットワーク容量の増加や縮小がない
+ ストレージ要件の着実な少量の増加
+ 既存のシステム機能に一致するQuality-of-service機能 (可用性、耐久性、スループット、パフォーマンスなど)
これは、非常に小さなポートフォリオを除くすべてのポートフォリオで、方向性のあるケースをうまく構築する目的に合致します。これは、前進する権限を得るために十分な価値を迅速に示します。
小規模なポートフォリオの場合、migrate-and-modernizeのペアを追加し、クラウド移行の付加価値の他の側面を示すシナリオt-migrate-and-modernize方が有益です。次に例を示します。
+ 中程度と大容量の成長要件がワークロード間で混在し、その成長が見込まれる
+ 高可用性、DR、耐障害性などの強化された耐障害性を含める
+ エッジコンピューティング、コンテンツ配信ネットワーク (CDN)、マルチリージョンデータベースレプリケーションでグローバルパフォーマンスが向上しました。
+ プログラムのビジネス上の優先事項となったその他の特定の改善されたサービス品質
これらのシナリオでは、新しい仕様に合わせて現在の非クラウドインフラストラクチャアーキテクチャをアップグレードした場合のコストとキャッシュフローへの影響が正確に推定されていることを確認してください。この見積りを取得する最も直接的な方法は、特に移行コンピテンシーを持つ AWS コンサルティングパートナーで、migrate-and-modernizeのシナリオと移行t-migrate-and-modernizeのシナリオの両方をサポートできる場合、システムインテグレーターに見積りをリクエストすることです。
シナリオのペアごとに、以下で構成されるケースを組み立てます。
+ 移行およびt-migrate-and-modernizeシナリオのコスト。最も基本的なケースには、以下が含まれます。
+ 現在のインフラストラクチャ設定のビジネスケース期間における総所有コスト
+ コンピューティング、ストレージ、ネットワークトラフィックの消費量の定期的な増加
+ migrate-and-modernizeのコスト。シナリオには以下が含まれます。
+ プログラムのセットアップには、詳細な検出、移行計画、詳細なビジネスケース開発、コアチームの確立とスキルの向上、まだ導入されていない場合のランディングゾーンの確立、移行されたワークロードのセキュリティ管理と運用の統合の確立が含まれます。
+ ワークロードの移行とモダナイゼーションのコスト
+ ネットワーク接続、 [AWS Snowball Edge](https://aws.amazon.com/snowball/) や などのデータ移行サービス[AWS DataSync](https://aws.amazon.com/datasync/)、移行プロセス自体に必要なアーキテクチャの AWS ユーティリティコスト (テストなど) を含む移行インフラストラクチャのコスト
+ ウェーブが稼働するにつれて移行中の AWS ユーティリティコストが増加し、既存のインフラストラクチャコストが AWS ベースのサービスに置き換えられて廃止されるにつれて増加します。
+ ストランドアセットの廃止コストと償却
## 移行とモダナイゼーションプログラムのセットアップの見積もり
プログラムを成功させるためにセットアップするには、ベースライン機能と詳細な計画を構築するための一連の基本的なアクティビティを事前に実行する必要がある場合があります。これらの基本的なアクティビティには以下が含まれます。
1. ポートフォリオ[分析と移行計画のセクションで説明されているように、詳細なポートフォリオ検出、移行計画、](portfolio-analysis-migration-planning.md)詳細なビジネスケース開発を実行するとともに、使用した検出ツールのコストを文書化します。
1. クラウドビジネスおよび技術コアチームを確立し、トレーニングと雇用を通じて社内スキルを開発します。トレーニングが必要な IT 組織のメンバーを特定し、各メンバーにトレーニング予算を割り当てます。
1. ラン[ディングゾーン](https://aws.amazon.com/solutions/implementations/aws-landing-zone/)を確立し、必要なコスト、運用、セキュリティガバナンス機能をサポートするように設定します。
AWS コンサルティングパートナーは、項目 1 と 3 の見積りを提供できます。
*移行とモダナイゼーションのコストの見積もり*
方向性のあるビジネスケースの目標を達成し、次のフェーズに進むのに十分な**商用の可能性を示すには、移行とモダナイゼーションのコスト見積もりをできるだけ基本的なものに保ちます。
そのためには、次の移行戦略に該当するアプリケーションに焦点を当てて、方向性のあるビジネスケースを準備することをお勧めします。
+ リタイア
+ Retain
+ リロケート
+ リホスト
+ リプラットフォーム
+ 再購入
通常、ワークロードの約 70% はリホスト、再配置、またはリプラットフォームでき、さらに 5% はリタイアできます。移行戦略によるアプリケーションの評価は、通常、コスト削減ケースの中核をなします。
リファクタリングまたは再設計のコストの見積もりは複雑****になる場合があります。方向性のあるビジネスケースを準備するために与えられた期間内にこれを試すことは実用的ではありません。前述したように、[移行と](prioritization-and-migration-strategy.md#migration-r-type)モダナイゼーションの最初のフェーズでは、リホスト、再配置、またはリプラットフォーム戦略の使用を検討してください。これらの R 戦略は、初期ペイバックを加速し、実装リスクを軽減し、短期的にビジネスケースを改善する可能性があります。また、アプリケーションチームは AWS 、環境内で実行されているアプリケーションを、そうでないアプリケーションよりもモダナイズしやすくなります。[詳細なビジネスケース](detailed-business-case.md)の準備が整うと、リファクタリング (再設計) 固有のアプリケーションの見積もりが最適に追加されます。
*戦略による移行の労力の見積もり*
移行はそれぞれ異なります。予算や計画をコミットする前に、社内のアプリケーションチーム、 AWS プロフェッショナルサービス、パートナー AWS 組織など、プロジェクトを担当するチームからの移行アクティビティのワークロード見積もりをシードします。
ディレクショナルケースの構築に役立つように、次の表にさまざまな処理の労力範囲を示します。これらの範囲は、medium-to-largeのポートフォリオが移行中であり、移行チームがトレーニングされ、経験があることを前提としています。小規模なポートフォリオの場合、方向性のあるケースであっても、移行を担当するチームに見積りを準備することをお勧めします。
| 移行戦略 | 見積りプロセス | [Elements] (要素) | 人時 | 人時 |
| --- |--- |--- |--- |--- |
| Retain | Do nothing, with no cost, no benefits, and no reduction in technology debt. | – | – | – |
| Retire | Estimate decommissioning the hardware equipment used, if any. | – | – | – |
| Relocate | Estimate copying the workload within VMware using VMware tools. This includes copying the data, smoke testing to verify, and any hardware decommissioning. The effort to relocate VMs is typically less than for low-complexity rehost patterns. | – | – | – |
| Rehost | Estimate copying the workload and data with an image copy, smoke testing, high availability (HA) and disaster recovery (DR) testing where appropriate for production servers, and any hardware decommissioning. The best practice is to use tools such as [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/). Divide workloads into low, medium, and high complexity, based on factors such as whether a database or other infrastructure software is running, database complexity, whether clustered, integration complexity, and data volumes. | Effort per app per server | Migration | HA/DR test |
| Low | 10–14 | 3–5 |
| Medium | 16–24 | 4–6 |
| High | 26–38 | 8–12 |
| Replatform | For replatform migrations that include upgrades to operating system or RDBMS version, take the estimate for a rehost, and add time to run a rebuild and smoke test on the new platform.If the replatform includes changing the technology of the platform, estimate additional time for the use of the conversion tools, such as [AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/) and [AWS Database Migration Service](https://aws.amazon.com/dms/), and a more complete application test. An example of changing the technology is migrating away from a proprietary commercial database to an open source replacement. | Effort per app per server | Version up | Technology change |
| Low | Add 1–3 | Add 10–15 |
| Medium | Add 2–5 | Add 20–30 |
| High | Add 4–8 | Add 40–60 |
| Repurchase | Estimate data extraction, transformation, and uploading into the newly purchased SaaS service replacement, and any hardware decommissioning. | – | – | – |
*移行インフラストラクチャのコストの見積もり*
移行中に使用するインフラストラクチャの見積もりを含めます。通常、これらの見積もりは以下で構成されます。
+ 現在の環境から へのワークロードとデータ移行のための接続とデータ交換サービスの予算 AWS
+ 移行、テスト、カットオーバープロセス中に移行されたワークロードをホストするために必要な の予算 AWS のサービス (特にコンピューティングとストレージ)
+ 各移行ウェーブの完了に伴う AWS ユーティリティコストの増加
+ 移行されたワークロードを実行しない既存のインフラストラクチャの廃止コスト
データ交換については、合計データボリュームを調べ、ネットワークの使用の実現可能性を評価します。移行後に運用上の使用のために [AWS Direct Connect](https://aws.amazon.com/directconnect/) または [Site-to-Site VPN](https://aws.amazon.com/vpn/)から WAN 上のポイント AWS へのリンクを事前にプロビジョニングしている場合は、そのリソースをサービスクォータまで使用できます。
ネットワーク容量が不十分な場合、仮想プライベートネットワーク (VPN) によるインターネット帯域幅の短期的な増加は、多くの場合、費用対効果の高いソリューションです。そうでない場合、 [AWS Snowball Edge](https://aws.amazon.com/snowball/)や などの AWS メディア交換デバイスは、ほとんどの ソリューション[AWS Snowball Edge](https://aws.amazon.com/snowcone/)を提供します AWS リージョン。また、非常に大量のデータ移行の場合は、 の予算を含めることを検討してください。これにより[AWS DataSync](https://aws.amazon.com/datasync/)、使用するメディアに関係なく信頼性が向上し、転送が高速化されます。
AWS サービスの拡大と既存のインフラストラクチャの縮小をモデル化することは、ビジネスケースのキャッシュフロー分析要素にとって重要です。この段階では、いつコストが発生するかを正確に判断するためのウェーブプランがある可能性は低くなります。次の構成を推奨します。
+ のコストを移行よりも一定の割合 AWS で引き上げます。
+ 廃止予定の既存のインフラストラクチャのコストを同じ期間にわたって一定の割合で削減する。
既存のインフラストラクチャがランプダウンする 1～2 か月前に、 AWS コストのランプアップを開始します。これにより、各ウェーブの移行を実行するために 1 か月間の AWS ユーティリティ使用量が提供されます。これには、テストの時間と、置き換えられたインフラストラクチャのコストの発生を停止するために必要な廃止作業を完了する追加の時間が含まれます。
*廃止コストの見積もり*
再デプロイできない機器を廃止し、法的かつ環境に優しく廃棄すると、少額のコストが発生する可能性があります。ただし、方向性のあるビジネスケースでは、通常、潜在的に重要な合計は、置き換えられたアセットの残りの書籍価値を償却するコストです。
方向性のあるビジネスケースでは、以下を実行することをお勧めします。
+ アセットリストを確認します。
+ 廃止されるものを特定します。
+ 書き込みオフを減らすには、リストの新しいデバイスを使用して、より完全に廃止された古いアセットを置き換えることができるように、デバイスを切り替えられる機会を調べます。
+ その時点で廃止されるアセットの将来の書籍価値を評価します。
+ これを廃止の移行コストとして含めます。
*完全な方向性のビジネスケースの組み立てと調整*
シナリオのペアごとにコストの完全なセットを準備したら、それぞれに割引キャッシュフローステートメントを作成し、グラフ化します。ハードウェアの更新サイクルと同じ期間に方向性のあるビジネスケースを構築することをお勧めします。サーバー、ストレージ、ネットワークデバイスの場合は、通常 5 年です。ハードウェアの更新サイクルと同じ期間を使用する場合、1 回のみの更新のコストは、各シナリオの現状のままのコストに含まれます。
次に、プログラムの次のフェーズに移行するための承認を得るために必要な主要な財務メトリクスを計算します。通常、以下が含まれます。
+ 評価されたコスト削減と生産性の向上の絶対値を測定する正味現在価値 (NPV)
+ リターンが十分に高速であることを確認するための月単位のペイバック期間
+ プロセスが期間にわたって十分なコストを奪っているかどうかを確認する最後の実行レート比較
+ 組織が優先する可能性のある資本に対する他の需要と比較して、プログラムの相対的な財務パフォーマンスを評価するための投資収益率 (ROI) と変更された投資収益率 (MIRR)
次の例のように、ケースの最初の反復を使用して、予想される財務パフォーマンスが絞り込む必要があるかどうかを判断します。
+ 支払いが遅すぎる場合は、次のような移行のコストを高速化して削減するオプションを検討してください。
+ AWS パートナーまたは AWS プロフェッショナルサービスを使用して利用可能なリソースを拡張し、より基本的なパターンでワークロードの移行をさらに並列化します。
+ VMware で実行されているワークロードの場合、少なくとも初期フェーズでは、再配置戦略とリホストまたはリプラットフォーム戦略を比較します。再配置戦略を使用すると、移行コストを削減し、移行速度を向上させることができます。
+ 技術的に可能な場合は、より複雑なリプラットフォームまたはリファクタリング (リアーキテクト) 戦略を必要とするワークロードを、最初のビジネスケースの範囲外の将来のフェーズにプッシュします。
+ ROI と MIRR が低すぎる場合は、次の点を考慮してください。
+ 検討しているシナリオは保守的すぎますか? 最も可能性の高い容量の増加と伸縮性のニーズを反映したシナリオはありますか? 目標内のサービス品質の向上を含むコストを比較するシナリオはありますか?
+ 第 1 フェーズで移行するアプリケーションポートフォリオの範囲を絞り込んで、現在の使用率が低いワークロードや、ディザスタリカバリ (DR) のニーズが高いワークロードなど、より強力なリターンをもたらすワークロードに集中できますか?
+ アプリケーションポートフォリオの範囲を絞り込んで、最初に商用性が低い特定のワークロードを除外できますか? たとえば、パブリッククラウドインフラストラクチャへのデプロイ条件が異なるため、サードパーティーのソフトウェアライセンスのコストが高くなるワークロードを延期できますか?
+ 最終的な実行レート比較が予想されるターゲットを満たさない場合は、以下を調べます。
+ まず、他のメトリクスが期待を満たしていることを確認します。方向性のあるビジネスケースは、主に移行準備の次のフェーズを開始することを正当化する十分な財務機会があることを示すためのものです。
+ 移行の初期フェーズ AWS 後も のコストパフォーマンスを継続的に改善する機会のリストを特定します。
詳細なビジネスケースを準備するときは、機会のリストの評価を含めます。さらに、ケースの継続的なメンテナンスと、移行完了後のmonth-to-monthのコスト最適化プロセスに機会評価を含めます。