Zenn
📖

Cloud Service Mesh を深掘りたい！- Part.1 Next'24 での発表 -

2024/04/30に公開
Google Cloud
Istio
サービスメッシュ
cloudservicemesh
tech

2024 年 4 月 25 日に行われたGoogle Cloud Next '24報告会@Lazuli に登壇させていただきました。

Google Cloud Next '24 で何か 1 つピックアップして話したいと思った時に Cloud Run のアップデートの中で知った Cloud Service Mesh が頭に浮かびました。サービスメッシュとは？から発表された Cloud Service Mesh の概要を知りたいという方はぜひお読みください！

Overview

  • Cloud Service Mesh は既存の Anthos Service Mesh と Traffic Director が統合されて新しいサービスメッシュのサービスとして発表されました。従来の GKE や Compute Engine へのサービスメッシュの導入に加えて、Cloud Run への導入が可能な点が大きなポイントでした。
  • Istio のデータプレーンの新たな実装である Ambient Mode でのデプロイ方式も予定されており、Sidecar Mode で課題となっていた 「アプリケーションの阻害」「リソースの非効率な使用」「非 HTTP 準拠アプリケーションの問題」 に関するアプローチとなっているようです。
  • 特にノードへ配置される共有プロキシが L4 処理のみを担当することで軽量化されており、Sidecar Mode より柔軟なサービスメッシュの導入が可能となっていそうです。

背景

Google Cloud Next '24 の Cloud Run: What's new のセッションの中で Cloud Run でサービスメッシュを実現できる Cloud Service Mesh with Cloud Run の Private Preview のアナウンスがありました。

こちらで Cloud Service Mesh の存在を知り、改めて Introducing Cloud Service Mesh: A fully managed global scale service mesh に沿って勉強したいと思いました。

サービスメッシュとは？なぜサービスメッシュなのか？

そもそもサービスメッシュって名前は知っているけど、自分自身具体的に言葉にできないという状態でした。調べていると、マイクロサービスアーキテクチャにおけるサービス数の増加に起因した複雑さ、トラフィック管理・通信の暗号化・認証認可など、を一手に担ってサービス間の信頼性・セキュリティ・可観測性を向上してくれるアプローチということがわかってきました。

それぞれの項目で解決したい課題感が何でサービスメッシュがどんな機能を提供をするか簡単にまとめてみます。（※ 大雑把に書いています。）

スケーラビリティ

  • 課題：マイクロサービス数が増加するとサービス間の通信が複雑になりシステム全体のスケーリングが困難になる
  • アプローチ：サービスの位置情報を自動的に管理してサービスの追加や削除に対応する 「サービスディスカバリー」 やトラフィックを複数のサービスに分散する 「負荷分散」 などの機能を提供

信頼性

  • 課題：マイクロサービスアーキテクチャでの単一のサービス障害がシステム全体に影響を与える可能性ある
  • アプローチ：障害が発生したサービスへのトラフィックを遮断して障害の連鎖を防ぐ 「サーキットブレーカー」 などの機能を提供

セキュリティ

  • 課題：マイクロサービス数の増加による攻撃ポイントの増加（攻撃には盗聴や改ざんなど）したり、各サービスが互いに認証を行う必要があることからの認証管理の複雑になる
  • アプローチ：盗聴や改ざんを防ぐためにサービス間の通信を暗号化や認証する 「mTLS」 やサービスにロールを割り当てる 「RBAC のサポート」 などの機能を提供

サービス管理

  • 課題：マイクロサービス数が増加すると、システム全体の動作を把握することが困難になる
  • アプローチ：サービスのパフォーマンス・健全性・依存関係を把握しやすくするメトリクス・ログ・トレースといった 「テレメトリデータの収集」 などの機能を提供

サービスディスカバリとサービスメッシュの違いは？

調べていく中で Istio の役割として 「サービスディスカバリ」 という単語も出てきました、こちらも聞いたことがある程度で実態やサービスメッシュとの違いがわからなかったので簡単にまとめました。

Google Cloud のサービスメッシュ

サービスメッシュの基本を抑えたところで、Google Cloud のサービスメッシュに入っていきたいと思います。Google Cloud のサービスメッシュとして一番に頭が浮かぶのが 「Anthos Service Mesh」 でした、一方で 「Traffic Director」 なるサービスメッシュのサービスがあることを初めて知りました。

これら 2 つのサービスが統合されて +α の機能が備わったサービスメッシュサービスが今回発表された 「Cloud Service Mesh」 のようです。セッションによると下記スライドの文言が謳い文句のようでした。

Anthos Service Mesh

ASM のデプロイ方式には「マネージド ASM」と「クラスタ内コントールプレーン」の 2 種類があります。ここでは マネージド ASM の説明を公式ドキュメントから引用します。(※1)

マネージド Anthos Service Mesh は、マネージド コントロール プレーンとマネージド データプレーンで構成されます。マネージド Anthos Service Mesh では Google がアップグレード、スケーリング、セキュリティに関する作業を行い、ユーザー側の手動メンテナンスの必要性は最小限に抑えられます。マネージド データプレーンを有効にすると、サイドカー プロキシを管理するクラスタ内コントローラが Google によってインストールされます。

Google Cloud Next '23 で GKE Enterprise という Anthos の後継が発表されてから、Anthos Service Mesh がどのようにリブランディングされるか気になっていましたが、別サービスとの統合という形で新しく生まれ変わるのには驚きました！

Traffic Director

同様に Traffic Director の説明を公式ドキュメントから引用します。(※2)

Traffic Director は、アプリケーション ネットワーキングを対象とするマネージド コントロール プレーンです。Traffic Director を使用すると、トラフィック管理やオブザーバビリティなどの高度なアプリケーション ネットワーキング機能を備えた、グローバルで可用性の高いサービスを提供できます。

VM を含めたサービスメッシュの構成やプロキシレスを用いたネットワーキング機能を提供しているようです。

Ambient Mode

Cloud Service Mesh の大きな特徴としてデプロイ方式に Sidecar Mode と gRPC Proxyless に加えて 「Ambient Mode」 が加わると発表がありました。

Istio の Sidecar を使用しない新しいデータプレーンの実装で、調べてみると 「Ambient Mesh」 という名称が引っかかりました。これは下記の Sidecar によるデプロイの課題に対するアプローチのようです。

  • アプリケーションの阻害：サイドカーとしてアプリケーション Pod に注入されるため、Istio のインストールやアップグレード時には Pod の再起動が必須
    → アプリケーションの動作が一時的に停止・中断を引き起こす可能性がある

  • リソースの非効率な使用：Sidecar ではデータプレーンが提供する機能がすべて有効になる
    → 一部しか必要としない場合でも余分なリソースを確保してしまう

  • 非 HTTP 準拠アプリケーションの問題：Sidecar のデータプレーンはHTTP 準拠のアプリケーションを前提としている
    → HTTP 準拠でないアプリケーションの場合は予期しない動作を引き起こす可能性がある

セッション中に紹介された「Ambient Mode」の特徴について、共有プロキシを深掘ります。

共有プロキシ

各ノードに軽量な共有リソースとして動作するプロキシを配置します。デプロイの仕方について、Sidecar Mode と大きく異なる部分ですね。

また、Sidecar Mode では L4・L7 の処理を担いますが、Ambient Mode では L4 の処理のみを担います。この点は Sidecar Mode の課題であがっていた 「リソースの非効率な使用」 に関連する部分かと思います。(※3)

この L4 の処理のみを担当するのが「Ztunnel」と呼ばれるコンポーネントで Daemonset としてデプロイされるようです。(※4)

L4 の処理のみを担当するということで、共有プロキシである Ztunnel はノード内のアプリケーションコンテナとの通信に mTLS が適用されます。一方でノード間通信には適用されないため、必要であれば L7 専用のプロキシをデプロイすることが推奨されるようです。

サービスメッシュとは？から Cloud Service Mesh の概要について、Google Cloud Next '24 のセッションベースに調べてみました。単語レベルでしかわからなかったサービスメッシュを多少なりとも言葉で説明できるようになった気がしています！Cloud Service Mesh の続報に注目していきたいですね。

参考

本編参照

Cloud Service Mesh 関連

Anthos Servie Mesh 関連

Traffic Director 関連

Istio 関連

さいごに

今回ラスベガス現地でお声がけいただいて、登壇の機会をもらえたということで非常に嬉しい経験となりました。海外イベントだからといって英語をしゃべることに躍起にならず、日本人との関わりも積極的に持つことも重要だなと感じました。

https://twitter.com/pHaya72

Discussion