2026-02-24 月末 Tech Lunch Online #10 Cloud Runのデプロイの課題から考えるアプリとインフラの境界線

Transcript

1. Cloud Runのデプロイの課題から考える アプリとインフラの境界線 Copyright © 3-shake, Inc. All Rights Reserved. 2026-02-24 月末 Tech Lunch Online #10 すずきまさし
2. Copyright © 3-shake, Inc. All Rights Reserved. おまえだれよ 2 • すずきまさし/masasuzu/@masasuz • 株式会社スリーシェイクSreake事業部シニアアーキテクト • クラウドインフラなんでも屋さんをしてます ◦ お客様の外部から ▪ 設計、運用、構築等の技術支援を行います。 ◦ お客様の内部から ▪ インフラチームの一員として内製化支援も行います。 • 得意領域 ◦ AWS ▪ AWS Community Builder Cloud Operation ▪ 2025 Japan All AWS Certifications Engineers ◦ Google Cloud ▪ Google Cloud Partner Top Engineer 2026 ◦ Terraform
3. • はじめに • Cloud Runデプロイの課題 • Cloud Runデプロイの課題解決 • まとめ Copyright © 3-shake, Inc. All Rights Reserved. 目次 3
4. Copyright © 3-shake, Inc. All Rights Reserved. はじめに 01 4
5. • 開発チームにはアプリとインフラの2つのロールがある • アプリはアプリのデプロイに責任を持つ • インフラはクラウドリソースの構築、運用に責任を持つ • テストされたコンテナイメージを使用したいので、コンテナイメージデプロイを行う • Cloud Run Serviceを対象とする • インフラはIaC(Terraform)化されている 今回はアプリとインフラで職掌が別れている前提で考えていきます。 Copyright © 3-shake, Inc. All Rights Reserved. いったんコンテキストを合わせたいです 5
6. • コンテナさえあれば、コマンド一発でwebアプリがデプロイできる • スケーリングも勝手にやってくれる • ただ動かすだけなら他のリソースの事前準備が不要 サクッと使うには考えることが少なくて便利 Copyright © 3-shake, Inc. All Rights Reserved. Cloud Run (Service)便利ですよね 6
7. • Google Cloud サービスと連携するなら ◦ Service Accountの権限設定 • VPCとつなぐなら ◦ Direct VPC Egressの設定およびサブネット設定 ◦ Ingress/Egress設定 • シークレット情報を扱うならSecret Managerの設定 • etc このあたりインフラ側チームとの連携が必要となります Copyright © 3-shake, Inc. All Rights Reserved. でも、実運用を考えると 7
8. Cloud Run Serviceの設定にはアプリの設定もインフラの設定も両方含まれています。 そのため、誰がどうデプロイ管理するのかが課題になります。 次章で詳しく見ていきます。 Copyright © 3-shake, Inc. All Rights Reserved. Cloud Runはアプリでもあり、インフラでもある 8
9. Copyright © 3-shake, Inc. All Rights Reserved. Cloud Run デプロイの課題 02 9
10. 課題を考える前にCloud Runのデプロイ方法を見ていきます。 Cloud Runのデプロイ方法としては以下の3つあります。 • Terraform • gcloud run deploy • gcloud run services replace (マニフェスト) いったんそれぞれを見ていきます。 Copyright © 3-shake, Inc. All Rights Reserved. Cloud Runのデプロイ方法 10
11. インフラがTerraformで管理されているの で、合わせてCloud RunもTerraformで管 理するのが自然です。 ただし、コンテナイメージや環境変数などア プリ側で管理したいパラメータも含まれて いるのがネック。 Copyright © 3-shake, Inc. All Rights Reserved. Terraform 11 resource "google_cloud_run_v2_service" "main" { name = var.name location = var.location template { service_account = var.service_account containers { image = var.image env { name = "ENV" value = var.env } env { name = "DB_PASSWORD" value_source { secret_key_ref { secret = var.db_password_secret_id version = "latest" } } } } vpc_access{ network_interfaces { network = var.network subnetwork = var.subnetwork } } } }
12. gcloud コマンドのパラメータに設定を定義 していきます。 明示的に設定したパラメータ以外は既存の リビジョンの設定を引き継ぎます。 Copyright © 3-shake, Inc. All Rights Reserved. gcloud run deploy 12 gcloud run deploy ${NAME} \ --region=${LOCATION} \ --image=${IMAGE} \ --service-account=${SERVICE_ACCOUNT} \ --set-env-vars=ENV=${ENV} \ --set-secrets=DB_PASSWORD=${DB_PASSWORD_SECRET_ID}:latest \ --network=${NETWORK} \ --subnet=${SUBNETWORK}
13. Knative Serving APIと互換性があるので マニフェストを利用してデプロイもできま す。 Copyright © 3-shake, Inc. All Rights Reserved. gcloud run services replace (マニフェスト) 13 apiVersion: serving.knative.dev/v1 kind: Service metadata: name: ${NAME} namespace: ${PROJECT_NUMBER} labels: cloud.googleapis.com/location: ${LOCATION} annotations: run.googleapis.com/launch-stage: GA spec: template: spec: serviceAccountName: ${SERVICE_ACCOUNT} containers: - image: ${IMAGE} env: - name: ENV value: ${ENV} - name: DB_PASSWORD valueFrom: secretKeyRef: name: ${DB_PASSWORD_SECRET_ID} key: latest metadata: annotations: run.googleapis.com/network-interfaces: '[{"network":"${NETWORK}","subnetwork":"${SUBNETWORK}"}]' gcloud run services replace sample.yaml --region=${LOCATION}
14. Terraformでクラウドインフラの管理をしている前提として、gcloud run deployやgcloud run services replaceでアプリをデプロイする場合、Terraformで設定したものを外部か ら書き換えてしまいます。 このときTerraformを再度デプロイすると上書きます。それゆえ意図しないデグレードが 発生しうります。 e.g. Direct VPC Egressの設定が消えたため、DB接続ができなくなった。 どうしたらいいのか。。。。 Copyright © 3-shake, Inc. All Rights Reserved. Terraformのドリフト(差分)課題 14
15. いずれの方法でも、Cloud Runの設定にアプリとインフラで責任を持つ範囲が含まれて しまう。 • デプロイの責任をインフラが持つと、 ◦ デプロイのたびにインフラに依頼することになりスピードが落ちる。 • デプロイの責任をアプリが持つと、 ◦ 本来責任外のインフラ周りの設定を意図せず変更してしまうリスクがある。 どうしたらいいのか。。。。 余談ですが、このあたりECS Task Definitionにも同じ課題を感じます。 Copyright © 3-shake, Inc. All Rights Reserved. Cloud Runはアプリでもあり、インフラでもある 15
16. • アプリ ◦ コンテナイメージ ◦ 環境変数 ◦ スペック(CPU、 Memory、 インスタンス 数) うまく責任ごとに分担できないか? Copyright © 3-shake, Inc. All Rights Reserved. 設定項目の責任範囲 16 • インフラ側 ◦ ネットワーク ▪ VPC接続 ▪ Ingress/Egress制御 ◦ 認証 ◦ サービスアカウント ◦ 環境変数に注入する Secret Manager
17. Copyright © 3-shake, Inc. All Rights Reserved. Cloud Run デプロイの課題解決 03 17
18. • Cloud Runの箱とインフラ設定のみ Terraform側で管理する • アプリ側で設定する項目は ignore_changesを入れる ◦ env ◦ image ◦ client、client_version ▪ デプロイしたクライアントが設定される この設定を入れることで、アプリ側で設定した ものが差分になっていても、無視させるので Copyright © 3-shake, Inc. All Rights Reserved. ドリフトの解消 18 resource "google_cloud_run_v2_service" "main" { name = var.name location = var.location template { service_account = var.service_account containers { image = "nginx" # 仮イメージ、アプリから設定される } vpc_access { network_interfaces { network = var.network subnetwork = var.subnetwork } } } lifecycle { ignore_changes = [ template[0].containers[0].image, template[0].containers[0].env, client, client_version, ] } }
19. gcloud run deployを使って必要な部分だ けデプロイします。 指定されていないパラメータに関しては既 存の最新のリビジョンのものを引き継ぎま す。 Copyright © 3-shake, Inc. All Rights Reserved. デプロイの設定 19 gcloud run deploy ${NAME} \ --image=${IMAGE} \ --set-env-vars=ENV=${ENV} \ --set-secrets=DB_PASSWORD=${DB_PASSWORD_SECRET_ID}:latest
20. 環境変数が多数の場合、--set-env-varsが 長くなってしまいます。その場合、 --env-vars-fileを使用して、YAMLファイル で外部化することによって整理できます。 --set-secretsも同様の問題がありますが、 オプションを使ってファイルでの外部化が できないので、シェルで組み立てるワーク アラウンドする方法が考えられます。 Copyright © 3-shake, Inc. All Rights Reserved. 環境変数tips 20 # 1. コメント行(#)と空行を除外し、 改行をカンマ (,)に変換して変数に格納 SECRETS_STR=$(grep -v '^\s*#' secret_mangager.txt | grep -v '^\s*$' | tr '\n' ',' | sed 's/,$//') # 2. 組み立てた文字列を --set-secrets に渡す gcloud run deploy my-app-service \ --image "${IMAGE}" --env-vars-file env.yaml \ --set-secrets="${SECRETS_STR}" \ --region asia-northeast1 # env.yaml --- ENV: "dev" PROJECT: "hogehoge_project" # secret_manager.txt # DB接続情報 DB_PASSWORD=my-db-secret:latest # 外部APIキー API_KEY=external-api-key:latest # サービスアカウントキー（ファイルマウントの例） /app/secrets/sa-key.json=my-sa-key:latest
21. インフラ • Terraformでインフラ設定を行う • ignore_changesでアプリ側の設定の 差分無視を行う ◦ env ◦ image等 Copyright © 3-shake, Inc. All Rights Reserved. 役割分担まとめ 21 アプリ • gcloud コマンドでアプリに必要な設定 のみ指定してデプロイを行う この方法により、インフラチームはリソースの安定性を確保しつつ、アプリチームはデ プロイのスピードと自律性を確保できます。
22. Copyright © 3-shake, Inc. All Rights Reserved. まとめ 04 22
23. Cloud Runのデプロイおけるインフラとアプリの責任分界について見てきました。 Cloud Run Serviceリソース自体はインフラでもありアプリでもあるため、一筋縄ではい きません。今回は責任分界に基づいたTerraformのignore_changesとgcloud run deployを組み合わせたソリューションを説明しました。 今回説明した方法が唯一解ではないです。 アプリが多数増えたときにすべてのアプリに対してインフラチームがインフラを個別対応 するのは現実的ではないので、アプリチームにインフラ責任を移譲する場合もあります。 そのときは別のアプローチが必要となります。 Copyright © 3-shake, Inc. All Rights Reserved. まとめ 23
24. • トラフィック移行 ◦ カナリアリリース • ソースデプロイ • ビルドなしのデプロイ • ベースイメージの自動更新 • CI/CDパイプライン • Platform Engineering • レポジトリわけ ◦ アプリとインフラはライフサイクルが違うのでレポジトリを分けたほうがいいです 時間が足りないのでブログ等で後日触れたいです。 Copyright © 3-shake, Inc. All Rights Reserved. 関連するが今回触れなかったトピック 24