Google Cloud には、コンテナ化アプリケーションを実行するための 2 つの主要なプラットフォームがあります。コンテナを Kubernetes クラスタ上で実行するための GKE と、コンテナを Google Cloud インフラストラクチャ上で直接実行するための Cloud Run です。では、どちらを使用するべきでしょうか。両方を使用できるのでしょうか。このページでは、この 2 つのプラットフォームを比較してそれぞれの長所を説明します。単一プラットフォームとハイブリッドのどちらの戦略のどちらが適しているかを判断するのにお役立てください。
このガイドは、さまざまなコンテナ化ワークロードを実行しているインフラストラクチャ管理者とアプリケーション オペレーターを対象としており、Google Kubernetes Engine（GKE）と Cloud Run の両方の強みを活用してアプリケーションを Google Cloud Platform にデプロイしたいと考えている場合にご利用いただけます。
このページを読む前に、次のことを理解しておいてください。
ステートレスとステートフルのワークロード
GKE と Cloud Run を併用する理由
GKE と Cloud Run は、コンテナ化されたアプリケーションを実行するうえで多くの利点があります。また、ワークロードのさまざまな複雑さにも対応しています。ただし、この 2 つのプラットフォームの一方だけを選ぶ必要はありません。必要に応じて 2 つのプラットフォーム間でワークロードを移行できるので、GKE と Cloud Run の両方の強みを同時に活用できます。このようなハイブリッド戦略は、コスト、パフォーマンス、管理オーバーヘッドを最適化するのに役立ちます。
両方のランタイムを使用してワークロードをデプロイするメリットは次のとおりです。
GKE と Cloud Run は、比較的高いレベルの移植性を備えています。
どちらのプラットフォームも、デプロイ アーティファクトとして標準のコンテナ イメージを使用します。どちらのプラットフォームでも、変更せずに同じイメージをアプリケーションに使用できるため、GKE と Cloud Run の間でワークロードをシームレスに移行できます。コンテナ イメージが Artifact Registry に保存されている限り、GKE と Cloud Run の間で移行するために継続的インテグレーションの設定を更新する必要はありません。
GKE と Cloud Run はどちらも宣言型 API モデルを使用します。Cloud Run Admin API v1 は、Kubernetes API と互換性を持たせるように設計されています。つまり、Deployment、Service、HorizontalPodAutoscaler などの一般的な Kubernetes コンセプトを使用して Cloud Run サービスを管理できます。この類似性により、2 つのプラットフォーム間で構成の変換を容易に行うことができます。
リソースは、同じ宣言型で標準構造の YAML ファイルで表されるため、ランタイム間で簡単に移行できます。次に、Kubernetes Deployment と Cloud Run サービスの YAML ファイルを比較した例を示します。
GKE と Cloud Run はどちらも Cloud Logging および Cloud Monitoring とシームレスに統合されているため、プラットフォームに関係なく、Google Cloud コンソールで一元化されたビューを使用して、アプリケーションの指標をモニタリングできます。両方のプラットフォームでサービスレベル目標（SLO）のモニタリングを使用し、Cloud Monitoring ダッシュボードに SLO を統合して表示することもできます。
Cloud Deploy を使用して、GKE リソースまたは Cloud Run サービスに継続的デリバリーを実装できます。必要に応じて並行デプロイを使用して、GKE と Cloud Run の両方にアプリケーションを同時にデプロイできます。
GKE と Cloud Run のサービスに外部ロードバランサと内部ロードバランサを使用することで、高度なトラフィック管理を実現できます。これには、外部エンドポイントを公開する機能も含まれます。これにより、両方のプラットフォームで同じアプリケーションの異なる URL をデプロイして実行できます。GKE と Cloud Run で、同じサービスへのトラフィックを分割して、プラットフォーム間でシームレスに移行することもできます。
Google Cloud には、両方のランタイムを使用している場合のセキュリティ ポスチャーを強化するためのセキュリティ ツールが用意されています。OS スキャンを使用すると、どちらかのプラットフォームにデプロイする前に、コンテナの脆弱性をスキャンできます。中央の Binary Authorization ポリシーによって、GKE と Cloud Run コントロール プレーンとの統合を適用し、定義したポリシーに基づいてイメージのデプロイを許可またはブロックできます。VPC Service Controls を使用すると、セキュリティ チームは GKE リソースと Cloud Run リソース全体できめ細かい境界制御を定義できます。
GKE と Cloud Run の比較
GKE と Cloud Run の優れた機能を活用し、それらの間でワークロードを移動するタイミングを判断するには、2 つのサービスの相違点を理解することが重要です。
| 機能 | GKE | Cloud Run |
|---|---|---|
| デプロイと管理 | ノード構成、ネットワーキング、スケーリング、アップグレードなど、Kubernetes クラスタを管理します。 Google Cloud は基盤となるインフラストラクチャを管理し、クラスタ オペレーションを簡素化するツールを提供しますが、Kubernetes のコア部分はお客様の責任となります。 |
Google Cloud のスケーラブルなインフラストラクチャ上でコンテナを直接実行できます。 ソースコードまたはコンテナ イメージを提供するだけで、Cloud Run がコンテナをビルドします。クラスタを作成する必要はありません。インフラストラクチャのプロビジョニングや管理を行う必要もありません。 |
| 管理と柔軟性 | Kubernetes クラスタを完全な制御できます。 ノード構成、ネットワーク ポリシー、セキュリティ設定、アドオンに対して高度なカスタマイズを行うことができます。 |
基盤となるインフラストラクチャの制御は限定的です。 環境変数、同時実行、ネットワーク接続などの構成は可能ですが、基盤となるインフラストラクチャや環境のカスタマイズはできません。シンプルさとスピードを重視する場合に最適です。 |
| アプリケーションの種類 | ステートレス アプリケーションとステートフル アプリケーションの両方をサポートしています。特定のリソース要件を持つ複雑なアプリケーションに最適です。 | ステートレス、リクエスト ドリブン、イベント ドリブンのサービス、ウェブサービス、関数に最適です。 |
| 料金モデル | 運用モード（Standard または Autopilot）、クラスタのサイズ、トポロジに関係なく、1 時間あたりのクラスタ単位の料金となります。 | 従量課金制で、100 ミリ秒単位で切り上げられます。 |
ユースケース
あなたは、大規模な e コマース プラットフォームを構築している小売業のプラットフォーム管理者です。デプロイするコンテナ化されたワークロードは次のとおりです。
フロントエンド ウェブサイトとモバイルアプリ: 商品の閲覧、検索、購入を処理するステートレス ウェブ アプリケーション。
商品の在庫管理: 商品の在庫と更新を管理するステートフル サービス。
レコメンデーション エンジン: ユーザーごとにパーソナライズされたおすすめ商品を提案する複雑なマイクロサービス。
バッチ処理ジョブ: 商品カタログの更新やユーザーの行動分析などの定期的なタスクが含まれます。
これらのワークロードではステートレス サービスとステートフル サービスが混在しているため、最適なパフォーマンスを得るために GKE と Cloud Run の両方を利用することにしました。以下では、ワークロードにハイブリッド アプローチを実装する方法の一つを紹介します。
Cloud Run ワークロードの適合性の基準を確認した後、ウェブサイトとモバイルアプリ、バッチ処理ジョブに Cloud Run を使用することにしました。これらのサービスを Cloud Run にデプロイすると、次のような利点があります。
トラフィックの急増や大規模なバッチジョブに応じた自動スケーリング。これは手動での介入なしに自動的に処理されます。
従量課金モデルによる費用対効果。ユーザーが閲覧または決済手続きをしているときと、バッチジョブの実行中にリソースが使用されているときにのみ、料金が発生します。
アップデートをすぐに利用できるため、デプロイが高速になり、ユーザー エクスペリエンスが向上します。
他の Google Cloud サービスと簡単に統合できます。たとえば、イベント ドリブン処理の場合に、Cloud Run functions を使用してバッチ処理ジョブを Cloud Run 上で開始して、シームレスなワークフローを実現できます。
商品在庫管理はきめ細かい制御を必要とするステートフル サービスであり、カスタム ストレージ ソリューションが必要になる可能性があります。永続ストレージが提供され、商品データの永続性と信頼性のためにボリュームを接続できるため、GKE を使用してこのサービスをデプロイすることにしました。
レコメンデーション エンジンは、GKE のメリットを利用できる複雑なマイクロサービスです。GKE を使用すると、複雑な依存関係を管理し、リソースの割り当てとスケーリングをきめ細かく制御できます。
GKE は、複雑なマイクロサービス アーキテクチャ、ステートフル アプリケーション、カスタム インフラストラクチャまたはネットワーク構成を必要とするワークロードなど、Kubernetes の詳細な制御が不可欠なシナリオに最適です。Cloud Run はイベント ドリブン アプリに最適です。ステートレス ウェブサービス、API、バッチジョブなど、従量課金制を利用するワークロードに最適です。
上記の例では、GKE と Cloud Run を組み合わせることで、e コマース プラットフォームに強力かつ柔軟なソリューションを提供する方法を示しています。両方のプラットフォームのメリットを享受できます。ステートレス ワークロードにはサーバーレスの効率性、複雑なマイクロサービスとステートフル コンポーネントには Kubernetes のコントロールを使用できます。
考慮事項
GKE と Cloud Run は互いに補完し合い、複雑なアプリケーションのさまざまなニーズに対応します。
ワークロードのデプロイにハイブリッド アプローチを採用する場合には、次のことを考慮してください。
費用効率とスケーラビリティのため、Cloud Run でステートレス マイクロサービスを実行します。
GKE に詳細なカスタマイズを必要とする複雑なステートフル アプリケーションをデプロイします。
Google Cloud でプライベート ネットワークを使用している場合、Cloud Run サービスから GKE クラスタ内のリソースにアクセスするには、ダイレクト VPC 下り（外向き）を使用して Virtual Private Cloud（VPC）ネットワークにリクエストを送信できます。GKE クラスタの Kubernetes Service にアクセスするには、Cloud Run サービスがクラスタの VPC ネットワークに接続され、Kubernetes Service が内部パススルー ネットワーク ロードバランサを使用していることが必要です。
Cloud Run と GKE の間でトラフィックを移行するには、グローバル外部アプリケーション ロードバランサの背後に外部エンドポイントを公開します。このロードバランサを両方のランタイムのサービスの前に実装すると、Cloud Run と GKE の両方に同じアプリケーションをデプロイできます。これにより、プラットフォーム間でトラフィックを段階的に移行できます。
プライベート IP の背後にある Virtual Private Cloud で Cloud Run サービスを公開するには、内部ロードバランサを使用します。
ワークロードがすでに Cloud Run 上にある場合は、必要に応じていつでも GKE に移行できます。
GKE と Cloud Run を併用すべきでない場合
GKE と Cloud Run は、コンテナ化された多くのワークロードに適したアプローチを提供しますが、これらを組み合わせて使用すべきでないケースもあります。ハイブリッド アプローチを採用すべきでない例を次に示します。
密結合のマイクロサービス: マイクロサービス間の相互依存が大きく、低レイテンシの通信が頻繁に必要になる場合、異なるプラットフォーム間でマイクロサービスを管理すると、複雑になる可能性があります。プラットフォーム間で頻繁にネットワーク呼び出しを行うと、オーバーヘッドが増加してボトルネックが発生し、パフォーマンスに影響する可能性があります。
カスタム依存関係を持つレガシー アプリケーション: Cloud Run でサポートされていない特定のライブラリ、フレームワーク、または構成にアプリケーションが依存している場合、アプリケーションの一部に使用するには、かなりのリファクタリングや回避策が必要になることもあります。これにより、サーバーレスのメリットがなくなり、プラットフォーム固有のメンテナンス オーバーヘッドが発生する可能性があります。
予測可能なワークロードの予算制約: ワークロードのリソース要件が一定で、予算が限られている場合は、GKE のノード単位の従量課金モデルが、Cloud Run の従量課金よりも費用対効果が高い場合があります。予測可能なワークロードでは、Cloud Run の自動スケーリングのメリットを十分に活用できず、GKE の固定費用のほうがよい場合があります。
最終的には、最適なアプローチは特定のニーズと優先事項によって異なります。GKE と Cloud Run のハイブリッド アーキテクチャを決定する前に、アプリケーションの要件、リソースの制約、チームの専門知識を慎重に評価してください。
次のステップ
Cloud Run から GKE に移行するで、Cloud Run サービスを Kubernetes デプロイに変換する方法を確認する。
Kubernetes から Cloud Run に移行するの説明に従って、Kubernetes Deployment を Cloud Run 対応のコンテナにパッケージ化する。