このドキュメントは、技術的および組織的な考慮事項を踏まえてアプリケーションの要件を評価し、Cloud Run と Google Kubernetes Engine（GKE）Autopilot のどちらを選ぶかを判断する際に役立ちます。このドキュメントは、ワークロードの Google Cloud ターゲット コンテナ ランタイム環境を選択する必要があるクラウド アーキテクトを対象としています。このドキュメントは、Kubernetes と Google Cloudに精通しており、Cloud Run、Cloud Run functions、AWS Lambda などのクラウド サーバーレス ランタイム環境に関する知識があることを前提としています。
Google Cloud には、さまざまな機能を備えた複数のランタイム環境オプションが用意されています。次の図は、 Google Cloudマネージド サービスの範囲を示しています。
この図は次のことを示しています。
最もマネージドなランタイム環境（このガイドの焦点）:
これらのオプションは Google によって管理され、基盤となるコンピューティング インフラストラクチャのユーザー管理は行われません。
最小限のマネージド ランタイム環境:
- GKE Standard。エンタープライズ ワークロード向けに最適化されており、最大 65,000 ノードの単一クラスタのスケーラビリティを提供します。
- Compute Engine。これには、機械学習（ML）とハイ パフォーマンス コンピューティング（HPC）ワークロード用のアクセラレータ最適化 A3 ファミリーの仮想マシンが含まれます。
これらのオプションでは、コンピューティング機能の基盤となる仮想マシン（VM）など、ユーザーレベルのインフラストラクチャ管理がある程度必要になります。GKE Standard の VM は Kubernetes クラスタノードです。Compute Engine の VM は、要件に合わせてカスタマイズできるコア プラットフォーム サービスです。
このガイドは、最も管理されたランタイム環境である Cloud Run と GKE Autopilot のどちらを選択するかを判断するのに役立ちます。 Google Cloud ランタイム環境の概要については、Google Cloud アプリケーションのホスティング オプション ガイドをご覧ください。
環境の概要
このセクションでは、Cloud Run と GKE Autopilot の機能の概要について説明します。Cloud Run と GKE Autopilot はどちらも Google Cloudと緊密に統合されているため、2 つのサービスには多くの共通点があります。どちらのプラットフォームも、Google の信頼性とスケーラビリティに優れたロード バランシング サービスによるロード バランシングの複数のオプションをサポートしています。また、よりきめ細かいプライベート ネットワーキングが必要な場合は、どちらも VPC ネットワーキング、Identity-Aware Proxy（IAP）、Google Cloud Armor をサポートしています。どちらのプラットフォームでも、アプリケーションで使用した正確なリソース量に対してのみ課金されます。
ソフトウェア デリバリーの観点から、コンテナ ランタイム環境として、Cloud Run と GKE Autopilot は、 Google Cloud コンテナ エコシステムを構成するサービスによってサポートされています。これらのサービスには、Cloud Build、Artifact Registry、Binary Authorization、Cloud Deploy による継続的デリバリーが含まれます。これにより、アプリケーションを本番環境に安全かつ確実にデプロイできます。つまり、ビルドとデプロイの決定は、お客様とお客様のチームが所有します。
2 つのプラットフォームには共通点があるため、GKE と Cloud Run を併用するのガイドで詳しく説明されているように、アプリケーションをデプロイする場所に対して柔軟なアプローチを採用することで、それぞれの強みを活用できます。以降のセクションでは、Cloud Run と Autopilot の固有の側面について説明します。
Cloud Run
Cloud Run は、Google のスケーラブルなインフラストラクチャ上でアプリケーションを直接実行できるサーバーレス マネージド コンピューティング プラットフォームです。Cloud Run は、次の 2 種類の主要なアプリケーションの自動化とスケーリングを提供します。
- Cloud Run サービス: ウェブ リクエストに応答するコード。
- Cloud Run ジョブ: 1 つ以上のバックグラウンド タスクを実行し、作業が完了すると終了するコード。
これら 2 つのデプロイモデルにより、Cloud Run は幅広いアプリケーション アーキテクチャをサポートしながら、ベスト プラクティスを可能にし、デベロッパーがコードに集中できるようにします。
Cloud Run では、次のソースからアプリケーション コードをデプロイすることもできます。
- 個々の軽量関数
- ソースコードから完全なアプリケーションを生成
- コンテナ化アプリケーション
Cloud Run には、FaaS とソースからビルドする機能の両方をサポートするビルドとデプロイの機能が組み込まれています。また、ビルド済みのコンテナ ランタイム機能も備えています。この方法で Cloud Run を使用すると、実行されるアプリケーション コンテナ イメージのビルドとデプロイの手順が完全に自動化され、カスタム構成は必要ありません。
GKE Autopilot
GKE Autopilot は、GKE で推奨されるデフォルトのクラスタ運用モードです。Autopilot を使用すると、インフラストラクチャを管理するオーバーヘッドなしで Kubernetes でアプリケーションを実行できます。Autopilot を使用すると、ノードのプロビジョニングとスケーリング、デフォルトのセキュリティ ポスチャー、その他の事前構成された設定など、クラスタ構成の主要な基盤となる側面が Google によって管理されます。Autopilot がノードリソースを管理するため、ワークロードによってリクエストされたリソースに対してのみ料金が発生します。Autopilot は、インフラストラクチャのリソースを継続的にモニタリングして最適化し、ワークロードの SLA を提供しながら、最適なリソースを確保します。
GKE Autopilot は、Cloud Run に適していないワークロードをサポートしています。たとえば、GKE Autopilot は通常、長時間実行されるワークロードやステートフル ワークロードをサポートしています。
ランタイム環境を選択する
一般に、ワークロードの特性がマネージド プラットフォームに適している場合は、Cloud Run のサーバーレス ランタイム環境が最適です。Cloud Run を使用すると、管理するインフラストラクチャが減り、セルフマネージド構成が減るため、運用上のオーバーヘッドが削減されます。Kubernetes を特に必要としない限り、ターゲット ランタイム環境として最初にサーバーレスを検討することをおすすめします。Kubernetes はオープン プラットフォームの強力な抽象化を提供しますが、使用すると複雑さが増します。Kubernetes が必要ない場合は、アプリケーションがサーバーレスに適しているかどうかを検討することをおすすめします。ワークロードがサーバーレスに適していない条件がある場合は、Autopilot を使用することをおすすめします。
以降のセクションでは、これらの質問、特にワークロードがサーバーレスに適しているかどうかという質問に答えるのに役立ついくつかの基準について詳しく説明します。前のセクションで説明した Autopilot と Cloud Run の共通点を考えると、技術的な障害やその他の障害がない場合、プラットフォーム間の移行は簡単な作業です。移行オプションの詳細については、Cloud Run から GKE に移行すると Kubernetes から Cloud Run に移行するをご覧ください。
ワークロードのランタイム環境を選択する際は、技術的な考慮事項と組織的な考慮事項を考慮する必要があります。技術的な考慮事項は、アプリケーションまたは Google Cloudランタイム環境の特性です。組織に関する考慮事項は、意思決定に影響する可能性がある組織またはチームの非技術的な特性です。
技術的な考慮事項
プラットフォームの選択に影響する技術的な考慮事項には、次のようなものがあります。
- 制御と構成可能性: 実行環境の制御の粒度。
- ネットワーク トラフィック管理とルーティング: ネットワークを介したインタラクションの構成可能性。
- 水平方向と垂直方向のスケーラビリティ: 容量の動的な増減をサポートします。
- ステートフル アプリケーションのサポート: 永続的な状態を保存する機能。
- CPU アーキテクチャ: さまざまな CPU タイプのサポート。
- アクセラレータのオフロード（GPU と TPU）: 専用ハードウェアにコンピューティングをオフロードする機能。
- メモリ、CPU、その他のリソース容量が多い: 消費されるさまざまなリソースのレベル。
- Kubernetes への明示的な依存関係: Kubernetes API の使用に関する要件。
- マルチテナンシー用の複雑な RBAC: プールされたリソースの共有をサポートします。
- コンテナタスクの最大タイムアウト時間: 長時間実行されるアプリケーションまたはコンポーネントの実行時間。
以降のセクションでは、ランタイム環境の選択に役立つ技術的な考慮事項について詳しく説明します。
管理と構成可能性
GKE Autopilot では、Cloud Run と比較して、ワークロードの実行環境をより細かく制御できます。Pod のコンテキスト内で、Kubernetes には、アプリケーションの要件を満たすように調整できる構成可能なプリミティブが多数用意されています。構成オプションには、権限レベル、サービス品質パラメータ、コンテナ ライフサイクル イベントのカスタム ハンドラ、複数のコンテナ間のプロセス名前空間の共有などがあります。
Cloud Run は、Kubernetes Pod API サーフェスのサブセットを直接サポートしています。これについては、Cloud Run Service オブジェクトのリファレンス YAML と Cloud Run Job オブジェクトのリファレンス YAML で説明されています。これらのリファレンス ガイドは、アプリケーションの要件に沿って 2 つのプラットフォームを評価する際に役立ちます。
Cloud Run 実行環境のコンテナ契約は比較的単純で、ほとんどのサービング ワークロードに適しています。ただし、契約には、満たす必要のある要件がいくつか指定されています。アプリケーションまたはその依存関係がこれらの要件を満たせない場合や、実行環境をより細かく制御する必要がある場合は、Autopilot の方が適している可能性があります。
構成と管理に費やす時間を短縮するには、ランタイム環境として Cloud Run を選択することを検討してください。Cloud Run には Autopilot よりも構成オプションが少ないため、デベロッパーの生産性を最大化し、運用オーバーヘッドを削減できます。
ネットワーク トラフィックの管理とルーティング
Cloud Run と GKE Autopilot はどちらも Google Cloud Load Balancing と統合されています。ただし、GKE Autopilot には、サービス間通信のネットワーキング環境を構成するための豊富で強力なプリミティブ セットも用意されています。構成オプションには、Namespace とネットワーク ポリシー、ポートの再マッピング、クラスタ内の組み込み DNS サービス ディスカバリを使用した、ネットワーク層でのきめ細かい権限と分離が含まれます。GKE Autopilot は、高度に構成可能で柔軟な Gateway API もサポートしています。この機能により、クラスタ内のサービスとの間のトラフィックのルーティング方法を強力に制御できます。
Autopilot は高度に構成可能であるため、ネットワークの相互依存度が高い複数のサービスがある場合や、アプリケーション コンポーネント間のトラフィックのルーティング方法に関する複雑な要件がある場合に最適なオプションとなります。このパターンの例としては、複雑な相互依存パターンを持つ多数のマイクロサービスに分解された分散アプリケーションがあります。このようなシナリオでは、Autopilot ネットワーキング構成オプションを使用すると、サービス間のインタラクションを管理および制御できます。
水平方向と垂直方向のスケーラビリティ
Cloud Run と GKE Autopilot はどちらも、サービスとジョブの手動および自動の水平スケーリングをサポートしています。水平スケーリングでは、必要に応じて処理能力を増強し、不要になったら追加した処理能力を削除します。一般的なワークロードの場合、Cloud Run は通常、GKE Autopilot よりも迅速にスケールアウトして、1 秒あたりのリクエスト数の急増に対応できます。たとえば、動画デモ「サーバーレス コンピューティングの新機能」では、は、Cloud Run が約 10 秒で 0 から 10,000 を超えるインスタンスにスケーリングすることを示しています。Kubernetes で水平スケーリングの速度を上げるために（追加費用が発生します）、Autopilot では追加のコンピューティング容量をプロビジョニングできます。
インスタンスを追加して使用可能なリソースのレベルを増やすことでアプリケーションをスケーリングできない場合は、Autopilot の方が適している可能性があります。Autopilot は垂直スケーリングをサポートしており、アプリケーションの実行中のインスタンス数を増やすことなく、使用可能な処理能力を動的に変更できます。
Cloud Run は、アプリケーションが使用されていないときにレプリカを自動的にゼロにスケールダウンできます。これは、費用最適化に特に重点を置く特定のユースケースに役立ちます。アプリケーションをゼロにスケーリングする方法の特性により、リクエストの到着からアプリケーションが起動して実行され、リクエストを処理できるようになるまでの時間を最小限に抑えるために、複数の最適化手順を実行できます。
ステートフル アプリケーションのサポート
Autopilot は、Persistent Disk を基盤とする完全な Kubernetes Volume サポートを提供します。これにより、セルフマネージド データベースを含む幅広いステートフル デプロイを実行できます。Cloud Run と GKE Autopilot の両方で、Filestore や Cloud Storage バケットなどの他のサービスに接続できます。どちらも、Cloud Storage FUSE を使用してオブジェクト ストア バケットをファイル システムにマウントする機能を備えています。
Cloud Run はインメモリ ファイル システムを使用します。これは、永続的なローカル ファイル システムを必要とするアプリケーションには適していない可能性があります。また、ローカルのインメモリ ファイル システムは、アプリケーションのメモリと共有されます。したがって、エフェメラル ファイル システムとアプリケーションおよびコンテナのメモリ使用量の両方が、メモリ上限の枯渇に寄与します。サイズの上限が設定された専用のインメモリ ボリュームを使用すると、この問題を回避できます。
Cloud Run サービスまたはジョブコンテナには、最大タスク タイムアウトがあります。Autopilot クラスタの Pod 内で実行されているコンテナは、Pod Disruption Budget（PDB）で構成された制約に従って、再スケジュールできます。ただし、ノードの自動アップグレードやスケールダウン イベントによって生じるエビクションから保護されている場合、Pod は最大 7 日間実行できます。通常、タスク タイムアウトは、Cloud Run のバッチ ワークロードで考慮される可能性が高くなります。長期間のワークロードや、タスクの最大期間内に完了できないバッチタスクの場合は、Autopilot が最適なオプションになる可能性があります。
CPU アーキテクチャ
すべての Google Cloud コンピューティング プラットフォームは、x86 CPU アーキテクチャをサポートしています。Cloud Run は Arm アーキテクチャ プロセッサをサポートしていませんが、Autopilot は Arm アーキテクチャに基づくマネージド ノードをサポートしています。ワークロードに Arm アーキテクチャが必要な場合は、Autopilot を使用する必要があります。
アクセラレータへのオフロード
Autopilot は、GPU の使用と TPU の使用をサポートしています。これには、予約済みリソースを使用する機能も含まれます。Cloud Run は、いくつかの制限付きで GPU の使用をサポートしています。
メモリ、CPU、その他のリソース要件が高い
GKE Autopilot のリソース リクエストの上限と比較すると、1 つの Cloud Run サービスまたはジョブ（1 つのインスタンス）で消費できる CPU リソースとメモリリソースの最大値は制限されています。ワークロードの特性によっては、Cloud Run に、使用可能なリソースを制限する他の上限が適用される場合があります。たとえば、Cloud Run では、起動タイムアウトとアウトバウンド接続の最大数が制限される場合があります。Autopilot では、一部の上限が適用されない場合や、許可される値が大きくなる場合があります。
Kubernetes への明示的な依存関係
一部のアプリケーション、ライブラリ、フレームワークには、Kubernetes への明示的な依存関係がある場合があります。Kubernetes の依存関係は、次のいずれかの結果である可能性があります。
- アプリケーションの要件（たとえば、アプリケーションが Kubernetes API を呼び出す、または Kubernetes のカスタム リソースを使用する）。
- アプリケーションの構成またはデプロイに使用されるツール（Helm など）の要件。
- サードパーティのクリエイターまたはサプライヤーのサポート要件。
これらのシナリオでは、Cloud Run が Kubernetes をサポートしていないため、Autopilot がターゲット ランタイム環境になります。
マルチテナンシー用の複雑な RBAC
組織に特に複雑な組織構造やマルチテナンシーの要件がある場合は、Autopilot を使用して Kubernetes のロールベース アクセス制御（RBAC）を活用します。より簡単なオプションとして、Cloud Run に組み込まれているセキュリティ機能と分離機能を使用できます。
組織に関する考慮事項
環境の選択に影響する組織的な考慮事項には、次のようなものがあります。
- 広範な技術戦略: 組織の技術的な方向性。
- Kubernetes エコシステムの活用: OSS コミュニティの活用に関心がある。
- 既存の社内ツール: 特定のツールを現在使用している。
- 開発チームのプロファイル: デベロッパーのスキルセットと経験。
- 運用サポート: 運用チームの機能と重点。
以降のセクションでは、環境の選択に役立つ組織的な考慮事項について詳しく説明します。
広範な技術戦略
組織やチームは、特定のテクノロジーを他のテクノロジーよりも優先する戦略に合意している場合があります。たとえば、サーバーレスまたは Kubernetes のいずれかで可能な限り標準化するという合意がチームにある場合、その合意はターゲット ランタイム環境に影響を与えるか、またはターゲット ランタイム環境を決定する可能性があります。
特定のワークロードが、戦略で指定されたランタイム環境に適していない場合は、次のいずれかを行うことができます。ただし、注意点があります。
- ワークロードを再設計する。ただし、ワークロードが適していない場合、パフォーマンス、費用、セキュリティ、その他の特性が最適化されない可能性があります。
- 戦略的方向性の例外としてワークロードを登録する。ただし、例外を過度に使用すると、テクノロジー ポートフォリオが不均一になる可能性があります。
- 戦略を再検討する。ただし、そうするとポリシーのオーバーヘッドが発生し、進行が妨げられたり、ブロックされたりする可能性があります。
Kubernetes エコシステムの活用
前述の広範な技術戦略の一環として、組織やチームは、エコシステムが大きく成長していることから、Kubernetes をプラットフォームとして選択することがあります。この選択は、前のセクションの Kubernetes への明示的な依存関係で説明したように、技術的なアプリケーションの依存関係のために Kubernetes を選択することとは異なります。Kubernetes エコシステムの使用を検討する際には、活発なコミュニティ、豊富なサードパーティ ツール、強力な標準とポータビリティが重視されます。Kubernetes エコシステムを活用することで、開発速度を加速し、製品化までの時間を短縮できます。
既存の社内ツール
場合によっては、組織またはチームの既存のツール エコシステムを使用する方が有利なこともあります（どの環境でも）。たとえば、Kubernetes を使用している場合は、ArgoCD などのデプロイツール、Gatekeeper などのセキュリティとポリシーのツール、Helm などのパッケージ管理を引き続き使用できます。既存のツールには、組織のコンプライアンス自動化のための確立されたルールや、代替ターゲット環境の実装に費用がかかる、または長いリードタイムが必要となるその他の機能が含まれている場合があります。
開発チームのプロファイル
アプリケーション チームまたはワークロード チームが Kubernetes の経験がある場合、Autopilot でのチームのベロシティと機能が向上する可能性があります。チームが新しいランタイム環境に習熟するまでには時間がかかることがあります。運用モデルによっては、スキルアップ期間中にプラットフォームの信頼性が低下する可能性があります。
成長中のチームの場合、採用能力が組織のプラットフォームの選択に影響する可能性があります。市場によっては、Kubernetes のスキルを持つ人材が不足しているため、採用コストが高くなる可能性があります。Cloud Run などの環境を選択すると、採用プロセスを効率化し、予算内でチームをより迅速に成長させることができます。
運用サポート
ランタイム環境を選択する際は、SRE、DevOps、プラットフォーム チーム、その他の運用スタッフの経験と能力を考慮してください。信頼性の観点から、本番環境を効果的にサポートする運用チームの能力は重要です。また、運用チームが本番環境前の環境をサポートして、ダウンタイム、手動プロセスへの依存、煩雑なデプロイ メカニズムによってデベロッパーのベロシティが妨げられないようにすることも重要です。
Kubernetes を使用している場合は、中央オペレーション チームまたはプラットフォーム エンジニアリング チームが Autopilot Kubernetes のアップグレードを処理できます。アップグレードは自動的に行われますが、通常、運用スタッフはワークロードの中断を最小限に抑えるために、アップグレードを注意深くモニタリングします。一部の組織では、コントロール プレーンのバージョンを手動でアップグレードすることを選択しています。GKE には、複数のクラスタにまたがるアプリケーションの管理を効率化して簡素化する機能も含まれています。
Autopilot とは異なり、Cloud Run では継続的な管理オーバーヘッドやコントロール プレーンのアップグレードは必要ありません。Cloud Run を使用すると、運用プロセスを簡素化できます。単一のランタイム環境を選択することで、運用プロセスをさらに簡素化できます。複数のランタイム環境を使用する場合は、チームがそれらのランタイム環境をサポートする能力、機能、関心を持っていることを確認する必要があります。
選択
選定プロセスを開始するには、さまざまな関係者と話し合います。アプリケーションごとに、開発者、運用スタッフ、中央テクノロジー ガバナンス グループの代表者、内部アプリケーション ユーザーとコンシューマ、セキュリティ、クラウド財務最適化チーム、組織内のその他の関連するロールまたはグループで構成されるワーキング グループを編成します。情報収集アンケートを配布してアプリケーションの特性をまとめ、セッションの前に結果を共有することもできます。必要な関係者のみを含む小規模なワーキング グループを選択することをおすすめします。すべての作業セッションにすべての担当者が必要なわけではありません。
Autopilot または Cloud Run、あるいはその両方でアプリケーションを構築して実行した経験のある他のチームやグループの代表者を含めることも有用です。このドキュメントの技術的および組織的な考慮事項を使用して、会話をガイドし、各プラットフォームに対するアプリケーションの適合性を評価します。
数か月後にチェックインをスケジュールして、新しい環境にアプリケーションをデプロイした結果に基づいて、決定を確認または再検討することをおすすめします。
次のステップ
- これらのランタイム環境の詳細については、GKE Autopilot Qwik Startと Cloud Run ラボをご覧ください。
- Cloud Run から GKE への移行と Kubernetes から Cloud Run への移行の詳細を確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Henry Bell | クラウド ソリューション アーキテクト
その他の寄稿者:
- Marco Ferrari | クラウド ソリューション アーキテクト
- Gari Singh | アウトバウンド プロダクト マネージャー
- Maridi (Raju) Makaraju | サポート性に関するテクニカル リーダー
- Parag Doshi | キー エンタープライズ アーキテクト
- Daniel Stamer | カスタマー エンジニア、デジタル ネイティブ
- Steren Giannini | グループ プロダクト マネージャー
- Victor Szalvay | シニア プロダクト マネージャー
- William Denniss | グループ プロダクト マネージャー