これがクラウドランです: Configuration For Windows 7,8,10,11

これはパートです 3 「This is Cloud Run」シリーズ. で 一部 1, Cloud Run とは何か、そしてそれをいつ選択するべきかについて説明しました. で 一部 2, 導入オプションとリビジョン管理について説明しました。. さあ、調整しましょう.

Cloud Run のデフォルトは適切です. それについてはパートで説明しました 1. ただし、すべてのワークロードには独自のニーズがあります, Cloud Run はそれらに合わせて調整するためのノブを提供します. この記事では、最も頻繁に使用する設定について説明します.

CPUとメモリ

すべての Cloud Run インスタンスが CPU とメモリを共有します. デフォルト (1 vCPU, 512 MiB) 軽量 API としては妥当です, ただし、ワークロードのニーズを理解したら調整することをお勧めします.

CPU からの範囲 0.08 vCPU (コアの10分の1未満) に 8 vCPU. メモリ からの範囲 128 MiBから 32 GiB. 二人はリンクしている: CPU 割り当てを増やすには、最小メモリしきい値が必要です, 一部のメモリ構成では最小限の CPU が必要です.

しかし、より重要な決定は、 CPU割り当てモード:

リクエストのみ (デフォルト). CPU は、インスタンスがリクエストをアクティブに処理している間のみ割り当てられます。. リクエスト間, CPU がゼロ近くまでスロットルされる. 料金はリクエストの処理にかかった時間に対してのみお支払いいただきます. こちらはサーバーレスモデルです, ほとんどの HTTP API にとってこれは正しい選択です.
常時オン. CPUはいつでも利用可能, リクエストの合間にも. これにはさらに費用がかかります, ただし、リクエスト処理以外の作業を行うワークロードには必要です: 状態を維持する WebSocket 接続, キューを処理するバックグラウンドスレッド, またはメモリ内キャッシュを暖かく保つ必要があるサービス.

gcloud run デプロイ my-service \
  --私のイメージ \
  --CPU 2 \
  --メモリ1Gi \
  --CPU スロットルなし \
  --リージョン us-central1

の –no-cpu-throttling フラグにより CPU の常時稼働が有効になります. それがなければ (または一緒に –CPUスロットリング), デフォルトのリクエスト専用モードが得られます.

価格差は大きい. リクエスト専用割り当ての場合, リクエストの処理中のみ、vCPU 秒および GiB 秒ごとに料金が発生します. 常時オンで, インスタンスのライフサイクル全体に対して料金を支払います. アイドル期間のあるバースト的な HTTP トラフィックを処理するサービスの場合, リクエストのみの場合は大幅に安くなる可能性があります. バックグラウンドタスクを実行するサービス、または WebSocket 接続を維持するサービスの場合, 常時オンが正しく機能する唯一のオプションです.

ヘルスチェック

Cloud Run は準備ができるまでインスタンスにトラフィックを送信しません. デフォルトでは, それはを使用します TCP 起動プローブ: コンテナが予期されたポートでリッスンするのを待ちます, その後、準備ができたとみなします.

ほとんどのサービスについて, それで十分です. ただし、アプリケーションがデータをロードするのに時間が必要な場合は、, ウォームキャッシュ, または、ポートが開いた後にデータベース接続を確立します。, カスタムが欲しくなるでしょう HTTP 起動プローブ:

スタートアッププローブ:
  httpGet:
    パス: /ヘルスズ
    ポート: 8080
  初期遅延秒数: 0
  期間秒: 2
  失敗しきい値: 15

これにより、Cloud Run に /healthz を取得するように指示します 2 秒. 失敗したら 15 回, インスタンスは異常とマークされ、再起動されます. プローブが成功した場合にのみ、インスタンスはトラフィックの受信を開始します。. これにより、 502 errors that happen when a load balancer sends requests to an instance that's technically listening but not yet ready to serve.

Cloud Run もサポート 活性プローブ 起動後も継続して実行されるもの. liveness プローブが失敗した場合, Cloud Run がインスタンスを再起動します. スタックしたプロセスの検出に役立ちます, デッドロック, または、コンテナはクラッシュしないが応答しなくなるメモリリーク.

のために gRPC サービス, Cloud Run は、次の gRPC ヘルスチェックプローブをサポートしています。 gRPC ヘルスチェックプロトコル.

リクエストのタイムアウト

すべての Cloud Run リクエストには、タイムアウト. デフォルトは 300 秒 (5 分). 最大値は 3600 秒 (60 分).

gcloud run デプロイ my-service \
  --私のイメージ \
  --タイムアウト 600 \
  --リージョン us-central1

サービスが大きなファイルのアップロードを処理する場合, レポートを生成します, または長時間実行される計算を実行する, これを増やしたくなるでしょう. しかし、覚えておいてください: タイムアウトはリクエストごとに適用されます. 1 つのリクエストにタイムアウトよりも長い時間がかかる場合, Cloud Run が終了する. WebSocket 接続もこのタイムアウトの影響を受けます。, だからこそパート 1 約 60 分の接続制限について言及しました.

長時間にわたる作業によくあるパターン: 要求を受け入れる, 処理を非同期で開始する (経由クラウドタスクまたはパブ/サブ), そして、を返します 202 すぐに. クライアントはステータスをポーリングするか、作業が完了するとコールバックを受け取ります. これにより、リクエストのタイムアウトが短くなり、サービスの応答性が向上します。.

定期的に最大 60 分に達してしまう場合, それは、ワークロードがより適している可能性があることを示しています Cloud Run ジョブ (バッチ処理用) または完全に異なるプラットフォーム.

スケーリング: インスタンスと同時実行性

Cloud Run のオートスケーラーは 3 つの関連設定を管理します:

最小インスタンス数 トラフィックがないときにウォーム状態を維持するインスタンスの数を制御します. デフォルトは 0 (ゼロまでスケールする). に設定する 1 or higher eliminates cold starts but means you're paying for idle instances. It's the classic serverless trade-off: レイテンシー vs. 料金. レイテンシの影響を受けやすい実稼働サービス向け, 1 多くの場合、正しい数値です. 開発環境の場合, 0 請求書をゼロに保ちます.

最大インスタンス数 Cloud Run がスケールアップできる範囲の上限. デフォルトは 100. これにより暴走スケーリングから保護されます (そして驚きの請求書) 予期せぬトラフィック急増時. ただし、これは慎重に設定してください: サービスが 20 の接続プールを持つデータベースと通信する場合, 100 すべてのインスタンスが接続しようとすると圧倒されてしまいます. Match your max instances to your backend's capacity.

同時実行性 単一インスタンスが同時に処理するリクエストの数を制御します. デフォルトは 80. This is one of Cloud Run's key advantages over the old Cloud Functions 1st gen model, インスタンスごとに 1 つのリクエストを処理しました. 同時実行時 80, 単一のインスタンスでサービスを提供できる 80 Cloud Run が別のインスタンスを起動する前の同時リクエスト.

各リクエストに専用の処理能力が必要な、CPU 負荷の高いワークロードの同時実行性を下げます。. 上げてください (まで 1000) ほとんどの時間をネットワーク呼び出しの待機に費やす軽量の I/O バウンドハンドラー向け. 同時実行性の設定 1 mimics the one-request-per-instance model if your code isn't thread-safe.

gcloud run デプロイ my-service \
  --私のイメージ \
  --最小インスタンス数 1 \
  --最大インスタンス数 10 \
  --同時実行性 80 \
  --リージョン us-central1

そして覚えておいてください起動時のCPUブーストパートから 1: Cloud Run はインスタンスの初期化中に CPU を一時的に 2 倍にし、インスタンスの準備を迅速化します. 最小インスタンスとの組み合わせ, これにより、コールドスタートはほとんどのワークロードで問題になりません。.

環境変数とシークレット

Cloud Run は、コンテナに構成を渡すための 2 つのメカニズムをサポートしています, 仕事に適したものを使用することが重要です.

環境変数 非機密構成用です: 機能フラグ, APIエンドポイント, ロギングレベル, データベースのホスト名. デプロイ時に設定します。 –環境変数の設定:

gcloud run デプロイ my-service \
  --私のイメージ \
  --set-env-vars "DB_HOST=10.0.0.1,LOG_LEVEL=info,ENV=本番環境" \
  --リージョン us-central1

これは次のとおりです 12-ファクターアプリ方法論: 構成は環境内に存在します, コードにない.

秘密機密性の高い認証情報用です: APIキー, データベースのパスワード, TLS証明書, OAuth クライアントシークレット. これらは、 一度もない プレーンな環境変数であること. プレーン環境変数は Cloud Run コンソールに表示されます, デバッグログに現れる, エラーレポートに漏洩する可能性があります. その代わり, に保管してくださいシークレットマネージャーデプロイ時にそれらを参照します:

gcloud run デプロイ my-service \
  --私のイメージ \
  --set-secrets "API_KEY=my-api-key:最新" \
  --set-secrets "/secrets/tls.key=tls-private-key:最新" \
  --リージョン us-central1

シークレットは環境変数またはファイルとしてマウントできます。. 上記の最初の例では、シークレットを API_KEY という環境変数としてマウントします。. 2 つ目は、/secrets/tls.key にファイルとしてマウントします。. シークレットはバージョン管理されています, IAM経由でアクセス制御される, 監査ログに記録される. 秘密が漏洩した場合, Secret Manager でローテーションして再デプロイします. コードの変更はありません.

ボリュームマウント

Cloud Run インスタンスは一時的です, ただし、一時的なストレージや共有ファイルへのアクセスが必要な場合もあります。. Cloud Run は 3 種類のボリュームマウント:

インメモリボリューム are tmpfs-style mounts backed by your instance's RAM. They're fast but volatile (インスタンスが終了すると消滅する) メモリ制限に対してカウントします. 一時ファイルの処理に便利, ファイルをダウンロードするような, それを変える, そして結果をアップロードする:

gcloud run デプロイ my-service \
  --私のイメージ \
  --追加ボリューム名=スクラッチ,タイプ=メモリ内,サイズ制限=256Mi \
  --追加ボリュームマウントボリューム=スクラッチ,マウントパス=/tmp/work \
  --リージョン us-central1

クラウドストレージFUSE をマウントしますクラウドストレージローカルファイルシステムとしてのバケット. コードは通常どおりファイルの読み取りと書き込みを行います, そして GCS ヒューズこれらのオペレーションを Cloud Storage API 呼び出しに変換します:

gcloud run デプロイ my-service \
  --私のイメージ \
  --追加ボリューム名=モデル,type=クラウドストレージ,バケット=my-ml-models \
  --add-volume-mount volume=モデル,マウントパス=/mnt/models \
  --リージョン us-central1

キャッチ: それは結局一貫している. ファイルロックなし, 最後の書き込みが勝ちます. 共有アセットの読み取りに適しています (ML モデル, 設定ファイル) またはアーティファクトを書く (ログ, 輸出). 同じファイルへの同時書き込みには適さない.

Filestore経由のNFS あなたに完全に与えます POSIX-適切なファイルロックを備えた準拠したネットワークファイルシステム. ランダム読み取りの場合、GCS FUSE よりも低いレイテンシー. 必要 VPC 接続以来ファイルストアインスタンスは VPC 上に存在します. ファイルレベルの一貫性を備えた共有読み取り/書き込みアクセスを必要とするワークロードに最適.

ほとんどの Cloud Run サービスの場合, これらはどれも必要ありません. しかし、そうするときは (画像処理パイプライン, ML モデルの提供, インスタンス間で構成を共有する), 回避策を構築する手間を省きます.

ネットワーク構成

Cloud Run のネットワークのデフォルトはシンプルです: あなたのサービスは公開されています, アウトバウンドトラフィックのためにインターネットに接続します. しかし、さらに制御が必要な場合には, 設定する領域は 3 つあります.

イングレス

イングレス設定誰がサービスにアクセスできるかを制御する:

全て (デフォルト). インターネット上のどこからでもトラフィックを受け入れます. パブリック API や Web アプリには最適.
内部. 内部からのトラフィックのみを受け入れます VPC または他の Google Cloud サービスから (のようにパブ/サブ, クラウドスケジューラ, またはクラウドタスク). サービスは公共のインターネットからは見えません. 外部クライアントから直接呼び出すべきではないバックエンドサービスにこれを使用します。.
内部 + クラウド負荷分散. 内部と同じ, しかし、経由のトラフィックも受け入れます。グローバル外部アプリケーションロードバランサ. これはカスタムドメインへのパスです, CDN キャッシュクラウドCDN, と WAF 保護クラウドアーマー. このロードバランサパターンは、以下のカスタムドメインとクラウドアーマーのセクションで再び登場します。.

gcloud run デプロイ my-service \
  --私のイメージ \
  --内部への進入 \
  --リージョン us-central1

Egress と VPC 接続

デフォルトでは, Cloud Run インスタンスはインターネットに直接接続します. ただし、サービスがプライベートリソースにアクセスする必要がある場合は、 (あるクラウド SQL データベース, あるメモリーストア Redis インスタンス, 内部 API), VPC アクセスが必要です.

2 つのオプション:

サーバーレス VPC アクセスコネクタ. 本来のアプローチ. Cloud Run と VPC のブリッジとなるコネクタリソースを作成します。. 作品, ただし、ネットワークホップが追加され、スループット制限があります.
VPC の直接下り. 新しいアプローチ. Cloud Run インスタンスは VPC サブネットに直接配置されます. コネクタは必要ありません, 余分なホップはありません, スループットのボトルネックがない. これは、新規デプロイメントに推奨されるパスです.

新しく始める場合, ダイレクト VPC エグレスを使用する. コネクタを使用した既存のサービスがある場合, 彼らは働き続けるだろう, ただし、都合がよければ移行を検討してください.

カスタムドメイン

すべての Cloud Run サービスは、自動 HTTPS を使用して *.run.app URL を取得します。. しかし、生産に関しては, you'll want your own domain. 2つのパス:

Cloud Run ドメインのマッピング. よりシンプルなオプション. ドメインを Cloud Run サービスに直接マッピングする. SSL 証明書は自動的にプロビジョニングおよび更新されます. api.example.com をサービスに指定するだけで済む簡単なセットアップで機能します.
グローバル外部アプリケーションロードバランサー. より有能なオプション. CDN キャッシュを提供します, クラウドアーマーWAF, マルチリージョンルーティング, さまざまなサービスへの URL ベースのルーティング. さらにセットアップ, しかし、ドメインマッピングだけでは提供できない機能が利用できるようになります。.

セキュリティ構成

Cloud Run のセキュリティのデフォルトは強力です (一部でカバーされています 1). ただし、本番サービスの場合, いくつかの設定をカスタマイズする必要があります.

サービスアカウント

すべての Cloud Run サービスはサービスアカウント, どの Google Cloud リソースにアクセスできるかを決定します. デフォルトでは, Cloud Run はプロジェクトのデフォルトのコンピューティングサービスアカウントを使用します, 通常、広範な権限が付与されます.

生産用, を作成します サービスごとの専用サービスアカウント 必要な権限のみを付与して. サービスが Cloud Storage から読み取り、Pub/Sub に書き込む場合, そのサービスアカウントには storage.objectViewer と pubsub.publisher が必要です. それ以上は何もありません. これは最小特権の原則です, サービスが侵害された場合の爆発範囲を制限します.

gcloud run デプロイ my-service \
  --私のイメージ \
  --サービスアカウント [email protected] \
  --リージョン us-central1

IAM認証

デフォルトでは, Cloud Run には認証が必要です. すべてのリクエストには有効な ID トークンが含まれている必要があります, 呼び出し元は、サービスに対するroles/run.invokerロールを持っている必要があります。. これはサービス間通信の正しいデフォルトです.

一般向けサービスの場合 (API, Webhook, ウェブアプリ), 明示的にオプトアウトするには、roles/run.invoker ロールを allUsers に付与します。:

gcloud run services add-iam-policy-binding my-service \
  --member="allUsers" \
  --role="roles/run.invoker" \
  --リージョン us-central1

ただし、非認証アクセスが有効になっている場合でも、, アプリケーションコードに独自の認証層を実装できます. Cloud Run はトランスポートセキュリティを処理します (HTTPS) およびプラットフォームレベルのアイデンティティ (IAM 実行者チェック). アプリはアプリケーションレベルの ID を処理します: ユーザーログイン, APIキー, JWTの検証.

バイナリ認証

バイナリ認証デプロイ時ポリシーを適用します: CI/CD パイプラインによって署名されたコンテナーイメージのみをデプロイできます。. これにより、テストされていないイメージを運用環境に直接デプロイすることができなくなります。, たとえそのための IAM 権限を持っていたとしても.

これは、コンプライアンス要件や厳格な変更管理プロセスを持つ組織にとって意味のあるガバナンスの層です。.

クラウドアーマー

クラウドアーマー Google Cloud の WAF です (ウェブアプリケーションファイアウォール). Cloud Run サービスの前に配置され、強制的に実行できます。:

IP 許可リストと拒否リスト
地理的制限
クライアントごとのレート制限
事前設定された WAF ルール (SQLインジェクション, XSS, 等)

Cloud Armor には、グローバル外部アプリケーションロードバランサ Cloud Run サービスの前で. ロードバランサーを使用せずにデフォルトの *.run.app URL を使用している場合, Cloud Armor isn't available. ただし、サービスが公開されており、機密データを処理する場合は、, ロードバランサ + Cloud Armor の組み合わせは追加セットアップの価値があります.

結論

Cloud Run には、実際のワークロードに合わせて調整するための十分な構成ノブが用意されています. ただし、一度にすべてに触れる必要はありません.

私がオススメするパターン: デフォルトから始める. サービスをデプロイする, 実際のトラフィックの下でどのように動作するかを確認してください, それから調整します. 限界に達している場合はメモリを増やしてください. リクエストが CPU 負荷の高い場合は同時実行性を下げる. 起動が遅い場合はヘルスチェックを追加する. 本番環境に移行する前に専用のサービスアカウントを設定する. すべての変更は次のデプロイメントで有効になります, ダウンタイムゼロで. 永続的なものは何もない.

パートの場合 1 についてでした かどうか Cloud Run はアーキテクチャに属します, とパート 2 についてでした コードをそこに取り込む, この記事はについてです 特定のニーズに合わせてうまく機能するようにする. シンプルに始める. ワークロードで必要な場合に複雑さを追加する, 以前はなかった.

シリーズに参加するだけなら, 一部 1 始める場所です.

リソース

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