再配置のためにクラウド ワークロードを評価する
評価は、再配置の移動フェーズの最初のステップです。 評価の目標は、再配置するワークロードを理解して、正常に移動できるようにすることです。 再配置するすべてのワークロードは、評価ステップから始まる、移動フェーズの 4 つのステップを経る必要があります。
ワークロードを選択する
ワークロードの優先順位を付けたリストを作成し、そのリストでワークロードを再配置する順序を特定する必要があります。 評価ステップにアクセスするたびに、リストの一番上にあるワークロードを選択してください。 小規模なチームの場合は、一度に 1 つずつワークロードを再配置する必要があります。 ワークロードの再配置は、そのたびに学習して改善する機会です。 大規模なチームでは、複数のワークロードの再配置を検討する必要があります。 一括再配置は、規模の経済を実現するのに役立ちます。
検出を実施する
ワークロード検出は再配置の基礎です。 検出の目的は、スムーズな再配置を確実に実行するため、ワークロードを十分に理解することです。 検出において、ワークロードの組織的と技術的な側面を包括的に明らかにする必要があります。
組織的な検出の実施
ワークロードの組織的な検出には、ワークロードを担当するユーザーの特定、ワークロードの移動に伴うリスクの理解、移動に関するコミュニケーション方法の計画が含まれます。 この手順は、誰が関与する必要があるかについて特定、リスクの管理、全員に適切に情報を提供することに役立ちます。 この慎重なプランニングは、移行をスムーズにしてビジネスとその顧客への影響を減らすことに役立ちます。
ワークロードの所有権: ワークロードを担当するユーザーを決定します。
利害関係者の識別: ワークロードに関心を持つすべての関係者を特定します。
リスク評価: ワークロードの移動に関連する潜在的なビジネス リスクを評価します。
変更管理: ワークロードに対する変更管理のプロセスを明確に理解できるようにします。
停止ウィンドウ: 再配置のためにシステムがオフラインになるときの許容時間を確認します。
影響分析: 再配置が影響を与える内部ユーザーまたは外部顧客を認識します。
通信ニーズ: ダウンタイムや変更についてコミュニケーションを取るために現在必要なコミュニケーション計画を理解します。
ポリシー コンプライアンス: 再配置が組織方針と業界の規制に準拠していることを確認します。
技術的な検出の実施
技術的なワークロード検出は、ワークロードの依存関係、リソース、ネットワーク構成、その他の技術的な要件や制約を含め、技術的な側面を包括的に理解することが含まれます。 技術的な発見は、再配置に関連するリスクを予測して軽減するために役立ちます。 技術的な発見を実施するための戦略は次のとおりです。
依存関係の評価
依存関係は、ワークロードを実行する必要があるリソースまたはサービスです。 ワークロードを正常に再配置するには、すべての依存関係を特定することが不可欠です。 依存関係には、ワークロードの操作に不可欠であるさまざまなリソースとサービスが含まれます。 次のリストには、依存関係の例をいくつか示します。
Azure サービス: ワークロードが依存するすべての Azure サービス。 グローバル リソースは特定のリージョンに展開しないため、再配置で移動する必要はありません。 ただし、別のリージョンで動作するように再構成することもできます。 たとえば、再配置されたワークロードの新しい IP アドレスを指すように、Azure Front Door プロファイルの IP アドレスを更新する必要がある場合があります。
マイクロソフト以外のアプリケーション: ワークロードに統合または必要なその他のベンダーのアプリケーション。 ワークロードに関連する製品の機能と制限事項について説明します。
ライセンス: 必要なすべてのソフトウェア ライセンスが、新しい場所に登録されて有効であることを確認します。
ネットワーク: ファイアウォールを含むネットワークセットアップを理解し、再配置後のシームレスな接続を確保します。
テスト: 新しい環境でワークロードが正しく機能することを確認するために必要なテスト手順を決定します。
タグ付け: 効果的な管理と追跡のためにリソースを適切にタグ付けして識別します。
自動化: 組織はコードとしてスクリプトとインフラストラクチャを使用する場合があります。 スクリプトまたはコード内の Azure リージョン、サービス名、サービス URL へのリファレンスを更新する必要があります。 リファレンスは、移動先の新しい Azure リージョンに対応する必要があります。
ワークロードのライフサイクル中に変更される可能性があるコード内の値のハードコーディングを避ける必要があります。 代わりに、これらの値を動的に取得するか、コード内で構成可能なパラメーターを使用します。 このアプローチにより、変更の負担が軽減されてスムーズな再配置プロセスが保証されます。
DNS: Azure は、リージョンに応じてエンドポイントにパブリック IP アドレスが割り当てます。 エンドポイントを別の Azure リージョンに移動するとき、別の IP アドレスが取得されます。 必ず DNS レコードをこれらの新しい IP アドレスで更新してください。 また、"許可" リストに以前の IP アドレスがあるシステムに新しい IP アドレスを指定する必要があります。
古いリソースをオフにする前に、新しい Azure リージョンに新しいリソースの展開が必要になる場合があります。 その場合、2 つのリソースが一度に同じ DNS 名を持つことができない問題が発生する可能性があります。 この問題を回避するには、サービスごとに一意の名前を使用することを検討してください。 場合によっては、CNAME レコードを使用して抽象化レイヤーを提供できる場合があります。 これにより、リソース名の変更を管理しやすくなります。
ロード バランサー。 新しいバックエンド IP アドレスまたはホストを指すロード バランサーを更新します。 DNS ベースのロード バランサーの場合、DNS キャッシュと Time to Live(TTL)レコードの有効期限に基づいて変更が反映されるまでに時間がかかる場合があります。 詳細については、「Azure の負荷分散サービス」を参照してください。 DNS レコードの Time to Live(TTL)設定を一時的に減らすことを検討してください。 DNS レコードが新しい IP アドレスにすばやく切り替えるようになります。 また、短い期間にバックエンド システムの正常性をより頻繁にチェックするため、ロード バランサーを設定することを検討してください。 後で余分なコストとパフォーマンス低下を避けるため、必ず移行後にこれらの設定を通常の設定に戻してください。
Azure Backup の登録。 新しい Azure リージョンに仮想マシンを移動する場合、必ず現在のリージョンの Azure Backup サービスから登録を解除し、新しいリージョンの Azure Backup サービスに登録してください。 既存のバックアップ回復ポイントは、新しいバックアップ コンテナーに転送できないため、アクセスできません。 新しいリージョンで新しい回復ポイントの作成を開始する必要があります。
エンドポイントの評価
エンドポイント検出とは、ワークロードに関連しているすべてのエンドポイントまたは IP アドレスを識別するプロセスを指します。 すべてのワークロード エンドポイントを検出することにより、すべてのネットワーク接続とアクセス ポイントに含まれて、新しい環境で適切に構成する準備をできるようにします。 パブリック IP アドレスとプライベート エンドポイントに対応するための推奨事項は次のとおりです。
- パブリック IP アドレス: パブリック IP アドレスはリージョン固有です。 リージョン間でそれらを移動することはできません。 パブリック IP の構成をエクスポートし、新しいターゲット リージョンにデプロイする必要があります。 詳細については、Azure パブリック IP 構成を別の Azure リージョンに移動するに関するページを参照してください。
- プライベート エンドポイント: プライベート エンドポイントを再展開するとき、リンク先のサブネットから新しい IP アドレスが取得される可能性があります。 プライベート エンドポイントを介してリソースに接続する場合、これらのエンドポイントは仮想ネットワーク内のリソースのネットワーク アドレスを解決するプライベート DNS ゾーンにリンクされます。 再配置では、プライベート DNS ゾーン内の DNS レコードを更新して接続を維持する必要があります。
自動化ツールの使用
可能であれば、自動化ツールを使用して、ワークロードを構成するアプリケーションと Azure サービスに関する情報を収集します。 これらのツールを使用すると、特定のワークロードの再配置について、低レベルの検出とアーキテクチャ設計の検出を実行できます。 次の Azure ツールとサービスを使用する必要があります。
Azure Resource Mover を試してください。 最初に Azure Resource Mover を試してください。 現在、これは最も使いやすい検出ツールであり、サービスとデータを再配置することもできます。 しかし、Azure Resource Mover は限られた数のサービスのみをサポートしているため、続行する前にサービスがサポートされていることを確認してください。 詳細については、Azure Resource Mover でサポートされているリソースに関するページを参照してください。
視覚化ツールを使用します。 Azure Resource Mover がすべてのニーズを満たしていない場合は、視覚化ツールを使用して検出を支援できます。 Azure には、依存関係のマップに使用できる視覚化ツールがいくつかあります。 ご自分のニーズに最適なツールを選択します。
"リソース グループ ビジュアライザー": リソース グループ内のリソース間の接続を視覚化できます。 Azure portal で、リソース グループに移動し、左側のナビゲーションから [リソース ビジュアライザー] を選択します。
"Azure Monitor トポロジ": Azure Monitor のトポロジ機能を使用してネットワークの依存関係を表示できます。 詳細については、ネットワーク分析情報トポロジに関するページを参照してください。
Application Insights: Application Insights には、分散アプリケーションの論理構造を表示できるアプリケーション マッピング機能があります。 詳細については、Azure Application Insights のアプリケーション マップに関するページを参照してください。
Azure Resource Explorer: Azure Resource Explorer には、Microsoft Entra テナント内のすべてのリソースが一覧表示されます。 これは可視性を提供しますが、依存関係を示すわけではありません。 ワークロード コンポーネントと依存関係を手動でマップする必要があります。 詳細については、Azure Resource Explorer に関するページを参照してください。
Azure Resource Graph: Azure Resource Graph を使用すると、Microsoft Entra テナント内のリソースに対してクエリを実行できます。 Resource Graph には、ポータルとコマンド ラインからアクセスできます。 ワークロード コンポーネントと依存関係を手動でマップする必要があります。 詳細については、Azure Resource Graph のドキュメントを参照してください。
インベントリ ダッシュボード: Azure portal では、ビルトインのインベントリ テンプレートを使用し、既存のリソースを追跡するダッシュボードを作成できます。 これは、持っているリソースとインスタンスの数を簡単に判断する方法です。
ドキュメントの手動作成
自動検出アプローチでは十分でない場合は、ワークロードの手動評価を行うことができます。 ほとんどの手動評価は、必要な情報を取得するために、技術専門家とのインタビューと技術ドキュメントに依存しています。 製品またはアプリケーションの所有者を特定し、その人たちにインタビューします。 これらのインタビューは任意ですが、ツールによって提供される情報のギャップをチームがカバーする必要がある場合には必要です。 また、アプリ所有者はタグをプルし、依存関係を手動で識別できます。
リージョンのサポート性を見つける
Azure のすべてのリージョンが同じサービスを提供しているわけではないため、ワークロードを実行するために必要なサービスがターゲット リージョンで利用できることを確認する必要があります。 この決定はプロセスの終わりに行うものに見えるかもしれませんが、サポート性を確保するには検出の詳細が必要です。 実際のワークロードのリージョンのサポート性を確認するには、各 Azure リージョンで利用できる製品とサービスに関するページを参照してください。
ターゲット リージョンがペア リージョンかどうか、および可用性ゾーンをサポートしているかどうかを確認します。 リージョンのペアリングと可用性ゾーンは再配置作業には影響しませんが、ターゲット リージョンでの事業継続とディザスター リカバリー (BCDR) 戦略には影響します。 詳細については、Azure リージョンと可用性ゾーンに関するページを参照してください。
ワークロード サービスを分類する
再配置は、サービスとコンポーネント レベルで行われます。 ほとんどのワークロードでは、複数のサービスが使用されています。 サービスには、ステートフルとステートレスの 2 つの主な種類があります。 各サービスをステートフルまたはステートレスとして分類する必要があります。 この知識は、依存関係を特定し、サービス統合を理解し、再配置の自動化オプションを絞り込むのに役立ちます。
ステートレス サービス: ステートレス サービスには構成情報のみが含まれます。 これらのサービスでは、データを継続的に複製して移動する必要はありません。 例として、仮想ネットワーク、ネットワーク アダプター、ロード バランサー、ネットワーク セキュリティ グループなどがあります。
ステートフル サービス: ステートフル サービスには、移動する必要がある構成情報とデータが含まれます。 例として、仮想マシンと SQL データベースなどがあります。
次のステップ
ワークロードを評価すると、再配置方法と、選択した方法を実行するためのツールを選択するのに十分な情報が得られます。 選択ステップでは、再配置方法とその再配置方法に適したツールを選択するための決定を順を追って説明します。