このドキュメントでは、技術的な考慮事項と組織的な考慮事項に基づいて、アプリケーション要件を評価し、Cloud Run と Google Kubernetes Engine（GKE）Autopilot のどちらを選択するかを説明します。このドキュメントは、ワークロードに Google Cloud ターゲット コンテナ ランタイム環境を選択する必要があるクラウド アーキテクトを対象としています。Kubernetes と Google Cloud に精通していること、Cloud Run、Cloud Run 関数、AWS Lambda などのクラウド サーバーレス ランタイム環境に関する知識があることを前提としています。
Google Cloud には、さまざまな機能を備えた複数のランタイム環境オプションが用意されています。次の図は、Google Cloud マネージド サービスの範囲を示しています。
この図は次のことを示しています。
ほとんど管理対象のランタイム環境（このガイドの対象）:
これらのオプションは Google によって管理され、基盤となるコンピューティング インフラストラクチャはユーザーが管理しません。
最小限に管理されたランタイム環境:
- GKE Standard: エンタープライズ ワークロード向けに最適化されており、最大 15,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 はワークロードの実行環境をより細かく制御できます。Kubernetes には、Pod のコンテキスト内で、アプリケーション要件に合わせて調整できる構成可能なプリミティブが多数用意されています。構成オプションには、権限レベル、サービス品質パラメータ、コンテナのライフサイクル イベント用のカスタム ハンドラ、複数のコンテナ間のプロセス Namespace の共有などがあります。
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 には、サービス間通信用のネットワーキング環境を構成するための豊富で強力なプリミティブ セットも用意されています。構成オプションには、namespaces とネットワーク ポリシー、ポート リマッピング、クラスタ内の組み込み DNS サービス ディスカバリを使用して、ネットワーク レイヤできめ細かい権限と分離を行うことが含まれます。GKE Autopilot は、高度に構成可能で柔軟な Gateway API もサポートしています。この機能により、クラスタ内のサービス間およびクラスタ内のサービスへのトラフィックのルーティング方法を強力に制御できます。
Autopilot は高度に構成可能なため、ネットワーキングの相互依存性が高く、アプリケーション コンポーネント間でのトラフィック ルーティング方法に関する複雑な要件がある場合は、最適なオプションです。このパターンの例としては、相互依存の複雑なパターンを持つ多数のマイクロサービスに分解された分散アプリケーションがあります。このようなシナリオでは、Autopilot ネットワーキング構成オプションを使用して、サービス間のインタラクションを管理および制御できます。
水平方向と垂直方向のスケーラビリティ
Cloud Run と GKE Autopilot はどちらも、サービスとジョブの手動と自動の水平スケーリングをサポートしています。水平方向のスケーリングでは、必要に応じて処理能力を増やし、必要がなくなったら追加の処理能力を削除します。一般的なワークロードの場合、Cloud Run は通常、GKE Autopilot よりも迅速にスケールアウトして、1 秒あたりのリクエスト数の急増に対応できます。たとえば、動画デモの 「サーバーレス コンピューティングの新機能」をご覧ください。Cloud Run が約 10 秒でゼロから 10,000 を超えるインスタンスにスケーリングしています。Kubernetes での水平スケーリングの速度を上げるために（追加費用を支払って）Autopilot で追加のコンピューティング容量をプロビジョニングできます。
アプリケーションでインスタンスを追加して利用可能なリソースのレベルを増やすことでスケーリングできない場合は、Autopilot の方が適している可能性があります。Autopilot は垂直スケーリングをサポートしており、アプリケーションの実行中インスタンスの数を増やすことなく、使用可能な処理能力の量を動的に変更できます。
Cloud Run は、アプリケーションが使用されていないときに、アプリケーションをレプリカ 0 に自動的にスケールダウンできます。これは、費用の最適化に重点を置いた特定のユースケースに役立ちます。アプリケーションをゼロにスケーリングする方法の特性により、リクエストの到着からアプリケーションが稼働し、リクエストを処理できるようになるまでの時間を最小限に抑えるために、複数の最適化手順を実施できます。
ステートフル アプリケーションのサポート
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
組織の組織構造やマルチテナンシーの要件が特に複雑な場合は、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 Enterprise には、複数のクラスタにまたがるアプリケーションの管理を効率化、簡素化する機能も含まれています。
Autopilot とは対照的に、Cloud Run では、継続的な管理オーバーヘッドやコントロール プレーンのアップグレードが必要ありません。Cloud Run を使用すると、運用プロセスを簡素化できます。1 つのランタイム環境を選択することで、運用プロセスをさらに簡素化できます。複数のランタイム環境を使用する場合は、チームにそれらのランタイム環境をサポートする能力、機能、関心があることを確認する必要があります。
選択
選定プロセスを開始するには、さまざまな関係者と話し合います。アプリケーションごとに、開発者、運用スタッフ、中央技術ガバナンス グループの代表者、内部アプリケーションのユーザーとコンシューマ、セキュリティ、クラウド財務最適化チーム、および関連する可能性のある組織内の他のロールまたはグループで構成されるワーキング グループを編成します。情報収集アンケートを配布して申請の特徴をまとめ、セッションの前に結果を共有することもできます。必要なステークホルダーのみを含む小規模なワーキング グループを選択することをおすすめします。すべての担当者がすべての作業セッションに参加する必要はありません。
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 | カスタマー エンジニア、Digital Natives
- Steren Giannini | グループ プロダクト マネージャー
- Victor Szalvay | シニア プロダクト マネージャー
- William Denniss | グループ プロダクト マネージャー