はじめのProfessional Cloud Developer認定取得講座⑩Service Directory による Cloud Run の動的サービス検出ガイド、Cloud Runのトラフィック分割で実現する安全なカナリアリリース完全ガイド、GKEステートレスサービスの自動スケーリング最短導入ガイドを説明します！

クラウド

Professional Cloud Developer では、単なるサービス理解にとどまらず、「疎結合な設計」「安全なリリース」「効率的なスケーリング」といった実践的な設計力が問われます。


本記事では、サービス間連携を柔軟にする Service Directory、リスクを抑えたリリースを実現する Cloud Run のトラフィック分割、そして運用負荷を軽減するGKEの自動スケーリングについて解説します。いずれもクラウドネイティブなシステムにおいて重要な設計要素であり、実務でも頻出のテーマです。個別の機能としてではなく、「どのように組み合わせて使うか」という視点が重要になります。


本記事を通じて、試験対策だけでなく、実務に直結する設計力を体系的に整理していきます。安定性・拡張性・運用性を高めるための具体的なアプローチを押さえていきましょう。

是非、最後までご覧いただけると嬉しいです。

Service Directory による Cloud Run の動的サービス検出ガイド

サービスが 2 つや 3 つのうちは、環境変数に USER_SERVICE_URL を書き込むだけで十分に運用できます。しかし、サービスが 10、20 と増え、さらに Cloud Run や関数が複雑に連携し始めると、どのサービスがどこを向いているのかを把握するのは急激に難しくなります。接続先の変更のたびに再デプロイが必要になり、設定ミスや古いURLの残存といった問題も発生しやすくなります。こうした状況では、構成の見通しが悪くなり、運用負荷や障害リスクも増大します。
本記事では、こうした課題を解決するための仕組みとして、Service Directory を活用した動的サービス検出の設計と実装方法を解説します。

1. Service Directory とは？

Service Directory は、Google Cloud 上のあらゆるサービス（Google Cloud リソース、サードパーティ サービス、オンプレミス リソース）を、一元的に登録・管理・検出するためのマネージド型プラットフォームです。

いわば、クラウド環境内の「電話帳（イエローページ）」のような役割を果たします。

主な構成要素

  • 名前空間 (Namespace)：サービスを論理的にグループ化する単位（例：production, development）。
  • サービス (Service)：具体的なアプリケーションの単位（例：inventory-api）。
  • エンドポイント (Endpoint)：サービスに到達するための情報（IPアドレス、ポートなど）。

2. なぜ環境変数（ENV）ではなく Service Directory なのか？

環境変数による管理には、以下の 3 つの大きな弱点があります。

  • 密結合：呼び出し先の URL が変わると、呼び出し元すべての環境変数を更新して再デプロイが必要になる。
  • 不整合：手動更新によるタイポや、古い URL の残留が発生しやすい。
  • スケーラビリティの欠如：サービスが増えるほど、依存関係の網の目が複雑になり管理不能になる。

Service Directory を導入すると、呼び出し元は「ターゲットの名前」を知っているだけでよくなり、物理的な接続先を知る必要がなくなります。

3. 実装のステップ：動的検出の仕組みを作る

ステップ1：サービスの登録（デプロイ時）

新しい Cloud Run サービスや Function をデプロイする際、そのサービスの接続情報を Service Directory に登録します。Service DirectoryのエンドポイントはIPアドレスとポートを登録する設計になっています。

Cloud RunのようなURLベースのサービスを登録するには、以下のいずれかの方式を選択します。

  • Private Service Connect（推奨）：Cloud RunをPSC経由でVPC内部IPとして公開し、そのIPをエンドポイントに登録します。
  • メタデータ格納方式：エンドポイントのアドレスに実際のIPを指定しつつ、URLをメタデータに持たせる方式です。この場合、アプリ側でメタデータからURLを取得するロジックが必要です。
⚠️ --address=0.0.0.0 のようなプレースホルダーは有効なIPアドレスではないため、正常に動作しません。エンドポイントには必ず有効なIPアドレスを指定してください。

＜gcloudコマンド＞

# 名前空間の作成（初回のみ）
gcloud service-directory namespaces create my-namespace \
    --location=asia-northeast1

# サービスの登録
gcloud service-directory services create my-service \
    --namespace=my-namespace --location=asia-northeast1

# エンドポイントの登録（PSCで取得した内部IPを使用）
gcloud service-directory endpoints create my-endpoint \
    --service=my-service --namespace=my-namespace \
    --location=asia-northeast1 \
    --address=10.0.0.5 --port=443

これは、デプロイ用スクリプト（Terraform や gcloud コマンド）の一部として自動化するのがベストです。

ステップ2：動的な検出（コード内でのルックアップ）

呼び出し元のアプリケーションでは、環境変数を読み込む代わりに、Service Directory API を叩いて最新の接続先情報を取得します。Google Cloud クライアントライブラリを使用すれば、数行のコードで実装可能です。

URL が変わっても、Service Directory 側のエンドポイント情報を更新するだけで、呼び出し元は再デプロイなしに新しい接続先を参照できます。

ステップ3：プライベート DNS ゾーンとの連携

Cloud Run サービスが内部 VPC ネットワーク内のみで通信する場合、Service Directory と Cloud DNS のプライベートゾーンを連携させることで、DNS クエリによるサービス検出が可能になります。

この機能を利用するには、以下の手順が必要です。

  1. Cloud DNSでプライベートゾーンを作成し、ゾーン作成時に「Service Directoryの名前空間を使用する」オプションを選択して名前空間と紐付けます。
  2. DNSゾーンに任意のDNS名（例：my-namespace.internal）を設定します。
  3. 設定後、VPC内のリソースがそのDNS名でサービスを解決できるようになります（例：my-service.my-namespace.internal）。
⚠️ DNS名の形式はユーザーがCloud DNSゾーン作成時に自由に設定するものです。特定のTLDが自動的に付与されるわけではありません。

4. 運用上のメリットとさらなる拡張

  • メタデータの活用：Service Directory のエンドポイントには「バージョン情報」や「重み」などのメタデータを付与できます。これをコード側で判別すれば、カナリアリリースのような高度なトラフィック制御も容易になります。
  • 一貫したセキュリティ：IAM 権限を使用して、「どのサービスが電話帳のどの情報を閲覧できるか」を厳密に制御できます。
  • 疎結合の実現：インフラ構成の変更（Cloud Run から GKE への移行など）が発生しても、Service Directory のエンドポイント情報を更新するだけで、呼び出し側のコードを書き換える必要がありません。

Service Directory による Cloud Run の動的サービス検出ガイドのまとめ

Service Directory は、Cloud Run を含む複数サービスの接続先を一元管理し、動的に解決するための強力な基盤です。
従来の環境変数管理と異なり、サービス名ベースでの疎結合な通信を実現できる点が大きな利点です。PSCやメタデータを活用した登録により、柔軟かつ実運用に適した構成が可能になります。
さらに、APIによるルックアップやCloud DNS連携により、動的かつスケーラブルなサービス検出が実現されます。メタデータ活用やIAM制御を組み合わせることで、セキュリティと運用性も向上します。
結果として、変更に強く、拡張性の高いクラウドネイティブなアーキテクチャを構築できます。

Cloud Runのトラフィック分割で実現する安全なカナリアリリース完全ガイド

新機能のリリースは、ユーザー価値を高める一方で、障害リスクとも常に隣り合わせです。特に本番環境での一斉リリースは、想定外の不具合が発生した場合に大きな影響を及ぼします。
こうしたリスクを抑える有効な手法が「カナリアリリース」です。
Cloud Run では、トラフィック分割機能とリビジョン管理により、この仕組みをシンプルかつ強力に実現できます。
本記事では、追加インフラなしで安全な段階的リリースを行う方法を、具体的な手順とともに解説します。実運用でそのまま使えるベストプラクティスも含め、リスクを最小化するリリース戦略を整理します。

1. Cloud Runの強力な武器「リビジョン」と「トラフィック分割」

Cloud Runに新しいコードをデプロイするたびに、「リビジョン」と呼ばれる不変のスナップショットが作成されます。このリビジョンの存在こそが、安全なデプロイの鍵です。

通常、新しいリビジョンをデプロイするとトラフィックの100%が即座に切り替わりますが、Cloud Runでは「どのリビジョンに、何パーセントのトラフィックを流すか」を自由自在に設定できます。

2. 最小限の手間で進める「段階的デプロイ」の3ステップ

複雑なロードバランサーの設定は不要です。以下の手順だけで、安全なリリースが完了します。

ステップ1：新しいリビジョンを「トラフィックなし」でデプロイ

まずは、いきなりユーザーに新機能を見せないようにデプロイします。

＜gcloudコマンド＞

gcloud run deploy [SERVICE_NAME] --image [IMAGE_URL] --no-traffic --tag candidate
  • --no-traffic：新しいリビジョンを作成しますが、まだトラフィックは流しません。
  • --tag candidate：このリビジョンに candidate というタグを付けます。これにより、https://candidate---[SERVICE_NAME]-[HASH].[REGION].run.app という専用URLで、開発者だけが本番環境での動作確認を行えます。

ステップ2：トラフィックの5%だけを新機能に流す

動作確認に問題がなければ、全ユーザーの5%だけを新しいリビジョンへ誘導します。タグを付けている場合は --to-tags を使うのが確実です。

＜gcloudコマンド＞

gcloud run services update-traffic [SERVICE_NAME] --to-tags candidate=5

これにより、残りの95%のユーザーは引き続き安定した旧バージョンを利用し、ごく一部のユーザーだけが新機能を利用する状態になります。

ステップ3：モニタリングしながら段階的に増やす

エラー率やレイテンシに異常がないことを確認しながら、流量を20%、50%、100%と増やしていきます。この操作はGoogle Cloudコンソールのスライダーを動かすだけでも実行可能です。

＜gcloudコマンド＞

# 20%に増やす
gcloud run services update-traffic [SERVICE_NAME] --to-tags candidate=20

# 100%に切り替えて完了
gcloud run services update-traffic [SERVICE_NAME] --to-tags candidate=100

3. もし問題が起きたら？ 秒速の「ロールバック」

段階的デプロイの最大のメリットは、問題発見時の被害を最小限に抑えられることです。

もし新リビジョンでエラーが多発した場合、コマンド一つ（またはボタン一つ）で、トラフィックを100%即座に旧リビジョンへ戻すことができます。Cloud Runは古いリビジョンを破棄せず保持しているため、再デプロイの時間すら必要ありません。

＜gcloudコマンド＞

# 旧リビジョンのタグ（例: stable）に全トラフィックを戻す
gcloud run services update-traffic [SERVICE_NAME] --to-tags stable=100

4. SREチームも納得の運用ベストプラクティス

  • タグを活用したプレビュー：--tag を使うことで、一般公開前にQAチームが本番と同じ環境でテストできます。
  • 段階的な拡大：5% → 20% → 50% → 100% と段階を踏むことで、CPUやメモリの負荷、データベースへの影響を慎重に見極められます。
  • 構成の自動化：これらのトラフィック分割設定はTerraformなどのIaC（Infrastructure as Code）でも管理できるため、一度仕組みを作れば次回のリリースからはさらに手間が減ります。

Cloud Runのトラフィック分割で実現する安全なカナリアリリース完全ガイドのまとめ

Cloud Runのトラフィック分割機能を活用することで、安全かつ柔軟なカナリアリリースが実現できます。リビジョン単位でトラフィックを制御できるため、新旧バージョンの共存と段階的な切り替えが容易になります。
また、問題発生時には即座にロールバックできる点も大きな強みです。
タグを活用したプレビューや段階的なトラフィック増加により、リスクを最小限に抑えた運用が可能です。さらに、IaCと組み合わせることで、再現性の高いデプロイプロセスを構築できます。
これらを実践することで、信頼性とスピードを両立したリリース戦略を実現できます。

GKEステートレスサービスの自動スケーリング最短導入ガイド

短納期でシステムの信頼性を高めるには、手動調整ではなく自動化されたスケーリング戦略が不可欠です。
特にステートレスなワークロードでは、リソース最適化と運用効率を両立する設計が求められます。
Google Kubernetes Engine においては、Vertical Pod Autoscaler（VPA）を活用することで、コード変更なしにリソース調整を自動化できます。
本記事では、最短で導入可能なVPAの仕組みと実践手順を、2週間のスケジュールをベースに解説します。さらに、HPAとの違いや併用時の注意点にも触れ、現場で迷わない設計判断を整理します。限られた期間でも成果を出すための、現実的なスケーリング戦略を提示します。

1. なぜ「VPA」が最短ルートなのか？

通常、スケーリングと言えばPodの数を増やす「水平スケーリング（HPA）」を思い浮かべますが、HPAを正しく動かすには「各Podがどれくらいのリソース（CPU/メモリ）を消費するか」を正確に設定する必要があります。

ここがズレていると、スケーリングが遅れたり、逆にリソースを無駄に食い潰したりします。VPA（垂直ポッドオートスケーラー）を導入すれば、以下のメリットを即座に享受できます。

  • コード変更不要：アプリケーションの改修は一切不要です。
  • リソース見積もりの自動化：「CPUをどれくらい割り当てるべきか」をデータに基づいて自動決定します。
  • ステートレスとの相性：ステートレスなサービスであれば、Podの退避・再作成が伴う調整もPDBと組み合わせることでサービス断を最小化できます。
⚠️ 重要：VPAはローリングアップデートではありません 
VPAのAuto/Recreateモードはリソース変更が必要な場合にPodを退避（evict）させ再作成します。DeploymentのローリングアップデートのようにPodを1つずつ入れ替えるわけではないため、PodDisruptionBudget（PDB）の設定が必須です。

2. VPAの動作モード

VPAには、状況に合わせて選べる複数のモードがあります。今回の2週間という期間では、以下のステップを推奨します。

モード内容導入のタイミング
Off推奨値の計算のみを行い、適用はしない。1週目：現状分析
InitialPodの作成時のみ、推奨値を割り当てる。実行中のPodには影響を与えない。段階的移行時
Recreateリソース変更が必要な場合、Podを退避・再作成して推奨値を適用する。2週目：自動適用
AutoRecreateモードとほぼEquivalentの動作。現行GKEではRecreateと同様。2週目：自動適用
💡 新しいモード（Kubernetes 1.34以降）: InPlaceOrRecreate モードが利用可能になりました。まずインプレース更新を試み、それが不可能な場合のみPodを再作成します。Pod再起動の頻度を抑えたい場合に有効です。

3. 実装のステップ（2週間のスケジュール）

【第1週】現状把握と「推奨値」の確認

まずはVPAを「参照モード（Off）」でデプロイします。

＜gcloudコマンド＞

# GKEクラスタでVPAを有効化
gcloud container clusters update [CLUSTER_NAME] --enable-vertical-pod-autoscaling

VPAオブジェクト（updateMode: “Off”）を作成し、数日間実際のトラフィックを流しながら、VPAが算出する「推奨リソース量」を確認します。

【第2週】自動適用の開始

蓄積されたデータに基づき、VPAを「Auto」モードに切り替えます。

＜YAMLファイル＞

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Auto"

モード変更後は、負荷に応じてPodが適切なサイズで再作成され、リソース不足（OOMKilledなど）が発生しないか監視します。

4. 水平スケーリング（HPA）との併用について

「トラフィック急増への対応（Podの数を増やしたい）」という要件がある場合は、HPAとの併用も検討します。ただし、以下の制約を正しく理解してください。

  • HPAとVPAをCPUまたはメモリという同じメトリクスで同時に使うことはできません。 双方が競合し、不安定なスケーリング動作を引き起こします。
  • 「HPAはCPU、VPAはメモリ」という切り分けも推奨されません。 同一リソース群に両者が干渉するリスクがあります。

【推奨される構成】

要件推奨アプローチ
リソース最適化のみVPAのみ導入
CPUで水平・メモリで垂直を同時に行いたいMultidimensional Pod Autoscaler（MPA）（ベータ）を利用
カスタムメトリクス（リクエスト数など）で水平スケーリング + リソース最適化HPAをカスタムメトリクスで設定 + VPAを併用

5. 最小限の変更でリリースするためのチェックリスト

  • Metrics Serverの確認：GKEではデフォルトで有効ですが、kubectl top pods が動くことを確認してください。
  • PodDisruptionBudget（PDB）の設定（必須）：VPAがPodを退避させる際の同時停止数を制限し、サービス断を防ぎます。VPAはPDBを尊重して退避を実施します。
  • ステートレスの再確認：セッション情報などがメモリ内に保持されていないか再確認してください。VPAによるPod再作成時にクリアされます。
  • 推奨値の確認期間の確保：VPAが高精度な推奨値を算出するには少なくとも24時間以上のデータ蓄積が必要です。

GKEステートレスサービスの自動スケーリング最短導入ガイドのまとめ

VPAを活用することで、リソース見積もりの自動化と運用負荷の軽減を短期間で実現できます。特にステートレスサービスでは、Pod再作成を伴う調整もPDBと組み合わせることで安定運用が可能です。まずはOffモードで推奨値を把握し、その後Autoモードへ移行する段階的導入が効果的です。
一方で、HPAとの併用には制約があり、設計時にはメトリクスの競合に注意が必要です。最小限の変更で導入するためには、事前の観測データと適切な設定が成功の鍵となります。
これらを実践することで、信頼性と効率を両立したスケーリング基盤を構築できます。

まとめ

今回は、下記３点について説明しました。

  1. Service Directory による Cloud Run の動的サービス検出ガイド
  2. Cloud Runのトラフィック分割で実現する安全なカナリアリリース完全ガイド
  3. GKEステートレスサービスの自動スケーリング最短導入ガイド

本記事では、動的サービス検出、安全なカナリアリリース、自動スケーリングという3つの重要テーマを解説しました。

Service Directoryにより疎結合なサービス連携を実現し、変更に強いアーキテクチャを構築できます。Cloud Runのトラフィック分割を活用することで、安全かつ段階的なリリースと迅速なロールバックが可能になります。さらに、GKEのVPAを用いることで、リソース最適化と運用効率の向上を短期間で実現できます。
これらは個別最適ではなく、全体設計として組み合わせることで真価を発揮します。

試験対策にとどまらず、実務で通用するクラウド設計力として活用していくことが重要です。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！

スポンサーリンク
タイトルとURLをコピーしました