Google Cloud Next’24 で発表された Cloud Service Mesh に触れ合う Google Cloud Next ‘24 報告会@Lazuli - Tomonori Hayashi 1

Tomonori Hayashi ● NTT コミュニケーションズ イノベーションセンター所属 ○ ノーコード時系列分析ツール「 Node-AI」の開発/運用 ○ アプリケーションエンジニア ■ Front：TypeScript - React/Next.js ■ Infra：Google Cloud ● Google Cloud Partner Top Engineer 2024 ● Google Cloud All Certifications ● Favorite Word ○ class SRE implements DevOps @pHaya72 2 @t_hayashi

Node-AI の紹介 ● ノーコードで AI モデルを作成できる WEB アプリケーション ● カードを直感的につなげるだけで 時系列データの前処理から AI モデルの学習・評価までの パイプラインを作成・実行 できる ● 技術スタック ○ TypeScript + React / Next ○ Python + Django ○ C# + ASP.NET Core ○ Kubernetes ○ Google Cloud ○ Scikit-learn / Tensorflow / Pytorch 3

Cloud Run Cloud Service Mesh 4

Cloud Run とは？ 5 コンテナ実行環境 Kubernetes 上にサーバーレス環境 を構築できる Knative がベース フルマネージドなサービスでシンプル に使える 最小インスタンス数を 0 にすることで リクエストが発生しない間はコスト 0 などかゆいところに手が届く機能も豊 富

Cloud Service Mesh with Cloud Run 6 Cloud Run で サービスメッシュを実現 サービスメッシュといえば Kubernetes で構築するイメージだっ た Cloud Run で実現できるのは めちゃくちゃ興味深い でも、サービスメッシュってなんだっけ ・・・😇 深ぼっていきたい！

サービスメッシュについて 7 サービスメッシュとは？ コントロールプレーン サービスA アプリケーション インスタンス アプリケーション インスタンス サービスB データプレーン データプレーン Ingress Traffic Mesh Traffic Egress Traffic マイクロサービスアーキテクチャの 複雑さ（認証/認可・通信暗号化 etc）を管理して、 信頼性・セキュリティ・可観測性を向上させる 処理レイヤ

なぜサービスメッシュなのか？ 8 サービスメッシュとは？ コントロールプレーン サービスA アプリケーション インスタンス アプリケーション インスタンス サービスB データプレーン データプレーン Ingress Traffic Mesh Traffic Egress Traffic マイクロサービスアーキテクチャの 複雑さ（認証/認可・通信暗号化 etc）を管理して、 信頼性・セキュリティ・可観測性を向上させる 処理レイヤ 1. スケールと信頼性 サービス間のトラフィック管理や負荷分散などの機能提供により アプリケーションのスケーラビリティと信頼性を向上 2. セキュリティとポリシー サービス間の通信を保護やアクセス制御の機能提供により ゼロトラストセキュリティを実現 3. サービス管理 サービス間の通信に関するテレメトリデータを提供により アプリケーションのパフォーマンスや依存関係を監視

なぜサービスメッシュなのか？ 9 サービスメッシュとは？ コントロールプレーン サービスA アプリケーション インスタンス アプリケーション インスタンス サービスB データプレーン データプレーン Ingress Traffic Mesh Traffic Egress Traffic マイクロサービスアーキテクチャの 複雑さ（認証/認可・通信暗号化 etc）を管理して、 信頼性・セキュリティ・可観測性を向上させる 処理レイヤ 1. スケールと信頼性 サービス間のトラフィック管理や負荷分散などの機能提供により アプリケーションのスケーラビリティと信頼性を向上 2. セキュリティとポリシー サービス間の通信を保護やアクセス制御の機能提供により ゼロトラストセキュリティを実現 3. サービス管理 サービス間の通信に関するテレメトリデータを提供により アプリケーションのパフォーマンスや依存関係を監視 マイクロサービスアーキテクチャによって高まった 通信の暗号化や認証認可といった複雑性をアプリケーションで実現するのは大変 アプリケーションの近くにそれらの処理を一括して担う コンテナを配置することで透過的に処理を実現する （ここでの透過的とは、コード変更なし & ユーザーに意識させないという意味）

サービスディスカバリとの違いは？ 10 サービスディスカバリ フォーカスしているポイント ・サービス間の通信 課題に対するアプローチ ・マイクロサービスにおけるサービス間の通信の動的な変化（ IP アドレスやポート）に起因した検知や位置の特定 サービスメッシュ フォーカスしているポイント ・サービス間の信頼性と可観測性 課題に対するアプローチ ・マイクロサービスにおけるサービス間の通信の複雑性が高ま ることに起因した暗号化や認証 /認可の適用 ・マイクロサービスにおけるサービス間の通信の増加に起因した トラフィックの集中管理（ルーティング・ロードバランシング etc） ・問題が発生した場合に原因を特定するためのテレメトリ（メトリ クス・ログ・トレース）の送出 サービスメッシュは サービスディスカバリーの情報を活用 & サービスディスカバリーの機能を拡張 と概ね言えそう （※ サービスメッシュは必ずしもサービスディスカバリの機能を提供しなくてもよい）

Google Cloud のサービスメッシュ 11 Anthos Service Mesh ・Istio ベースのフルマネージドサービス ・ハイブリッド & マルチクラウドに対応 ・プラットフォーム管理者やサービス運用者などのサービスメッ シュに理解が深いユーザーがターゲット Traffic Director ・フルマネージドサービス ・Google Cloud のみ対応 ・ネットワーク管理者など Google Cloud 内に簡単にサービス メッシュを導入したいユーザーがターゲット Anthos Service Mesh コントロールプレーン App A Pod Pod App B データ プレーン Traffic Director App A インスタンス インスタンス App B （プロキシレス） データ プレーン サイドカー コンテナ テンプレートに フラグを追加する データ プレーン

Google Cloud のサービスメッシュ 12 Anthos Service Mesh ・Istio ベースのフルマネージドサービス ・ハイブリッド & マルチクラウドに対応 ・プラットフォーム管理者やサービス運用者などの サービスメッシュに理解が深いユーザーがターゲット Traffic Director ・フルマネージドサービス ・Google Cloud のみ対応 ・ネットワーク管理者など Google Cloud 内に簡単にサービス メッシュを導入したいユーザーがターゲット Cloud Service Mesh A globally scalable, fully managed, Google platform integrated service mesh for all enterprise

Google Cloud のサービスメッシュ 13 Anthos Service Mesh ・Istio ベースのフルマネージドサービス ・ハイブリッド & マルチクラウドに対応 ・プラットフォーム管理者やサービス運用者などの サービスメッシュに理解が深いユーザーがターゲット Traffic Director ・フルマネージドサービス ・Google Cloud のみ対応 ・ネットワーク管理者など Google Cloud 内に簡単にサービス メッシュを導入したいユーザーがターゲット Cloud Service Mesh A globally scalable, fully managed, Google platform integrated service mesh for all enterprise 世界中のどこからでもサービス管理 コントロールプレーン・ データプレーンが Google 管理 Google Cloud のネットワークやコン ピュートとシームレスに統合可能 エンタープライズレベルの 巨大なデプロイメントにも対応

従来の Sidecar Mode と gRPC Proxyless に加えて 14 Ambient Mode の提供 ・Istio のデータプレーン実装の新しいアプローチ ・アプリケーションコードを変更することなく導入可能 ・各ノードにプロキシが配置される コントロールプレーン App A Node Node Proxy App B App A Proxy App B

従来の Sidecar Mode と gRPC Proxyless に加えて 15 Ambient Mode の提供 ・Istio のデータプレーン実装の新しいアプローチ ・アプリケーションコードを変更することなく導入可能 ・各ノードにプロキシが配置される コントロールプレーン App A Node Node Proxy App B App A Proxy App B 1. 共有プロキシ 各ノードで軽量なプロキシが共有リソースとして動作 プロキシは L4(TCP/IP) トラフィック管理を担当、透過的に機能 2. オプションの L7 プロキシ L7(HTTP/gRPC) の高度な機能が必要であれば専用のプロキシを追加可能 全てのワークロードに配置しなくてよい 3. xDS API Ambient Mode も従来の Istio 同様に xDS API でトラフィックを管理

従来の Sidecar Mode と gRPC Proxyless に加えて 16 Ambient Mode の提供 ・Istio のデータプレーン実装の新しいアプローチ ・アプリケーションコードを変更することなく導入可能 ・各ノードにプロキシが配置される コントロールプレーン App A Node Node Proxy App B App A Proxy App B 1. 共有プロキシ 各ノードで軽量なプロキシが共有リソースとして動作 プロキシは L4(TCP/IP) トラフィック管理を担当、透過的に機能 2. オプションの L7 プロキシ L7(HTTP/gRPC) の高度な機能が必要であれば専用のプロキシを追加可能 全てのワークロードに配置しなくてよい 3. xDS API Ambient Mode も従来の Istio 同様に xDS API でトラフィックを管理 Sidecar Mode に比べて リソース消費の削減やパフォーマンス向上を期待できる Ambient Mode と Sidecar Mode の それぞれのプロキシが担っている処理の違いは？

Ambient Mode の共有プロキシは L4 のみ処理 17 Ambient Mode の共有プロキシ ・L4 の処理のみを扱う コントロールプレーン App A Node Proxy　 App B Sidecar Mode の単体プロキシ ・L4 と L7 の処理を扱う コントロールプレーン App A Pod Proxy　 L4 の主な役割：接続の確立とデータのパケット転送 ノードごとに配置した共有プロキシが L4 の処理のみを扱うため （オプションの L7 専用プロキシと合わせても）リソース消費を抑えられる L7 の主な役割：アプリケーション固有のデータの処理 Pod ごとに配置した単体プロキシが L4 加えて L7 の処理も必須で扱うため より複雑な処理となりリソース消費が大きい L4 L7 L4

Ambient Mode の共有プロキシは L4 のみ処理 18 Ambient Mode の共有プロキシ ・L4 の処理のみを扱う コントロールプレーン App A Node Proxy　 App B Sidecar Mode の単体プロキシ ・L4 と L7 の処理を扱う コントロールプレーン App A Pod Proxy　 L4 の主な役割：接続の確立とデータのパケット転送 ノードごとに配置した共有プロキシが L4 の処理のみを扱うため （オプションの L7 専用プロキシと合わせても）リソース消費を抑えられる L7 の主な役割：アプリケーション固有のデータの処理 Pod ごとに配置した単体プロキシが L4 加えて L7 の処理も必須で扱うため より複雑な処理となりリソース消費が大きい ノード間の通信を 認証や暗号化はできない L4 L7 L4 mTLS によりアプリケーションと 共有プロキシ間の通信を認証 & 暗号化 ノード間の通信も 認証や暗号化ができる

Ambient Mode の共有プロキシは L4 のみ処理 19 Ambient Mode の共有プロキシ ・L4 の処理のみを扱う コントロールプレーン App A Node Proxy　 App B Sidecar Mode の単体プロキシ ・L4 と L7 の処理を扱う コントロールプレーン App A Pod Proxy　 L4 の主な役割：接続の確立とデータのパケット転送 ノードごとに配置した共有プロキシが L4 の処理のみを扱うため （オプションの L7 専用プロキシと合わせても）リソース消費を抑えられる L7 の主な役割：アプリケーション固有のデータの処理 Pod ごとに配置した単体プロキシが L4 加えて L7 の処理も必須で扱うため より複雑な処理となりリソース消費が大きい ノード間の通信を 認証や暗号化はできない L4 L7 L4 mTLS によりアプリケーションと 共有プロキシ間の通信を認証 & 暗号化 ノード間の通信も 認証や暗号化ができる Ambient Mode では アプリケーションと共有プロキシ間のみ mTLS によって認証や暗号化が可能 代わりにノード間の通信は対象外 Sidecar Mode に比べて 機能が制限がされている代わりにリソース消費の効率が良い 求められているセキュリティ要件によって 使い分ける必要がありそう

さいごに 20

さいごに 21 より多くのランタイムやインフラに適用可能 Google Cloud の主要なコンピュートプラットフォームやネットワーク、 また多様なデータプレーンなどをサポート ユーザーのいかなるユースケースにも対応できそう（していきそう）

さいごに 22 より優れた Google Cloud エコシステムとの統合 App Hub や Google Cloud Load Balancing などのサービス との連携やデータプレーンの拡張によりカスタム可能 マルチやハイブリッドに Cloud Service Mesh を 使えるとはいえ、 Google Cloud がベースにあることで より真価を発揮できそう

さいごに 23 メッシュではなくサービスに集中 サービスメッシュを管理するのではなく、サービスメッシュの 提供する機能利用に集中 マネージドであることを活かして エンジニアが注力したい分野に集中してほしそう

さいごに 24 メッシュではなくサービスに集中 サービスメッシュを管理するのではなく、サービスメッシュの 提供する機能利用に集中 マネージドであることを活かして エンジニアが注力したい分野に集中してほしそう Cloud Run との掛け合わせも含めて 今後のアップデートが気になるサービスです！

CREDITS: This presentation template was created by Slidesgo, and includes icons by Flaticon, and infographics & images by Freepik Thanks! @pHaya72 @t_hayashi 25

参考文献 ★ Cloud Run：What’s New ○ https://assets.swoogo.com/uploads/3784231-66186072d78aa.pdf ★ Introducing Cloud Service Mesh: A fully managed global scale service mesh ○ https://assets.swoogo.com/uploads/3777201-661713fbb0003.pdf ★ [速報]フルマネージドなサービスメッシュサービス Cloud Service Mesh が登場 ○ https://zenn.dev/cloud_ace/articles/881608bb25ea14 ★ Traffic Director でプロキシレス サービスメッシュを試してみる ○ https://medium.com/google-cloud-jp/traffic-director-%E3%81%A7%E3%83%97%E3%83%AD%E3%82%AD%E3%82 %B7%E3%83%AC%E3%82%B9-%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%83%A1%E3%83%83%E3% 82%B7%E3%83%A5%E3%82%92%E8%A9%A6%E3%81%97%E3%81%A6%E3%81%BF%E3%82%8B-4c806883a8d1 ★ 第8回: Anthos Service Mesh 入門 ○ https://caddi.tech/archives/4653 26

Appendix 27