クラウド移行のワークロードを評価する

評価フェーズでは、Microsoft Azureに移行する前に、すべてのコンポーネント、依存関係、要件を完全に把握できます。 アーキテクチャ、パフォーマンス、セキュリティ、コード、データベースに関する詳細情報を収集することで、問題を予測し、リスクを最小限に抑え、情報に基づいた移行の決定を行うことができます。

ワークロード アーキテクチャを評価する

完全なアーキテクチャ評価により、すべてのワークロード コンポーネントとその相互作用を可視化できます。 この可視性は、一緒に移動する必要があるコンポーネントと、変更が必要なコンポーネントを特定することで、正確な移行計画をサポートします。

1. 評価ツールを使用します。 Azure Migrateやその他の製品などのツールにより、ワークロード コンポーネントと構成の検出が自動化されます。 これらのツールを使用すると、手動による作業が減り、環境全体で一貫したデータ収集が提供されますが、文書化されていない依存関係が失われる可能性があります。 Cloudockit などのツールを使用して、ダイアグラムを生成できます。 Azureアイコンを使用して独自のダイアグラムを作成したり、Azureアーキテクチャ センターでダウンロード可能なダイアグラムを調整したりすることもできます。

2. 主題の専門知識を使用してアーキテクチャを検証します。 ワークロード所有者は、ツールの結果を確認し、不足している情報または古い情報を特定できます。 インタビューまたはアーキテクチャ レビュー セッションを実施して、自動化された検出データのギャップを埋めます。

3. ドキュメント アーキテクチャ。 アーキテクチャダイアグラム、コンポーネントリスト、および構成データを、計画と検証をサポートする形式で格納します。 この情報を維持するために、Microsoft Visio、スプレッドシート、Azure DevOps Wiki などのツールを使用します。

ワークロード コンポーネントを評価する

ワークロードごとに、現在の環境から詳細なベースライン パフォーマンスと使用状況メトリックを収集します。 このデータは、リソースAzure適切なサイズ設定を行い、移行後のパフォーマンスを比較するために重要です。

1. ワークロード メトリックを収集します。 CPU 使用率、メモリ使用量、ディスク I/O (読み取り/書き込み、IOPS)、ネットワーク スループット、ピークコンカレンシーまたはユーザー負荷を追跡します。 容量のニーズを理解するために、毎日または毎週のピークを特定します。 ユーザー トランザクションの平均応答時間、1 時間あたりに処理されるジョブのスループット、および SLA 関連のメトリックを測定します。 この情報は、移行されたワークロードが同じビジネス パフォーマンス要件を満たしていることを確認するのに役立ちます。

2. 構成の詳細をキャプチャします。 スケーリングの構成、現在の仮想マシン (VM) のサイズ、物理サーバーの仕様 (CPU コア、RAM)、OS の種類とバージョン、ストレージの種類 (SSD/HDD) と容量、GPU などの特別なハードウェアに注意してください。 これらの詳細は、AZURE VM サイズまたは PaaS サービスの選択を通知します。 ソフトウェア ライセンス情報も記録します。 この情報により、Azure ハイブリッド特典の使用が可能になる場合や、ライセンスの移行が必要になる場合があります。

3. すべてのセキュリティと ID の構成を文書化します。 すべてのセキュリティと ID の構成をインベントリします。サービス アカウント、ハードコーディングされた資格情報、使用される暗号化方法、ファイアウォール規則を一覧表示します。 これらの構成は、Azureでレプリケートまたは調整する必要があります。

   セキュリティ コンポーネント	Action	Purpose
   ID インベントリ	アプリケーションが認証に使用するすべてのサービス アカウント、ユーザー アカウント、API キーを記録する	リフトアンドシフトまたはモダン化のアプローチを選択した場合の移行シーケンスに影響します
   暗号化に関するドキュメント	保存データと転送中データの現在の暗号化方法を文書化する	これらの要件をセキュリティ標準を維持するためのAzure暗号化サービスにマップする
   ネットワーク セキュリティの構成	ネットワーク セキュリティ規則、ファイアウォール構成、およびアクセス制御リストをキャプチャする	この情報を使用して、ネットワーク セキュリティ グループとアクセス ポリシー Azure設計します

4. 互換性の問題を特定します。 自動化されたツールは、オペレーティング システム、ミドルウェア、アプリケーション フレームワークをAzure サポート ポリシーに対して体系的に分析します。 これらのツールは、サポートされていない、非推奨、またはサポート終了に近づいているコンポーネントにフラグを設定します。 Azure Migrateやその他の評価ツールなどのツールは、手動で構成レビューを行わなくても、環境全体でこれらの問題を検出できます。

5. 必要な修復を一覧表示します。 すべての互換性の問題とその修復要件の包括的な一覧を作成します。 移行前に修正する必要がある優先順位 (阻害要因) と、必要に応じて移行後に対処できる優先度を設定します。 必要に応じてベンダーと連携し、商用ソフトウェアのアップグレード パスを理解します。

内部依存関係と外部依存関係のマップ

1. 内部依存関係をマップします。 ワークロードのコンポーネントが相互に通信し、組織内の他のシステムと通信する方法をマップします。 ネットワーク監視ツールまたはアプリケーション パフォーマンス監視を使用して、サービス間のランタイム接続を確認します。 このマッピングは、移行ウェーブでのグループ化を決定するのに役立ちます。 たとえば、アプリ A がデータベース B を常に呼び出す場合は、それらをまとめて移行するか、両方がクラウドに存在するまで、Azureとソース環境の間にネットワーク接続を提供します。

2. すべての外部依存関係を識別します。 ワークロードが対話する外部サービスを一覧表示します。 これらの依存関係には、SaaS プラットフォーム、パートナー API、オンプレミス システム、アプリケーションが適切に機能するために必要なサード パーティのサービスが含まれます。 依存関係の完全な状況を理解するには、すべてのアップストリームとダウンストリームの統合、共有サービス、およびデータ パイプラインをカタログ化する必要があります。 ドキュメント API、メッセージング システム、ETL プロセス、共有データベース、認証方法、データ交換パターン、およびサービス レベル アグリーメント。 統合ドキュメントを確認し、アプリケーション所有者にインタビューを実施して、すべての外部接続を完全に可視化します。 この包括的なマッピングにより、統合エラーが回避され、正確な移行シーケンスがサポートされます。

3. ワークロード所有者が依存関係データを検証して完了するように促します。 ワークロード所有者は、ツールが検出しない可能性があるシステム動作、共有リソース、非公式の統合に関する重要な分析情報を提供します。 ツールによって生成されたデータを検証し、文書化されていない依存関係を特定するには、アプリケーションとワークロードの所有者と構造化されたインタビューまたはワークショップを実施する必要があります。 この手順により、依存関係マップの完全性と精度が確保され、移行シーケンスを通知するビジネス コンテキストをキャプチャするのに役立ちます。

4. 中央リポジトリ内のすべての依存関係を文書化します。 スプレッドシート、アーキテクチャ図、依存関係マッピング ツールなど、チーム間のコラボレーションと移行の計画をサポートする形式で依存関係データを格納します。 移行プロセス中の変更を反映するように、リポジトリがアクセス可能で定期的に更新されていることを確認します。

5. 依存関係を使用して移行を計画します。 ワークロードを移行ウェーブに整理し、破損した依存関係を最小限に抑えます。 詳細については、 移行ウェーブ計画を参照してください。

コンプライアンスと運用上の要件を評価する

1. 規制コンプライアンス要件を特定します。 規制コンプライアンス要件を明確に理解することで、Azureアーキテクチャが法律、業界、組織の義務と一致することが保証されます。 これらの要件は、リージョンの選択、サービスの可用性、データ保護、アーキテクチャの決定に影響します。 規制とコンプライアンスの標準には、グローバル、地域、業界固有、および内部ポリシーが含まれます。 これらの標準には、HIPAA、FedRAMP、ISO 27001、SOX などの金融規制が含まれる場合があります。 各標準では、データ処理、アクセス制御、暗号化、監査可能性に固有の要件が課されます。 法律、コンプライアンス、およびセキュリティの利害関係者に相談して、各ワークロードに適用されるすべての標準を特定する必要があります。

2. SLA、RPO、RTO を文書化します。 サービス レベル アグリーメント (SLA)、回復ポイント目標 (RPO)、回復時間目標 (RTO) は、許容される可用性レベルとデータ損失レベルを定義します。 これらのメトリックは、バックアップ、レプリケーション、およびフェールオーバー戦略の設計をガイドします。 アーキテクチャがビジネス継続性の期待を満たしていることを確認するには、ワークロードごとにこれらの値を文書化する必要があります。 信頼性要件の定義を参照してください。

3. 各ワークロード環境を分類します。 ワークロードは通常、運用環境、テスト環境、または開発環境で実行されます。 各環境には、可用性、セキュリティ、パフォーマンスの要件が異なります。 移行シーケンス、アクセス制御、およびリソース割り当てを通知するには、各ワークロードの環境分類を文書化する必要があります。

4. ISV と Azure の統合を検証します。 多くのワークロードは、独立系ソフトウェア ベンダー (ISV) のソフトウェアに依存しています。 移行前にすべての ISV ソフトウェアがAzureと互換性があることを確認する必要があります。 ISV でベンダーのドキュメント、テスト環境、または直接検証を使用します。 必要な更新、置換、または構成の変更を特定します。 また、Azure ハイブリッド特典またはその他のライセンス モデルが適用されるかどうかを決定します。 正確な予算作成とスケジュール設定のために、移行計画にライセンス コストと互換性の調整を含めます。

アプリケーション コードを評価する

アプリケーション コード評価では、移行の成功に影響を与える可能性がある互換性の問題と最新化の機会を特定します。 この評価は、アプリケーションがAzureで確実に実行されるようにし、移行ウェーブを効果的に計画するために不可欠です。 早期に阻害要因を検出し、移行エラーのリスクを軽減し、ターゲット アーキテクチャの決定を通知するために、アプリケーション コードを評価する必要があります。

自動化されたツールを使用してアプリケーション コードを評価する

1. GitHub Copilot アプリ モダン化ツール (.NETおよびJava).GitHub Copilot アプリ モダン化では、.NETとJavaワークロードの詳細な評価が提供されます。 AppCAT の評価機能とCopilotの AI 主導の支援を組み合わせて、最新化をより迅速かつ簡単にします。 この統合はコーディング パートナーとして機能し、次の作業に役立ちます。

   • アプリケーション関連の依存関係をキャプチャする
   • Azure サービスのソース コードを修正して最適化する
   • コードを更新し、一般的な脆弱性と露出 (CVE) を修復する
   • 柔軟なデプロイのためにアプリケーションをコンテナー化する
   • デプロイ ファイルを生成して移行を効率化する
   • AI 支援コーディングを使用して労力を削減する

2. 他のアプリケーション言語にサード パーティ製ツールを使用する。 CloudPilot や CAST Highlight などのツールは、Python、JavaScript、Node.js、Go などの言語をサポートします。 これらのツールは、Azure互換性に必要なコード レベルの変更を識別し、最新化の分析情報を提供します。 これらのツールを使用して、非.NETワークロードと非Javaワークロードを評価します。

3. 評価結果を使用して、ターゲット アーキテクチャの決定を通知します。 アプリケーションの互換性の結果は、Azure サービスの選択に影響を与える可能性があります。 たとえば、あるサービスと互換性のないアプリケーションは、最小限のコード変更で別のサービスと互換性がある可能性があります。 Azure App Serviceなどのサービスでは通常、必要なコード変更が少なくなりますが、コンテナー プラットフォーム サービスではデプロイ前に必要なコード更新が増える場合があります。 この柔軟性を使用して、アプリケーションをより早く移行し、コードの最新化を後のフェーズに延期します。 このアプローチにより、移行リスクが軽減され、クラウドへの時間が短縮されます。

フレームワークと SDK の互換性を検証する

1. コードの互換性について理解します。 フレームワークと SDK の互換性により、アプリケーションがAzureで確実に実行されます。 サポートされていないバージョンまたは互換性のない SDK では、ランタイム エラーが発生したり、大幅なやり直しが必要になったりする可能性があります。 Azureがアプリケーションの言語バージョンとフレームワークをサポートしていることを確認する必要があります。

2. アプリケーションの言語とフレームワークのAzure サポートを確認します。 Azureが .NET Java、Python、JavaScript、Node.js、および Go。 互換性を検証するには、公式のAzureドキュメントを使用します。

3. 不要なフレームワークの変更を避けます。 ビジネス上の正当な理由が強い場合は、新しいフレームワーク (Microsoft .NET Framework から .NET Core など) にのみ移行します。 フレームワークの変更には、大幅な開発作業とテストが必要です。

データベースを評価する

多くの場合、データベースの依存関係によって、アプリケーションの移行の成功が決まります。 共有データベース、アプリケーション間の依存関係、統合パターンは、移行計画を複雑にする可能性があります。 アプリケーションをサポートするデータベースを評価し、その依存関係を理解する必要があります。 このガイダンスに従ってください。

1. アプリケーションによって使用されるすべてのデータベースを識別します。 アプリケーションで使用されるすべてのデータベースの完全なインベントリを作成します。 データベース エンジンの種類 (SQL Server、MySQL)、バージョン、ホスティング モデル (オンプレミス、IaaS、PaaS など) を含めます。 Azure Migrateなどのツールを使用して、この情報を体系的に収集します。 データベースをセルフホステッドにするか、仮想マシンでホストするか、マネージド サービスとして配信するかを指定します。 この情報は、移行の準備状況とターゲット プラットフォームの互換性を判断するのに役立ちます。

2. 受信依存関係と送信依存関係をマップします。 移行をシーケンス処理し、サービスの中断を回避するために、各データベースとの間でデータがどのように送受信されるかを明確に把握することが重要です。 依存関係は、多くの場合、複数のアプリケーション、サービス、および外部システムにまたがるものです。 内部アプリケーション、API、バッチ ジョブ、レポート ツール、その他の統合が含まれます。 依存関係が読み取り専用、書き込み専用、または双方向のいずれであるかを指定します。 この詳細は、ワークロードに優先順位を付け、潜在的な移行の阻害要因を特定するのに役立ちます。

3. データベース移行戦略を決定します。 データベースを共有インスタンスとして移動するか、ワークロード別に分割するかを決定します。 共有データベースは管理を簡略化しますが、複数のアプリケーションがそれらに依存している場合、移行が遅れる可能性があります。 データベースを分割すると、独立した移行が可能になりますが、慎重な調整とテストが必要です。 データベース移行計画でアプリケーションの移動のシーケンス処理がサポートされていることを確認し、ダウンタイムやサービスの中断を最小限に抑えます。

リスク レジスタを作成して維持する

リスク レジスタは、クラウド導入に影響する可能性がある潜在的なリスクを特定、評価、優先順位付け、監視するために使用するドキュメントまたはツールです。 軽減戦略の概要を示します。 このレジスタを維持することで、積極的なリスク管理が保証されます。

1. すべてのワークロードのリスク レジスタを確立します。 技術的、運用上、および組織の要因に関連するリスクを記録します。 このレジスタは、潜在的な阻害要因とその値を可視化します。

2. 軽減策を定義し、その状態を追跡します。 リスクごとに、軽減策アクション、責任当事者、解決タイムラインを文書化します。 この追跡により、リスクを積極的に管理および解決できます。

詳細については、「CAF ガバナンス - クラウド リスクの評価」を参照してください。

Azureリソースとツール

次のステップ