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

Last reviewed 2023-12-08 UTC

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

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

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

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

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

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

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

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

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

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

4 フェーズの移行パス

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

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

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

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

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

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

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

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

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

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

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

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

基盤を計画して構築する

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

Google Cloud リソースの管理に必要な柔軟性を実現するには、開発環境、テスト環境、本番環境といった、複数の環境をサポートする Google Cloud リソース階層を設計することをおすすめします。

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

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

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

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

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

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

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

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

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

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

たとえば、Cloud Build を使用してアーティファクトを構築し、テストスイートを実行します。テストが成功したら、結果を Container Registry に格納します。コンテナ イメージの構築について詳しくは、コンテナ構築のベスト プラクティスをご覧ください。

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

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

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

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

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

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

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

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

環境を最適化する

デプロイ プロセスを実装したら、コンテナ オーケストレーション ツールを使用して、デプロイ プロセスの最適化を開始できます。詳細については、Google Cloud への移行: 環境の最適化をご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

基盤を計画して構築する

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

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

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

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

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

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

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

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

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

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

環境を最適化する

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

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

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

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

次のステップ