移行前に資産を修復する
移行の評価プロセス中、チームは資産と選択したクラウド プロバイダーが非互換になる可能性があるあらゆる構成を特定します。 修復は、非互換性を解決するために使用できる移行プロセスのチェックポイントです。
この記事は一般的な修復タスクをいくつか説明したもので、修復が賢明な投資であるかどうかを判断するのに役立ちます。
修復の種類
デプロイ全体で計画する必要がある修復アクティビティには、大きく分けて 2 種類あります。
- 評価アクティビティの結果に基づく
- レプリケーションとデプロイを許可するために完了する必要がある修復アクティビティ。
- 評価フェーズ中に、ワークロード評価でこれらの修復アクティビティを決定しました。 これらのタスクを実行して、クラウドでワークロードを適切にレプリケートしてステージングできることを確認する必要があります。
- これは主に移行するソース サーバーに焦点を当てています。
- テスト アクティビティの結果に基づく
- これは、移行アクティビティのテストとビジネス テストの実行に起因します。
- これらの修復アクティビティは、レプリケート先サーバーの構成と、ロード バランサー、仮想ネットワーク、ストレージ アカウントなどの支援サービスに重点を置きます。
- これらのタスクは、より反復的である可能性が高いです。 すべてのテスト ケースが成功するまで、複数のサイクルを通してテストと修復を行います。
修復アクティビティを追跡する
イテレーション全体を通して、評価またはテストを通じてワークロードの修復タスクを特定できます。 これらのタスクが完了したことを確認するには、プロジェクト アクティビティとして追跡する必要があります。
小さな移行ウェーブではスプレッドシートを使用して項目を追跡できますが、修復タスクが多い大きなウェーブでは複数の項目が生成されます。 Azure DevOps などのツールを使用して、作業項目の作成と優先順位付けを行い、特定のフェーズを移動してスケールアウトを支援できます。他の作業に Azure DevOps を使用しない場合でも、それを使用して修復の問題をトリアージし、移行プロセスのタスクを整理できます。
これらのタスクを作成するときは、それらのタスクが影響するワークロードに接続し直す必要があります。 これにより、修復タスクによって遅延する可能性のあるワークロードを評価できます。 その後、ワークロードの優先順位で作業に優先順位を付けることができます。
一部の問題は、複数のワークロードに影響する可能性があります。 これらは一般に、ホスト、広範な構成、またはランディング ゾーン全体に関する問題を含む項目です。 これらの問題は、修復のために優先される最初の問題である必要があります。
一般的な修復タスク
技術的負債は、企業環境の健全で期待される部分です。 オンプレミス環境に適合したアーキテクチャの決定は、クラウド プラットフォームには適さない場合があります。 いずれの場合も、移行のために資産を準備する一般的な修復タスクが必要になる可能性があります。 以下に例を示します。
- ホストのマイナー アップグレード: 場合によっては、期限切れのホストをレプリケーション前にアップグレードする必要があります。
- ゲスト オペレーティング システムのマイナー アップグレード: レプリケーションの前にオペレーティング システムに修正プログラムを適用するかアップグレードすることがおそらく必要になります。
- サービス レベル アグリーメント (SLA) の変更: バックアップと回復プロセスは、クラウド プラットフォーム上では大幅に変わります。 移行された資産のバックアップ プロセスは、クラウドで必要な SLA を引き続き達成するために変更が必要になる場合があります。
- アプリケーション構成の変更: 移行したアプリケーションでは、依存資産へのネットワーク パスなどの変数の調整、サービス アカウントの変更、または依存 IP アドレスの更新が必要になることがあります。
- ネットワーク パスに対する軽微な変更: ユーザー トラフィックを新しい資産に正しくルーティングするために、ルーティング パターンを変更することが必要になることがあります。 これは新しい資産への実働ルーティングではなく、資産全般への適切なルーティングができるようにするための構成です。
大規模な修復タスク
データセンターが適切に保守、パッチ適用、更新されている場合、修復はほとんど必要ありません。 修復が多い環境は、大規模なエンタープライズによく見られる傾向があります。 これには大幅な IT のダウンサイジングを経てきた組織や従来の管理サービス環境、買収が多い環境下の組織が含まれます。 これらの各環境では、移行作業の大部分を占めるのが修復です。 以下の修復タスクが頻繁に発生したり、移行のスピードや一貫性に悪影響が生じたりする可能性があります。 これが発生する場合は、クラウドの導入とクラウドのガバナンスと同様に、修復を並行する作業とチームに分割します。
- ホストの頻繁なアップグレード: ワークロードの移行を完了するために複数のホストをアップグレードすると、移行チームが遅延する可能性があります。 計画されたリリースに影響を受けるアプリケーションを含める前に、影響を受けるアプリケーションを分離し、修復手順に対処することをお勧めします。
- ゲスト オペレーティング システムの頻繁なアップグレード: 大規模エンタープライズでは、最新でないバージョンの Linux または Windows をサーバーで実行していることがよくあります。 最新でないオペレーティング システムを運用するというセキュリティ リスクとは別に、影響を受けるワークロードの移行を妨げる互換性の問題もあります。 複数の仮想マシン (VM) でオペレーティング システムの修復が必要な場合は、これらの作業を並列のイテレーションに分離してみてください。 一部のアップグレードは、移行プロセスの一環として移行ツールによって完了できます (Azure Migrate と Modernize の Windows Server アップグレード機能など)。
大規模な修復に対処する
小規模なワークロードの修復は簡単な場合があるため、最初の移行ウェーブの対象として小規模なワークロードを選択します。 移行作業に慣れ、より大規模なワークロードへの取り組みを開始すると、修復に時間とコストがかかるようになる可能性があります。 たとえば、5,000 個以上の VM を伴う資産プールがある Windows Server 2003 の移行の場合、修復作業によって移行が数か月の単位で遅延する可能性があります。 このような大規模な修復が必要な場合は、影響を受けるワークロードを移行するための計画を変更することが必要になる場合があります。 このような場合、修復作業の価値を最大化するための最新化アクティビティの方が効率的で生産性が高い場合があります。
判断に役立つ次の質問を使用できます。
- 修復によって影響を受けるすべてのワークロードを特定し、移行バックログに記載されていますか?
- 影響を受けないワークロードについて、移行によって同様の投資収益率 (ROI) が得られますか?
- 影響を受ける資産は、元の移行タイムラインに合わせて修復できますか? タイムライン変更が ROI にどのような影響を与えますか?
- 移行作業と並行して資産を修復することは経済的に実現可能ですか?
前の質問に回答できない場合は、次の方法を検討してください。
- コンテナ化: 一部の資産は、修復せずに、コンテナ化された環境でホストできます。 これにより、好ましいパフォーマンスを下回る可能性があり、セキュリティやコンプライアンスの問題が解決されません。
- オートメーション: ワークロードと修復の要件によっては、DevOps アプローチを使用して新しい資産へのデプロイをスクリプトにする方が有益な場合があります。
- 再構築: 修復コストとビジネス価値が同等に高い場合は、ワークロードは再構築または再設計に適しています。