サービスを選ぶ

コンピューティングの選び方

コンテナで動くなら Cloud Run から検討し、Kubernetes が要件にあれば GKE、OS やライセンスに手を入れる必要があれば Compute Engine を選びます。管理の少ないサービスでは満たせない条件があるかを、上から順に確かめるのが判断の軸です。

アプリを動かす場所は、Google に任せる範囲が広い順に Cloud Run functions、Cloud Run、GKE、Compute Engine、Google Cloud VMware Engine と並びます。Google はマネージドなサービスを優先するよう推奨しているので、PCA では同じ要件を満たせるなら管理の少ないほうが正解です。

右へ行くほど自分で管理する層が増えます。OS の行が「自分」になるのは Compute Engine と VMware Engine だけです。GKE は Autopilot の場合です。

判断の順序

次の問いを上から確かめ、最初に「はい」になったサービスを選びます。

vSphere で動く環境を、構成を変えずに移すか。はいなら VMware Engine。
OS の種類や設定、カーネル、ライセンス、GPU を載せた長時間の計算など、VM の中身を自分で決めるか。はいなら Compute Engine。
Kubernetes の API やエコシステム (Helm、オペレーター、サービスメッシュ) が要件か。はいなら GKE。
コンテナにでき、HTTP のリクエストかジョブとして終わるか。はいなら Cloud Run。
Cloud Storage へのアップロードや Pub/Sub のメッセージなど、イベント 1 件ごとに短い関数を動かすだけか。はいなら Cloud Run functions。

どれにも当たらなければ、まずコンテナにして Cloud Run で動かせないかを検討し直します。

上の問いほど、管理の少ないサービスでは満たせない条件です。最初の「はい」で止まり、下の問いは確かめません。

試す実行環境を絞り込む

1. vSphere の環境

2. OS の管理

3. Kubernetes

4. 処理の形

5. イベントごとの関数

1. vSphere の環境を構成を変えずに移すかいいえ
2. OS やライセンスなど VM の中身を自分で決めるかいいえ
3. Kubernetes の API やエコシステムが要件かいいえ
4. コンテナにでき、HTTP かジョブとして終わるかはい
5. イベント 1 件ごとに短い関数を動かすだけか確かめない

選ばれたサービス

Cloud Run

Google Cloud VMware EnginevSphere の VM をそのまま移す要件がない。
Compute EngineOS、カーネル、ライセンスに手を入れる要件がない。管理の少ないサービスを優先する。
GKE (まず Autopilot)Kubernetes が要件にない。コンテナを動かすだけなら Cloud Run のほうが管理が少ない。
Cloud Run functionsイベント 1 件ごとに関数を動かす形。HTTP やジョブとして動くコンテナは Cloud Run で動かす。

コンテナで HTTP のリクエストを受ける処理で、Kubernetes も OS の管理も要らない。インスタンスは 0 まで減り、使った分だけ払う。

4 と 5 は境目が近く、どちらでも動く要件が多いです。関数 1 つで書けてイベントの種類で起動したいなら Cloud Run functions、コンテナのイメージを自分で作って管理したいなら Cloud Run です。

Cloud Run: サービスとジョブ

Cloud Run は、コンテナイメージを渡すとリクエスト数に合わせてインスタンスを増減させるサーバーレスの実行環境です。リクエストがなければ 0 まで減り、使った分だけ払います。問題文に「サーバーを管理したくない」「トラフィックが予測できない」「コンテナ化済み」とあれば第一候補です。

サービスは HTTP に応答する形で、リクエストのタイムアウトは既定 5 分、最長 60 分です。ジョブはリクエストを受けずに処理して終わる形で、タスクのタイムアウトは既定 10 分、最長 168 時間 (7 日) です。夜間の集計のように HTTP では時間が足りない処理はジョブにします。VPC の中の DB へのつなぎ方はVPC の設計で扱います。

Cloud Run functions は、関数のコードを渡すと Google がコンテナにビルドし、Cloud Run のサービスとしてデプロイする仕組みです。Cloud Functions の後継で、公式の比較によると Eventarc が扱うすべてのイベントをトリガーにできます。実体は Cloud Run なので、性能や制約も同じです。

GKE はまず Autopilot

GKE はマネージドな Kubernetes です。既に Kubernetes で運用している、数十のマイクロサービス間の通信を細かく制御したい、オンプレミスや他クラウドと同じ構成で動かしたい、という要件で選びます。コンテナを動かすだけなら Cloud Run のほうが管理は少なく、「運用の負担を最小に」という問題で GKE を選ぶと多くの場合は誤りです。

Autopilot はノードを Google が管理し、多くの場合 Pod が要求したリソースに払います。Standard はノードプールを自分で管理し、ノードの VM に払います。公式ドキュメントは Autopilot を推奨しています。ノードのマシンタイプを固定したいなどの理由がなければ Autopilot です。

Compute Engine: VM の中身を自分で決める

Compute Engine は VM です。オンプレミスのアプリの rehost、Windows Server や特定のディストリビューション、物理コアに紐づくライセンスといった要件で選びます。物理ホストを専有する単一テナントノードは移行の計画で扱います。

マシンタイプは汎用から始めます。vCPU とメモリの比率が合わなければカスタムマシンタイプで個別に指定し、余分な vCPU に払わずに済ませます。
Spot VM は余剰の容量を使い、多くのマシンタイプでオンデマンドより最大 91% 安くなります。いつでも停止 (プリエンプト) されることがあり、SLA の対象外です。止まってもやり直せるバッチ、レンダリング、CI に使い、DB や 1 台だけの Web サーバーには使いません。
同じ構成の VM を並べるなら、インスタンステンプレートからマネージドインスタンスグループ (MIG) を作ります。負荷に応じた自動スケーリング、ヘルスチェックに失敗した VM の作り直し、ローリング更新を MIG が行います。

99.99% が要件なら、1 台の VM では満たせません。リージョン MIG で複数のゾーンに分けます。

Compute Engine の SLA は Premium Tier のネットワークで、単一のインスタンスが 99.9% (メモリ最適化ファミリーは 99.95%)、複数のゾーンに置いたインスタンスが 99.99% です。ゾーンの考え方はリージョン・ゾーンと可用性で読み返してください。

VMware Engine: vSphere のまま移す

Google Cloud VMware Engine は、Google Cloud の中で vSphere、vSAN、NSX などの VMware の環境を専用に動かすサービスです。VM の OS やアプリに手を入れずに移し、運用手順も VMware のまま続けられます。データセンターの契約終了が迫り、作り直す時間がないときに選び、移したあとで Compute Engine やコンテナへ段階的に作り直す計画の最初の一歩にもなります。

試してみる

Cloud Shell で、Google が公開しているサンプルのコンテナを Cloud Run にデプロイします。数回アクセスする程度なら無料枠の範囲で終わります。

gcloud config set project YOUR_PROJECT_ID
gcloud services enable run.googleapis.com

gcloud run deploy hello \
  --image=us-docker.pkg.dev/cloudrun/container/hello \
  --region=asia-northeast1 \
  --allow-unauthenticated

表示される URL をブラウザで開くとサンプルのページが出ます。コンソールの Cloud Run の画面で、アクセスがないときにインスタンス数が 0 に戻ることを確かめてください。

gcloud run services describe hello --region=asia-northeast1 --format='value(status.url)'

終わったらサービスを削除します。

gcloud run services delete hello --region=asia-northeast1 --quiet

試験で問われる判断

以下は、このカリキュラム用に作った例です。

「コンテナ化した Web アプリを運用担当なしで動かしたい。アクセスは平日の日中に集中し、夜間はほぼない」。答えは Cloud Run です。GKE Autopilot も動きますが、Kubernetes が要件にない以上、夜間に 0 まで減る Cloud Run を選びます。

「動画のエンコードを毎晩数百本行う。途中で止まってもやり直せる。費用を最小にしたい」。答えは Spot VM を使った MIG かバッチ処理です。「翌朝 8 時までに必ず終わること」が加わったら、通常の VM と組み合わせます。

「オンプレミスの vSphere 上の 300 台の VM を、改修なしで半年以内に移す」。答えは VMware Engine です。Compute Engine への rehost は VM ごとの変換と検証が要り、期限に合いません。

「Helm チャートで管理しているマイクロサービス群を移したい」。答えは GKE で、ノードを細かく管理する理由がなければ Autopilot です。

次のページでは、アプリが読み書きするデータをどこに置くかを選びます。