移行前に資産を修復する

  • [アーティクル]

移行の評価プロセス中、チームは資産と選択したクラウド プロバイダーが非互換になる可能性があるあらゆる構成を特定します。 "修復" は、あらゆる非互換性が確実に解決するようにするための移行プロセスにおけるチェックポイントです。 この記事は一般的な修復タスクを参考としていくつか説明したもので、修復が賢明な投資であるかどうかを判断するのに役立ちます。

一般的な修復タスク

どのような企業環境にも技術的な負債が存在しますが、これは正常であり、予想されているものです。 オンプレミス環境に適合したアーキテクチャの決定は、クラウド プラットフォームには適さない場合があります。 いずれの場合も、移行のために資産を準備する一般的な修復タスクが必要になる可能性があります。 以下に例を示します。

  • ホストのマイナー アップグレード: 場合によっては、期限切れのホストをレプリケーション前にアップグレードする必要があります。
  • ゲスト OS のマイナー アップグレード: レプリケーションの前に OS に修正プログラムを適用するかアップグレードすることがおそらく必要になります。
  • SLA の変更: バックアップと回復は、クラウド プラットフォーム上では大幅に変わります。 クラウド上で確実に機能を継続させるために、資産のバックアップ プロセスに変更を加えることが必要な場合があります。
  • PaaS の移行: 場合によっては、導入を加速するためにデータ構造やアプリケーションの PaaS へのデプロイが必要になることがあります。 PaaS へのデプロイ用にソリューションを準備するために、軽微な変更が必要になります。
  • PaaS コードの変更: カスタム アプリケーションの場合、PaaS に対応させるためにコードの軽微な変更が必要になることは珍しくありません。 例として、ローカル ディスクに書き込むメソッドや、メモリ内セッション状態の使用などがあります。
  • アプリケーション構成の変更: 移行したアプリケーションでは、依存資産へのネットワーク パスなどの変数の変更、サービス アカウントの変更、または依存 IP アドレスの更新が必要になることがあります。
  • ネットワーク パスに対する軽微な変更: ユーザー トラフィックを新しい資産に正しくルーティングするために、ルーティング パターンを変更することが必要になることがあります。

    Note

    これは新しい資産への実働ルーティングというよりは、資産全般への適切なルーティングができるようにするための構成です。

大規模な修復タスク

データセンターが適切に保守、パッチ適用、更新されていれば、修復はほとんど必要でない可能性が高くなります。 修復が多い環境は、大規模なエンタープライズによく見られる傾向があります。 これには大幅な IT のダウンサイジングを経てきた組織や従来の管理サービス環境、買収が多い環境なども含まれます。 これらの種類の環境では、移行作業の大部分が修復に費やされます。 以下の修復タスクが頻繁に発生したり、移行のスピードや一貫性に悪影響が生じたりする可能性があります。 これが発生する場合は、修復を並行する作業とチームに分割します (クラウドの導入とクラウドのガバナンスと同様)。

  • ホストの頻繁なアップグレード: ワークロードの移行を完了するために多数のホストをアップグレードする必要がある場合、移行チームが遅延する可能性があります。 計画されたリリースに影響を受けるアプリケーションを含める前に、影響を受けるアプリケーションを特定し、修復手順に対処することをお勧めします。
  • ゲスト OS の頻繁なアップグレード: 大規模エンタープライズでは、最新でないバージョンの Linux または Windows をサーバーで実行していることがよくあります。 最新でない OS を運用することの明らかなセキュリティ リスクとは別に、影響を受けるワークロードの移行を妨げる互換性の問題もあります。 多くの VM で OS の修復が必要な場合は、これらの作業を分割して並行する反復作業にしてみてください。
  • 大幅なコードの変更: 以前のカスタム アプリケーションでは、PaaS へのデプロイ用に準備するために大幅な変更が必要になる場合があります。 このような場合は、移行バックログからそれらを完全に削除し、別のプログラムで管理するようにしてみてください。

意思決定フレームワーク

小規模なワークロードの修復は簡単な場合があるため、最初の移行の対象として小規模なワークロードを選択します。 移行作業に慣れ、より大規模なワークロードへの取り組みを開始すると、修復に時間とコストがかかるようになる可能性があります。 たとえば、5,000 個以上の VM 資産プールがある Windows Server 2003 の移行の場合、修復作業によって移行が数か月の単位で遅延する可能性があります。 このような大規模な修復が必要な場合に意思決定ガイドとして役立つ質問を以下に示します。

  • 修復によって影響を受けるすべてのワークロードを特定し、移行バックログに記載されていますか?
  • 影響を受けないワークロードについて、移行によって同様の投資収益率 (ROI) が得られますか?
  • 影響を受ける資産は、元の移行タイムラインに合わせて修復できますか? タイムラインの変更によって ROI にどのような影響がありますか?
  • 移行作業と並行して資産を修復することは経済的に実現可能ですか?
  • スタッフには移行と修復を行う十分な処理能力がありますか? 一方または両方のタスクを実行するためにパートナーが関与する必要がありますか?

前の質問に回答できない場合は、次の方法を検討してください。

  • コンテナー化。 一部の資産は、修復せずに、コンテナー化された環境でホストできます。 これにより、好ましいパフォーマンスを下回る可能性があり、セキュリティやコンプライアンスの問題が解決されません。
  • オートメーション。 ワークロードと修復の要件によっては、DevOps アプローチを使用して新しい資産へのデプロイをスクリプトにする方が有益な場合があります。
  • Rebuild。 修復コストが非常に高く、ビジネス価値が同等に高い場合は、ワークロードはリビルドまたはリアーキテクトに適しています。

次のステップ

修復が完了すると、レプリケーション アクティビティの準備が整います。

資産をレプリケートする