ワークロードの準備状況を評価する
この記事は、クラウドに移行するワークロードの準備状況の評価方法に重点を置いています。
ワークロードを移行する場合、クラウド導入チームは、すべての資産と関連する依存関係がデプロイ モデルおよびクラウド プロバイダーと互換性があることを確認します。 チームは、互換性の問題を修復するために必要なすべての作業を文書化します。
評価の前提条件
Azure のクラウド導入フレームワークでの原則を説明しているほとんどの内容は、クラウドに依存しません。 ただし、準備の評価プロセスは、各クラウド プラットフォームと、準備フェーズで選択した移行ツールに固有である必要があります。
選択した評価ツールは、移行の阻害要因に関する情報を提供する必要があります。 一般的な阻害要因には、オペレーティング システムのサポート、サーバー サイズ、およびレプリケーションに影響する可能性があるデータ変更率が含まれます。
一部の組織では、ソース ハイパーバイザー プラットフォームを利用する仮想マシン (VM) の構成に関する問題にも直面しています。 これらの構成には、仮想化ベースのセキュリティ、ダイナミック ディスク、Microsoft 以外のアプリケーションのライセンス、データ ソース構成、証明書が含まれます。
この記事では、各環境とビジネスの成果によって特定の要件が決められるため、考えられるすべての評価アクティビティを取り込むわけではありません。 これらの要件を判断するために、インフラストラクチャ、データベース、ネットワークに関連するいくつかの一般的な評価アクティビティを次に示します。
データセンターにまたがる依存関係の評価
複数のデータセンターからワークロードを移行する場合は、それらのデータセンター間の依存関係を評価する必要があります。
データセンター間の依存関係を評価するには、次の機能を検討してください。
- 依存関係を視覚化する: Azure Migrate と Modernize の依存関係の視覚化 機能を使用して、依存関係を特定します。
- グループの依存関係: グローバルな複雑さに対処する場合は、依存関係のグループ化を使用します。 この機能は、ワークロードをサポートするために必要なすべての資産の IP アドレスとポートを識別するのに役立ちます。
重要
- 資産の配置と IP アドレス スキーマを理解している領域の専門家が、セカンダリ データセンターに存在している資産を識別する必要があります。
- 視覚化されたダウンストリームの依存関係とクライアントの両方を評価して、双方向の依存関係を理解する必要があります。
シナリオ例
次のセクションでは、ワークロードとデータベースをクラウドに移行する準備状況を評価するためのガイダンスを提供します。
Azure Migrate と Modernize の一般的な評価アクティビティ
次のガイダンスでは、ワークロードを Azure に移行することを前提としています。 また、レプリケーション アクティビティに Azure Migrate と Modernize を使用していることを前提としています。
Azure Migrate と Modernize プロジェクトを使用してワークロードを評価し、Azure での運用コストを計算できます。 詳細については、「Azure Migrate と Modernize の Azure VM 評価」を参照してください。
また、Azure Migrate と Modernize プロジェクトを使用して、移行の準備状況を評価し、実際の使用に基づいてサーバー サイズを Azure サブスクリプションに変換し、コストを計算することもできます。 ビジネス ケースを構築して、コスト計算をさらに絞り込みます。
ホスト構成、レプリケートされた VM 構成、ストレージ要件、またはネットワーク構成での不一致をすべて文書化するようにしてください。 この情報を使用して、移行の帯域幅に関する考慮事項を見積もってください。 帯域幅の見積もりの一般的なコンポーネントは次のとおりです。
- 合計ストレージ: リリースまでのイテレーション中にレプリケートされる VM の合計ストレージを計算します。
- ドリフトまたは変更の比率: リリースまでのイテレーション中にレプリケートされる VM のストレージのドリフトまたは変更の比率を計算します。
- 帯域幅の要件: ストレージとドリフトの合計を加算することによって、各イテレーションに必要な帯域幅の要件を計算します。
- 未使用の帯域幅: イテレーションの配置ごとに検証するために現在のネットワークで使用可能な未使用の帯域幅を計算します。
- 移行速度帯域幅: 予想される移行速度に達するために必要な帯域幅を文書化します。 必要な帯域幅を提供するために何からの修復が必要な場合は、修復アクティビティを担当するチームに通知します。
Note
合計ストレージは、初期レプリケーション中の帯域幅要件に直接影響を与えます。 ただし、ストレージ ドリフトはレプリケーションの時点からリリースまで続きます。 つまり、ドリフトには使用可能な帯域幅への累積効果があります。
帯域幅要件の測定に関するガイダンスについては、「移行と最新化のツールに関する一般的な質問」を参照してください。
一般的なデータベース評価アクティビティ
サーバーの移行の一環として、SQL Server インスタンスまたはその他のデータベース サーバーの移行も確認できます。
- RPO および RTO を文書化する: 現在のデータベース デプロイの回復ポイントの目標 (RPO) と回復時間の目標 (RTO) を文書化します。 この情報は、アーキテクチャ アクティビティ中に決定を下すのに役立ちます。
- 高可用性の要件を文書化する: 高可用性の構成要件を文書化します。 SQL Server の要件を理解するには、「SQL Server 高可用性ソリューション ガイド」を参照してください。
- PaaS の評価: サービスとしてのプラットフォーム (PaaS) の互換性を評価します。 Azure Database Migration Service のガイドでは、オンプレミス データベースが Azure Cosmos DB、Azure SQL データベース、Azure Database for MySQL、Azure Database for PostgreSQL、Azure Database for MariaDB などの互換性のある Azure PaaS ソリューションにマップされています。
- ドキュメントのサイズと変更率: 移行する予定の各データベースのサイズと変更率を文書化します。
- アプリケーションとデータベースの依存関係を文書化する: 可能な場合は、各データベースへの呼び出しを行うアプリケーションまたはその他の資産をすべて文書化します。
Note
資産を同期すると、レプリケーション プロセス中に帯域幅が消費されます。 一般的な落とし穴は、資産をレプリケーションの時点とリリースの間で同期された状態に維持するために必要な帯域幅の量を見落とすことです。 データベースはリリース サイクル中の帯域幅の一般的なコンシューマーであり、ストレージ フットプリントの大きな、または変更の比率の高いデータベースが特に問題になります。
ユーザー受け入れテスト (UAT) とリリースの前に、制御された更新を使用してデータ構造をレプリケートすることを検討してください。 このようなシナリオでは、Azure Site Recovery に代わる方法の方がより適切な場合があります。 詳細については、「Azure Database Migration Service ガイド」を参照してください。
次のステップ
システムの評価が完了すると、出力により、新しいクラウド アーキテクチャの開発が可能になります。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示