Google Cloud へのコンテナの移行: スタートガイド

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このドキュメントでは、コンテナの Google Cloud への移行を計画、設計、実装する際に役立つ情報を提供します。方法を誤ると、別の環境へのワークロードの移行は困難なタスクになるため、慎重に移行を計画して実施してください。

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

このドキュメントは、コンテナを Google Cloud に移行する方法を説明するシリーズの一部です。

このドキュメントは、オンプレミス、プライベート ホスティング環境、または別のクラウド プロバイダで走行するコンテナから開始する場合や、ワークロード全体を Google Cloud に移行する場合、オンプレミスまたはプライベート ホスティング環境でのワークロードの一部を維持する場合などの、さまざまなシナリオで役立ちます。

また、移行について検討している場合、その概要を把握したり、利用可能なオプションについて調べたりするためにも利用できます。Google Cloud で使用可能なワークロードを実行するコンテナには、さまざまな環境があります。複数の選択から 1 つのオプションを選択すると、いくつかの要因が左右されます。他のオプションより本質的に優れたオプションはありません。どの環境にも独自の強みと弱みがあります。環境の選択は、次の手順に沿って行います。

  1. ワークロードを実行するためのコンテナ環境に、一連の評価基準を確立します。
  2. 評価基準に照らして各環境を評価します。
  3. ニーズに最適な環境を選択します。

すべてのワークロードに同じ環境を選択する必要はありません。ワークロードのタイプやクラスが複数ある場合は、それらのタイプやクラス向けに異なる環境を選択できます。

Google Cloud への移行の設計

コンテナを移行元の環境から Google Cloud に移行するには、Google Cloud への移行のシリーズで説明されているフレームワークに従うことをおすすめします。

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

4 フェーズの移行パス

上の図に示すフレームワークは、4 フェーズで構成されています。

  1. 評価。このフェーズでは、移行元の環境、Google Cloud に移行するワークロード、各ワークロードをサポートできる環境について評価します。
  2. 計画。このフェーズでは、リソース階層のプロビジョニングやネットワーク アクセスの設定など、ワークロードの基本的なインフラストラクチャを作成します。
  3. デプロイ。このフェーズでは、コンテナを移行元の環境から Google Cloud に移行します。
  4. 最適化。このフェーズでは、クラウドのテクノロジーと機能を最大限に活用します。

ワークロードを実行するためのコンテナ環境に評価基準を確立する

ワークロードを実行するためのコンテナ環境のオプション用の評価基準を確立するには、それらの環境で最も重要となる機能を考慮します。最も必要な機能に関する情報を収集するには、ワークロードを評価します。ワークロードの評価について詳しくは、Google Cloud への移行: ワークロードの評価と検出をご覧ください。

評価基準とリストの順序は一例です。ワークロードを評価して、ご自身とワークロードにとって重要な基準をリストアップし、重要度に基づいて並べ替える必要があります。たとえば、ワークロードを評価した後、重要度の高いものからリストアップされた次の評価基準を検討できます。

  1. パフォーマンス。その環境では、ワークロードのパフォーマンスが低下する可能性があるオーバーヘッドが追加されているか？
  2. スケーラビリティ。その環境には、どのようなスケーラビリティ機能があるか？これらは、応答時間とスケーラビリティ ロジックの両方において、ワークロードのスケーラビリティの要件を十分に満たしているか？
  3. 制御性と柔軟性。環境に対し、どの程度の制御性を必要としているか？ニーズに合わせて環境をカスタマイズできるか？
  4. 信頼性。その環境では、どの保証が提供されるか？ワークロードへの適合性は充分か？効果的な高可用性と障害復旧戦略を実装するのに十分な信頼性があるか？
  5. 管理の負担。環境の管理にどれくらいの労力が必要か？必要なスキルを身に着けるようにチームをトレーニングする必要があるか、または既存の知識が活用できるか？
  6. サービスを使用するための要件。ワークロードが遵守すべき要件、技術契約、インターフェースはあるか？ワークロードと環境の互換性を維持するために、多大な労力を必要とするか？
  7. データの永続性。ワークロードを実行するためのコンテナ環境で、データの永続性はサポートされているか？この永続性は、パフォーマンス、信頼性、法規制などのワークロードの要件と互換性があるか？
  8. 料金モデルと費用。コスト効率の高い方法でこの環境を使用できるか？ワークロードを実行するためにコンテナ環境に切り替え、適切な投資収益率を得ることができるか？
  9. 将来への対応。その環境には、ワークロードの進化に使用できるアップグレード パスが用意されているか？
  10. 他のサービスとの統合。その環境は他の Google Cloud サービスと他のクラウド プロバイダのサービスと統合されているか？
  11. ロックイン。その環境では、特定のテクノロジー、パラダイム、またはインターフェースにアクセスできなくならないか？その環境では、ワークロードの移植性が低下しているか？
  12. セキュリティ。その環境はセキュリティとプライバシーの要件を満たしているか？

ワークロードを実行するためのコンテナ環境を評価する

Google Cloud では、コンテナを実行するためのさまざまなオプションがご利用いただけます。ワークロードに最適なオプションを選択するには、まず先ほど確立した評価基準に照らして評価します。環境ごとに、任意に順序付けしたスケールのスコアを評価基準に割り当てます。たとえば、各評価基準に照らして 1～10 のスケールを各環境に割り当てることができます。

Google Cloud でコンテナを実行するには、次のオプションをおすすめします。これらのオプションは、基盤となるインフラストラクチャをどの程度制御できるかという基準に対して昇順で表示されます。

  1. Cloud Run と Cloud Run for Anthos
  2. Google Kubernetes Engine（GKE）と Anthos クラスタ
  3. Compute Engine

プロダクトのドキュメントを参照して、一部の基準に対してスコアを割り当てることができます。たとえば、パフォーマンス、スケーラビリティ、制御性と柔軟性、他のサービスとの統合と照らして Cloud Run を評価できます。ただし、他の基準にスコアを割り当てるには、より詳細なベンチマークとシミュレーションをデザインして実行する必要があります。たとえば、さまざまなコンテナ ランタイムのパフォーマンスのベンチマークを行い、ワークロードのオーバーヘッドが大幅に増加するかどうかを評価する必要がある場合などです。

Cloud Run と Cloud Run for Anthos

Cloud Run は、Knative 上に構築された、コンテナ化されたステートレス ワークロードを実行するためのマネージド プラットフォームです。Cloud Run で管理されるコンテナ化されたワークロードは、次の場所で実行できます。

  • Cloud Run を選択すると、ワークロードは Google が管理するインフラストラクチャ上で走行します。
  • Cloud Run for Anthos を選択した場合、ワークロードは GKE で走行します。このワークロードは Google Cloud、オンプレミス、その他のクラウド プロバイダで使用できます。

以下のリストを使用して、先ほど確立した基準に照らして Cloud Run と Cloud Run for Anthos を評価します。

  1. パフォーマンス。Cloud Run と Cloud Run for Anthos は、コンテナ化されていないワークロードと同等のパフォーマンスを持つ Docker コンテナを使用します。このため、コンテナのパフォーマンスが大幅に低下することはありません。
  2. スケーラビリティ。Cloud Run はワークロードのインスタンスを自動的にスケーリングし、アプリケーションをゼロ インスタンスにスケーリングできます。この機能は、ワークロードでインスタンスを常に実行する必要がない場合に便利です。インスタンスの起動時間を最小限に抑えるには、ワークロードの初期化を最適化してください。
  3. 制御性と柔軟性。Cloud Run と Cloud Run for Anthos は、ワークロードが走行するコンテナ化された環境を完全に制御する必要があるワークロードに適していますが、その環境をカスタマイズする必要はありません。
  4. 信頼性。Cloud Run と Cloud Run for Anthos は Cloud Monitoring、Cloud Logging、Cloud Audit Logs、Error Reporting と統合されているため、コンテナ、リクエスト、エラー、監査ログへのアクセスや、パフォーマンスのモニタリングが可能になります。
  5. 管理の負担。Cloud Run と Cloud Run for Anthos は環境を管理するため、基盤となるインフラストラクチャのプロビジョニング、構成、メンテナンスに煩わされることなく、ワークロードに集中できます。
  6. サービスを使用するための要件。ワークロードはコンテナ ランタイムの契約を遵守する必要があります。したがって、Cloud Run との互換性を確保するための追加作業を行えない場合は、他のオプションのいずれかを選択することをおすすめします。Cloud Run の制限の詳細については、Cloud Run の既知の問題をご覧ください。
  7. データの永続性。Cloud Run と Cloud Run for Anthos はステートレス コンテナを実行するように設計されています。ワークロードのデータ永続性が必要な場合は、別のデータ永続性システムをプロビジョニングして構成する必要があります。ステートフル ワークロードにコンテナ ランタイム環境が必要な場合は、別のオプションを選択することをおすすめします。
  8. 料金モデルと費用。Cloud Run は、ワークロードが使用するコンピューティング リソースに対して課金します。Cloud Run for Anthos は Anthos のサブスクリプションに含まれています。
  9. 将来への対応。Cloud Run では、ロールバック、段階的なロールアウト、トラフィック移行を行うことができます。デプロイ パイプラインで、これらの機能を使用できます。
  10. 他のサービスとの統合。Cloud Run は、内部 IP アドレスを持つ Compute Engine VM やその他のリソースへのアクセスを許可する Virtual Private Cloud（VPC）ネットワークに接続できます。
  11. ロックイン。Cloud Run は Knative をベースとして構築されています。ワークロードが Knative との互換性を維持するための作業を行った場合は、追加の変更を行うことなくコンテナ化されたワークロードを Cloud Run、GKE、VMware 上の Anthos クラスタ、その他の Knative 互換のランタイム環境で実行できます。
  12. セキュリティ。Cloud Run で走行するワークロードは、gVisor を使用してサンドボックス化されます。Cloud Run for Anthos はコンテナ サンドボックスを使用しませんが、デフォルトの Kubernetes コンテナ分離機能を使用します。Identity and Access Management（IAM）でアクセスを管理し、サービス ID を構成することで、Cloud Run リソースを保護できます。

詳細については、Cloud Run プラットフォームの選択をご覧ください。

GKE と Anthos クラスタ

GKE と Anthos クラスタは、ワークロードを実行するためのコンテナ環境を提供する Google マネージド サービスです。GKE と Anthos クラスタは、どちらも Kubernetes クラスタ内でコンテナ化されたワークロードを実行します。GKE では、クラスタは Google Cloud 上で走行し、Anthos クラスタでは、クラスタは Google Cloud、オンプレミス、または他のパブリック クラウド環境で実行できます。

次のリストを使用して、先ほど確立した基準に照らして GKE と Anthos クラスタを評価します。

  1. パフォーマンス。GKE と Anthos クラスタは、コンテナ化されていないワークロードと同等のパフォーマンスを持つ Docker コンテナを使用します。このため、コンテナのパフォーマンスが大幅に低下することはありません。
  2. スケーラビリティ。GKE と Anthos クラスタには、ニーズに合わせて対応できる微調整されたスケーリング ロジックが含まれています。ワークロードのスケーリングと GKE および Anthos クラスタを垂直方向および水平方向の両方にスケーリングできます。複雑なスケーリング ロジックが不要な場合は、別のオプションを選択することをおすすめします。このオプションを選択した場合、効果的なスケーラビリティ メカニズムの構成に多大な労力を要する可能性があります。
  3. 制御性と柔軟性。必要に応じて、GKE クラスタと Anthos クラスタをプロビジョニングおよび構成できます。ストレージ、ネットワーキング、セキュリティなど、クラスタノードのあらゆる側面をカスタマイズできます。コントロール プレーンは Google に管理されているため、コントロール プレーンの構成をカスタマイズする必要がある場合は、別のオプションを選択することをおすすめします。
  4. 信頼性。GKE と Anthos クラスタは Cloud Monitoring および Cloud Logging と統合されているため、パフォーマンス モニタリングとコンテナ、リクエスト、エラー、監査ログへのアクセスのすべての機能を利用できます。GKE リージョン クラスタと Anthos クラスタの高可用性オプションを使用して、環境の信頼性を高めることができます。
  5. 管理の負担。GKE では、クラスタのコントロール プレーンを管理する必要はありません。Anthos クラスタを使用すると、同じツールチェーンとプロセスを持つすべての Kubernetes クラスタを管理できます。この機能により、環境の管理に必要となる労力が大幅に削減されますが、基盤となるインフラストラクチャの一部を管理する必要があります。たとえば、GKE ではクラスタノードを管理できます。ほとんどの管理操作を自動化できますが、それでも環境の維持に必要な作業を計画しておくことが必要です。ワークロードを実行するためのフルマネージド コンテナ環境が必要な場合は、別のオプションの選択をおすすめします。
  6. サービスを使用するための要件。GKE または Anthos クラスタにワークロードをデプロイするには、ワークロードをコンテナ化する必要があります。
  7. データの永続性。GKE と Anthos は、ステートフル アプリケーションと永続ディスク ストレージを実行できます。
  8. 料金モデルと費用。GKE は、クラスタの管理料金とクラスタノードが使用するリソースに対して課金されます。Anthos クラスタは Anthos のサブスクリプションに含まれています。
  9. 将来への対応。GKE と Anthos クラスタには、複雑なデプロイ プロセスを処理する機能があります。
  10. 他のサービスとの統合。GKE と Anthos クラスタにデプロイされたワークロードは、必要な接続、認証、認可システムが設定されている場合、他の Google Cloud サービスへのアクセスが許可されます。
  11. ロックイン。ワークロードをコンテナ化して GKE または Anthos クラスタで実行できるようにすると、わずかな調整で他の環境に移植できます。Kubernetes はポータブルなプラットフォームであり、ベンダー環境にロックインさせられることはありません。

  12. セキュリティ。GKE には、ノード、コントロール プレーン、ワークロードを保護するためのさまざまな方法が用意されています。

詳細については、GKE セキュリティの概要をご覧ください。

GKE と Anthos クラスタへの移行の詳細については、Google Cloud へのコンテナの移行: Kubernetes から GKE への移行、および Google Cloud へのコンテナの移行: OpenShift から Anthos への移行をご覧ください。

Compute Engine

Compute Engine を使用すると、Google のインフラストラクチャ上で VM を作成して実行できます。

Compute Engine VM でコンテナを実行することも可能ですが、このドキュメントで説明されている他のコンテナ環境のいずれかを選択して、ワークロードを実行することをおすすめします。Compute Engine で動作するセルフマネージド環境を運用するために必要な労力は、得られるメリットをはるかに上回ります。

とはいえ、Compute Engine VM 上でコンテナを実行する場合は、次のリストを使用して、先ほど確立した基準に照らして Compute Engine を評価します。

  1. パフォーマンス。Compute Engine VM にはコンテナ ランタイムがプリインストールされていないため、要件に最適なコンテナを選択してください。
  2. スケーラビリティ。Compute Engine は、マネージド インスタンス グループを使用して VM インスタンスを自動的にスケーリングします。マネージド インスタンス グループの自動スケーリング メカニズムを構成するときに、Compute Engine がマネージド インスタンス グループのスケールイン、スケールアウトに使用する自動スケーリング シグナルを定義します。
  3. 制御性と柔軟性。Compute Engine のリソース割り当てを遵守している限り、各 Compute Engine VM のプロビジョニングと構成のすべての側面をカスタマイズできます。
  4. 信頼性。Compute Engine VM は、Cloud Monitoring、Cloud Logging、および Cloud Audit Logs でモニタリングできます。これにより、パフォーマンスのモニタリングとログのすべての機能を利用できます。また、Compute Engine は、マネージド インスタンス グループ、インスタンスのヘルスチェック、および自動修復を使用します。
  5. 管理の負担。Compute VM はセルフマネージドであるため、環境を効果的に管理するために、妥当な運用作業を計画してください。
  6. サービスを使用するための要件。ワークロードがサポートされているオペレーティング システムで走行している場合、それらのワークロードは Compute Engine VM 上で実行できます。Compute Engine の制限の詳細については、Compute Engine の既知の問題をご覧ください。
  7. データの永続性。Compute Engine には、ゾーン永続ディスク、リージョン永続ディスク、ローカル ソリッド ステート ドライブといった、データの永続性のさまざまなオプションがあります。
  8. 料金モデルと費用。Compute Engine は、ワークロードが必要とするリソースに対して課金されます。
  9. 将来への対応。統合、デプロイ、プロビジョニング、構成管理ツールを Compute Engine VM にインストールしてデプロイ プロセスに使用できます。
  10. 他のサービスとの統合。Compute Engine にデプロイされたワークロードは、必要な接続、認証、認可システムが設定されていれば、他の Google Cloud サービスへのアクセスが許可されます。
  11. ロックイン。Compute Engine を使用すると、独自の製品やサービスにロックインされることはありません。独自のオペレーティング システム イメージを構築して、プロビジョニングと構成プロセスを自動化し、移植できます。
  12. セキュリティ。Compute Engine は、環境のセキュリティ強化に役立ちます。

詳細については、Google Cloud の保護をご覧ください。

移行先の環境に適したオプションを選択する

前のセクションでは、各プロダクトのすべての基準に値を割り当てました。ワークロードを実行する各コンテナ環境の合計スコアを計算するには、基準に基づいてその環境に割り当てたすべてのスコアを合計します。たとえば、環境のパフォーマンス基準に 10、スケーラビリティ基準に 6 のスコアが付けられた場合、その環境の合計スコアは 16 になります。

また、各評価基準のスコアに異なる重みを割り当てて、各評価基準の重要度を表すこともできます。たとえば、評価においてパフォーマンスがスケーラビリティよりも重要である場合、パフォーマンスには 1.0 の乗数、スケーラビリティには 0.7 の乗数を反映するように乗数を定義できます。次に、これらの乗数を使用して、オプションの合計スコアを計算します。

評価した各環境の合計スコアを計算した後、合計スコアの降順によって環境を整理します。環境としてスコアが最も高いオプションを選択します。

このデータを表現する方法は複数あります。たとえば、レーダー チャートのような多変量データを表すグラフを使用して結果を可視化できます。

次のステップ