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

Last reviewed 2023-11-29 UTC

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

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

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

評価

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

完全な評価を行う

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

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

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

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

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

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

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

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

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

  • ワークロードがネットワークへの接続を失った場合、どうなりますか？
  • ワークロードは、停止後に作業を中断したところから再開できますか？
  • ワークロードまたはその依存関係のパフォーマンスが不十分な場合はどうなりますか？
  • アーキテクチャに同じ ID を持つ 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 環境に統合されたモニタリング、ロギング、アラートをサポートしています。

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

移行を管理する

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

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

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

次のステップ