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

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

この記事はシリーズの一部です。

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

4 フェーズの移行パス

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

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

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

  1. 手動でデプロイする。
  2. 構成管理(CM)ツールを使用してデプロイする。
  3. コンテナ オーケストレーション ツールを使用してデプロイする。
  4. 自動的にデプロイする。
  5. インフラストラクチャをコードパターンとして適用してデプロイする。

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

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

手動でデプロイする

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kubernetes などのツール、および Google Cloud 上の Google Kubernetes Engine(GKE)などのマネージド サービスを使用して、このデプロイ プロセスを実装できます。サーバーレス環境に関心がある場合は、App Engine フレキシブル環境Cloud FunctionsCloud Run などのツールを使用できます。

自動的にデプロイする

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

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

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

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

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

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

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

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

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

SonarQubeJenkinsCloud BuildContainer RegistrySpinnaker などのツールを使用して、完全に自動化されたプロセスを実装できます。

インフラストラクチャをコードパターンとして適用してデプロイする

コードとしてのインフラストラクチャは、ワークロードのソースコードを処理するのと同じ方法で、ランタイム環境でリソースのプロビジョニングを処理するプロセスです。たとえば、Cloud APIs を使用して Google Cloud リソースのライフサイクル全体を完全に管理し、ソースコードの最終状態を体系化することができます。次に、総合テストスイートを含むワークロードに実装したのと同様の完全に自動化されたプロビジョニング プロセスをインフラストラクチャにも実装します。

プロビジョニング ツールは、インフラストラクチャをブートストラップして構成できるように設計されています。このツールは、構成タスクを完了するという目的には適していません。そのため、インフラストラクチャ内のすべてのリソースをプロビジョニングした後、CM ツールを使用して、要件に従ってこれらのリソースを構成する必要があります。プロビジョニング ツールを使用して構成タスクを、また、CM ツールを使用してプロビジョニング タスクをそれぞれ実装できます。これらは、それぞれの目的のために設計されたもので相互に補完し合います。ジョブに適したツールを使用する必要があります。つまり、インフラストラクチャのプロビジョニングにはプロビジョニング ツール、インフラストラクチャの構成には CM ツールをそれぞれ使用します。

Google Cloud などの API を使用して、移行先の環境のリソースを完全に管理できる場合は、インフラストラクチャをコードプロセスとして実装する必要があります。これにより、クラウド インフラストラクチャ全体を完全に監査、およびバージョン管理する機能が即座に得られます。また、継続的インテグレーションと継続的デプロイ(CI/CD)プロセスを実装して、インフラストラクチャの変更を自動的に適用することもできます。

一方、ターゲット環境がリソースを管理および構成するためのプログラムによるアクセスを提供していない場合、コード デプロイメントとしてインフラストラクチャを実装することはできません。また、クラウド環境でリソースのプロビジョニングとプロビジョニング解除を行う場合、請求と費用が異なる可能性があるため、調達部門に確認する必要があります。

Terraform などのツールと Deployment Manager などのマネージド サービスを使用して、インフラストラクチャをコードプロセスとして実装できます。また、RSpecServerspecInSpec などのツールを使用して、インフラストラクチャのためのテストスイートを実装できます。

概要

いつ使用しいつ回避するかといったさまざまなオプションを理解できるようになり、探索のためのいくつかのサンプルツールを持っているので、以下のグラフを用いて、ワークロードとユースケースのオプションをそれぞれ簡単に比較対照できるようになりました。

デプロイ プロセスの種類 使用する場面 回避すべきとき ツールとサービス
完全に手動でデプロイ サンドボックス環境で実験を迅速に行う必要がある場合、または、必要な管理 API が不足しているベアメタル環境やレガシー仮想化インフラストラクチャを扱う場合 より管理しやすい代替手段がある場合は常に なし
CM ツールを使用したデプロイ 手動デプロイを自動化する方法が必要で、環境の構成用の CM ツールにすでに多額の投資がされている場合 デプロイに関する CM ツールの制限を克服するために多大な労力を費やす必要がある場合 AnsibleChefPuppetSaltStack
コンテナ オーケストレーション ワークロードがすでにコンテナ化されている場合、または将来コンテナ化される可能性がありその作業に投資する予定がある場合 潜在的な落とし穴がコンテナ化のメリットを上回る場合 KubernetesGKEApp Engine フレキシブル環境Cloud FunctionsCloud Run
デプロイの自動化 自動化、構造化、合理化された監査可能なプロセスが必要な場合 チームに必要なスキルがなく、トレーニングを受ける機会もない場合、または完全に自動化されたプロセスを実装する余力がない場合 SonarQubeJenkinsCloud BuildContainer RegistrySpinnaker
Infrastructure as code ターゲット環境のリソースを API およびプログラムで完全管理できる場合 ターゲット環境がリソースを管理および構成するためのプログラムによるアクセスを提供しない場合 TerraformCloud Deployment Manager

デプロイ プロセスの評価は、現在の状況、専門知識のレベル、およびプロセスに何を期待するかに依存します。したがって、最適なデプロイ プロセスというものは存在しません。

サポート

Google Cloud では、Google Cloud サービスを最大限有効に利用していただくために、必要なヘルプとサポートを見つける際の各種のオプションとリソースを提供しています。

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

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

次のステップ