Google Cloud への移行: 手動デプロイから、自動かつコンテナ化されたデプロイへの移行

このドキュメントは、クラウドネイティブ ツールと Google Cloud マネージド サービスを使用して、手動デプロイから自動かつコンテナ化されたデプロイへの移行パスを計画、設計する際に役立ちます。

このドキュメントは、Google Cloud への移行に関する複数のパートからなるシリーズの一部です。シリーズの概要については、Google Cloud への移行: 移行パスの選択をご覧ください。

このドキュメントはシリーズの一部です。

このドキュメントは、デプロイ プロセスのモダナイズを計画している場合や、手動およびレガシーのデプロイ プロセスを自動かつコンテナ化されたデプロイと Infrastructure as Code(IaC)に移行する場合に役立ちます、また、移行について検討している場合、その概要を把握するためにも利用できます。

この移行を開始する前に、移行の範囲と現在のデプロイ プロセスのステータスを評価し、期待する効果と目標を設定する必要があります。現在のワークロードのデプロイ方法に応じて開始点を選択します。

  • 手動でワークロードをデプロイしている。
  • 構成管理(CM)ツールを使用してワークロードをデプロイしている。

手動でのデプロイから完全に自動かつコンテナ化されたデプロイへ直接移行することは困難です。そこで、次の移行ステップをおすすめします。

  1. コンテナ オーケストレーション ツールを使用してデプロイする
  2. 自動的にデプロイする
  3. IaC パターンを適用してデプロイする

次の図は、この移行のパスを表しています。

手動デプロイから自動デプロイに移行するための移行パス。

各移行ステップでは、Google Cloud への移行: スタートガイドで定義されている次のフェーズに従います。

  1. ワークロードの評価と検出。
  2. 基盤の計画と構築。
  3. ワークロードのデプロイ。
  4. 環境とワークロードの最適化。

次の図は、各ステップの移行フェーズを示しています。

4 フェーズの移行パス

この移行パスに沿って進めるのが理想的ですが、特定の事例で費用より次のステップに移るメリットの方が大きい場合は、移行プロセスを途中で中止することもできます。たとえば、ワークロードを自動的にデプロイする予定がない場合は、デプロイ後コンテナ オーケストレーション ツールを使用して移行プロセスを中断できます。後日移行を再開する場合は、このドキュメントを再度ご確認いただけます。

次の移行ステップに進む過程で、同時に異なるデプロイ プロセスを使用することがあります。実際、すべてのワークロードに対して選択するデプロイ オプションを 1 つだけにする必要はありません。たとえば、コンテナ オーケストレーション ツールでワークロードをデプロイしながら、IaC パターンを適用してインフラストラクチャを管理するというハイブリッド環境にすることもできます。

コンテナ オーケストレーション ツールへ移行する

手動デプロイから移行する際、最初に行うステップの 1 つは、コンテナ オーケストレーション ツールを使用してワークロードをデプロイすることです。このステップでは、Kubernetes などのコンテナ オーケストレーション ツールを使用して、コンテナ化されたワークロードを処理するデプロイ プロセスを設計し、実装します。

ワークロードがまだコンテナ化されていない場合は、コンテナ化にかなりの労力がかかります。すべてのワークロードがコンテナ化に適しているわけではありません。クラウド ネイティブでないワークロードやコンテナ化の準備ができていないワークロードをデプロイする場合は、ワークロードをコンテナ化する意味がないこともあります。技術上またはライセンス上の理由からコンテナ化がサポートされていないワークロードもあります。

ワークロードを評価して検出する

移行の範囲を設定するには、まず、現在作成してデプロイしているアーティファクト、および他のシステムやアーティファクトへの依存関係のインベントリが必要です。このインベントリを構築するには、現在のアーティファクトの作成プロセスとデプロイ プロセスを設計、実装したチームの専門知識を活用する必要があります。Google Cloud への移行: ワークロードの評価と検出ドキュメントで、移行中の環境の評価方法とアプリのインベントリの構築方法について説明します。

アーティファクトごとに、現在のテスト カバレッジを評価する必要があります。次のステップに進む前に、すべてのアーティファクトに適切なテスト カバレッジが必要です。各アーティファクトを手動でテストして検証する必要がある場合は、自動化のメリットはありません。テストドリブンな開発など、テストに高い重要性が置かれている手法を採用してください。

手順を評価する際は、アーティファクトの異なるバージョンが本番環境にいくつあるかを考慮してください。たとえば、アーティファクトの最新バージョンがサポートの必要なインスタンスよりも新しいバージョンである場合は、両方のバージョンをサポートするモデルを設計する必要があります。

また、コードベースの管理に使用するブランチ戦略についても検討してください。ブランチ戦略は評価が必要なコラボレーション モデルの一部にすぎず、さらにチーム内外で幅広いコラボレーション プロセスを評価する必要があります。たとえば、柔軟なブランチ戦略を採用しているものの、コミュニケーション プロセスに適用していない場合、チームの効率が低下する可能性があります。

この評価フェーズでは、現在のデプロイ プロセスよりも効率的でコンテナ化に適したアーティファクトを作成する方法も決定します。効率を改善する方法の 1 つは、次の点を評価することです。

  • 共通点: アーティファクトの共通点を評価します。たとえば、共通のライブラリやその他のランタイム依存関係がある場合は、1 つのランタイム環境に統合することを検討してください。
  • ランタイム環境の要件: ランタイム環境を合理化して分散を減らすことができるかどうかを評価します。たとえば、すべてのワークロードの実行について異なるランタイム環境を使用している場合は、メンテナンスの負担を軽減するため、共通のベースから開始することを検討してください。
  • 不要なコンポーネント: アーティファクトに不要な部分が含まれているかどうかを評価します。たとえば、デバッグツールやトラブルシューティング ツールなど、厳密には必要のないユーティリティ ツールがある場合があります。
  • 構成とシークレットの挿入: ランタイム環境の要件に従って、アーティファクトの構成方法を評価します。たとえば、構成を挿入する現在のシステムがコンテナ化された環境をサポートしていない場合があります。
  • セキュリティ要件: コンテナのセキュリティ モデルが要件を満たしているかどうかを評価します。たとえば、コンテナ化された環境のセキュリティ モデルは、スーパー ユーザー権限、システム リソースへの直接アクセス、単一テナンシーなどのワークロードの要件と競合する場合があります。
  • デプロイ ロジック要件: 高度なデプロイ ロジックを実装する必要があるかどうかを評価します。たとえば、カナリア デプロイ プロセスを実装する必要がある場合は、コンテナ オーケストレーション ツールでサポートされているかどうかを判断できます。

基盤を計画して構築する

次に、Google Cloud のインフラストラクチャとサービスのプロビジョニングと構成をして、Google Cloud のデプロイ プロセスをサポートします。Google Cloud への移行: 基盤の構築ドキュメントに、基盤の構築方法に関するガイダンスが記載されています。

Google Cloud の組織フォルダプロジェクトを作成する場合は、デプロイ プロセスが複数の環境で共有されていることを考慮してください。機能指向の階層またはアクセス指向のきめ細かい階層をおすすめします。これらの階層により、リソースの管理に必要な柔軟性が得られ、開発やテストに複数の環境を使用できるようになります。

ユーザー ID とサービス ID を作成する場合は、うまく分離するために、デプロイ プロセスの各ステップで少なくとも 1 つのサービス アカウントが必要です。たとえば、アーティファクトの生成ステップとリポジトリへの格納の管理ステップをプロセスで実行する場合、少なくとも 2 つのサービス アカウントが必要です。デプロイ プロセス用の開発環境とテスト環境をプロビジョニングして構成するのであれば、より多くのサービス アカウントを作成する必要が生じる場合もあります。環境ごとに異なるサービス アカウントのセットがある場合は、環境を互いに独立させます。この構成ではインフラストラクチャの複雑さと運用チームの負担が増しますが、デプロイ プロセスへの変更ごとに個別にテストして検証できるという柔軟性を得られます。

また、サービスとインフラストラクチャを次のようにプロビジョニングして構成し、コンテナ化されたワークロードをサポートする必要があります。

  • Container Registry などのコンテナ イメージを格納するレジストリを設定します。このレジストリと関連するメンテナンス タスクを分離するには、専用の Google Cloud プロジェクトにレジストリを設定します。
  • ワークロードのサポートに必要な Kubernetes クラスタをプロビジョニングして構成します。現在の環境と目標に応じて、Google Kubernetes Engine(GKE)Anthos などのサービスを使用できます。
  • ステートフル ワークロードの永続ストレージをプロビジョニングして構成します。詳細については、Google Kubernetes Engine ストレージの概要をご覧ください。

コンテナ オーケストレーション ツールを使用することで、新しいワークロードをデプロイするときにインフラストラクチャをプロビジョニングする必要がなくなります。たとえば、クラスタ オートスケーラーを使用して、必要に応じて GKE クラスタのサイズを自動的に変更できます。

コンテナ オーケストレーション ツールを使用してアーティファクトをデプロイする

このステップの評価フェーズと基盤フェーズで収集した要件に基づいて、次の操作を行います。

  • ワークロードをコンテナ化する。
  • コンテナ化されたワークロードを処理するデプロイ手順を実装する。

ワークロードのコンテナ化は簡単なタスクではありません。以下は、ワークロードをコンテナ化するために適用および拡張する必要がある一般的なアクティビティのリストです。目標は、ネットワーキングとトラフィック管理、永続ストレージ、シークレットと構成のインジェクション、フォールト トレランスの要件など、独自のニーズを満たすことです。このドキュメントでは、ベースとして使用するコンテナ イメージのセットの構築と、ワークロード用のコンテナ イメージのセットの構築という、2 つのアクティビティについて説明します。

まず、アーティファクトの作成を自動化します。これにより、新しいデプロイごとに新しいイメージを手動で生成する必要がなくなります。アーティファクトの構築プロセスは、ソースコードが変更されるたびに自動的にトリガーされるため、各変更についてすぐにフィードバックを得られます。

各イメージを生成するには、次のステップを行います。

  1. イメージを構築する。
  2. テストスイートを実行する。
  3. イメージをレジストリに格納する。

たとえば、Cloud Build を使用してアーティファクトを構築し、テストスイートを実行します。テストが成功すれば、結果を Container Registry に格納します。

また、アーティファクトを識別するためのルールと規則を確立する必要があります。イメージを作成するときに、各イメージにラベルを付けて、プロセスを繰り返し実行できるようにします。たとえば、リリースを作成するときにコンテナ イメージにタグを付けるセマンティック バージョニングを使用して、リリースを識別する規則が一般的です。リリース前にまだ作業が必要なイメージを生成する場合は、識別子を使用して、コードベース内のイメージ生成の箇所に、イメージを結び付けることができます。たとえば、Git リポジトリを使用している場合は、commit ハッシュを、リポジトリのメインブランチに commit を push したとき作成した、対応するコンテナ イメージの識別子として使用できます。

このステップの評価フェーズでは、アーティファクト、その共通点、およびランタイム要件に関する情報を収集しました。この情報を使用して、ベースコンテナ イメージのセット、およびワークロード用の別のイメージのセットを設計および構築できます。ベースイメージを開始点として使用して、ワークロードのイメージを構築します。ベースイメージのセットは、サポート対象外のランタイム環境の急増を避けるために厳密に制御およびサポートする必要があります。

ベースイメージからコンテナ イメージを生成する場合は、各イメージ内のワークロードだけでなく、イメージをカバーするようにテストスイートを拡張してください。InSpecServerSpecRSpec などのツールを使用して、ランタイム環境に対してコンプライアンス テストスイートを実行できます。

このようなコンテナ イメージを自動的に生成するワークロードのコンテナ化と手順の実装が完了したら、デプロイ手順を実装して、コンテナ オーケストレーション ツールを使用します。評価フェーズでは、収集したデプロイ ロジック要件に関する情報を使用して、詳細なデプロイ手順を設計します。コンテナ オーケストレーション ツールを使用すると、手動で実装する代わりに、提供されたメカニズムを使用してデプロイ ロジックの作成に集中できます。

デプロイ手順を設計および実装する際は、ワークロードに構成ファイルとシークレットを挿入する方法と、ステートフル ワークロードのデータを管理する方法を検討してください。構成ファイルとシークレットの挿入は、不変のアーティファクトの生成に役立ちます。不変のアーティファクトをデプロイすると、次のことができるようになります。

  • たとえば、開発環境にアーティファクトをデプロイできます。次に、それらをテストして検証した後、品質保証環境に移行します。最終的には、本番環境に移行します。
  • 同じアーティファクトが複数のテストと検証作業を経ることになるため、本番環境で問題が発生する可能性が低くなります。

ワークロードがステートフルである場合は、データ用に必要な永続ストレージをプロビジョニングして構成することをおすすめします。Google Cloud には、次のオプションがあります。

デプロイするアーティファクトを自動的に生成できる場合は、ワークロードのデプロイに使用するツール用のランタイム環境を設定できます。デプロイツール用のランタイム環境を制御するには、その環境を Cloud Build のビルドとして設定し、アーティファクトを環境でデプロイする唯一の手段として、そのビルドを使用します。Cloud Build を使用すると、マシン上にランタイム環境を設定する各演算子は不要になります。ビルド構成のソースコードを調べることで、ランタイム環境とそのコンテンツを作成する手順をすぐに監査できます。

環境を最適化する

デプロイ プロセスを実装したら、コンテナ オーケストレーション ツールを使用して、デプロイ プロセスの最適化を開始できます。Google Cloud への移行: スタートガイドに、環境の最適化の方法に関するガイダンスが記載されています。

この最適化のイテレーションの要件は次のとおりです。

  • 必要に応じてモニタリング システムを拡張する。
  • テスト カバレッジを拡大する。
  • 環境のセキュリティを強化する。

モニタリング システムを拡張して、新しいアーティファクトの作成、デプロイ手順、すべての新しいランタイム環境をカバーします。

プロセスをできるだけ効果的にモニタリング、自動化、コード化するには、テスト カバレッジを広げることをおすすめします。評価フェーズで、少なくとも最小限のエンドツーエンドのテスト カバレッジを確保しています。最適化フェーズでは、より多くのユースケースに対応できるようにテストスイートを拡張できます。

最後に、環境のセキュリティを強化するには、Binary Authorization を構成して、署名付きイメージのセットのみがクラスタにデプロイされるようにします。また、Container Analysis を有効にして、Container Registry に保存されているコンテナ イメージの脆弱性をスキャンすることもできます。

デプロイの自動化へ移行する

コンテナ オーケストレーション ツールへ移行したら、完全なデプロイ自動化に移行し、アーティファクトの作成とデプロイの手順を拡張してワークロードを自動的にデプロイできます。

ワークロードを評価して検出する

以前の評価に基づき、次のデプロイ プロセスの要件に焦点を当てます。

  • 手動の承認ステップ: デプロイ手順で手動のステップをサポートする必要があるかどうかを評価します。
  • 時間あたりのデプロイ ユニット数: サポートする必要がある時間あたりのデプロイ ユニット数を評価します。
  • 新しいデプロイが必要となる要因: どの外部システムがデプロイ手順に関わるかを評価します。

手動のデプロイ手順をサポートする必要がある場合でも、手順を自動化できないわけではありません。この場合、手順の各ステップを自動化し、手動の承認ゲートを適切に配置します。

1 日または 1 時間ごとに多くのデプロイをサポートすることは、1 か月または 1 年ごとに数回のデプロイをサポートするよりも複雑です。ただし、頻繁にデプロイしないと、問題に対応する場合および、ワークロードに新機能を導入する場合のアジリティと能力が低下する可能性があります。このため、完全に自動化されたデプロイ手順を設計して実装する前に、期待と目標を設定することをおすすめします。

また、ランタイム環境で新しいデプロイをトリガーする要因も評価します。たとえば、新しい各リリースを開発環境にデプロイする場合があります。しかし、リリースの品質保証環境へのデプロイは、特定の品質基準を満たしている場合のみとなります。

基盤を計画して構築する

前の手順で構築した基盤を拡張するには、自動デプロイ手順をサポートするようにサービスをプロビジョニングして構成します。

ランタイム環境ごとに、デプロイ手順をサポートするために必要なインフラストラクチャを設定します。たとえば、開発環境、品質保証環境、本番前環境、本番環境においてデプロイ手順をプロビジョニングして構成すると、手順の変更を柔軟にテストできます。ただし、単一のインフラストラクチャを使用してランタイム環境をデプロイすると、管理は簡単になりますが、手順を変更する必要がある場合の柔軟性は低下します。

サービス アカウントとロールをプロビジョニングする際には、責任を共有しない専用のサービス アカウントを作成して、環境とワークロードを分離することを検討してください。たとえば、異なるランタイム環境で同じサービス アカウントを再利用しないでください。

完全に自動化された手順でアーティファクトをデプロイする

このフェーズでは、承認ステップ以外は手動による操作なしでアーティファクトをデプロイするように、デプロイ手順を構成します。

Spinnaker などのツールを使用すると、この移行ステップの評価フェーズで収集した要件に従って、自動デプロイ手順を実装できます。

アーティファクトごとに、各デプロイ手順で次のタスクを行う必要があります。

  1. アーティファクトをターゲット ランタイム環境にデプロイする。
  2. デプロイされたアーティファクトに構成ファイルとシークレットを挿入する。
  3. 新しくデプロイされたアーティファクトに対して、コンプライアンス テストスイートを実行する。
  4. アーティファクトを本番環境に昇格させる。

デプロイ手順では、要件に応じて新しいデプロイをトリガーするインターフェースが必ず提供されるようにしてください。

この手順の一部に短いフィードバック ループが設計されているため、自動デプロイ手順を実装する際には、コードレビューが必須になります。たとえば、何のレビューも通過しないまま変更内容を本番環境にデプロイすると、本番環境の安定性と信頼性に影響します。レビューされていない変更、不正や悪意が認められる変更は、サービス停止の原因となる可能性があります。

環境を最適化する

デプロイ手順を自動化した後、最適化のイテレーションをもう一度実行できます。このイテレーションの要件は次のとおりです。

  • モニタリング システムを拡張して、自動デプロイ手順をサポートするインフラストラクチャをカバーする。
  • より高度なデプロイ パターンを実装する。
  • ブレークグラス手順を実装する。

効果的なモニタリング システムにより、環境をさらに最適化できます。環境の動作を測定すると、パフォーマンスに支障をきたしているボトルネックやその他の問題(不正または誤ったアクセスや攻撃など)を見つけることができます。たとえば、特定のリソースの消費量がしきい値に達したときにアラートが通知されるように環境を構成します。

コンテナを効率的にオーケストレートできる場合は、ニーズに応じて高度なデプロイパターンを実装できます。たとえば、カナリア デプロイBlue/Green デプロイを実装して、環境の信頼性を高め、問題がユーザーへ与える影響を軽減できます。

デプロイ プロセスは完全に自動化されているため、ブレークグラス手順の設計と実装をして、通常のデプロイ手順を使用せずにランタイム環境を操作できるようにすることをおすすめします。この手順は、例外的な状況で、チームの上級メンバーが事前に承認した場合にのみ使用します。たとえば、デプロイ手順で問題が発生して環境へのアクセスができなくなった場合は、ブレークグラス手順を使用して、問題の原因となった変更をロールバックします。

Infrastructure as Code(IaC)を採用する

これで、Google Cloud を効果的に使用する方法をチームが習得できたので、IaC パターンを適用できます。IaC は、ワークロードのソースコードを処理するのと同じように、ランタイム環境でリソースのプロビジョニングを処理するプロセスです。

インフラストラクチャを評価して検出する

この評価フェーズでは、前の移行手順でプロビジョニングしたインフラストラクチャについて、次の項目を含め、理解を深めます。

  • インフラストラクチャの一部として構成した Google Cloud リソース。
  • 現在実施している変更管理プロセス。
  • インフラストラクチャを変更する権限を持つ組織のメンバー。

IaC を導入するには、現在のインフラストラクチャにあるリソースのインベントリを用意することが重要です。この移行ステップでは、リソースをコードで記述する必要があるためです。

変更管理プロセスは、インフラストラクチャの変遷を管理するための基礎となります。すでにインフラストラクチャの変更管理プロセスがあれば、IaC を処理するように調整してください。なければ、このフェーズで設計と実装を行います。変更管理プロセスには、少なくとも提案された変更を分析するレビュー フェーズを含める必要があります。この分析および、インフラストラクチャを変更できるチームメンバーの評価は、インフラストラクチャの変更によってダウンタイムや予期せぬ請求が発生する可能性を軽減するために必要です。

基盤を計画して構築する

前のステップで構築した基盤を拡張し、IaC の導入をサポートするインフラストラクチャをプロビジョニングして構成する必要があります。

まず、導入するツールを選択する必要があります。Google Cloud でよく使用されるツールは次のとおりです。

  • Deployment Manager: すべての Google Cloud リソースを完全にサポートするマネージド サービス。
  • Terraform: Google Cloud や他のクラウド プロバイダをサポートするオープンソースのプロビジョニング ツール。
  • ChefPuppetAnsible: Google Cloud をサポートするオープンソースの構成ツール。

IaC ツールを選択したら、それらをサポートするために必要なすべてのインフラストラクチャをプロビジョニングして構成する必要があります。少なくとも次のものが必要です。

  • リソースの記述子を管理およびバージョニングするためのソースコード リポジトリ。
  • 各変更を実装する前に分析して承認するコードレビュー ツール。
  • チームがレビュー中に変更を承認した後に IaC ツールを実行するランタイム環境。

インフラストラクチャを管理するためのサービスが必要な IaC ツールもあります。たとえば、組織の他のメンバーと連携してインフラストラクチャを管理する場合、Terraform はリモート データ ストレージを必要とします。

IaC ツールを使用してこの基盤を管理する場合は、変更を適用する際に基盤の中断を防ぐための安全措置を実装することをおすすめします。このような中断が発生すると、ダウンタイムが長くなり、復元できないデータ損失が発生する可能性があります。たとえば、インフラストラクチャ記述子を保存しているソースコード リポジトリを誤って削除すると、復元できないデータ損失が発生する可能性があります。リーエンのようなツールを使用すると、プロジェクトの削除を防ぐことができます。

IaC で Google Cloud リソースをプロビジョニングする

Google Cloud 環境の準備ができたら、次の手順で IaC を導入して環境内のリソースを管理できます。

  • 既存のリソースをコードで記述する。
  • IaC で新しいリソースをプロビジョニングする。

前の移行ステップでは、Cloud ConsoleCloud SDK、または Cloud APIs を使用して、Google Cloud リソースをプロビジョニングしました。このフェーズでは、選択した IaC ツールの構文と規則に従って、これらのリソースをコードで記述します。

IaC ツールに現在のリソースとインスタンスを認識させるには、ツールのインベントリにこれらのリソースとインスタンスをインポートする必要がある場合があります。選択した IaC ツールには、現在のリソースとインスタンスの状態に関する情報がありません。リソースをインポートするか、手動でインスタンスを破棄して IaC ツールに再作成させる必要があります。たとえば、Terraform は既存のインフラストラクチャをインポートできます。

インフラストラクチャに新しいコンポーネントを定義する必要がある場合は、他のプロビジョニング手順を行わずに、コードで直接記述します。

環境を最適化する

IaC を導入した後に、最適化のイテレーションをもう一度実行します。このイテレーションには次の要件があります。

  • 必要に応じてモニタリング システムを拡張する。
  • インフラストラクチャをカバーするようにテストスイートを拡張する。
  • インフラストラクチャのプロビジョニングと構成を自動化する。
  • インフラストラクチャをカバーするようにブレークグラスの手順を拡張する。

前のデプロイ フェーズ前の移行ステップの最適化フェーズで行ったことを基に、IaC 導入をサポートするインフラストラクチャにモニタリングを拡張します。たとえば、IaC ツールが実行されるすべてのランタイム環境をモニタリングし、各実行を正確に記録して、後で検査できる監査証跡を構築できます。

ワークロードやコンテナ イメージだけでなく、インフラストラクチャをカバーするようにテストスイートを拡張できます。InSpecServerSpecRSpec などのツールを使用すると、ランタイム環境でコンプライアンス テストスイートを実行できます。手動による変更や IaC パイプラインの外部からの変更から、インフラストラクチャを保護できます。インフラストラクチャに対してテストスイートを継続的に実行することで、不正な変更を検出して状況を修正できます。

IaC の導入に自信がある場合は、新しい手順を設計して実装することで、インフラストラクチャのプロビジョニングを自動化することを検討してください。これらの新しいプロビジョニング手順は、アーティファクトの作成とデプロイに使用する手順とは大きく異なります。インフラストラクチャのプロビジョニング手順は、アプリケーションに対する変更ではなく、インフラストラクチャに対する変更を処理するように設計されるものです。そのため、これらの手順では、アーティファクトの作成手順とデプロイ手順とは異なる問題を解決し、エラーの影響範囲も異なります。インフラストラクチャの要素に障害が発生した場合、エラーの影響範囲は障害の影響を表します。たとえば、問題のあるアーティファクトをデプロイすると、1 つまたはいくつかのユースケースに影響するサービス障害が発生する可能性があります。問題のあるインフラストラクチャ コンポーネントをプロビジョニングした場合に発生するサービス障害は、環境内のすべてではなくとも、多数のサービスに影響すると考えられます。

サポート

Google Cloud は次のサポート リソースを提供しています。

Google Cloud 移行センターには、ワークロードの Google Cloud への移行に利用できるリソースがさらにあります。

これらのリソースの詳細については、Google Cloud への移行: スタートガイドサポートのセクションをご覧ください。

次のステップ