はじめに
こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。
Google Cloud で好きなサービスは、圧倒的に Cloud Run です！
この投稿は AoTo Advent Calendar 2024 19日目の記事です。
Google Cloud 上でマネージドな Kubernetes 環境を構築できる Google Kubernetes Engine(GKE) は大規模で柔軟な管理が行えるコンテナオーケストレーションサービスです。
一方、Cloud Run は Kubenetes からより抽象化された Knative 互換の API を利用したマネージドコンテナサービスです。
2023年11月に Cloud Run のマルチコンテナ(サイドカー)機能が GA(一般提供) となり、GKE と Cloud Run の大きな差は縮まり、様々なユースケースで Cloud Run の利用を検討できるようになりました。
公式ドキュメントでは Cloud Run から GKE への移行について触れられていますが、今回は GKE から Cloud Run への移行を検討できる条件とその方法についてまとめています🐶
Cloud Run の特性
Cloud Run に適したアプリケーション
まずは稼働するアプリケーションが Cloud Run に適しているかを確認しましょう。これらの前提条件が合致しない場合は、Cloud Run の利用は検討外です。
- 通信プロトコルは
HTTP,HTTP/2,WebSocket,gRPCを用いる - 高パフォーマンスな永続ファイルストレージを必要としない
- インスタンスごとに8個の CPU と32 GiB のメモリを上限以上のリソースを必要としない
- 厳密なスケーリング戦略を必要としない
以上の制限に該当する場合は、GKE の利用が推奨されます。
ですが、一般的な Kubernetes の利用事例を参照すると、それほど問題なく Cloud Run に移行できる場合があります。特に、Cloud Run のリソース上限は一見厳しそうに見えますが、水平スケールを前提とする Kubernetes Deployments に当てはめると十分に実現可能なことがわかります。
Cloud Run の利点
さらに Cloud Run は高度に抽象化されたマネージドコンテナサービスのため、利用者の管理する部分のほとんどがコンテナに最小化されます。
サービスのリクエストを受信する Ingress コンテナはインスタンスに常に1つのみで、その前段には TLS 終端やDoS 攻撃保護を担う Google Fron End(GFE), Cloud Load Balancing と HTTP 受信リクエストを負荷分散する HTTP プロキシが自動的に配置されます。
Cloud Run はサーバレスでもあるため、そのネットワークも大部分を Google Cloud が管理します。デフォルトではサーバレスネットワークが適用される一方で、プライベートネットワークと Cloud Runを構成する柔軟なオプションが用意されています。
つまり、デフォルトでは IAM 認証や Ingress 制御で HTTP リクエストを制御しながら、Direct VPC Egress や VPC コネクタによる VPC 内のリソースとの統合が可能です。さらに、サーバレスネットワークエンドポイントグループ(NEG)によるネットワークアクセスの効率化・負荷分散や NEG を利用した Cloud Service Mesh の構成など、様々なネットワークオプションを活用し要件に合わせた環境を構築できます。
以下のように Kuberbenets による複雑な構成管理から脱却し、Cloud Run によるマネージドコンテナの恩恵を受けることができる場合は、Cloud Run を GKE の代替としても利用できます。
- 複雑なスケーリング戦略を持たない、外部公開サービス環境
- マルチリージョン冗長が必要な、高可用サービス環境
- ゼロスケールが有効な、ワークロードの波が大きな環境
- マルチコンテナアプリケーションの動作検証環境
GKE からの移行
GKE から移行する場合、単純な Deployment を定義した app.yaml ファイルは以下のように Cloud Run サービスの app.yaml のように書き換えることができます。
-apiVersion: apps/v1
+apiVersion: serving.knative.dev/v1
-kind: Deployment
+kind: Service
metadata:
name: my-app
- namespace: default
+ namespace: PROJECT_NUMBER
labels:
- app: my-app
+ app: cloud.googleapis.com/location: REGION
spec:
template:
metadata:
- labels:
- app: my-app
+ name: REVISION_NAME
+ annotations:
+ autoscaling.knative.dev/minScale: MIN_INSTANCES
+ autoscaling.knative.dev/maxScale: MAX_INSTANCES
spec:
containers:
- image: gcr.io/cloudrun/hello
ports:
- containerPort: 80
env:
- name: HELLO
value: world
- image: gcr.io/datadoghq/agent
env:
- name: SIDECAR
value: woofwoof
- replicas: 3
- selector:
- matchLabels:
- app: my-app
詳細を全て解説はしませんが、Cloud Run は Knative Serving 互換で yaml を記述します。そのため、apiVersion: serving.knative.dev/v1, kind: Service のように Kubernetes では見慣れない内容を記述します。
加えて Cloud Run の構成のために、プロジェクト ID が .metadata.namespace に定義されます。ReplicaSet のような記載は必要なく、Cloud Run インスタンスの最大最小スケーリングを .spec.template.metadata.annotations.autoscaling.knative.dev/ で定義します。
簡略化のため記載を省略していますが、コンテナ定義の ports.containerport, resource.limits, volumeMounts, command, args などはそのまま利用できます。詳細はCloud Run YAML リファレンスをご参照ください。
コンテナは10コンテナまで記載でき、そのうち Ingress コンテナは1つまでの点には注意が必要です。
おわりに
Cloud Run はシングルコンテナのマネージドサービスから大幅に進化しています。現在は、Google Cloud 上のコンテナホスティングサービスとしては、マネージドサービスの恩恵を受けられる第一の選択肢として選定できるサービスです。
これまで GKE を利用してきた方も、これを機に Cloud Run の利用を検討してみてはいかがでしょうか🐶