これがクラウドランです: Windows の開発者のための意思決定ガイド 7,8,10,11

私はスパゲッティを壁に投げてくっつくかどうか見るのが好きです.

私の最高のプロジェクトのいくつかはまさにそのようにして始まりました. 土曜日の朝のアイデア, ランチまでにデプロイされたコンテナ, 夕食までに友人と共有した URL. インフラストラクチャ計画がない, プロビジョニングチケットなし, 単一行のビジネスロジックを作成する前に、VPC 構成を介して 3 日間の寄り道をする必要はありません. コードを書くだけ, 展開する, 終わり.

それぞれが走り続けたクラウドラン.

私にとって, Cloud Run が私の頼りです, それがどこにも行かない可能性のある週末の実験であっても、クライアントのための実稼働ソリューションであっても. 複数回, Cloud Run 上に構築した簡単なデモは、最終的に実際の本番システムに成熟しました, まったく同じセットアップで実行されている.

最近の例: AIで何かを構築するたびに, 簡単にバイブコード化されたプロトタイプでも, LLM API 呼び出しを安全に保ち、資格情報キーを公衆の目から遠ざけるためのサーバー側コンポーネントが必要です. Cloud Run はこれに最適です. 数分で HTTPS による安全なバックエンドが完成します, インフラストラクチャについてはまったく考える必要がありませんでした. プロトタイプは動作します, 鍵は安全です, そしてプロジェクトが現実的なものに成長したら, バックエンドはすでに本番環境に対応しています.

実際のユーザーで何かをテストする前に、インフラストラクチャの準備に数日かかるという考えは、私には常に後ろ向きに感じられました。. できるだけ早く何かをライブにできると信じています, それを人の前に出す, そして それから さらなる投資に値するかどうかを判断する.

でもこの記事はラブレターではありません. 実際のアーキテクチャ上の決定を下すための理解を提供したいと考えています: Cloud Run が正しい選択となるのはいつですか, そしてそれはいつではないでしょうか? 実際にボンネットの下に何があるか見てみましょう, 無料で得られるもの, その境界はどこにあるのか, Kubernetes への移行を検討すべき時期. 最後までに, Cloud Run が次のプロジェクトに属するかどうかがわかります, それとも全く別のことに手を伸ばすべきなのか.

クラウドランとは?

Cloud Run は、フルマネージドのサーバーレスプラットフォームです。グーグルクラウドコンテナを実行するもの. コードを与えると, URLが表示されます. プロビジョニングするクラスターがありません, 管理するノードがない, ロードバランサーを構成する必要はありません. コードを持ってきてください; それ以外はすべて Google が対応します.

しかし、Cloud Run が他のものと異なるのは、その核となる約束です: 概念実証を実行するのと同じ構成で本番環境に移行できます.

それについて少し考えてください. ほとんどのクラウドサービスでは、2 つのバケットのいずれかに強制的に割り当てられます。: プロトタイプ作成に「手っ取り早い」オプションを使用するか、後で破棄する必要があります, または、実稼働グレードの環境を構築するために、インフラストラクチャのセットアップに数日を事前に投資します。. Cloud Run はそのトレードオフを拒否します. 週末のプロジェクトと本番ワークロードは同じプラットフォームで実行されます, 同じセキュリティで, 同じスケーリング, 同じ導入モデル.

誰もあなたのサービスを使用していないとき? ゼロまでスケールします. あなたは何も支払いません. つまり、10 個の実験的サービスを立ち上げることができます, 1か月間放置してください, そして請求額はまさにゼロです.

では、Cloud Run はサーバーレス環境のどこに位置するのでしょうか。? 仮想マシンではありません, OSを管理していない. Kubernetes クラスターではありません, ノードやポッドを管理しない. それは関数ではありません, 15 分のタイムアウトを持つ単一のエントリポイントに制限されません. それは サービスとしてのコンテナー: コンテナ内で実行できるものを提供する, プラットフォームがその他すべてを処理します (配置, スケーリング, ネットワーキング, TLS). コンテナについてすでに知っている場合, イメージを持ち込むと Cloud Run で実行されます. そうしないと? ソースコードを指定するだけで、Cloud Run がパッケージ化してデプロイします。. HTTP フレームワークを管理したくない場合でも、, Cloud Runの機能関数を作成して個別にデプロイできるようにする, Cloud Run がそれぞれをサーバーにラッピングします. どちらにしても, 最終的にサービスが実行されることになります.

カーテンの向こうには何があるのか?

Cloud Run を使用するためにこれを理解する必要はありません. しかし、その根底にあるものを知れば説明がつくなぜデフォルトは本番グレードであり、なぜ信頼できるのか.

ボーグ: Google の内部エンジン

Cloud Run は別の環境では実行されません, 実績の低いインフラストラクチャ. 直接実行されますボーグ, Google の内部クラスタ管理システム. Gmail を動かしているのと同じシステム, YouTube, Google検索, および他のほぼすべての Google サービス. Borg は 10 年以上にわたって生産されています, 配備する 週あたり数十億個のコンテナ 数万台のマシンのクラスター全体.

ボーグに聞き覚えがあるなら, それはすべきです. それは直接の前身でした Kubernetes. 同じエンジニアとアーキテクチャのコンセプトの多くが引き継がれています. しかし、Kubernetes は私たちのために構築されたオープンソースバージョンですが、, Borg は、現在も社内で Google を運営している歴戦のオリジナルです.

これはコンテナにとって何を意味しますか? これは、同じスケジュールを継承することを意味します, フェイルオーバー, Google が自社製品のために信頼しているリソース管理. これは、あなたのサービスが Google の恩恵を受けられることを意味します。 BeyondProd ゼロトラストセキュリティフレームワーク, 信頼がコードの出所とサービス ID に依存する場合, ネットワークの場所ではありません. つまり、 Borg の Binary Authorization レビューのみを検証します, 適切に構築されたコードがインフラストラクチャにデプロイされる.

要するに: コンテナは Gmail と同じインフラストラクチャ上で実行されます.

ナイブ: API レイヤー

Cloud Run の API は以下に基づいていますネイティブのサービング, 元々は Kubernetes 上でサーバーレスワークロードを実行するために Google によって開始されたオープンソースプロジェクト. ただし、Cloud Run は「マネージド Knative」ではありません. Borg 上に Knative Serving API を再実装します。, その下に Kubernetes が存在しない.

実践的なポイント: Knative YAML マニフェストを使用してサービスを定義する場合, この定義は、Cloud Run と Kubernetes 上の自己ホスト型 Knative の間で移植可能です。. そして、内部には Kubernetes が存在しないため、, クラスターの管理に伴う複雑さの負担がかかりません.

gVisor とコンテナのサンドボックス化

すべての Cloud Run インスタンスはサンドボックス化されています 2層の絶縁: 標準コンテナのような Linux 名前空間や cgroup だけではありません, しかし、その上にハードウェアによる仮想化が組み込まれています.

Cloud Run は 2 つの実行環境を提供します:

Gen1 (gバイザーベース): gバイザー Google が開発したオープンソースのコンテナサンドボックスです. ユーザー空間カーネルとして機能します, コンテナのシステムコールをインターセプトして再実装する Go で書かれたプロセス, そのため、ホストカーネルが直接公開されることはありません. これにより、攻撃対象領域が小さくなり、コールドスタートが高速化されます。, ただし、通常とは異なるシステムコールに依存する一部のソフトウェアには互換性がない可能性があります。.

Gen2 (Linux microVMベース): gVisor の代わりに, Gen2 は、完全な Linux カーネルを備えた軽量仮想マシン内でコンテナを実行します。. 完全なシステムコール互換性が得られます, CPU とネットワークのパフォーマンスの持続性が向上, ただし、コールドスタートが少し長くなります.

どちらの環境も同じ 2 層アプローチを使用します: ハードウェアに裏付けられた 仮想マシンモニター (VMM) インスタンス間の境界, プラスソフトウェアカーネル層 (gVisor または microVM). たとえ誰かがコンテナサンドボックスから脱出する方法を見つけたとしても, 彼らは依然としてハードウェア仮想化の境界に直面することになる.

サービスごとに選択します. 価格は同一です. ほとんどの開発者はそれについて考える必要はありません. 実行環境を指定しない場合, Cloud Run は、サービスが使用する機能に基づいて自動的に選択します。.

実稼働対応のデフォルト

これらを何も知らなくても Cloud Run を快適に使用できます. しかし、誰かが「Cloud Run は本番環境に対応していますか?」と尋ねると、?」, 答えは「おそらく」ではありません。すべてのインスタンス間のハードウェアによる分離, ゼロトラストセキュリティ, 実証済みのスケジュール設定. 硬化してきます.

箱から出してすぐに手に入るもの

1 つのデプロイコマンドで得られるものは次のとおりです, 単一の構成ファイルに触れる前に:

$ gcloud rundeploy my-api --source . --リージョン us-central1 --allow-unauthenticated

Dockerfile を使用して構築し、コンテナを Cloud Run サービスにデプロイする [私のAPI] プロジェクト内 [私のプロジェクト] 地域 [米国中央1]
✓ 構築と展開。. 終わり.
  ✓ ソースをアップロードしています。.
  ✓ コンテナの構築...
  ✓ リビジョンを作成しています。.
  ✓ トラフィックのルーティング...
終わり.
サービス [私のAPI] リビジョン [私のAPI-00001-ABC] 導入され、サービスを提供しています 100 トラフィックの割合.
サービスURL: https://my-api-abc123-uc.a.run.app

その URL はライブです, 負荷分散された, 自動スケーリング, 管理された TLS 証明書で保護されています. 何が含まれているかを見てみましょう.

安全 (ゼロ構成)

すべての Cloud Run サービスは自動的に:

管理された TLS 証明書を使用した HTTPS. すべての *.run.app URL は、自動プロビジョニングを使用して HTTPS 経由で提供されます。, 自動更新された証明書. パブリックエンドポイントでプレーン HTTP を提供するオプションはありません. 安全でないサービスを誤って展開することはできません.
DDoS保護. の Google フロントエンド (GFE) すべての Cloud Run サービスの前に配置されます, Google 独自のサービスを保護するのと同じ DDoS 保護を適用します.
ハードウェアによるコンテナ分離. 「カーテンの裏側」セクションで説明したように、, すべてのインスタンスは VMM 境界の背後でサンドボックス化されます. これは名前空間の分離ではありません, それは仮想化レベルの分離です.
どこでも暗号化. Google が管理する鍵を使用して保存時のデータを暗号化. Google Cloud サービス間のすべてのトラフィックは転送中に暗号化されます. これはデフォルトであり、常にオンです.
私は-ベースのアクセス制御. すべてのサービスは Google Cloud IAM と統合されます. デフォルトでは, サービスには認証が必要です. 次の方法でパブリックアクセスを明示的にオプトインします。 –許可されていない.

スケーリング (ゼロ構成)

デフォルトでゼロまでスケールする. 渋滞なし? インスタンスがありません. 費用はかかりません. これはデフォルトの動作です, あなたはそれを設定しません, あなたはそれを有効にしていません. それはちょうどうまくいきます.
までの自動スケール 100 デフォルトのインスタンス. Cloud Run は 2 つの主要なシグナルを自動的に評価します: 同時実行のリクエスト (ターゲティング 60% 設定された最大値の) とCPU使用率 (ターゲティング 60%). 実際の需要に基づいてスケールアップおよびスケールダウンします. デフォルトの上限は 100 インスタンスはより上位に構成可能です. それを視野に入れると: サービスが一度に 1 つのリクエストを処理し、突然リクエストが急増した場合 80 同時ユーザー, Cloud Run が大まかに起動する 80 負荷を吸収するインスタンス, その後、トラフィックが減少するとスケールダウンします.
アイドル状態のインスタンスの保持. 最後のリクエストの後, インスタンスは最長でアイドル状態に保たれる場合があります 15 終了される数分前. これにより、コールドスタートを行わずにトラフィックのバーストを吸収します。. 細かい部分が実際に大きな違いを生む.
起動時のCPUブースト. インスタンスの起動時, Cloud Run が一時的に 2 倍になる (以上) 初期化を高速化するための CPU 割り当て. 設定されたサービス 2 vCPU は次のようにブーストされます 4 起動時および起動時の vCPU 10 数秒後. Google が報告したところによると、 50% この機能を有効にすると、Java/Spring アプリケーションの起動時間が短縮されます。.

可観測性 (ゼロ構成)

自動ロギング. コンテナが stdout と stderr に書き込むものはすべて、自動的にキャプチャされます。クラウドロギング. インストールするエージェントがありません, サイドカーを設定する必要はありません. Write structured JSON logs and they're automatically parsed into searchable fields. 例えば, のようなJSON行 {"severity":"ERROR", "message":"connection refused", "sessionId":"abc-123", "userId":"user-42"} Cloud Logging コンソールで完全にフィルタ可能なログエントリになります. つまり、JSON ペイロードに任意のカスタムフィールドを追加できるということです。 (セッションID, ユーザーID, トレースをリクエストする, 機能フラグ) その後、その正確なフィールドでログをフィルタリングします. 特定のユーザーの問題をデバッグする? Filter by jsonPayload.userId="user-42" すべてのインスタンスにわたるそのユーザーのすべてのログエントリを取得します.
組み込みのメトリクス. クラウドモニタリングリクエスト数を自動的に追跡します, レイテンシの分布, CPU使用率, メモリ使用率, とインスタンス数. これらは設定なしで Cloud Run コンソールに表示されます.
監査ログは常にオンになっています. 管理アクティビティ監査ログ誰が何を導入したかを記録する, いつ, そしてどのような構成で. これらは常に有効になっており、オフにすることはできません.

インフラストラクチャー (ゼロ構成)

組み込みの負荷分散. リクエストはインスタンス間で自動的に分散されます. プロビジョニングまたは構成するロードバランサーが不要.
ダウンタイムゼロの導入. すべてのデプロイメントで新しい不変が作成されますリビジョン. トラフィックは、起動プローブを通過した後にのみ新しいリビジョンに切り替わります. 古いインスタンスは処理中のリクエストを処理し続ける. 導入戦略を構成する必要はありません. それはただ起こる. そして、リビジョンは不変であり、存続するため、, あなたはできるトラフィックを分割する彼らの間で. 送信 5% 新しいリビジョンへのトラフィックの 95% 現在のものに残ります, メトリクスを監視する, そして徐々にシフトしていきます. デプロイメントツールを使用しないカナリアデプロイメント.
自動ヘルスチェック. Cloud Run はデフォルトで TCP 起動プローブを構成します: コンテナがトラフィックを送信する前に、予想されるポートでリッスンするのを待ちます。. サービスは実際に準備が整うまでリクエストを受け取りません.
OSのパッチ適用とランタイムのメンテナンス. 基盤となる OS にパッチを適用することはありません, カーネル, またはランタイム. Google はコンテナの下にあるインフラストラクチャスタック全体を処理します.

クラウドラン機能: よりシンプルな道

上記はすべて Cloud Run に当てはまります サービス, 容器を持ち込むところ (またはソースコード) HTTPサーバーを実行する. しかし、HTTP フレームワークをまったく扱いたくない場合はどうすればよいでしょうか?

Cloud Runの機能それはすべてスキップさせてください. 関数を書くのはあなたです, そのうちの 1 つにデプロイメントを指定します, Cloud Run はそれを HTTP サーバーに自動的にラップします. ソースコードでは好きなだけ関数を定義できます. 各展開は 1 つのエントリポイントとして機能します, によって指定される –機能フラグ. 同じコードベース, 複数の展開, それぞれに独自の URL が付いています.

インポート関数_フレームワーク
@functions_framework.http
確かにこんにちは(リクエスト):
    名前 = request.args.get("name", "World")
    return f"Hello, {名前}!"

gcloud run デプロイ hello-func \
  --ソース . \
  --関数こんにちは \
  --基本イメージ python312 \
  --リージョン us-central1

それでおしまい. フラスコなし, FastAPIではない, Dockerfileがありません. Cloud Run がコンテナを構築する, HTTPサーバーを挿入します, そしてそれを展開します. 同じスケーリングが得られます, 同じセキュリティ, 完全な Cloud Run サービスと同じ構成ゼロのオブザーバビリティ.

これが次のように聞こえる場合クラウド機能, ここに歴史があります. Cloud Functions 第 1 世代は古いバージョンで実行されていました, 厳しい制限のある個別のインフラストラクチャ: 9-分のタイムアウト, インスタンスごとに 1 つのリクエスト, 同時実行性なし. クラウド機能第 2 世代 (得 2022) 内部的にはすでに Cloud Run の上に構築されていました, これにより、60 分のタイムアウトと複数リクエストの同時実行のロックが解除されました。. で 2024, Googleはそれを公式にし、第2世代を次のようにブランド名を変更しました Cloud Runの機能, すべてを Cloud Run 名の下に統合する. つまりこれは新製品ではありません. インフラはすでに統一されているという認識です. 関数がデプロイメントごとに 1 エントリポイントのモデルを超えてしまい、ルーティングが必要な場合, ミドルウェア, または単一の URL の背後にある複数のエンドポイント, 同じプラットフォーム上のフルサービスと交換する. 移行なし, 新しいインフラストラクチャはありません.

関数をいつ使用するか. サービス: Cloud Run の機能は単一目的のエンドポイントに最適です: Webhook, イベントハンドラー, 軽量 API, スケジュールされたタスク. 私自身のワークフローの良い例: AI を活用したフロントエンドアプリを構築するとき, クライアントから LLM API を直接呼び出すことはありません. つまり、API キーをブラウザに送信することになります。. その代わり, フロントエンドと LLM プロバイダの間に Cloud Run 機能をデプロイします. この関数はユーザーの権限を検証します, サーバー側で私の資格情報を使用して LLM 呼び出しを行います, そして応答を返します. 私のキーはサーバーから離れることはありません. セットアップには数分かかります, これはまさに、関数が最適な単一目的のエンドポイントです。. 複数のルートが必要な瞬間, ミドルウェア, または同じサービス内のバックグラウンド処理, 独自の HTTP フレームワークを備えた完全な Cloud Run サービスにより、その制御が可能になります. どちらが「優れている」という問題ではありません。重要なのはモデルを仕事に適合させることです.

サポートされているランタイムには Node.js が含まれます, パイソン, 行く, ジャワ, .ネット, ルビー, とPHP.

Cloud Run ジョブ: 完了まで実行

Cloud Run のサービスと機能はリクエスト主導型です: 彼らはトラフィックを待ってそれに応答します. しかし、すべてのワークロードがそのモデルに適合するわけではありません. 夜間のデータベースエクスポートについてはどうですか, 画像変換のバッチ, または 100 万行を処理して終了するデータパイプライン?

それが Cloud Run ジョブのためのものです. リクエストを聞く代わりに, ジョブはコンテナを最後まで実行して停止します. HTTPエンドポイントがありません, トラフィックに基づくスケーリングなし. あなたはそれに何をすべきかを教えます, それはそれをします, そして完了です.

gcloud run jobs create my-etl-job \
  --画像 us-docker.pkg.dev/my-project/repo/etl:v1 \
  --タスク 100 \
  --タスクタイムアウト30分 \
  --最大再試行回数 3 \
  --リージョン us-central1

gcloud run jobs を実行 my-etl-job --region us-central1

最初のコマンドはジョブを作成します. 2番目はそれを実行します. ジョブを実行することもできますスケジュール通りに使用してクラウドスケジューラ, または、ワークフローやイベント駆動型のパイプラインからトリガーします。.

の –タスクフラグが興味深いところです. ジョブは最大で実行できます 10,000 並列タスク, それぞれが CLOUD_RUN_TASK_INDEX 環境変数を受け取ります (0 を通して 9,999) そのため、どの作業部分を処理すべきかを知ることができます. 100万枚の画像を処理する必要がある? でジョブを作成します 1,000 タスク, それぞれの処理 1,000 画像. Cloud Run はそれらを並行して実行します, 失敗したものはすべて再試行します (まで –最大再試行回数), そして結果を報告します.

タスクのタイムアウトは最大です 168 時間 (7 日), または 1 GPU で 1 時間, サービスの 60 分のリクエストタイムアウトとの比較. これにより、ジョブは完了までに数時間かかるワークロードに自然に適合します。.

雇用はサービスと同じインフラストラクチャの利点を享受できます: 同じボーグのスケジュール, 同じコンテナの隔離, 同じスケーリング. 違いは実行モデルです. サービスは長期間存続し、リクエスト主導型です. ジョブは一時的でタスク主導型である. どちらもファーストクラスの Cloud Run ワークロードタイプです.

Cloud Run が正しい選択ではない場合

すべてのプラットフォームには境界があります. Cloud Run は過去 2 年間で大幅に縮小 (サイドカー, GPUのサポート, ボリュームマウント, そしてワーカープールはすべて着陸しました), しかし本当の限界はまだ残っている. 事前にそれらを知っておくと、プロジェクトを開始してから 6 か月後に、プラットフォーム上に構築するのではなく、プラットフォームと格闘しているという痛ましい認識から解放されます。.

設計による無国籍性

Cloud Run インスタンスは一時的です. いつでも作成したり破棄したりできます. アーキテクチャで次のいずれかが必要な場合, トレードオフを理解する必要がある:

インスタンスのライフサイクルを超えたローカルディスクの永続性. ローカルファイルシステムは一時的です. インスタンスがなくなったとき, ディスク上のすべても同様です. そうは言っても, Cloud Run がマウントをサポートするようになりました FUSE 経由の Cloud Storage バケットそして Filestore 経由の NFS ファイル共有, 永続的な共有ストレージへの読み取り/書き込みアクセスを許可します。. Cloud Storage のマウントは最終的に一貫性のあるものになります (ファイルロックなし, 最後の書き込みが勝ちます), 一方、Filestore は完全な POSIX セマンティクスを提供します. どちらもローカルディスクではありません, しかし、多くのユースケースではギャップを埋めることができます.
インスタンス間で共有されるインメモリキャッシュ. デフォルトではスティッキーセッションはありません (けれどセッションアフィニティベストエフォートベースで利用可能です). 各リクエストは異なるインスタンスにヒットする可能性があります. 共有状態が必要な場合, 次のような外部ストアが必要ですレディスまたはメモリーストア.
約 60 分を超えても存続する必要がある WebSocket 接続. Cloud Run は WebSocket をサポートします, セッションアフィニティと組み合わせると、リアルタイムアプリケーションにうまく機能します。. ただし、接続はおよそに制限されます 60 分 (最大のリクエストタイムアウト). 数時間または数日間存続する接続が必要な場合, 専用のインフラストラクチャが必要です.
HTTP トリガーを使用せずに長時間実行されるバックグラウンドワーカー. Cloud Run サービスはリクエスト主導型です. でもこの境界線は柔らかくなりつつある: Cloud Run ワーカープール (現在プレビュー中) Kafka コンシューマーや Pub/Sub サブスクライバーなどのプルベースのワークロード向けに設計されています, パブリック HTTP エンドポイントは必要なく、最大 40% 標準サービスよりも低価格な料金設定.

真にステートフルなワークロードを必要とするチーム (デプロイ間で存続する必要があるウォームキャッシュを使用して提供される ML モデル, 永続的な接続を備えたゲームサーバー 60 分) 探す GKE の永続ボリュームと StatefulSet はより正確に適合します.

マルチコンテナのサポート: 以前よりも良くなった, Kubernetes ではありません

Cloud Run がサポートされるようになりましたマルチコンテナインスタンス (サイドカー). まで走ることができます 10 同じネットワーク名前空間とメモリ内ボリュームを共有するインスタンスごとのコンテナ. これにより、ランニングなどのパターンが可能になりますリバースプロキシとしてのNginx, OpenTelemetry コレクターカスタムメトリクスの場合, 交通管理特使, または Prometheus によるメトリクスのエクスポート.

ただし、完全な Kubernetes ポッドトポロジではありません. 主な違い:

受信 HTTP トラフィックを受信するコンテナーは 1 つだけです (「入口コンテナ」). サイドカーは外部リクエストを独立して処理できません.
初期化コンテナはありません. 起動順序を制御できます (サイドカーはイングレスコンテナの前に開始されます), ただし、Kubernetes init コンテナとは異なります, サイドカーは走り続ける. メインコンテナが開始される前に実行が完了することはありません.
最大 10 インスタンスあたりのコンテナ数.

ほとんどのサイドカーパターンの場合 (プロキシ, 可観測性エージェント, ログプロセッサ), Cloud Run の実装で十分です. init コンテナと複数の Ingress ポイントを備えた複雑なポッドトポロジの場合, GKE が依然としてその答えです.

ネットワーキングの深さ

Cloud Run のネットワークは次のように改善されました。 VPC の直接下り (コネクタを使用せずにインスタンスを VPC に直接配置する), しかしチームは依然として壁にぶつかっている:

サービスメッシュの要件. それに対してそして Anthos サービスメッシュ GKE のネイティブである. Cloud Run で Envoy サイドカーを実行できます, ただし、mTLS を使用したフルサービスメッシュ, トラフィックポリシー, サービス間の可観測性は別の話です.
ポッド間の直接通信 ロードバランサーを経由せずに.
カスタムネットワークポリシー ゼロトラスト内部セグメンテーション用.
マルチクラスタルーティングとトラフィックミラーリング.

アーキテクチャに高度なネットワークトポロジや厳格な内部トラフィック制御が含まれる場合, GKE がノブを提供します. Cloud Run は、制御を犠牲にしてシンプルさを実現します.

コールドスタートの経済性

クラウドランの最小インスタンス数コールドスタートを軽減する機能, そして起動時のCPUブースト初期化中に CPU を一時的に 2 倍にし、インスタンスの準備をより速くします. 多くのワークロードに対応, これら 2 つの機能を組み合わせると、コールドスタートが問題になりません。.

ただし、レイテンシー要件が厳しく、インスタンスを常時稼働状態に保つことになる場合は、, サーバーレスのコストモデルを失った. 常時稼働のコンピューティングの料金を支払っていることになります. とにかく、常時稼働インスタンスの料金を支払うと、, 経済的な議論は GKE に移る, リソースのパッキングをより詳細に制御できる場所, ノード使用率, 同じクラスターを共有する複数のサービスにわたるコストの最適化.

ワークロードの異質性

Cloud Run は主に HTTP/gRPC ワークロードをターゲットとしています, 拡大し続けているにもかかわらず. Cloud Run ジョブバッチ処理を処理する, そして GPUのサポートゼロスケールの経済性で AI/ML 推論を可能にします. NVIDIA L4 (24 GBのVRAM) 一般に入手可能です, そしてNVIDIA RTX PRO 6000 ブラックウェル (96 GBのVRAM) プレビューで利用可能です.

しかし、チームが必要とする瞬間:

デーモンセット ノードレベルの操作の場合
優先クラスとプリエンプションポリシー
インスタンスごとに複数の GPU (Cloud Run は 1 つだけをサポートします)
シングル GPU の容量を超える大規模モデル (L4 24 GB VRAM ではパラメータが最大 9B に制限されます, RTX PROですが 6000 と 96 GB VRAM はプレビューでこれを大幅に拡張します)

…GKE が自然にフィットする. Cloud Run は実行内容について独自の意見を持っています. その意見は広がり続ける, しかしそれには限界がある.

移行パス: Cloud Run から Kubernetes へ

良いニュースです: Cloud Run で開始し、後で Kubernetes に移行する必要がある場合, 移行パスは簡単です, 少なくともコンテナ自体に関しては.

Docker イメージを使用してデプロイした場合, 同じイメージを変更せずに GKE で実行します. コンテナは、Cloud Run と Kubernetes のどちらで実行されているかを知りません。. ポートでリッスンします, HTTPリクエストに応答します, それで終わりです.

ソースコードからデプロイした場合 (Cloud Run のビルドパックベースのデプロイメントを使用する), Docker イメージへの変換は簡単です. すでに動作しているプロジェクトに Dockerfile を追加しようとしています. アプリケーションコード, 依存関係, 実行時の動作, それは何も変わりません. You're just making the packaging step explicit instead of letting buildpacks handle it.

しかし、ここからが正直な部分です: コンテナは移行の難しい部分ではありません. 再設計は、.

Kubernetes に移行しようとしています なぜなら Cloud Run にはないものが必要な場合: 複雑なポッドトポロジ, フルサービスメッシュ, マルチ GPU 推論, または無制限の接続存続期間. つまり、単にコンテナを移動するだけではありません; アーキテクチャを進化させています. Cloud Run 上のメモリ内キャッシュは、GKE 上の永続ボリュームを基盤とする Redis クラスタになります. Envoy サイドカーを備えた単一の Ingress コンテナーは、init コンテナーを備えたポッドになります, ネットワークポリシー, カスタムスケジュールルール. コンテナイメージはそのまま残ります; 周りのすべてが変化します.

容器は持ち運び可能. アーキテクチャはそうではないかもしれません. それでいいです. それは正しいトレードオフです. Cloud Run ですぐに始められる, 実際のユーザーを使ってアイデアを検証する, ソリューションに対する自信を築きます. 上で説明した限界に達したとき, 実績のあるコンテナと、実際に何が必要なのかを明確に理解した状態で、Kubernetes を卒業できます。.

Cloud Run は行き止まりではない. それは意図的な出発点です.

結論

意思決定の枠組みは次のとおりです:

Cloud Run から始めましょう コンテナ化されたサービスを構築していて、インフラストラクチャを気にせずに迅速に移行したい場合.
Cloud Run を使い続ける ワークロードがそのモデルに適合している限り: ステートレス, リクエスト主導型, プラットフォームが自然に処理するスケーリングのニーズに対応.
GKE を卒業 限界に達したとき. やってみれば分かるよ, プラットフォームの上に構築するのではなく、プラットフォームと戦うことになるからです.

コンテナは移植性の単位です. 最終的に Cloud Run に移行するかどうか, NGO, または完全に別のプラットフォーム, 構築と梱包に費やした労力は決して無駄になりません. これは Cloud Run に限ったことではありません. それはコンテナ全体のパワーです. ただし、Cloud Run は、コンテナが本番環境で動作することを証明するために私が見つけた最速の方法です, 通常必要な先行投資なしで.

一部 2 もうすぐ来ます. 実践してみます: Cloud Run にデプロイするさまざまな方法 (予想以上にたくさんあります), CPU を調整できる構成オプション, メモリ, スケーリング, ネットワーキング, 特定のニーズに合わせたセキュリティと. 見逃さないようにフォローしてください.

リソース

これがクラウドランです: 開発者向けの意思決定ガイドは、もともと Google Developer Experts on Medium で公開されました。, 人々がこのストーリーをハイライトして応答することで会話を続けている場所.