既存のワークロード インベントリを検出する

このセクションは、Azure への移行を必要とする Azure (オンプレミスまたは他のクラウド) 外の既存の IT ワークロードを持つ組織に適用されます。 包括的なワークロード インベントリは、このような組織向けの強固なクラウド導入計画の基礎です。 システムが存在するか、その特性を理解していない場合は、システムを移行する方法や移行方法を決定することはできません。 クラウド導入計画には、すべてのワークロードを検出し、それぞれに関する重要なデータを収集し、移行のために優先順位を付ける手順を含める必要があります。

ワークロード インベントリの検出

技術資産の完全なインベントリが、クラウド導入計画の基礎となります。 インベントリは、環境全体のすべてのシステム、アプリケーション、インフラストラクチャ コンポーネントを識別します。 どの クラウド移行戦略 が最適かを判断するには、このインベントリが必要です。

1. 各ワークロードとその境界を定義します。 ワークロードは、1 つ以上のビジネス プロセスをサポートする、サーバー、仮想マシン (VM)、クラウド サービス、アプリケーション、コード、データ、アプライアンスなどの IT コンポーネントのコレクションです。 ビジネス価値と技術的なフットプリントを理解するには、各ワークロードを定義する必要があります。 この明確さは、移行と最新化の取り組みに優先順位を付けるのに役立ちます。 ネットワーク トラフィック監視と依存関係マッピング ツールを使用して、ワークロードの境界を特定し、コンポーネント間のリレーションシップを視覚化します。

2. 自動検出ツールを使用する。Azure Migrate には、オンプレミス環境とクラウド環境向けの無料の検出機能が用意されています。 このツールは、サーバー、アプリケーション、およびその相互依存関係を自動的に識別します。 インベントリの作成を高速化し、手動エラーを減らすには、自動検出を使用する必要があります。 Azure Migrate が環境を完全にサポートしていない場合は、Azure Migrate 機能を拡張する Dr Migrate や CloudPilot などのツールを使用します。

3. すべての環境のすべてのコンポーネントを含めます。 インベントリでは、すべてのプラットフォームにわたってインフラストラクチャとアプリケーション コンポーネントをキャプチャする必要があります。 Azure、AWS、Google Cloud、その他のプロバイダーからのサーバー、VM、アプリケーション、データベース、通信パターン、統合、ID、クラウド サービスを含める必要があります。 この包括的なビューにより、計画または移行中に重要な資産が見落とされないようにします。

4. 自動化できない場合は、手動検出を使用します。 一部の環境では、セキュリティ ポリシーまたは技術的な制限により、自動検出ツールが制限されます。 Azure Migrate インポート テンプレートを使用して、制限された環境の資産を手動で文書化します。 手動ドキュメントを使用すると、自動化されたツールではアクセスできない資産を確実にキャプチャできます。

ビジネス価値と実現可能性によるワークロードの優先順位付け

在庫リストが長い場合は、圧倒されることがあります。 この計画には、クラウド導入作業で最初に取り組むワークロードに優先順位を付ける方法を含める必要があります。 すべてのワークロードが等しく重要な場合や、即時移行に等しく適しているわけではないため、優先順位付けフレームワークを使用してください。

1. ビジネス上の重要度を使用します。 ビジネス運用、収益、またはカスタマー エクスペリエンスにとってワークロードがどれだけ重要であるかによって、ワークロードをランク付けします。 多くの場合、一部のワークロードはミッション クリティカルであり (ダウンした場合は大きなビジネス損失)、他のワークロードは重要度が低くなります。 高いビジネス価値システムは、クラウドのスケーラビリティや回復性の恩恵を受けるために優先度が高い場合もあれば、移行のリスクが高すぎる場合は優先順位が低くなる場合があります。

2. クラウドの準備状況を見積もります。 既に知っていることに基づいて、各ワークロードのクラウド移行の準備状態を簡単かつ高レベルに見積もります。 詳細な技術的評価は後で行われますが、現時点では、技術的な複雑さ、レガシ コンポーネント、既知のリスクなどの要因を考慮してください。 一部のワークロードは簡単に行える場合もあれば、大幅なやり直しが必要なワークロードもあります。 よりシンプルなワークロードに優先順位を付けて勢いを高めたり、中程度に複雑だが価値の高いシステムを選択して早期の成功を最大化することができます。

3. 依存関係に注意してください。 この段階では、既存の知識を使用して依存関係を高いレベルで評価します。 完全な依存関係マッピングは後で行われますが、現時点では、他のワークロードと密接に結び付いているワークロードを特定します。 多くの接続を持つシステムは、中断を回避するために一緒に移行する必要がある場合があります。 優先順位の高いシステムがそれに依存するため、優先順位の低いワークロードを早く移動することが必要になる場合があります。 この分析情報を使用して、関連するワークロードを論理的な移行ウェーブにグループ化します。

4. 戦略的な連携を検討します。 特定のワークロードが戦略的イニシアチブの鍵となる場合は、より早く移行するように優先順位を付ける可能性があります。 一方、間もなく廃止または置き換えられる予定のワークロードは、移行において優先度を下げるべきです。

5. 優先順位付けされたバックログを作成します。 このバックログには、"Wave 1: Workloads A, B, C. Wave 2: Workloads D, E" のようなカテゴリのリストまたはテーブルを指定できます。関係者と共にこの順序を検証してください。 ビジネスと IT の所有者は、シーケンスが理にかなっていることを確認し、同意する必要があります。 あなたは彼らの同意を得て、後で反発を避けたいと考えています。 たとえば、部門の重要なアプリを担当者の意見を聞かずに最後にスケジュールすると、反対される可能性があります。 技術ロジックとビジネス ニーズのバランスを取るために、フィードバックに基づいて計画を調整します。

ワークロードごとにビジネスの詳細を収集する

特定されたワークロードごとに、プランは主要なビジネス コンテキストと要件をキャプチャする必要があります。 この情報は、移行戦略 (次のセクション) をガイドし、意思決定がビジネス ニーズに合うようにします。 文書化する重要な詳細

1. 所有者と利害関係者: ビジネスの観点 (CRM の営業担当副社長) と IT の観点 (アプリケーション所有者、インフラストラクチャ所有者) からワークロードを "所有" します。 移動の計画に関与する必要があるすべての利害関係者を一覧表示します。

2. ビジネス機能と重要度: ワークロードの機能と重要性を文書化します。 目的の簡単な説明を記録し、重要度レベル (高/中/低) を分類します。 重要度は、多くの場合、許容できるダウンタイムの量と結び付きます。

3. データの機密性とコンプライアンス: システムが処理するデータの分類 (パブリック、内部、機密、極秘) に注意してください。 このワークロードに適用されるコンプライアンス要件 (PCI、HIPAA、GDPR) を文書化します。 たとえば、特定のリージョンでデータ所在地が必要な場合、そのリージョンのクラウド アーキテクチャに影響します。

4. 運用上の制約: 特定のメンテナンス期間、ブラックアウト期間 (トラフィックの多い期間)、アップタイムの要件を文書化します。 移行スケジュールとターゲット アーキテクチャ (高可用性のニーズ) に影響するため、このような制約を文書化します。

5. 予測されるタイムラインまたは期限: このワークロードを移行するために必要なタイムラインがある場合は、同様に注意してください。 たとえば、契約の更新やデータ センターのリースが終了している可能性があります。 これらの要因は、ロードマップの全体的なスケジュール設定に影響します。

例については、「 移行導入計画」を参照してください。

Azure の検出と評価のツールとリソース

次のステップ