このドキュメントでは、技術的および組織的な考慮事項に基づいて、アプリケーション要件を評価し、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内に緊密に統合されているため、両者には多くの共通点があります。どちらのプラットフォームも、信頼性とスケーラビリティに優れた 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: プールされたリソースの共有をサポートします。
- コンテナ タスクの最大タイムアウト時間: 実行時間の長いアプリケーションまたはコンポーネントの実行時間。
以降のセクションでは、ランタイム環境の選択に役立つ技術的な考慮事項について詳しく説明します。
制御と構成可能性
Cloud Run と比較して、GKE Autopilot ではワークロードの実行環境をより細かく制御できます。Pod のコンテキスト内で、Kubernetes はアプリケーションの要件を満たすように調整できる構成可能なプリミティブを多数提供します。構成オプションには、権限レベル、サービス品質パラメータ、コンテナ ライフサイクル イベントのカスタム ハンドラ、複数のコンテナ間のプロセス Namespace の共有などがあります。
Cloud Run は、Cloud Run Service オブジェクトのリファレンス YAML と Cloud Run Job オブジェクトのリファレンス YAML で説明されている Kubernetes Pod API サーフェスのサブセットを直接サポートしています。これらのリファレンス ガイドは、アプリケーションの要件に沿って 2 つのプラットフォームを評価する際に役立ちます。
Cloud Run 実行環境のコンテナ契約は比較的単純で、ほとんどのサービング ワークロードに適しています。ただし、契約には満たす必要のある要件がいくつか規定されています。アプリケーションまたはその依存関係がこれらの要件を満たせない場合、または実行環境をより細かく制御する必要がある場合は、Autopilot の方が適している可能性があります。
構成と管理にかかる時間を短縮したい場合は、Cloud Run をランタイム環境として選択することを検討してください。Cloud Run は Autopilot よりも構成オプションが少ないため、デベロッパーの生産性を最大化し、運用オーバーヘッドを削減できます。
ネットワーク トラフィックの管理とルーティング
Cloud Run と GKE Autopilot は、どちらも Google Cloud Load Balancing と統合されています。ただし、GKE Autopilot には、サービス間通信のネットワーキング環境を構成するための豊富で強力なプリミティブのセットも用意されています。構成オプションには、名前空間とネットワーク ポリシーを使用したネットワーク レイヤでのきめ細かい権限と分離、ポートの再マッピング、クラスタ内の組み込み 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 のリソース リクエストの上限と比較して、単一の Cloud Run サービスまたはジョブ（単一のインスタンス）で使用できる CPU とメモリのリソースの上限は制限されています。ワークロードの特性によっては、Cloud Run に使用可能なリソースを制限する他の上限が設定されている場合があります。たとえば、起動タイムアウトとアウトバウンド接続の最大数は Cloud Run で制限されることがあります。Autopilot では、一部の制限が適用されないか、許容値が高くなる場合があります。
Kubernetes への明示的な依存関係
一部のアプリケーション、ライブラリ、フレームワークには、Kubernetes への明示的な依存関係がある場合があります。Kubernetes の依存関係は、次のいずれかの結果である可能性があります。
- アプリケーションの要件（アプリケーションが Kubernetes API を呼び出す、または Kubernetes カスタム リソースを使用するなど）。
- アプリケーションの構成またはデプロイに使用されるツール（Helm など）の要件。
- サードパーティのクリエイターまたはサプライヤーのサポート要件。
このようなシナリオでは、Cloud Run は Kubernetes をサポートしていないため、Autopilot がターゲット ランタイム環境になります。
マルチテナンシーの複雑な RBAC
組織の構造が特に複雑な場合や、マルチテナンシーに関する要件がある場合は、Kubernetes のロールベース アクセス制御（RBAC）を利用できるように、Autopilot を使用します。よりシンプルなオプションとして、Cloud Run に組み込まれているセキュリティと分離機能を使用できます。
組織に関する考慮事項
環境の選択に影響する組織上の考慮事項を次に示します。
- 広範な技術戦略: 組織の技術的な方向性。
- Kubernetes エコシステムの活用: OSS コミュニティの活用に関心がある。
- 既存の社内ツール: 特定のツールを既存のユーザーが使用している。
- 開発チームのプロフィール: デベロッパーのスキルセットと経験。
- 運用サポート: 運用チームの能力と重点。
以降のセクションでは、環境の選択に役立つように、組織に関するこれらの考慮事項について詳しく説明します。
広範な技術戦略
組織やチームによっては、特定のテクノロジーを他のテクノロジーよりも優先する戦略に合意している場合があります。たとえば、チームが可能な限りサーバーレスまたは Kubernetes のいずれかに標準化するという合意がある場合、その合意がターゲット ランタイム環境に影響を与えたり、ターゲット ランタイム環境を決定したりする可能性があります。
特定のワークロードが戦略で指定されたランタイム環境に適していない場合は、次の 1 つ以上を行うことを検討してください。ただし、次の点に注意してください。
- ワークロードを再設計する。ただし、ワークロードに適合しない場合は、パフォーマンス、費用、セキュリティなどの特性が最適化されない可能性があります。
- ワークロードを戦略的方向性に対する例外として登録します。ただし、例外を過度に使用すると、テクノロジー ポートフォリオがばらばらになる可能性があります。
- 戦略を再検討する。ただし、この方法では、進行を妨げたりブロックしたりするポリシー オーバーヘッドが発生する可能性があります。
Kubernetes エコシステムの活用
前述の広範な技術戦略の一環として、組織やチームは、大規模で成長を続けるエコシステムを理由に、Kubernetes をプラットフォームとして選択する場合があります。この選択は、前のセクションの Kubernetes への明示的な依存関係で説明したように、技術的なアプリケーションの依存関係のために Kubernetes を選択することとは異なります。Kubernetes エコシステムを使用する際の考慮事項では、活発なコミュニティ、豊富なサードパーティ製ツール、強力な標準と移植性が重視されます。Kubernetes エコシステムを活用することで、開発速度を向上させ、市場投入までの時間を短縮できます。
既存の社内ツール
場合によっては、組織またはチームの既存のツール エコシステム（任意の環境）を使用することが有利になることがあります。たとえば、Kubernetes を使用している場合は、ArgoCD などのデプロイ ツール、Gatekeeper などのセキュリティとポリシーのツール、Helm などのパッケージ管理ツールを引き続き使用することを選択できます。既存のツールには、組織のコンプライアンス自動化や、代替ターゲット環境に実装するのにコストがかかるか、長いリードタイムが必要になる可能性のあるその他の機能に関する確立されたルールが含まれている場合があります。
開発チームのプロフィール
アプリケーション チームやワークロード チームは、Kubernetes の経験があるため、チームの速度と Autopilot の提供能力を向上させることができます。チームが新しいランタイム環境に精通するまでには時間がかかることがあります。オペレーティング モデルによっては、アップスキリング期間中にプラットフォームの信頼性が低下する可能性があります。
チームの成長に伴い、採用能力が組織のプラットフォーム選択に影響する可能性があります。市場によっては、Kubernetes のスキルを持つ人材が不足しているため、採用にプレミアム料金が必要になることがあります。Cloud Run などの環境を選択すると、採用プロセスを効率化し、予算内でチームをより迅速に成長させることができます。
運用サポート
ランタイム環境を選択する際は、SRE、DevOps、プラットフォーム チームなどの運用スタッフの経験と能力を考慮してください。運用チームが本番環境を効果的にサポートする能力は、信頼性の観点から非常に重要です。また、運用チームが本番環境移行前の環境をサポートし、ダウンタイム、手動プロセスへの依存、煩雑なデプロイ メカニズムによってデベロッパーの速度が妨げられないようにすることも重要です。
Kubernetes を使用している場合は、中央の運用チームまたはプラットフォーム エンジニアリング チームが Autopilot Kubernetes のアップグレードを処理できます。アップグレードは自動で行われますが、通常、運用スタッフはワークロードの中断を最小限に抑えるために、アップグレードを綿密にモニタリングします。一部の組織では、コントロール プレーンのバージョンを手動でアップグレードしています。GKE Enterprise には、複数のクラスタにわたるアプリケーションの管理を効率化し、簡素化する機能も含まれています。
Autopilot とは対照的に、Cloud Run では継続的な管理オーバーヘッドやコントロール プレーンのアップグレードは必要ありません。Cloud Run を使用すると、運用プロセスを簡素化できます。単一のランタイム環境を選択することで、運用プロセスをさらに簡素化できます。複数のランタイム環境を使用する場合は、チームがそれらのランタイム環境をサポートする能力、機能、関心を持っていることを確認する必要があります。
選択
選択プロセスを開始するには、さまざまな関係者と話し合います。各アプリケーションについて、開発者、運用スタッフ、中央テクノロジー ガバナンス グループの代表者、内部アプリケーションのユーザーとコンシューマー、セキュリティ、クラウド財務最適化チーム、および組織内のその他の関連するロールまたはグループで構成されるワーキング グループを編成します。情報収集アンケートを配布してアプリケーションの特性を収集し、セッションの前に結果を共有することもできます。必要なステークホルダーのみを含む小規模なワーキング グループを選択することをおすすめします。すべての担当者がすべての作業セッションで必要になるわけではありません。
Autopilot または Cloud Run、あるいはその両方でアプリケーションの構築と実行の経験がある他のチームやグループの代表者を含めることも有効です。このドキュメントの技術的および組織的な考慮事項を使用して、会話をガイドし、各プラットフォームに対するアプリケーションの適合性を評価します。
数か月後にチェックインをスケジュールして、新しい環境にアプリケーションをデプロイした結果に基づいて、決定を確認または再検討することをおすすめします。
次のステップ
- これらのランタイム環境の詳細については、GKE Autopilot クイック スタートと 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 | グループ プロダクト マネージャー