Google Cloud への移行: 移行計画の検証に関するベスト プラクティス

Last reviewed 2024-11-08 UTC

このドキュメントでは、ワークロードを Google Cloud に移行する計画を検証するためのベスト プラクティスについて説明します。このドキュメントには、移行計画の検証に関するすべてのベスト プラクティスが記載されているわけではありませんし、成功を保証するものではありません。それでも、移行計画の潜在的な変更と改善に関する議論を活性化するのに役立ちます。

このドキュメントでは、オンプレミス環境、非公開のホスティング環境、または別のクラウド プロバイダから Google Cloud への移行を計画する際に役立つ情報を提供します。また、移行を検討している場合に、移行の概要を把握するうえでも、このドキュメントが役立ちます。

このドキュメントは、Google Cloud への移行に関する次の複数のパートからなるシリーズの一部です。

評価

ワークロードと環境の完全な評価を行うと、ワークロードと環境を深く理解するのに役立ちます。この点を理解しておくと、Google Cloud への移行中や移行後に発生する問題のリスクを最小限に抑えることができます。

完全な評価を行う

評価フェーズの手順に進む前に、ワークロードと環境の評価を完了してください。完全な評価を行うために、しばしば見落とされがちな次の項目を考慮してください。

  • インベントリ: 移行するワークロードのインベントリが最新であり、評価が完了していることを確認します。たとえば、評価に使用するソースデータの鮮度と信頼性、データに存在する可能性があるギャップを考慮に入れます。

  • ダウンタイム: ダウンタイムを許容できるワークロードと、そうしたダウンタイムを許容できる最大時間を評価します。ダウンタイムがゼロまたはほぼゼロの状態でワークロードを移行することは、ダウンタイムを許容できるワークロードを移行する場合よりも困難です。ダウンタイムなしで移行するには、移行するワークロードごとに冗長性を設計して実装する必要があります。また、こうした冗長インスタンスを取りまとめる必要もあります。

    ワークロードが許容できるダウンタイムの長さを評価するときは、ゼロ ダウンタイム移行によるビジネス上のメリットが、追加された移行の複雑さよりも大きいかどうかを評価します。可能な場合は、ワークロードにゼロ ダウンタイムの要件を作成しないでください。

  • クラスタリングと冗長性: どのワークロードクラスタリングと冗長性をサポートしているかを評価します。ワークロードがクラスタリングと冗長性をサポートしている場合、移行元の環境や移行先の環境など、異なる環境にまたがっても、そのワークロードの複数のインスタンスをデプロイできます。クラスタ化された冗長なデプロイでは、制限付きの介入でワークロード間の調整が可能になるため、移行が簡素化される可能性があります。

  • 構成の更新: ワークロードの構成を更新する方法を評価します。たとえば、移行する各ワークロードの構成に更新を配信する方法を検討してください。ワークロードを移行先の環境に移行するときに、ワークロードの構成の更新が必要になる場合があるため、この検討は移行を成功させるためには不可欠です。

  • 複数の評価レポートを生成する: 評価フェーズで、さまざまなシナリオを考慮するために複数の評価レポートを生成すると便利な場合があります。たとえば、ピーク時やオフピーク時など、ワークロードのさまざまな負荷プロファイルを考慮するレポートを生成できます。

ワークロードでサポートされる障害モードを評価する

例外的な状況でワークロードがどのように動作するかを知ることは、復旧できない条件にワークロードを晒さないようにするのに役立ちます。評価の一環として、ワークロードでサポートされている、自動的に復元可能な障害モードとその影響と、ユーザーの介入が必要な障害モードに関する情報を収集します。たとえば、考えられる障害モードに関する次のような質問から始めることができます。

  • ワークロードがネットワークへの接続を失った場合、どうなりますか？
  • ワークロードは、停止後に作業を中断したところから再開できますか？
  • ワークロードまたはその依存関係のパフォーマンスが不十分な場合はどうなりますか？
  • アーキテクチャに同じ識別子を持つ 2 つのワークロードがある場合はどうなりますか？
  • スケジュールされたタスクが実行されなかった場合はどうなりますか？
  • 2 つのワークロードが同じリクエストを処理する場合はどうなりますか？

サポートされていない障害モードの別の原因が、移行計画自体である可能性もあります。特定の条件の成功に依存するステップが移行計画に含まれているかどうか、条件が満たされていない場合には不測の事態が含まれているかどうかを確認します。このようなタイプの条件を含む計画は、計画自体が失敗するか、移行中に個々のコンポーネントが失敗する可能性があることを示します。

これらの障害モードとその影響を評価した後、障害をシミュレートして、障害モードをエミュレートした障害を挿入することで、影響の少ない環境で検出結果を検証します。たとえば、ワークロードがネットワーク接続の損失後に自動的に回復するように設計されている場合は、接続を強制的に中断して復元することにより自動回復を検証します。

データ処理パイプラインを評価する

ワークロード評価では、次の質問に答えられる必要があります。

  • リソースは移行に適したサイズになっていますか？
  • ワークロードに必要なデータの移行に必要な時間はどれくらいですか？
  • 移行先の環境はデータの全量に対応できますか？
  • 需要の急増や、特定の期間に生成されるデータ量の急増に対応する必要がある場合、ワークロードはどのように動作しますか？
  • ワークロードが急増するワークロードやデータ量が急増する場合、レイテンシの増加やレスポンスの遅延など、悪影響はありますか？
  • ワークロードが開始した後、期待されるパフォーマンス レベルに達するまでに時間が必要ですか？

この評価の結果はしばしば、ワークロードが満たす需要と所定の時間枠内でワークロードが生成するデータのモデルになります。このようなモデルを生成するためにデータポイントを収集する際は、それらのデータポイントがピーク時と非ピーク時の間で顕著に異なる可能性があることを考慮してください。モニタリングの方法と対象の詳細については、書籍『SRE サイトリライアビリティ エンジニアリング』でサービスレベル目標をご覧ください。

移行する各ワークロードを更新、デプロイできることを確認する

移行中は、移行するワークロードの一部の更新が必要になることがあります。たとえば、問題の修正をロールアウトしたり、問題の原因となっている最近の変更をデプロイしたりする必要がある場合があります。移行するワークロードごとに、変更を適用してデプロイできることを確認します。たとえば、ソースコードのあるワークロードを移行する場合は、そのソースコードにアクセスできることと、必要に応じてソースコードをビルド、パッケージ化、デプロイできることを確認します。

移行には、変更を適用およびデプロイできないワークロード（独自仕様のソフトウェアなど）が含まれる場合があります。このシナリオでは、移行計画をリファクタリングして、これらのワークロードの移行後に発生する可能性のある問題を軽減するための追加の作業を検討します。

ネットワーク インフラストラクチャを評価する

機能的なネットワーク インフラストラクチャは移行に必須です。ネットワーク インフラストラクチャは移行ツールの一部として使用できます。たとえば、移行計画に従って、ロードバランサと DNS サーバーを使用してトラフィックを転送できます。

移行中の問題を回避するには、ネットワーク インフラストラクチャを評価し、それが移行をどの程度サポートできるかを評価することが重要です。たとえば、次のようなロード バランシング インフラストラクチャに関する質問の検討から始めることができます。

  • ロードバランサを再構成するとどうなりますか？
  • 更新された構成が有効になるまでにどのくらいの時間がかかりますか？
  • ダウンタイムなしで移行する場合、更新された構成が導入される前にトラフィックが急増するとどうなるでしょうか。

ロード バランシング インフラストラクチャに関する質問について検討したら、次に挙げる DNS インフラストラクチャに関する質問を検討します。

  • ターゲット環境を指すようにどの DNS レコードを更新する必要がありますか。また、いつ更新する必要がありますか？
  • どのクライアントがそれらの DNS レコードを使用していますか？
  • DNS レコードの更新の有効期間（TTL）はどのように構成されていますか？
  • 移行の間、DNS レコードの TTL を最小に設定できますか？
  • DNS クライアントは、更新する DNS レコードの TTL を重視していますか？たとえば、移行用に構成した TTL を無視するクライアント側の DNS キャッシュがアプリケーションにありますか？
  • 移行が完了した後も、移行元の環境をターゲットとするトラフィックが検出されます。

移行計画

移行を慎重に計画することで、移行中と移行後の問題を回避できます。また、計画があれば、予期しないタスクに対処する作業の回避に役立ちます。

移行計画の各ステップに対するロールバック戦略を策定する

移行中に、実行する移行計画のステップによって、予期しない問題が発生する可能性があります。これらの問題から確実に復旧できるように、移行計画の各ステップに対するロールバック戦略を準備してください。停止時に時間がかかるのを防ぐには、次のようにします。

  • 各ロールバック戦略を定期的にレビューしてテストし、ロールバック戦略が機能することを確認します。
  • 移行ステップごとに、最大許容実行時間を設定します。この許容実行時間が終わると、チームは移行ステップのロールバックを開始します。

移行計画の各ステップでロールバック戦略を準備している場合でも、ステップの一部が中断される可能性はあります。中断を伴う可能性があるステップをロールバックすると、データ損失など、なんらかの損失が発生する場合があります。どのステップに中断を伴う可能性があるかを評価します。

移行計画のいずれかのステップを自動化した場合は、自動化が失敗した場合に各自動ステップに対して事前に計画した手順があることを確認します。ロールバック戦略と同様に、事前に計画した各手順を定期的に審査してテストします。

移行の一環として通信チャネルを設定する場合は、環境にアクセスできなくならないように、障害から復旧するためのバックアップ チャネルをプロビジョニングします。たとえば、Partner Interconnect を設定する場合は、プロビジョニング中および構成中に問題が発生した場合に備えて、公共のインターネット経由でバックアップ アクセスを設定することも、移行中にできます。

段階的に展開してデプロイするように計画する

移行中に発生する可能性のある課題と問題の範囲を狭めるには、大規模な変更を避け、変更を段階的にデプロイするように移行計画を設計します。たとえば、段階的なデプロイと構成変更を計画します。

段階的な展開を計画している場合は、変更の適用によって発生する予期せぬ問題のリスクを軽減するために、変更の数とサイズを最小限に抑えます。最初の小さなロールアウトの問題を特定して解決したら、同様の変更を行う後続のロールアウトを大規模に実施できます。

開発チームと運用チームにアラートを送信する

移行中に発生する可能性のある問題の影響を軽減するには、移行するワークロードを担当するチームに注意を喚起します。また、移行元と移行先の両方の環境のインフラストラクチャを担当するチームにも注意を喚起します。

チームが異なるタイムゾーンで作業している場合は、以下の点を確認します。

  • チームは、単一のシフトでは問題を解決できない可能性があるため、これらのタイムゾーンに適切に対処し、連続した複数のシフトで対応している。
  • チームは、直面する可能性のある問題に関する詳細な情報を収集する準備ができている。収集する内容は、次のシフトのエンジニアが前のシフトの内容とその理由を十分に理解するのに役立つ。
  • チーム内の特定の担当者が、特定のシフトについて責任を持ちます。

移行先の本番環境から概念実証のリソースを削除する

評価の一環として、移行先の環境を使用してテストと概念実証をホストしている可能性があります。移行前に、テストと概念実証のために作成したリソースを、移行先の環境の本番環境から削除します。

移行中に発生する可能性のある問題に関する情報を収集するのに役立つ可能性があるため、移行が進行している間、移行先の環境の非本番環境領域にリソースを保持できます。たとえば、移行後に本番環境ワークロードに影響を与える問題を診断するには、本番環境ワークロードの構成とデータログを、概念実証とテストの構成ログとデータログと比較できます。

移行が完了し、移行先の環境が想定どおりに動作していることを確認したら、移行先の環境の非本番環境領域のリソースを削除できます。

移行元の環境を安全に利用停止するための基準を定義する

2 つの環境を無期限に運用することによるオーバーヘッド コストを回避するには、移行元の環境を安全に利用停止するために満たす必要のある次のような条件を定義します。

  • バックアップ、高可用性、障害復旧メカニズムを含むすべてのワークロードが移行先の環境に正常に移行される。
  • 移行先の環境で移行されたデータには、一貫性があり、アクセス可能で、使用可能です。
  • 移されたデータの正確性と完全性が、定義された基準を満たしている。
  • 移行元の環境に残っているリソースは、移行スコープ外のワークロードの依存関係ではない。
  • 移行先の環境でのワークロードのパフォーマンスが SLA 目標を達成している。
  • モニタリング システムは、移行元の環境に送信されるネットワーク トラフィックがないことを報告する。
  • 定義した期間、移行先の環境で問題なくワークロードを実行した場合、移行元の環境へのフォールバックが不要になると確信できる。

運用

移行中に移行元の環境と移行先の環境を効率的に管理するには、運用プロセスも同様に設計する必要があります。

環境をモニタリングする

移行元と移行先の環境の動作を確認し、問題が発生した場合に診断できるようにするには、次の設定を行います。

  • シナリオに役立つ指標を収集するためのモニタリング システム。
  • ワークロードや環境の他のコンポーネントによって実行されるオペレーションのフローをモニタリングするためのロギング システム。
  • 問題となるイベントが発生する前に警告を発行するアラート システム。

Google Cloud Observability は、Google Cloud 環境に統合されたモニタリング、ロギング、アラートをサポートしています。

ワークロードとその依存関係は複数の環境にわたるため、異なる環境ごとに複数のモニタリング ツールとアラートツールの使用を検討する必要がある場合があります。ワークロードをサポートするモニタリング ポリシーとアラート ポリシーを移行するタイミングを検討してください。たとえば、特定のサーバーがダウンした際に移行元の環境がアラートするように構成されている場合、そのサーバーを意図的にダウンした際にアラートがトリガーされます。アラート トリガーは想定どおりですが、役に立つ挙動ではありません。移行の一環として、移行元の環境のアラートを継続的に調整し、移行先の環境のために再構成する必要があります。

移行を管理する

移行を管理するために、移行のパフォーマンスを確認して、移行の完了後に振り返りに利用できる情報を収集します。情報を収集したら、それを使用して移行のパフォーマンスを分析し、環境の改善の可能性がある点に関するデータポイントを準備します。

たとえば、移行の管理を計画し始めるには、次のことを検討してください。

  • 移行計画の各ステップにどれくらいの時間を要しましたか？
  • 移行計画に、想定よりも時間がかかるステップがありましたか？
  • 不足している手順やチェックはありましたか？
  • 移行中に有害事象が発生しましたか？

次のステップ

寄稿者

著者: Marco Ferrari | クラウド ソリューション アーキテクト