はじめに
こんにちは！
NILTOチームでインフラエンジニアをしている太田です。
2025年8月5日（火曜日）と6日（水曜日）の2日間、東京ビッグサイトにて開催された、Google Cloud Next Tokyo '25に参加してきました。
会場では、カテゴリごとに分かれた多数のセッションが聴講できるほか、Expoでの展示ブース、認定資格者ラウンジといったコミュニケーションのスペースなど、さまざまな催しものが楽しめました。
本記事では、私が聞いたセッション 「複雑なサービス メッシュはもう古い？ Cloud Runで手軽に始めるサービスメッシュ」 について、レポートします。
注意点
このセッションで紹介されたCloud Run向けのCloud Service Meshは、現在プレビュー版として提供されています。利用する場合は、以下の点に注意しましょう。
- 本番環境での利用は非推奨: プレビュー版の機能は、GA（一般提供）までに仕様が変更または廃止される可能性があります。本番環境での利用は避け、技術検証や開発環境での試用に留めておきましょう。
- SLA（サービスレベル契約）の対象外: プレビュー期間中はSLAが適用されないため、可用性やパフォーマンスに関する保証はありません。
- 今後の機能変更: 今後、機能が追加・変更される可能性があるため、利用を検討する際は、最新の公式ドキュメントを常に確認するようにしましょう。
サービスメッシュは複雑だ
マイクロサービスアーキテクチャにおいて、サービス間の通信を制御・可観測化するためのサービスメッシュは非常に強力なツールです。しかし、その導入や運用には高いハードルがあると感じている方も少なくないでしょう（私もその中の一人です）。
セッションでは、従来のサービスメッシュが抱える課題として、特にその運用の複雑さが指摘されていました。
- 高い学習・運用コスト: 一般的にサービスメッシュの構築で利用されるKubernetesやIstioは非常に高機能ですが、その分学習すべきことが多く、安定して運用し続けるには専門的な知識と経験が求められます。
- サイドカー設定の煩雑さ: 各サービスにサイドカープロキシを設定し、その設定を管理・維持するのは手間がかかる作業です。
- トラブルシューティングの難易度: リクエストが必ずサイドカープロキシを経由するため、通信経路が複雑化します。これにより、障害発生時の原因特定や切り分けが難しくなる傾向にあります。
- パフォーマンスチューニングの影響範囲: パフォーマンスを改善しようと考えた際も、メッシュ全体への影響を考慮する必要があるため、気軽に変更を加えるのが難しく、慎重な対応が求められます。
このように、サービスメッシュがもたらす恩恵は大きいものの、その裏側にある運用コストの高さが導入をためらわせる一因となる、とのことでした。
Cloud RunとCloud Service Meshで変わる開発・運用
セッションでは、前述したような従来のサービスメッシュが抱える課題を、Cloud RunとCloud Service Mesh（以下、CSM）でどのように解決するかが紹介されました。
CSMはGoogle Cloudが提供するマネージドなサービスメッシュで、Cloud Runと組み合わせることで、サービスメッシュの導入・維持コストを大幅に低減できます。アプリケーション基盤やコンテナ基盤、そしてサービスメッシュ基盤の多くをGoogle Cloudに任せられるため、開発者はアプリケーションロジックの実装に集中できます。
ここでは、紹介された中でも印象が強かった変化点について記載します。
サービス間の通信方法が簡素になる
CSMを導入すると、サービス間の通信方法が劇的に簡潔になります。従来、Cloud Runサービス間での通信では、呼び出し先のサービスのURL（長くて複雑）を指定し、リクエストごとに認証トークンをHTTPヘッダーに付与する必要がありました。
しかし、CSMを利用すると、Target.meshapps.internalのようなサービスメッシュ内で解決されるホスト名でアクセスできるようになります。さらに、サービス間の認証はCSMが自動的に行ってくれるため、認証トークンをコードに含める必要がなくなります。
今のところNILTOではサービス間通信がとても多いわけではないため、そこまで即効性はないですが、設定内容やURLがシンプルになるのはインフラ担当としても嬉しいですね！
Cloud Traceの自動連携
マイクロサービスアーキテクチャでは、システム全体の動作を把握する「可観測性」の確保が課題となりがちです。CSMは、この課題も解決します。CSMを導入すると、サービス間のリクエストに自動でトレースIDが伝播され、各サービスにデプロイされたサイドカーがその情報をCloud Traceに送信してくれます。
これにより、開発者は特別な計装コードを追加することなく、サービス間の呼び出し関係や各サービスでの処理時間などを可視化できます。 問題が発生した際のトラブルシューティングが大幅に容易になるのは、運用において非常に大きなメリットです。
Cloud Traceの計装は今年実際にやりましたが、なかなか面倒だった記憶があります。しっかりマイクロサービスが分割されていれば、それだけ計装を任せられる範囲が広がるので、サービスの設計が重要になってきそうですね。
このセッションを聞いて得たもの
今回のセッションは、マイクロサービスアーキテクチャの運用における課題と、それに対する具体的な解決策が非常に分かりやすく提示され、大きな学びがありました。
NILTOにおいてもCloud Runの利用が増えてきているため、Kubernetesやサービスメッシュの導入は今後の検討課題の一つでした。Cloud RunとCSMを組み合わせることで、これまで複雑で手が出しにくいと感じていたサービスメッシュのメリットを、低い運用コストで享受できるようになるのは非常に魅力的です。まずは検証環境で試しに導入してみるところから始められれば、と思います。
また、このセッションは個人的にKubernetesへの学習意欲を再燃させるきっかけにもなりました。セッションで語られていたKubernetes + Istioの「複雑さ」は、私自身の経験と一致するものでした。Kubernetesはローカル環境の構築が難しく、実践の機会が少ない点で、学習のハードルが高く感じられます。Cloud Run + CSMという強力な選択肢を知った上で、改めてKubernetesの学習にも取り組みたいと感じました。
セッションの最後にあった「『インフラの複雑さ』と『開発の関心事』を綺麗に分離できる。それがCloud Run + CSMの最大の価値」という言葉が、この解決策の本質を的確に表していると感じます。インフラ担当者としては、このようなマネージドサービスを積極的に活用し、開発者がより本質的な開発業務に集中できる環境を作っていくことが重要だと再認識しました。
おわりに
本記事では、私が参加したセッションの中から特に印象に残った「複雑なサービス メッシュはもう古い？ Cloud Runで手軽に始めるサービスメッシュ」について紹介しました。マネージドサービスを活用して、いかにインフラの複雑さを開発者から隠蔽し、本来の価値創造に集中できる環境を作るか、その具体的なアプローチを学べた非常に有意義なセッションでした。
さて、Google Cloud Next Tokyo '25の魅力はセッションだけではありません。次の記事では、組織変革を目指すスペシャルセッション・ワークショップや、多くのパートナー企業が出展し、最新の事例に触れることができたExpoの様子をレポートします。そのほか、Google Cloudの公式ユーザー会であるJagu’e’rとしての活動にも参加したので、その関連情報もお届けできればと思います。
ぜひ、そちらの記事もご覧いただけると嬉しいです！
