ワークロードを評価する
資産フェーズでは、ワークロードの準備状況を評価し、移行された状態を計画します。 このフェーズを完了したら、移行のためにワークロードをデプロイできます。
クラウド導入チームは、技術的な互換性、必要なアーキテクチャ、パフォーマンスとサイズの期待値、および依存関係を評価する必要があります。 この情報は、移行されたワークロードを効率的にクラウドにデプロイできるようにするために使用します。
ワークロードの分類
ガバナンス、セキュリティ、運用、クラウドスケールの分析要件が明確になるように、ワークロードを分類します。 データの漏えいの可能性がビジネスや顧客にどのような影響を与えるかに基づいてデータを分類します。 機密性の高いデータはセキュリティ リスクが高くなります。 ワークロードの重要度は、障害によるビジネスへの影響度に基づきます。
ワークロードを分類したら、その詳細をサポート チームと共有します。 通常、低い、またはサポート対象外のワークロードは、サポート チームにほとんど影響しません。 ただし、ワークロードがミッションクリティカルまたはユニットクリティカルに近い分類の場合、運用上の依存関係は増えます。
ワークロードの準備状況を評価する
ワークロードを移行する場合、クラウド デプロイ チームは、すべての資産と関連する依存関係がデプロイ モデルやクラウド プロバイダーと互換性があることを確認する必要があります。 チームは、互換性の問題を修復するために必要な作業を文書化する必要があります。
前提を評価します。 評価ツールを使用して、移行を妨げるものがあるかどうかを判断します。
複数のデータセンターからワークロードを移行する場合は、データセンター間の依存関係を評価します。 これらの依存関係を視覚化し、グループ化することで、ワークロードをサポートする資産の IP アドレスとポートを特定します。
レプリケーション アクティビティには Azure Migrate & Modernize を使用します。 Azure Migrate & Modernize プロジェクトを使用して、次のことができます。
- ワークロードを評価します。
- Azure での運用コストを計算します。
- 移行の準備状況を評価します。
- 実際の使用状況に基づいて、サーバーのサイズを Azure サブスクリプションに換算します。
サーバー移行の一環として、SQL Server インスタンスまたは他のデータベース サーバーを移行することもできます。
ホスト構成、レプリケートされた VM 構成、ネットワーク構成、ストレージ要件のすべての不一致を文書化します。 この情報を使用して、移行の帯域幅に関する考慮事項を見積もってください。
ワークロード アーキテクチャを設計する
移行する前に、目的とするワークロードの移行後の状態を設計する必要があります。
一般的な設計の前提条件を考慮して以下を設計します。
- Azure ランディング ゾーン実装の一環である、アプリケーション ランディング ゾーンのアーキテクチャ。
- ロード バランサーやその他のアプリケーション配信リソースなどのリソースを備えたワークロード ネットワーク アーキテクチャ。
- コンポーネント間の通信を考慮したワークロードの依存関係。
- 機密コンピューティング。
アーキテクチャの設計が完了したら、クラウドの見積もりを見直して、計画した予算内に収まっていることを確認します。
移行では、既存のアーキテクチャを維持し、クラウド プラットフォームに移行することに重点を置く傾向があります。 ただし、移行の場合でもワークロードの再設計が必要になることがあります。 以下のことが必要な場合は、状況に応じて移行前にアーキテクチャを変更します。
- 技術的負債を支払う。
- 信頼性を向上させる。
- 高コストのワークロードを最適化する。
- パフォーマンス要件を満たす。
- セキュリティで保護されたアプリケーション。