メルカリにおけるZone aware routing

Slide 1

Slide 1 text

1 メルカリにおけるZone aware routing Kensei Nakada / @sanposhiho

Slide 2

Slide 2 text

2 Mercari JP Platform Infra team / 2022卒新卒 Kubernetes upstream approver (SIG-Scheduling) Kubernetes Contributor award 2022 winner Kensei Nakada / sanposhiho

Slide 3

Slide 3 text

3 Prologue

Slide 4

Slide 4 text

4 俺の名前は高校生探偵工藤新一 Prologue

Slide 5

Slide 5 text

5 俺の名前は高校生探偵工藤新一新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺は Prologue

Slide 6

Slide 6 text

6 俺の名前は高校生探偵工藤新一新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。 Prologue

Slide 7

Slide 7 text

7 俺の名前は高校生探偵工藤新一新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。「Zone Aware Routingをちょちょっと設定すればええやん (easy!)」 Prologue

Slide 8

Slide 8 text

8 俺の名前は高校生探偵工藤新一新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。「Zone Aware Routingをちょちょっと設定すればええやん (easy!)」コスト削減額の試算に夢中になっていた俺は、 Prologue

Slide 9

Slide 9 text

9 俺の名前は高校生探偵工藤新一新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。「Zone Aware Routingをちょちょっと設定すればええやん (easy!)」コスト削減額の試算に夢中になっていた俺は、背後から近づいてくる黒づくめの(?)インシデント達に気が付かなかった…… 。 Prologue

Slide 10

Slide 10 text

10 俺の名前は高校生探偵工藤新一新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。「Zone Aware Routingをちょちょっと設定すればええやん (easy!)」コスト削減額の試算に夢中になっていた俺は、背後から近づいてくる黒づくめの(?)インシデント達に気が付かなかった…… いや、ギリギリ事前に気が付いた。 Prologue

Slide 11

Slide 11 text

11 俺の名前は高校生探偵工藤新一新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。「Zone Aware Routingをちょちょっと設定すればええやん (easy!)」コスト削減額の試算に夢中になっていた俺は、背後から近づいてくる黒づくめの(?)インシデント達に気が付かなかった…… いや、ギリギリ事前に気が付いた。「このインシデントの可能性達を野放しにしておけば、誰かが同じ轍を踏み、周りの人間にも危害が及ぶ」そう思った俺は、奴らの情報を共有するため、K8s meet upのセッション募集に転がり込んだ… Prologue

Slide 12

Slide 12 text

12 メルカリにおける迷宮の領域間通信 Kensei Nakada / @sanposhiho Inter zone egress

Slide 13

Slide 13 text

13 MercariにおけるK8s Cluster

Slide 14

Slide 14 text

14 MercariにおけるK8s Cluster - GKEを使用 (Standard mode) - 一つのClusterで、Mercari/Merpayほぼ全てのWorkloadが動いている - namespace: 500+ / deployment 1000+ - PlatformチームがCluster adminとして運用

Slide 15

Slide 15 text

15 FinOps! - 直近メルカリでは全社的な目標としてFinOpsを掲げている - Monolith -> Microserviceのマイグレーションを経て、インフラストラクチャーを洗練していくフェーズ - Platformチームでもインフラリソースの効率化を推進

Slide 16

Slide 16 text

16 Networkコストの最適化 - Networkコストの最適化はPlatform側で解決できないことも多い - 画像サイズやレスポンスのサイズが理にかなっているのか、削減の余地があるのかの判断はInfra視点だけを見ていても難しい - Infra側からNetworkコストの最適化として取りうるアプローチの考察

Slide 17

Slide 17 text

17 Networkコストの最適化 - Networkコストの最適化はPlatform側で解決できないことも多い - 画像サイズやレスポンスのサイズが理にかなっているのか、削減の余地があるのかの判断はInfra視点だけを見ていても難しい - Infra側からNetworkコストの最適化として取りうるアプローチの考察 - “Inter zone egressと言う怪しげで高額な取引”

Slide 18

Slide 18 text

18 Inter zone egressと言う怪しげで高額な取引数百万円

Slide 19

Slide 19 text

19 Zone aware routing

Slide 20

Slide 20 text

20 Cluster上のNetwork - Istioを使っているサービス、使ってないサービスの混在 - Istio、KubernetesそれぞれにZone aware routingが実現可能な手法が存在 - Istio: Locality Load Balancing - Kubernetes: Topology Aware Routing

Slide 21

Slide 21 text

21 Istio: Locality Load Balancing - Destination Ruleを設定するだけで有効になる。

Slide 22

Slide 22 text

22 Istio: Locality Load Balancing

Slide 23

Slide 23 text

23 Kubernetes: Topology Aware Routing (hint) - service.kubernetes.io/topology-mode: Auto annotationを Serviceにつけるだけで有効になる - 現状のClusterに存在するNodeのcore数から、「どのEndpointでどの Zoneからの通信を処理するか」を決定する

Slide 24

Slide 24 text

24 Kubernetes: Topology Aware Routing (hint) - service.kubernetes.io/topology-mode: Auto annotationを Serviceにつけるだけで有効になる - 現状のClusterに存在するNodeのcore数から、「どのEndpointでどの Zoneからの通信を処理するか」を決定する

Slide 25

Slide 25 text

25 Kubernetes: Topology Aware Routing の仕組み - Kubernetes側からは「どのPodがどのPodへ通信を送り得るのかが判断できない」 - Zoneに存在するNodeのリソース数がそのZoneが生成するトラフィック量に比例すると仮定

Slide 26

Slide 26 text

26 Kubernetes: Topology Aware Routing の仕組み NodeのCPUの総量が zoneA:zoneB:zoneC = 3:3:5 → 生み出されるトラフィックの量も zoneA:zoneB:zoneC = 3:3:5 になると仮定

Slide 27

Slide 27 text

27 Kubernetes: Topology Aware Routing の仕組み Endpointが3:3:5で存在していれば完璧なZone aware routingになる 3 3 5

Slide 28

Slide 28 text

28 Kubernetes: Topology Aware Routing の仕組みただ、もしEndpointの数が偏っていると …? 3 3 5

Slide 29

Slide 29 text

29 Kubernetes: Topology Aware Routing の仕組み ControllerはZone黄のPodが余っていると判断する 3 3 5

Slide 30

Slide 30 text

30 Kubernetes: Topology Aware Routing の仕組み Zone青 → Zone黄への Inter zone egressが発生する 3 3 5

Slide 31

Slide 31 text

31 Zone aware routing

Slide 32

Slide 32 text

32 どちらの機能が使用できるか通信を送るPodが... - Istio sidecarを持っている場合 → Istio Locality Load Balancing - Istio sidecarを持ってない場合 → K8s Topology Aware Routing

Slide 33

Slide 33 text

33 どちらの機能が使用できるか通信を送るPodが... - Istio sidecarを持っている場合 → Istio Locality Load Balancing - Istio sidecarを持ってない場合 → K8s Topology Aware Routing 「よし、んじゃあ設定するだけやな」「ほんまに大丈夫か？」

Slide 34

Slide 34 text

34 どちらの機能が使用できるか通信を送るPodが... - Istio sidecarを持っている場合 → Istio Locality Load Balancing - Istio sidecarを持ってない場合 → K8s Topology Aware Routing 「よし、んじゃあ設定するだけやな」「Podはほんまにすべての Zoneに存在するんか？」

Slide 35

Slide 35 text

35 博士「PodはほんまにすべてのZoneに存在するんか？」 …確かに

Slide 36

Slide 36 text

36 博士「PodはほんまにすべてのZoneに存在するんか？」 …何も考えずにPod作ったらどこかのZoneに全くPodが存在しない、みたいなこともあり得るなぁ

Slide 37

Slide 37 text

37 博士「PodはほんまにすべてのZoneに存在するんか？」アイデア: Pod Topology Spreadの使用 - Pod Topology Spreadを使用してすべてのZoneに均等にPodを配置 - HPAでMinReplicasを3に設定 - (K8sの方だと9にする必要あり)

Slide 38

Slide 38 text

38 博士「PodはほんまにすべてのZoneに存在するんか？」アイデア: Pod Topology Spreadの使用 - Pod Topology Spreadを使用してすべてのZoneに均等にPodを配置 - HPAでMinReplicasを3に設定「よし、これでPodが全部のZoneにスケジュールされるはずやな」「ほんまに大丈夫か？」

Slide 39

Slide 39 text

39 博士「PodはほんまにすべてのZoneに存在するんか？」アイデア: Pod Topology Spreadの使用 - Pod Topology Spreadを使用してすべてのZoneに均等にPodを配置 - HPAでMinReplicasを3に設定「よし、これでPodが全部のZoneにスケジュールされるはずやな」「スケジューリング制約を常に信じてしまってええんか？」

Slide 40

Slide 40 text

40 博士「Scheduling制約を常に信じていいんか？」 …確かに

Slide 41

Slide 41 text

41 博士「Scheduling制約を常に信じていいんか？」 - Scheduling制約は”Podのスケジュール時”に有効 - Scale downの際には考慮されないので、Scale downの際にZoneXの Podがすべて消えてしまうケースもあり得る

Slide 42

Slide 42 text

42 博士「Scheduling制約を常に信じていいんか？」アイデア: Deschedulerの使用 - 定期的にPodの状態をみて、Schedulingの制約に反している状態の場合は Podをevictしてくれる。 - EvictされたPodはSchedulerによって再度スケジュールされる

Slide 43

Slide 43 text

43 博士「Scheduling制約を常に信じていいんか？」アイデア: Deschedulerの使用 - 定期的にPodの状態をみて、Schedulingの制約に反している状態の場合は Podをevictしてくれる。 - EvictされたPodはSchedulerによって再度スケジュールされる「よし、これでPodが全部のZoneに常におるはずやな」「ほんまに大丈夫か？」

Slide 44

Slide 44 text

44 博士「Scheduling制約を常に信じていいんか？」アイデア: Deschedulerの使用 - 定期的にPodの状態をみて、Schedulingの制約に反している状態の場合は Podをevictしてくれる。 - EvictされたPodはSchedulerによって再度スケジュールされる「よし、これでPodが全部のZoneに常におるはずやな」「そもそも各Zoneが生み出すトラフィックの量って等しいんか？」

Slide 45

Slide 45 text

45 博士「各Zoneが生み出すトラフィックの量って等しい？」 ……等しくないかもなぁ「仮にいくつかのPodだけ通信を多めに受け取ったら HPAやばいんちゃうんか？」

Slide 46

Slide 46 text

46 博士「仮にいくつかのPodだけ通信を多めに受け取ったらHPA やばいんちゃうんか？」 …確かにHPAは全体の使用率をみてるしなぁ

Slide 47

Slide 47 text

47 博士「仮にいくつかのPodだけ通信を多めに受け取ったらHPA やばいんちゃうんか？」 …確かにHPAは全体の使用率をみてるしなぁ …通信の偏りが出たら、特定のZoneのPodだけ通信受け取りすぎて死ぬ、みたいな可能性あるなぁ

Slide 48

Slide 48 text

48 博士「仮にいくつかのPodだけ通信を多めに受け取ったらHPA やばいんちゃうんか？」アイデア: 通信を送っているPodにもPodTopologySpread+deschedulerを設定するこれによってZoneごとに通信量の偏りをなくすことができる

Slide 49

Slide 49 text

49 現状の整理

Slide 50

Slide 50 text

50 現状の整理すべてのZoneが等しい数のPodをもっており、等しい量のトラフィックを送る

Slide 51

Slide 51 text

51 現状の整理「よし、これで全部解決やな」「ちょっと前のスライド戻るで」

Slide 52

Slide 52 text

52 Kubernetes: Topology Aware Routing の仕組み NodeのCPUの総量が zoneA:zoneB:zoneC = 3:3:5 → 生み出されるトラフィックの量も zoneA:zoneB:zoneC = 3:3:5 になると仮定「…」「そもそも、ほんまにこの仮定って信じていいんか？」

Slide 53

Slide 53 text

53 メルカリのNode達いくつかのサービスは特定のZoneで動作する必要がある。 ↓ そのサービス向けに特化したNodePoolを用意しており、そのNodePoolはそのサービスのPodしか動作しないようになっている（Taints）

Slide 54

Slide 54 text

54 メルカリのNode達いくつかのサービスは特定のZoneで動作する必要がある。 ↓ そのサービス向けに特化したNodePoolを用意しており、そのNodePoolはそのサービスのPodしか動作しないようになっている（Taints） ↓ Nodeの数がZoneごとに偏りがある

Slide 55

Slide 55 text

55 Cluster Autoscaler (GKE) - location_policy: BALANCED を使うことで、Zone間でのNodeの数のばらつきを抑えてくれる - 常に均等であると保証はされない - Scale Downの際にはZoneは考慮されない。単純に使用率が低いNodeから削除される

Slide 56

Slide 56 text

56 理想すべてのZoneが等しい数のPodをもっており、等しい量のトラフィックを送る

Slide 57

Slide 57 text

57 現実 (zone黄だけNodeが少ないとする) Zone黄から生み出されるトラフィックは小さいはず、と判断されるのでZone黄に割り当てられるEndpointの数が少ない

Slide 58

Slide 58 text

58 現実 (zone黄だけNodeが少ないとする) Zone黄のいくつかのPodたちが他と比べてトラフィックを多く受ける

Slide 59

Slide 59 text

59 現実 (zone黄だけNodeが少ないとする) HPAは全体の使用率を見るので、 ScaleUpが行われないかも

Slide 60

Slide 60 text

60 ここまでの話し - PodはPod Topology Spread(w/ descheduler)を使えばZoneに均等に割り振れる - 通信を送る側、受け取る側両方に設定の必要がある - IstioのLocality Load Balancingはこれで大丈夫そう

Slide 61

Slide 61 text

61 ここまでの話し - PodはPod Topology Spread(w/ descheduler)を使えばZoneに均等に割り振れる - 通信を送る側、受け取る側両方に設定の必要がある - IstioのLocality Load Balancingはこれで大丈夫そう - ただ、K8sのTopology Aware Routingは各ZoneのNodeの総core数が Endpointの割り振りに影響する - そして、ZoneごとにNodeの総core数を均一にするのはどうしても難しい

Slide 62

Slide 62 text

62 メルカリでの結論

Slide 63

Slide 63 text

63 メルカリでの結論　　　　　　　　　「Deployment 1つじゃどうしようもなくね？」

Slide 64

Slide 64 text

64 メルカリでの結論アイデア: ZoneごとにHPA、Deploymentをセットアップする - 問題だったのは、特定のZoneのPodへ通信が集中しても、HPAが全ての Zoneの全てのPodをみているせいでScaleUpが起きない可能性があること - ZoneごとにDeploymentとHPAを設定することで、各Zone内のPodsごとにScaleUpが可能

Slide 65

Slide 65 text

65 現実 (zone黄だけNodeが少ないとする) 各ZoneのPod毎にScalingが行われれば、特定のZoneに通信が集まってもScaleされるはず

Slide 66

Slide 66 text

66 追加のメリット Pod Topology Spread と Deschedulerのセットアップが全く必要ない - メルカリでは一つのマイクロサービスが複数のマイクロサービスから通信を受けると言う場合も多い - 送る側のマイクロサービス全てにこれらをセットアップするのは実はしんどい

Slide 67

Slide 67 text

67 検証

Slide 68

Slide 68 text

68 検証内容 - Google Cloud metricsのpod_ﬂow/egress_bytes_countを使用 - どのNamespaceからどのNamespaceへどのくらいの通信量があるかが見える

Slide 69

Slide 69 text

69 検証内容 - Google Cloud metricsのpod_ﬂow/egress_bytes_countを使用 - どのNamespaceからどのNamespaceへどのくらいの通信量があるかが見える - これを使用して通信量が多いサービス間通信を検証のターゲットに

Slide 70

Slide 70 text

70 検証内容 - Google Cloud metricsのpod_ﬂow/egress_bytes_countを使用 - どのNamespaceからどのNamespaceへどのくらいの通信量があるかが見える - これを使用して通信量が多いサービス間通信を検証のターゲットに - K8sのTopology Aware Routingを使用 - Istioの方は別途検証中

Slide 71

Slide 71 text

71 グラフ: zone-cのPodが各Zoneから受けているTrafﬁc量

Slide 72

Slide 72 text

72 有効後、zone-cから受けるトラフィックの割合が急増

Slide 73

Slide 73 text

73 将来の展望

Slide 74

Slide 74 text

74 マニフェスト管理サービス開発者側でのZone Aware Routing有効化のためのオペレーションのコストをできるだけ減らしたい - HPA、Deploymentの複数作成/管理がめんどい - Zone毎にほぼ全く同じHPA、Deploymentの作成が必要 - 必要な設定もわかりづらい - Istioの機能、K8sの機能どちらを使えばいいのか

Slide 75

Slide 75 text

75 Kubernetes Kit メルカリにはKubernetes Kitと呼ばれる抽象化レイヤーがあり、開発者はそれを通してKubernetesのマニフェストを管理している

Slide 76

Slide 76 text

76 Kubernetes Kit

Slide 77

Slide 77 text

77 Kubernetes Kit 裏で必要な設定 + 必要な数のHPA、 Deploymentの生成を行う

Slide 78

Slide 78 text

78 Wanna know more about Kubernetes Kit?

Slide 79

Slide 79 text

79 KEP-2433: PreferZone Heuristic PreferZone と言う新たな Heuristic がKEP-2433に追加で提案されている Zoneごとの総core数の割合を見て、EndpointのZoneへの割り当てをするのではなく、Zone-xのEndpointをZone-xへ常に割り当てる (シンプル!)

Slide 80

Slide 80 text

80 v1.29で入る…?

Slide 81

Slide 81 text

81 まとめ

Slide 82

Slide 82 text

82 まとめ - Zone Aware Routing (Istio/K8s)はただ設定をいじるだけで有効になるが、単純に有効にするだけでは問題の種になり得る - Pod Topology Spread (w/ descheduler)を使うのは一つの手ではあるが、K8sのZone Aware Routingを使う時はNodeの数に注意が必要 - また、サービスの数によっては、セットアップのめんどさもある - Zone毎にDeploymentとHPAを作るのがシンプルでいいかも - ただ、マニフェスト管理等のめんどさもある - メルカリではKubernetes Kitを通して解決予定 (WIP)

Slide 83

Slide 83 text

83 We are めっちゃ hiring!!! Platformで働く仲間をめっちゃ探しています！！！！今回話したこと以外にも、めっちゃ色んな面白いことやってます！！！ - istioとかのnetworkらへん - 内製しているCI/CD基盤開発 - 開発者向けの内製抽象化レイヤーの開発 - etc…. ! 「メルカリ Platform 採用」でいますぐ検索！