はじめに
DX開発事業部の田村です。
Google Cloud Next Tokyo 2025のセッションレポートをお届けします。
セッション概要
セッションタイトル： 複雑なサービスメッシュはもう古い？Cloud Runで手軽に始めるサービスメッシュ
登壇者： 伊藤 裕一氏（Google Cloud アプリケーションモダナイゼーションコンサルタント）
サービスの運用において、トラフィック管理、セキュリティ、可観測性の向上を実現するサービス メッシュは非常に強力な技術です。
しかし、「サービス メッシュは Kubernetes の専門知識が必要で導入のハードルが高い」と感じている方も多いのではないでしょうか。
本セッションでは、そのようなイメージを覆し、サーバーレス環境である Cloud Run を活用することで、マネージドかつ手軽にサービス メッシュを導入できることをご紹介します。
Cloud Run であれば、複雑なインフラ管理に悩まされることなく、サービス メッシュの強力な機能を活用し始めることが可能です。
マイクロサービスの理想と現実
この「理想と現実」のスライドは非常に的確だと感じました。
マイクロサービスの理想は素晴らしいと思っておりますが、現実には多くの課題があり、特に「CI/CDが難しすぎる」や「トラブル調査でサービスを止めてしまう」、「うまくスケールしない」といった点は多くの開発現場で見られるものかなと思います。
マイクロサービスの普及と新たな課題
上図が示すように、シンプルなモノリシックアプリケーションから複雑なマイクロサービス構成に移行することで、サービス間の通信や依存関係の管理が非常に複雑になってしまいます。
Payment Service、Checkout Service、Frontend、Shipping Service、Currency Service、Product Catalog Service、Recommendation Service、Cart Serviceといった複数のサービスが相互に接続された構成は、確かに機能的には優れていますが、運用面では大きな負担となります。
Kubernetes上のサービスメッシュが抱える課題
サービスメッシュはマイクロサービスの課題を解決するソリューションの一つですが、動けば便利である一方で、導入と運用の負担が大きいのが課題です。
特に従来のKubernetesベースのサービスメッシュではサイドカープロキシの管理やIstioの設定など、インフラレベルでの専門知識が必要になり、十分に知見のあるエンジニアはそこまで多くはないのではないでしょうか。
Cloud Service MeshはGoogle Cloudが提供するマネージドなサービスメッシュで、Cloud Runと組み合わせることでサービスメッシュの導入と維持コストが大幅に低減されます。
Cloud Service Meshとは
「Cloud Service Mesh」（以降CSM）は、Google Cloudと、GKE Enterpriseでサポートされるオンプレミスなどの環境の両方に対応した、Googleのフルマネージドなサービスメッシュ・ソリューションです。
サービスメッシュ自体は、マイクロサービスで構成されたアプリケーションにおいて、サービス間の通信を管理しその状況を監視しながら安全性を確保するためのアーキテクチャです。
公式ドキュメントより（要約）
詳細は以下の公式ドキュメントをご参照ください
Cloud Service Mesh の概要
コンテナとサイドカーの運用をGoogle Cloudにオフロードする代わりに、機能が限定されるというトレードオフがありますが、多くの一般的なユースケースでは十分な機能を提供します。
フルマネージドサービスの特徴でもありますが、運用の手間を減らす代わりに一部機能が制限される。ただ、多くの場合はその制限よりも運用負荷の軽減メリットの方が大きいのではないでしょうか。
サンプルアプリケーションの構成
今回のセッションで紹介されたのは、以下のようなマイクロサービス構成でした
- Client (Cloud Run): Gateway/External LB経由でアクセス
- Proxy (Cloud Run): 中間プロキシサービス
- Target1, Target2, Target3 (Cloud Run): バックエンドサービス群
各サービスは Google Cloud 内の VPC 上で動作し、Cloud Service Mesh によって以下の機能が提供されます
- Cloud Run間の設定済み通信
- Ingress基本とInternal通信
- サービス間でのGCLBはなし
機能1: アプリ内の宛先名がCSM内部ホスト名に
CSMを導入することで以下のようにサービス間の通信作法が大幅にシンプルになります。長いCloud Run URLを使う必要がなく、直感的なホスト名でアクセスできるようになります。
- 宛先：`http://target.meshapps.internal`
- HTTPリクエストヘッダーの認証情報（トークン）の追加が不要
- 通信先の指定がサービスメッシュのホスト名で可能となる
正直、登壇者の方も仰ってましたがCloud RunのURLは本当に長く冗長に思います。
without-mesh-target-1088...517.asia-northeast1.run.app のようなURLを開発中に何度も書くよりも、target.meshapps.internal のように直感的な名前でアクセスできるのは、開発者体験として大きな改善だと思います。
機能2: CSMではこの認証コード、もう要りません
従来のCSMを利用しない場合のコードでは：
# CSMなしの場合
id_token = google.oauth2.id_token.fetch_id_token(request, target_url)
headers = {"Authorization": f"Bearer {id_token}"}
# HTTPリクエストにトークンを含むカスタムヘッダを追加
CSMを使用する場合：
- Google APIを使ってトークンを取得する処理が不要
- トークンをヘッダーデータに追加する処理も不要
- 宛先へのHTTPリクエストにトークンを含むカスタムヘッダを追加する処理も不要
- これらをやらないと403 Errorになる問題も解決
CSMが自動でCloud Run間の通信に認証ヘッダー（トークン）を付与してくれるため、開発者がこれらの認証コードを書く必要がなくなりました。
これは開発者にとって本当にありがたい機能ですね。OAuth2のトークン取得を毎回書くのは面倒ですしコードがシンプルになります。
機能3: mTLS相互認証とアクセス制御の実行例
mTLS相互認証の仕組み
- 誰と誰が通信できるかをIAMで定義（CSMなしでも可能）
- mTLSによりクライアントとサーバーが互いに相手を認証し、通信のHTTPS化
サービス間通信が自動的に暗号化され、相互認証が行われることで、セキュリティレベルが大幅に向上します。
この機能は特に金融系などのセキュリティ要求が高い業界において重要な価値を提供するとのことです。
403エラーできちんと制御されているのを見ると、期待通りに動作していることが分かります。
機能4: HTTP Routeによる内部のトラフィック管理
Cloud Load Balancerではなく、CSMのHTTP Route機能でトラフィック管理が可能で、カナリアリリースやA/Bテスト、リトライ処理などの機能を利用できます。
HTTP Routeは実質的にミニロードバランサーとして機能し、マイクロサービス間の細かなトラフィック制御を可能にします。
従来のCloud Load Balancerとは異なり、サービスメッシュ内部での柔軟なルーティングを実現できます。
HTTP Route設定により
- target-blue (Current Release): 99%のトラフィック
- target-green (New Release): 1%のトラフィック
カナリアリリースの例として、新サービスに1%だけ流すことで、安全にデプロイを進められます。
この機能の説明に関して「ミニロードバランサー」という表現が絶妙でした。
従来のCloud Load Balancerだと大げさすぎるような細かなトラフィック制御を、サービスメッシュ内部で手軽に実現でき、カナリアリリースで1%だけ新バージョンに振るなど、柔軟な制御ができるのは運用面で大きなメリットだと思います。
機能5: CSMとCloud Traceの自動連携
サービス間通信での自動トレーシングということで、各サービス（Client、Proxy、Target1）にIngressとEgressのサイドカーが配置され、トレース情報をCloud Monitoringに自動エクスポートします。
この自動トレーシング機能により、マイクロサービス間の依存関係や性能問題を簡単に把握できるようになります。
マイクロサービスでトラブルが発生した時、「どのサービスで遅延が起きているのか」を特定するために、各サービスのログを手動で突き合わせるのは大変な作業だと思います。それが自動でトレースされて可視化されるというのは、運用の生産性向上に大きく貢献しそうです。
開発(CI)と運用(CD)の「関心事の分離」の実現例
CSMの最大の価値は「インフラの複雑さ」と「開発の関心事」を綺麗に分離できることです。
このスライドで示されているように、CSMの設定を手動で行うとトラブルを生む可能性が高いため、IaC（Terraform など）やCI/CD（Cloud Build, GitHub Actions など）の利用が推奨されています。
またCSMは特にCI/CDプロセスとの相性が良く、設定項目自体は固定であることが多いため一度IaCでインフラコードを書いてしまえば、使いまわしていけるとのことです。
より一層インフラチームは基盤構築にやトラフィック制御、開発チームはアプリケーション開発とコード品質向上に集中できるようになります。
個人的に刺さったポイント
今回のセッションで最も印象的だったのは、実際のコードレベルでの改善が具体的に示されていたことでした。
特に「認証コード、もう要りません」の部分では、従来必要だった OAuth2 トークン取得やヘッダー追加のコードが完全に不要になることが実際のコード比較で示されており、開発者体験の向上が一目瞭然でした。
また、「関心事の分離」という観点も非常に説得力があり、インフラチームとアプリケーション開発チームがそれぞれの専門領域に集中できる環境を作ることで、全体の生産性向上が期待できます。
さいごに
正直、最初は「サービスメッシュってそんなに簡単になるものなの？」という疑問がありましたが、セッションを見ていると、本当にシンプルに実現できることが分かりました。
今後、マイクロサービスアーキテクチャを検討する際は、Cloud Run + CSM の組み合わせを積極的に選択肢として考慮していきたいと思います。
簡単30秒