Google Cloud への移行: ワークロードのデプロイ

Last reviewed 2023-12-08 UTC

このドキュメントでは、Google Cloud への移行のデプロイ フェーズを計画、設計するときに役立つ情報を提供しています。現在の環境を評価し、Google Cloud への移行を計画して Google Cloud の基盤を構築した後、ワークロードをデプロイできます。

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

次の図は、移行の過程を示しています。

4 フェーズの移行パス

デプロイ フェーズは、Google Cloud への移行の 3 番目のフェーズです。このフェーズでは、ワークロードのデプロイ プロセスを設計します。

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

このドキュメントでは、さまざまなデプロイ プロセスの種類を、柔軟性、自動化、複雑さの順に検討し、適切なアプローチを選択するための基準を以下のように示します。

  1. 手動でデプロイする。
  2. 構成管理（CM）ツールを使用してデプロイする。
  3. コンテナ オーケストレーション ツールを使用してデプロイする。
  4. 自動的にデプロイする。

ワークロードをデプロイする前に、デプロイ フェーズを計画および設計します。最初に、ワークロードに実装するさまざまなデプロイ プロセスの種類を評価する必要があります。デプロイ プロセスの種類を評価する場合、単純なプロセスから始めて、その後、より複雑なプロセスに移行するといった選択も可能です。このアプローチでは、結果をより迅速に得ることができます。しかし、より高度なプロセスに移行する際に、単純なプロセスを使用している間に蓄積した技術的な問題を受け入れる必要が生じるため、スムーズな移行が妨げられる可能性もあります。たとえば、完全に手動によりデプロイした場合、自動化されたソリューションに移行する際に、デプロイ パイプラインとアプリをアップグレードする必要が生じる可能性があります。

ワークロードのニーズに応じてさまざまな種類のデプロイ プロセスを実装することは可能ですが、そのようなアプローチの場合、フェーズの複雑さも増大する可能性があります。さまざまな種類のデプロイ プロセスを実装する場合、柔軟性が増すというメリットが得られますが、プロセスごとに専門知識やツールやリソースが必要になり、より多くの労力が必要になる可能性が生じます。

手動でデプロイする

完全に手動のデプロイは、完全に自動化されていないプロビジョニング、構成、およびデプロイ プロセスによって構成されます。プロセスの各ステップに仕様とチェックリストが存在する場合がありますが、それらの仕様の自動チェックまたは強制は実行されません。手動プロセスはヒューマン エラーを起こしやすく、再現性がなく、そのパフォーマンスはヒューマン ファクターによって制限されます。

たとえば、サンドボックス環境でテストをすばやく実行する必要がある場合などには、完全に手動のデプロイ プロセスが役立ちます。数分間続くテストのために構造化され自動化されたプロセスを設定すると、特に自動化されたプロセスを構築するためのツールや手法についての必要な専門知識が不足している場合、移行の初期段階で不必要にペースが遅くなる可能性があります。

Google Cloud では、このような制限はありませんが、必要な管理 API が不足している Bare Metal 環境で作業している場合は、完全な手動デプロイが唯一の選択肢となる可能性があります。この場合は、必要なインターフェースがないため、自動化プロセスを実装できません。自動化をサポートしないレガシー仮想化インフラストラクチャが存在する場合、完全に手動のプロセスを実装することを余儀なくされる可能性があります。

その他に選択肢がない場合を除き、完全に手動でデプロイしないことをおすすめします。

Google Cloud コンソール、Cloud Shell、Cloud APIs、Google Cloud CLI などのツールを使用して、完全に手動のプロビジョニング、構成、デプロイ プロセスを実装できます。

構成管理ツールを使用してデプロイする

CM ツールを使用すると、繰り返し可能な制御された方法で環境を構成できます。これらのツールには、一般的な構成操作をすでに実装しているプラグインとモジュールのセットが用意されています。これらのツールを使用すると、最終状態に到達するためのロジックを実装することではなく、環境で実現する必要がある最終状態そのものに集中できます。用意されている操作セットでは不十分な場合でも、独自のモジュール開発に使用できる拡張システムが CM ツールに備わっていることが多くあります。こうした拡張システムを使用することは可能ですが、必要に応じて事前に定義されたモジュールとプラグインを使用し、開発とメンテナンスの負担が必要以上にかかることを避けてください。

環境を構成する必要がある場合は、CM ツールを使用します。また、これらを使用してインフラストラクチャをプロビジョニングし、ワークロードのデプロイ プロセスを実装することもできます。CM ツールは、完全に手動のプロビジョニング、構成、およびデプロイ プロセスと比較して、再現性があり、制御され、監査可能であるため、より優れたプロセスです。ただし、CM ツールはプロビジョニングまたはデプロイタスク用に設計されていないため、いくつかの欠点があります。通常、インフラストラクチャの実際の状態と必要な状態の違いを検出および管理するなどの精巧なプロビジョニング ロジックを実装するための組み込み機能、またはダウンタイムのないデプロイや Blue / Green デプロイメントなどの豊富なデプロイ プロセスが欠けています。欠落している機能は、前述の拡張ポイントを使用して実装できます。カスタマイズされたデプロイメント ソリューションを設計、開発、および維持するために必要な専門知識が必要なため、これらの拡張により余分な労力が発生し、デプロイ プロセスの全体的な複雑さが増す可能性があります。

Ansible、Chef、Puppet、SaltStack などのツールを使用して、このタイプのプロビジョニング、構成、およびデプロイ プロセスを実装できます。

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

ワークロードのコンテナ化への投資を進めている、または進めることを計画している場合は、コンテナ オーケストレーション ツールを使用してワークロードをデプロイできます。

コンテナ オーケストレーション ツールを使用すると、現在の環境の基盤となるインフラストラクチャの管理を行い、さまざまなデプロイ操作とビルディング ブロックをサポートして、組み込みロジックでは不十分な場合に使用できるデプロイ ロジックを実装できます。これらのツールを使用することにより、提供されたメカニズムを実装する代わりに、提供されたメカニズムを使用して実際のデプロイ ロジックの作成に集中できます。

コンテナ オーケストレーション ツールを使用すると、デプロイ プロセスをさまざまな基盤となる環境に一般化して適用するための抽象化の機能も提供されるため、環境ごとに複数のプロセスを設計および実装する必要はなくなります。たとえば、これらのツールには通常、デプロイメントをスケーリングおよびアップグレードするためのロジックが含まれているため、そうした機能を自分で実装する必要はありません。これらのツールを活用すれば、現在ご使用中の環境にデプロイ プロセスを実装することが可能です。設計ではほぼ同様の実装であるため、環境への実装の後にターゲット環境に移植できます。これらのツールを早期に採用することで、コンテナ化された環境に関する管理経験が得られ、その経験により Google Cloud への移行が容易になります。

ワークロードがすでにコンテナ化されている場合、または将来においてコンテナ化が可能でありその作業に取り組む予定がある場合は、コンテナ オーケストレーション ツールを使用できます。後者の場合、各ワークロードを徹底的に分析して、以下について判断する必要があります。

  • ワークロードのコンテナ化が可能であることを確認する。
  • ワークロードをコンテナ化することで得られる潜在的なメリットを評価する。

潜在的な落とし穴がコンテナ化の利点を上回る場合、チームがすでにそれらを使用することにコミットしており、多種多様な環境を管理したくない場合にのみ、コンテナ オーケストレーション ツールを使用する必要があります。

たとえば、データ ウェアハウス ソリューションは、エフェメラル コンテナで実行するように設計されていないため、通常、コンテナ オーケストレーション ツールを使用してもデプロイされません。

このデプロイ プロセスは、Google Cloud の Google Kubernetes Engine（GKE）を使用して実装できます。サーバーレス環境に関心がある場合は、Cloud Run などのツールを使用できます。

自動的にデプロイする

どのようなプロビジョニング、構成、デプロイ、およびオーケストレーションのツールを環境で使用するかにかかわりなく、完全に自動化されたデプロイ プロセスを実装すると、ヒューマン エラーを最小限に抑え、組織全体でプロセスを統合、合理化、および標準化できます。デプロイ プロセスに必要に応じて手動の承認手順を挟む場合はありますが、それ以外のすべての手順が自動化されます。

典型的なエンドツーエンドのデプロイ パイプラインの手順は次のとおりです。

  1. コードレビュー。
  2. 継続的インテグレーション（CI）。
  3. アーティファクトの生成。
  4. 最終的な手動の承認を伴う継続的デプロイ（CD）。

これらの各ステップは、他のステップから独立して自動化できるため、現在のデプロイ プロセスを自動化されたソリューションに徐々に移行する、またはターゲット環境に新しいプロセスを直接実装することができます。このプロセスを効果的にするには、コードレビュー ステップや CI ステップだけでなく、パイプラインの各ステップでテストと検証のプロセスが必要になります。

コードベースの変更ごとに、徹底的なレビューを実行して変更の品質を評価する必要があります。ほとんどのソースコード管理ツールには、コードレビューのトップクラスのサポートが付いています。また、コードベースの各領域を担当するチームを構成した場合、変更されたソースコード領域を調べることで、レビューの自動作成と初期化をサポートすることもよくあります。また、各レビューでは、リンターや静的アナライザなどのソースコードに対して自動チェックが実行され、コードベース全体で一貫性と品質標準を確保できます。

CI ツールは、コードベースの変更を確認して統合した後に、自動的にテストを実行し、結果を評価して、現在のビルドの問題について通知します。テスト駆動型開発の手順で各ワークロードの機能を完全に網羅するテストを行うことにより、このステップに価値を付加できます。

ビルドが成功するたびに、デプロイメント アーティファクトの作成を自動化できます。このようなアーティファクトは、最新の変更を加えた、すぐにデプロイできるワークロードのバージョンを表します。アーティファクトを作成する手順の一部として、アーティファクト自体の自動検証を実行することもできます。たとえば、既知の問題に対して脆弱性スキャンを実行し、脆弱性が見つからない場合にのみデプロイ用のアーティファクトを承認します。

最後に、ターゲット環境で承認された各アーティファクトのデプロイを自動化できます。複数のランタイム環境がある場合は、必要に応じて手動承認の手順を追加することで、それぞれに独自のデプロイ ロジックを実装することもできます。たとえば、開発環境、品質保証環境、および本番前環境にワークロードの新しいバージョンを自動的にデプロイできますが、本番環境にデプロイするには、製造管理チームによる手動のレビューと承認が必要になります。

完全に自動化されたエンドツーエンド プロセスは、自動化、構造化、合理化された監査可能なプロセスが必要な場合の最良のオプションの 1 つですが、このプロセスの実装は簡単なタスクではありません。この種のプロセスを選択する前に、予想される利点、関連する費用、および現在のチームの知識と専門知識のレベルが完全に自動化されたデプロイ プロセスを実装するのに十分かどうかを明確に把握する必要があります。

Cloud Deploy を使用すると、完全に自動化されたデプロイ プロセスを実装できます。

次のステップ