Reducing Cross-Zone Egress at Spotify with Custom gRPC Load Balancing Recap

Transcript

1. Kubernetes Meetup Tokyo #64 KubeCon + CloudNativeCon Europe 2024 Recap Reducing Cross-Zone Egress at Spotify with Custom gRPC Load Balancing 株式会社スリーシェイク 永瀬滉平 Copyright © 3-shake, Inc. All Rights Reserved.
2. 自己紹介 Copyright © 3-shake, Inc. All Rights Reserved. 株式会社スリーシェイク Sreake事業部所属。 2019年から新卒でISPの会社に入社し、パブリッククラウドの構築・運用に 従事。モバイルデバイスを用いた R&Dにも携わる。 2021年にスリーシェイク入社後、 AWS・GCPを中心にクラウドと Kubernetesを組み合わせたシステムの設計・構築・運用およびマネジメ ン トに従事 永瀬 滉平 (@koh_naga) 弊社からは3人が参加しました！
3. 取り上げるセッション Reducing Cross-Zone Egress at Spotify with Custom gRPC Load Balancing 訳: Spotify社におけるカスタムgRPCロードバランシングを用いたクロスゾーン Egressトラフィックの削減 セッション情報: https://sched.co/1YePw 【セッション選定の背景】 以前、AWS設計業務の中でAvailability Zoneを跨ぐ通信の制御について設計したことがあったが、その時とは別のア プローチを採用している点が興味深かったため、このセッションを取り上げた。 私が行った設計アプローチの紹介、および Spotify社事例との比較も行う。 ML/AI系セッションが多かったので逆張りを ...
4. セッション紹介 ※以降、スライドを引用し説明します 01 Copyright © 3-shake, Inc. All Rights Reserved.
5. Spotifyの抱える課題について • Spotify社のサービスはクラウド上にマイクロサービスアーキテクチャで構築されている • サービス間で行われる大量の通信の実に約 70%がゾーンを跨ぐ通信でありこれがコスト要因となっていた 3ゾーンあって1つのクライアントからシンプルに ロードバランシングすると約2/3はゾーン跨ぎと なる
6. Spotifyの抱える課題について • Spotify社のサービスはクラウド上にマイクロサービスアーキテクチャで構築されている • サービス間で行われる大量の通信の実に約 70%がゾーンを跨ぐ通信でありこれがコスト要因となって いた これを解消するためすでに利用していたgRPCを拡張してクライアント側ロードバランシン グを実装した
7. gRPCについて gRPCはオープンソースの RPC(Remote Procedure Call)フレームワーク。HTTP/2をベースとしており、双方向スト リーミングやプラグイン的に認証やロードバランシングポリシーを差し込むことができる。 バックエンドサーバーやモバイルデバイスなど幅広いユースケースをカバーしている。 • gRPCではいくつかのロードバランシングアルゴリズムが使える (※ライブラリや言語によって異なる ) ◦ ラウンドロビン ◦ 重みづけラウンドロビン ◦ Least Request • これに加えて独自のロードバランシングを実装することもできる (Proposal A52) • ロードバランシングアルゴリズムで使用するメトリクスが必要な場合は、これもカスタム実装することができる (Proposal A51)
8. Spotifyでのロードバランシング要件 • 基本的には同一ゾーン内で通信したい • しかし料金分の効果が見込めるシチュエーションにおいてはゾーン間通信を許容してトラフィック制御を行うよ うにしたい ◦ レイテンシーが少なく、ユーザビリティ向上に寄与することが見込まれる場合 ◦ サクセスレートが高く、ユーザビリティ向上に寄与することが見込まれる場合
9. ロードバランシングアルゴリズムについて ベースのロードバランシングアルゴリズムは Expected Latencyと呼んでいる。 過去のRPCのレイテンシーをベースに予測されるレイテンシーを計算しロードバランシングを行う
10. 前提として、各サーバーには FIFOキューが設けられていて、ここからデキューしてサーバーが処理を行うものとす る。 サクレスレートが100%である場合を考える ロードバランシングアルゴリズムについて • a = キューに積まれている既存のリクエスト • 1 = クライアント(ワンちゃん)が送信したリクエスト • L = 1つのリクエスト対してかかるレイテンシー
11. 次にサクレスレートが 50%である場合を考える (リトライが発生するシチュエーション ) ロードバランシングアルゴリズムについて 確率pの事象が発生するまでの試行回数の 期待値は1/p (多分½ * 2だけでいいんじゃないかな...？)
12. 失敗のときのレイテンシーを掛け合わせて足すことで Expected Latencyとする ロードバランシングアルゴリズムについて 1つのリクエストを処理する時に失敗時のレイ テンシーが予測されるリトライ回数分だけ繰り 返されることを示す
13. ロードバランシングアルゴリズムについて Copyright © 3-shake, Inc. All Rights Reserved. ここにゾーン跨ぎによる重みづけを取り入れる クライアントとサーバの存在するゾーンが違う場合は係数 10を掛け算する。 係数を以てしてもExpected Latency(E)が覆らない -> ユーザビリティが向上することによって料金分を十分ペイできると 判断しゾーン間通信を許容することを意味する Zc = クライアントの存在するゾーン Zs = サーバの存在するゾーン
14. 実装においてはORCA(Open Request Cost Aggregation)を参考にしつつ独自の実装を行なった • ORCAはサーバーからリクエストコストや各種メトリクスを収集・レポーティングするための標準仕様 • SpotifyではJavaをメインで使用しており、 gRPCライブラリでの実装がすでに行われていたため、こ の実装を参考にゾーンデータなどのデータを収集 実装について
15. 約70% -> 約30% までゾーン間通信が削減 効果
16. 約70% -> 約30% までゾーン間通信が削減 効果 複雑な問題として捉えていたが、これだけシンプルな仕組みで サービス影響を与えずに十分な効果を得られた！
17. ORCAについて 02 Copyright © 3-shake, Inc. All Rights Reserved.
18. ORCAについて 02 Copyright © 3-shake, Inc. All Rights Reserved. ※プロポーザルでのキャッチアップに終始して、現時点の実装を追うには至りませんでし た...申し訳ないです
19. ORCA(Open Request Cost Aggregation)について プロポーザル: https://github.com/envoyproxy/envoy/issues/6614 • データプレーンロードバランシングにフォーカスを当てた標準仕 様とその実装(を目指している) • 含まれるスコープ ◦ バックエンドでのメトリクス集計メカニズム ◦ データプレーン上でこれらのレポートを集計 • 含まれないスコープ ◦ 集約されたデータを操作するロードバランシングアルゴリ ズム ◦ ロードバランシングポリシーをデータプレーンに配信する メカニズム Open Request Cost Aggregation (ORCA) (https://docs.google.com/document/d/1NSnK3346BkBo1JUU3I9I5NYYnaJZQPt8_Z_XCBCI3uA/edit)
20. ORCA ロードレポートフォーマット • ロードレポートはキーバリューで定義される • CPU・Memoryの利用率をコアメトリクスとして定義しているが、ユーザー定義の値も設定可能 • ロードレポートはClusterStats messageに統合されて、LRS(Load Report Service)にて管理サーバー に転送される • ロードレポートはprotobufスキーマで定義される https://github.com/cncf/xds/blob/main/xds/data/orca/v3/orca_load_report.proto#L15
21. ORCA ロードレポートフォーマット • In-band reporting: リクエストパス内で実施するレポーティング ◦ JSONエンコード ◦ Protobufのバイナリシリアライズ ◦ HTTPヘッダエンコード • Out-of-band reporting: リクエストパス外で実施するレポーティング ◦ ロードレポートを行うためのエージェントなどを設置して、定期的にサンプリングを行うようにする ◦ データプレーンロードバランサはエージェントに接続してフェッチする or エージェントからレポーティングを実 施してもらう service OpenRCAService { rpc StreamCoreMetrics(LoadReportRequest) returns (stream LoadReport) { } } message LoadReportRequest { // Interval for generating ORCA core metric responses. google.protobuf.Duration report_interval = 1; // Request costs to collect. If this is empty, all known requests costs tracked by // the load reporting agent will be returned. This provides an opportunity for // the client to selectively obtain a subset of tracked costs. repeated string request_cost_names = 2; }
22. ORCA バックエンドのアーキテクチャデザイン(In-band report) • サイドカー ◦ サイドカーでresponseにin-band reportのヘッダ追加を行 う ◦ ベースとしてアプリケーションを変更する必要がない ◦ コアメトリクス(CPU, Memory)以外のメトリクスにおいては OpenTelemetryなどのライブラリを使う必要がある Open Request Cost Aggregation (ORCA) (https://docs.google.com/document/d/1NSnK3346BkBo1JUU3I9I5NYYnaJZQPt8_Z_XCBCI3uA/edit) • ライブラリ ◦ OpenTelemetryなどでメトリクス収集の上 responseに in-band reportのヘッダ追加を行う ◦ Googleがコアとなって開発している gRPCライブラリであ れば、言語によってはこれらの機能がすでに統合されて いる
23. ORCA バックエンドのアーキテクチャデザイン(Out-of-band report) • エージェント ◦ Out-of-band reportのためのエージェント ◦ サイドカー同様、コアメトリクス (CPU, Memory)以外のメトリクスにおいては OpenTelemetryなどのラ イブラリを使う必要がある ◦ またこれらをエージェントが取得するために Service側でポートを開けるなどの措置が必要 Open Request Cost Aggregation (ORCA) (https://docs.google.com/document/d/1NSnK3346BkBo1JUU3I9I5NYYnaJZQPt8_Z_XCBCI3uA/edit)
24. 別の解決策 ~ IstioのLocality Load Balancingを用いた アプローチ ~ 03 Copyright © 3-shake, Inc. All Rights Reserved.
25. Istioについて IstioはKubernetes環境にて使用される、いわゆるサービスメッシュツールの一つで、以下のようなモチ ベーションで用いられる • 可観測性の向上 サービス間の関連性を図示したり、サービスに関するメトリクスを提供 • きめ細やかなトラフィック制御 ロケーションを考慮した負荷分散を実現したり、アプリケーションバージョン毎にトラフィック量を調整する 機能などを提供 • セキュリティの向上 外部サービスなどと連携した認証認可の実装やサービス間通信に mTLSを提供 Istio (https://istio.io/latest/)
26. Locality Load Balancing トラフィック制御の一つとして Locality Load Balancingという機能を提供している。 アベイラビリティゾーンやリージョンのような地理的条件を考慮してロードバランシングをする 使用できる地理情報の定義とラベル • Region: topology.kubernetes.io/region • Zone: topology.kubernetes.io/zone • Sub-zone: 任意のカスタムラベル。例えば、ネットワークセグメントやラックについてなど ・Istio / Locality Load Balancing (https://istio.io/latest/docs/tasks/traffic-management/locality-load-balancing/)
27. apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: sapmle-rule1 spec: host: sample.sample.svc.cluster.local trafficPolicy: loadBalancer: localityLbSetting: enabled: true failoverPriority: - "topology.kubernetes.io/region" - "topology.kubernetes.io/zone" outlierDetection: consecutive5xxErrors: 3 interval: 3s baseEjectionTime: 1m サンプルマニフェストとロードバランシングのイメージ
28. サンプルマニフェストとロードバランシングのイメージ apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: helloworld spec: host: helloworld.sample.svc.cluster.local trafficPolicy: loadBalancer: localityLbSetting: enabled: true distribute: - from: region1/zone1/* to: "region1/zone1/*": 70 "region1/zone2/*": 20 "region3/zone4/*": 10 outlierDetection: consecutive5xxErrors: 100 interval: 1s baseEjectionTime: 1m ・Istio / Locality weighted distribution (https://istio.io/latest/docs/tasks/traffic-management/locality-load-balancing/distribute/) • トポロジーを指定してゾーン毎に重み付けを行うことも できる • 右記の例ではregion1のzone1が送信元のトラフィック に対して、 ◦ region1/zone1には70% ◦ region1/zone2には20% ◦ region3/zone4には10% の割合でルーティングすることが示されている
29. Appendix: Topology Aware Routingの場合 同じゾーン内でトラフィックをルーティングするように調整する Kubernetesの機能 (v1.29現在 beta機能) ・Topology Aware Routing | Kubernetes (https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) endpoints: - addresses: - 10.161.19.132 conditions: ready: true serving: true terminating: false hints: forZones: - name: ap-northeast-1a nodeName: ip-10-161-19-184.ap-northeast-1.compute.internal targetRef: kind: Pod name: sample-pod-566c5b4c9b-6wd8j namespace: sample uid: 1249d074-e163-48fc-a17e-a0f0fa7a8052 zone: ap-northeast-1c • serviceリソースに対してannotationで、 service.kubernetes.io/topology-mode: autoを 設定することで有効化 • EndpointSliceにhintsが示されて、kube-proxyが これを元にルーティングを調整する • ゾーンに存在するノードの CPU core数に応じて Endpointの比率が設定される
30. Spotifyのソリューションとの比較 Expected Latency Istio Locality Load Balancing Topology Aware Routing 地理的条件の考 慮 ⚪ ⚪ △ ある程度ゾーンごとの CPU core数を管理する必 要があるが、オートスケーリングが絡むと期待通 りに動作する条件を整い続けるのは難しそう レイテンシーの 考慮 ⚪ △ ゾーン毎に重みづけができるものの、レイテン シーをベースにダイナミックに変更することはでき ない。 × 実装容易性 △ バックエンドにカスタムメトリクスの収集を 独自に実装したりとやや煩雑 ⚪ ⚪ 運用性 △ 変更の際にアプリケーションコードに手を 加えることになる △ アプリケーションとは切り離してロードバランシン グをk8sの世界で管理できるものの、 Istioというコ ンポーネントが一つ増えることになる ⚪
31. あわせて見たいセッション Troubleshooting Hidden Performance and Costs in Network Traffic Across Multiple AZs with eBPF セッション情報: https://sched.co/1YeNc 【概要】 • AWSにおけるAZを跨ぐ構成のKubernetesにおいて、AZを跨ぐトラフィックに関するコスト・パフォーマンスを eBPFを用いて可視化したことについてのセッション • トラフィックのうちxx%がAZを跨いでいるかや、AZの跨ぎ方パターンによってパフォーマンス傾向に違いがあ るかなどを可視化し、コストとアベイラビリティ・パフォーマンスのトレードオフにおけるバランスを探れるよう にした このセッション内容と合わせてロードバランシングのためのデータ収集と活用がさらに最適化・簡素化できないか。 詳細な内容についてはここでは割愛 ...
32. 今後さらにやってみたいこと • ORCAの実装をコードリーディングし理解を深める • gRPCのCustom backend metricsを用いてExpected Latencyに必要なメトリクスを収集 • Expected latencyを実装 • バックエンド側メトリクス収集における別のアプローチ検討 ◦ eBPFやOpentelemetryなどのキーワードを元に調査してみたい
33. まとめ • プロキシレスでのロードバランシングの実装の選択肢も考えられた ◦ gRPCのカスタムロードバランシングを用いて独自のロードバランシングアルゴリズムを実装できる ◦ サーバーからのメトリクス・データ収集には ORCAのようなロードレポートの実装もすでにある程度成 されている • KubeCon初参加でしたが、本当にいい刺激になりました • みんなKubeCon参加してみよう！ 　　　　　　　　　　　　　　　　これもらえるよ →
34. ご清聴ありがとうございました Copyright © 3-shake, Inc. All Rights Reserved.