初期評価データ要件を理解する

データ収集にはかなりの時間がかかり、どのデータが必要でいつ必要かが明確でない場合に、簡単にブロックされる可能性があります。重要なのは、このステージの結果には、少なすぎるデータと多すぎるデータのバランスを理解することです。このポートフォリオ評価の初期段階に必要なデータと忠実度レベルに焦点を当てるには、データ収集に反復的なアプローチを採用します。

データソースとデータ要件

最初のステップは、データソースを特定することです。まず、データ要件を満たすことができる組織内の主要な利害関係者を特定します。これらは通常、サービス管理、運用、キャパシティプランニング、モニタリング、サポートの各チームのメンバーであり、アプリケーション所有者でもあります。これらのグループのメンバーとの作業セッションを確立します。データ要件を伝え、データを提供できるツールと既存のドキュメントのリストを取得します。

これらの会話をガイドするには、次の一連の質問を使用します。

• 現在のインフラストラクチャとアプリケーションのインベントリはどの程度正確で最新ですか？ 例えば、会社設定管理データベース (CMDB) の場合、ギャップがどこにあるかはわかっていますか？

• CMDB (または同等のもの) を更新し続けるアクティブなツールやプロセスはありますか？ その場合、どのくらいの頻度で更新されますか？ 最新の更新日はいつですか？

• CMDB などの現在のインベントリには application-to-infrastructure マッピングが含まれていますか？ 各インフラストラクチャアセットはアプリケーションに関連付けられていますか？ 各アプリケーションはインフラストラクチャにマッピングされていますか？

• インベントリには、各製品のライセンスとライセンス契約のカタログが含まれていますか？

• インベントリには依存関係データが含まれていますか？ サーバーからサーバー、アプリケーションからアプリケーション、アプリケーション、サーバーからデータベースへの通信データが存在することに注意してください。

• アプリケーションとインフラストラクチャの情報を提供できるその他のツールは、環境で利用できますか？ データソースとして使用できるパフォーマンス、モニタリング、および管理ツールが存在することに注意してください。

• アプリケーションやインフラストラクチャをホストするデータセンターなど、さまざまな場所は何ですか？

これらの質問に回答したら、特定されたデータソースを一覧表示します。次に、各 に忠実度レベルまたは信頼レベルを割り当てます。ツールなどのアクティブなプログラムによるソースから最近 (30 日以内に) 検証されたデータは、最高レベルの忠実度を持ちます。静的データは忠実度が低く、信頼度が低いと見なされます。静的データの例としては、ドキュメント、ワークブック、手動で更新された CMDBs、プログラムで管理されていないその他のデータセット、または最終更新日が 60 日を超えるデータセットなどがあります。

次の表のデータ忠実度レベルを例として示します。仮定や関連するリスクに対する最大の許容度の観点から組織の要件を評価し、適切な忠実度レベルを決定することをお勧めします。表では、組織的知識とは、文書化されていないアプリケーションとインフラストラクチャに関する情報を指します。

データソース	忠実度レベル	ポートフォリオカバレッジ	コメント
専門知識	低 - 正確なデータの最大 25%、75% の想定値、またはデータが 150 日より古い。	低	重要アプリケーションに重点を置いた希少
ナレッジベース	中低 - 正確なデータの 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)	高い
アプリケーション名	このアプリケーションが組織で認識される名前。必要に応じて、商用 off-the-shelf (COTS) ベンダーと製品名を含めます。	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	やや高い
コスト	ソフトウェアライセンス、ソフトウェアオペレーション、メンテナンスのコスト	該当なし	O	中程度

インフラストラクチャ

属性名	説明	インベントリと優先順位付け	ビジネスケース	推奨忠実度レベル (最小）
一意の識別子	例えば、サーバー ID などです。通常、既存の CMDBs またはその他の内部インベントリと管理システムで使用できます。一意の IDs組織で定義されていない場合は必ず作成することを検討してください。	R	R	高い
ネットワーク名	ネットワーク内のアセット名 (ホスト名など）	R	O	やや高い
DNS 名 (完全修飾ドメイン名、または FQDN)	[DNS 名]	O	O	中程度
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	中程度
コスト	ハードウェア、メンテナンス、オペレーション、ストレージ (SAN、NAS、オブジェクト）、オペレーティングシステムライセンス、ラックスペースの共有、データセンターのオーバーヘッドなど、ベアメタルサーバーのフルロードコスト	該当なし	O	やや高い

ネットワーク

属性名	説明	インベントリと優先順位付け	ビジネスケース	推奨忠実度レベル (最小）
パイプのサイズ (MB/秒）、冗長性 (Y/N)	現在の WAN リンク仕様 (1000 Mb/秒冗長など）	O	R	中程度
リンク使用率	ピーク使用率と平均使用率、アウトバウンドデータ転送 (GB/月）	O	R	中程度
レイテンシー (ms)	接続されたロケーション間の現在のレイテンシー。	O	O	中程度
コスト	現在の 1 か月あたりのコスト	該当なし	O	中程度

移行

属性名	説明	インベントリと優先順位付け	ビジネスケース	推奨忠実度レベル (最小）
リホスト	各ワークロード (人日）、1 日あたりのカスタマーとパートナーのコストレート、ツールコスト、ワークロード数に関するカスタマーとパートナーの労力	該当なし	R (F)	やや高い
リプラットフォーム	各ワークロード (人日）、1 日あたりの顧客およびパートナーのコストレート、ワークロード数に関する顧客およびパートナーの労力	該当なし	R (F)	やや高い
リファクタリング	各ワークロード (人日）、1 日あたりの顧客およびパートナーのコストレート、ワークロード数に関する顧客およびパートナーの労力	該当なし	O	やや高い
リタイア	サーバー数、平均廃止コスト	該当なし	O	やや高い
ランディングゾーン	既存の (はい/いいえ) の再利用、必要な AWS リージョンのリスト、コスト	該当なし	R (F)	やや高い
人と変化	クラウド運用と開発でトレーニングするスタッフ数、1 人あたりのトレーニングコスト、1 人あたりのトレーニング時間のコスト	該当なし	R (F)	やや高い
duration	対象範囲内のワークロード移行の期間 (月）	O	R (F)	やや高い
並列コスト	移行中に現状のままコストを削除できる時間枠とレート	該当なし	O	やや高い
	移行中に AWS 製品やサービス、およびその他のインフラストラクチャコストが導入される時間枠とレート	該当なし	O	やや高い

検出ツールの必要性の評価

組織には検出ツールが必要ですか？ ポートフォリオ評価には、アプリケーションとインフラストラクチャに関する高い信頼性、 up-to-date データが必要です。ポートフォリオ評価の初期段階では、仮定を使用してデータギャップを埋めることができます。

ただし、進捗に応じて、忠実度の高いデータにより、移行計画を正常に作成し、ターゲットインフラストラクチャを正しく推定してコストを削減し、メリットを最大化できます。また、依存関係を考慮し、移行の落とし穴を回避する実装を有効にすることで、リスクを軽減します。クラウド移行プログラムの検出ツールの主なユースケースは、以下を通じてリスクを軽減し、データの信頼度を高めることです。

• 自動またはプログラムによるデータ収集により、検証済みで信頼性の高いデータが得られます。

• データの取得速度の加速、プロジェクトの速度の向上、コストの削減

• CMDB では通常利用できない通信データや依存関係など、データの完全性のレベルCMDBs向上

• 自動アプリケーション識別、TCO 分析、予測実行率、最適化の推奨事項などのインサイトの取得

• 信頼性の高い移行ウェーブプランニング

システムが特定の場所に存在するかどうかが不明な場合、ほとんどの検出ツールはネットワークサブネットをスキャンし、ping または Simple Network Management Protocol (SNMP) リクエストに応答するシステムを検出できます。すべてのネットワークまたはシステム設定で ping または SNMP トラフィックが許可されるわけではありません。これらのオプションについて、ネットワークチームや技術チームと話し合います。

アプリケーションポートフォリオの評価と移行のさらなる段階は、正確な依存関係マッピング情報に大きく依存しています。依存関係マッピングは、 に必要な AWS インフラストラクチャと設定 (セキュリティグループ、インスタンスタイプ、アカウントの配置、ネットワークルーティングなど) を理解します。また、同時に移動する必要があるアプリケーション (低レイテンシーネットワーク経由で通信する必要があるアプリケーションなど) のグループ化にも役立ちます。さらに、依存関係マッピングはビジネスケースを進化させるための情報を提供します。

検出ツールを決定するときは、評価プロセスのすべての段階を検討し、データ要件を予測することが重要です。データギャップはブロックになる可能性があるため、将来のデータ要件とデータソースを分析してそれらを予測することが重要です。の分野での経験から、ほとんどの停止した移行プロジェクトには、対象範囲内のアプリケーション、関連するインフラストラクチャ、およびそれらの依存関係が明確に識別されないデータセットが限られていることがわかります。この識別の欠如は、誤ったメトリクス、決定、遅延につながる可能性があります。データの取得 up-to-date は、移行プロジェクトを成功させるための最初のステップです。

検出ツールの選択方法

市場内のいくつかの検出ツールは、さまざまな機能と機能を提供します。要件を検討してください。また、組織に最適なオプションを決定します。移行用の検出ツールを決定する際の最も一般的な要因は次のとおりです。

セキュリティ

• ツールデータリポジトリまたは分析エンジンにアクセスするための認証方法は何ですか？

• データにアクセスできるユーザーと、ツールにアクセスするためのセキュリティコントロールは何ですか？

• ツールによるデータ収集方法 専用の認証情報が必要ですか？

• ツールがシステムにアクセスしてデータを取得するには、どの認証情報とアクセスレベルが必要ですか？

• ツールコンポーネント間でのデータ転送方法

• このツールは、保管中および転送中のデータ暗号化をサポートしていますか？

• データは環境内外の単一のコンポーネントに一元化されていますか？

• ネットワークとファイアウォールの要件は何ですか？

セキュリティチームが検出ツールに関する初期の会話に関与していることを確認します。

データ主権

• データはどこに保存され、処理されますか？

• このツールは Software as a Service (SaaS) モデルを使用していますか？

• 環境の境界内にすべてのデータを保持する可能性はありますか？

• 組織の境界を離れる前にデータをスクリーンできますか？

データレジデンシー要件の観点から、組織のニーズを考慮してください。

アーキテクチャ

• どのようなインフラストラクチャが必要で、どのようなコンポーネントが必要ですか？

• 複数のアーキテクチャを利用できますか？

• このツールは、エアロックされたセキュリティゾーンへのコンポーネントのインストールをサポートしていますか？

パフォーマンス

• データ収集がシステムに与える影響

互換性と範囲

• このツールは、私の製品とバージョンのすべてまたはほとんどをサポートしていますか？ ツールドキュメントを確認して、サポート対象プラットフォームがスコープに関する現在の情報と照合されていることを確認します。

• ほとんどのオペレーティングシステムはデータ収集でサポートされていますか？ オペレーティングシステムのバージョンがわからない場合は、検出ツールのリストを、サポートされているシステムの範囲が広いものに絞り込もうとします。

収集方法

• ツールでは、ターゲットシステムごとに エージェントをインストールする必要がありますか？

• エージェントレスデプロイをサポートしていますか？

• エージェントとエージェントレスは同じ機能を提供しますか？

• 収集プロセスとは

特徴

• 利用できる機能は何ですか？

• 総所有コスト (TCO) と推定 AWS クラウド実行率を計算できますか？

• 移行計画をサポートしていますか？

• パフォーマンスを測定しますか？

• ターゲット AWS インフラストラクチャを推奨できますか？

• 依存関係マッピングは実行されていますか？

• どのレベルの依存関係マッピングが提供されますか？

• API アクセスを提供しますか? (例えば、データを取得するためにプログラムでアクセスできますか?)

強力なアプリケーションとインフラストラクチャの依存関係マッピング機能を持つツールと、通信パターンからアプリケーションを推測できるツールを検討してください。

コスト

• ライセンスモデルとは

• ライセンスの料金はいくらですか？

• 各サーバーの料金は ですか？ 階層型料金ですか？

• オンデマンドでライセンスできる機能が限られているオプションはありますか？

検出ツールは、通常、移行プロジェクトのライフサイクル全体で使用されます。予算が限られている場合は、少なくとも 6 か月を検討してください。ただし、検出ツールがないと、通常、手動作業と内部コストが増加します。

サポートモデル

• デフォルトでは、どのレベルのサポートが提供されますか？

• サポートプランはありますか？

• インシデントへの対応時間はどれくらいですか？

プロフェッショナルサービス

• ベンダーは検出結果を分析するためのプロフェッショナルサービスを提供していますか？

• このガイドの要素について説明できますか？

• ツール + サービスに割引やバンドルはありますか？

検出ツールの推奨機能

複数のツールからのデータのプロビジョニングと結合を時間の経過とともに回避するには、検出ツールで次の最小機能をカバーする必要があります。

• ソフトウェア — 検出ツールは、実行中のプロセスとインストールされているソフトウェアを特定できる必要があります。

• 依存関係マッピング — ネットワーク接続情報を収集し、サーバーと実行中のアプリケーションのインバウンドとアウトバウンドの依存関係マップを構築できる必要があります。また、検出ツールは、通信パターンに基づいてインフラストラクチャのグループからアプリケーションを推測できる必要があります。

• プロファイルと設定の検出 — CPU ファミリー (x86、PowerPC など）、CPU コア数、メモリサイズ、ディスク数とサイズ、ネットワークインターフェイスなどのインフラストラクチャプロファイルをレポートできるはずです。

• ネットワークストレージ検出 — ネットワーク接続ストレージ (NAS) からネットワーク共有を検出してプロファイリングできる必要があります。

• パフォーマンス — CPU、メモリ、ディスク、ネットワークのピーク使用率と平均使用率をレポートできるはずです。

• ギャップ分析 — データ量と忠実度に関するインサイトを提供できるはずです。

• ネットワークスキャン — ネットワークサブネットをスキャンし、不明なインフラストラクチャアセットを検出できる必要があります。

• レポート — 収集と分析のステータスを提供できる必要があります。

• API アクセス — 収集されたデータにアクセスするためのプログラムによる手段を提供できる必要があります。

考慮すべき追加機能

• TCO 分析により、現在のオンプレミスコストと予測コストの AWS コストを比較できます。

• リホストおよびリプラットフォームシナリオにおける Microsoft SQL Server および Oracle システムのライセンス分析と最適化の推奨事項。

• 移行戦略の推奨事項 (検出ツールは、現在のテクノロジーに基づいてデフォルトの移行 R タイプの推奨事項を作成できますか?)

• インベントリのエクスポート (CSV または同様の形式）

• 適切なサイズのレコメンデーション (例えば、レコメンデーションターゲット AWS インフラストラクチャをマッピングできますか?)

• 依存関係の視覚化 (依存関係マッピングをグラフィカルモードで視覚化できるかなど）

• アーキテクチャビュー (例えば、アーキテクチャ図を自動的に作成できますか?)

• アプリケーションの優先順位付け (移行の優先順位付け基準を作成するために、アプリケーション属性とインフラストラクチャ属性に重みや関連性を割り当てることはできますか?)

• ウェーブプランニング (アプリケーションの推奨グループや移行ウェーブプランを作成する機能など）

• 移行コストの見積もり (移行作業の見積もり）

デプロイに関する考慮事項

検出ツールを選択して調達したら、以下の質問を検討して、組織内でのツールのデプロイを担当するチームとの会話を促進します。

• サーバーまたはアプリケーションはサードパーティーによって運用されていますか？ これにより、チームは と プロセスが関与するように指示される可能性があります。

• 検出ツールのデプロイの承認を取得するための大まかなプロセスは何ですか？

• サーバー、コンテナ、ストレージ、データベースなどのシステムにアクセスするための主な認証プロセスは何ですか？ サーバー認証情報はローカルですか、それとも一元管理されていますか？ 認証情報を取得するプロセスは何ですか？ システムからデータを収集するには、認証情報が必要です (コンテナ、仮想サーバーまたは物理サーバー、ハイパーバイザー、データベースなど）。検出ツールが各アセットに接続するための認証情報を取得するのは、特にこれらのアセットが一元化されていない場合、難しい場合があります。

• ネットワークセキュリティゾーンの概要は何ですか？ ネットワーク図は利用できますか？

• データセンターでファイアウォールルールをリクエストするプロセスは何ですか？

• データセンターの運用 (検出ツールのインストール、ファイアウォールリクエスト) SLAs) は何ですか？