メルカリにおけるZone aware routing

Kubernetes Meetup Tokyo #61
https://k8sjp.connpass.com/event/298147/

Transcript

1. 1 メルカリにおけるZone aware routing Kensei Nakada / @sanposhiho
2. 2 Mercari JP Platform Infra team / 2022卒新卒 Kubernetes upstream approver (SIG-Scheduling) Kubernetes Contributor award 2022 winner Kensei Nakada / sanposhiho
3. 3 Prologue
4. 4 俺の名前は高校生探偵工藤新一 Prologue
5. 5 俺の名前は高校生探偵工藤新一 新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺は Prologue
6. 6 俺の名前は高校生探偵工藤新一 新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。 Prologue
7. 7 俺の名前は高校生探偵工藤新一 新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。 「Zone Aware Routingをちょちょっと設定すればええやん (easy!)」 Prologue
8. 8 俺の名前は高校生探偵工藤新一 新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。 「Zone Aware Routingをちょちょっと設定すればええやん (easy!)」 コスト削減額の試算に夢中になっていた俺は、 Prologue
9. 9 俺の名前は高校生探偵工藤新一 新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。 「Zone Aware Routingをちょちょっと設定すればええやん (easy!)」 コスト削減額の試算に夢中になっていた俺は、背後から近づいてくる黒づくめの(?)イン シデント達に気が付かなかった…… 。 Prologue
10. 10 俺の名前は高校生探偵工藤新一 新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。 「Zone Aware Routingをちょちょっと設定すればええやん (easy!)」 コスト削減額の試算に夢中になっていた俺は、背後から近づいてくる黒づくめの(?)イン シデント達に気が付かなかった…… いや、ギリギリ事前に気が付いた。 Prologue
11. 11 俺の名前は高校生探偵工藤新一 新卒2年目にしてネットワークチームに配属され、FinOps担当になった俺はInter zone egressと言う怪しげで高額な取引を目撃した。 「Zone Aware Routingをちょちょっと設定すればええやん (easy!)」 コスト削減額の試算に夢中になっていた俺は、背後から近づいてくる黒づくめの(?)イン シデント達に気が付かなかった…… いや、ギリギリ事前に気が付いた。 「このインシデントの可能性達を野放しにしておけば、誰かが同じ轍を踏み、周りの人 間にも危害が及ぶ」 そう思った俺は、奴らの情報を共有するため、K8s meet upのセッション募集に転が り込んだ… Prologue
12. 12 メルカリにおける迷宮の領域間通信 Kensei Nakada / @sanposhiho Inter zone egress
13. 13 MercariにおけるK8s Cluster
14. 14 MercariにおけるK8s Cluster - GKEを使用 (Standard mode) - 一つのClusterで、Mercari/Merpayほぼ全てのWorkloadが動いている - namespace: 500+ / deployment 1000+ - PlatformチームがCluster adminとして運用
15. 15 FinOps! - 直近メルカリでは全社的な目標としてFinOpsを掲げている - Monolith -> Microserviceのマイグレーションを経 て、インフラストラクチャーを洗練していくフェーズ - Platformチームでもインフラリソースの効率化を推進
16. 16 Networkコストの最適化 - Networkコストの最適化はPlatform側で解決できないことも多い - 画像サイズやレスポンスのサイズが理にかなっているの か、削減の余地があるのかの判断はInfra視点だけを 見ていても難しい - Infra側からNetworkコストの最適化として取りうるアプローチの考察
17. 17 Networkコストの最適化 - Networkコストの最適化はPlatform側で解決できないことも多い - 画像サイズやレスポンスのサイズが理にかなっているの か、削減の余地があるのかの判断はInfra視点だけを 見ていても難しい - Infra側からNetworkコストの最適化として取りうるアプローチの考察 - “Inter zone egressと言う怪しげで高額な取引”
18. 18 Inter zone egressと言う怪しげで高額な取引 数百万円
19. 19 Zone aware routing
20. 20 Cluster上のNetwork - Istioを使っているサービス、使ってないサービスの混在 - Istio、KubernetesそれぞれにZone aware routingが実現可能な手法が 存在 - Istio: Locality Load Balancing - Kubernetes: Topology Aware Routing
21. 21 Istio: Locality Load Balancing - Destination Ruleを設定するだけで有効になる。
22. 22 Istio: Locality Load Balancing
23. 23 Kubernetes: Topology Aware Routing (hint) - service.kubernetes.io/topology-mode: Auto annotationを Serviceにつけるだけで有効になる - 現状のClusterに存在するNodeのcore数から、「どのEndpointでどの Zoneからの通信を処理するか」を決定する
24. 24 Kubernetes: Topology Aware Routing (hint) - service.kubernetes.io/topology-mode: Auto annotationを Serviceにつけるだけで有効になる - 現状のClusterに存在するNodeのcore数から、「どのEndpointでどの Zoneからの通信を処理するか」を決定する
25. 25 Kubernetes: Topology Aware Routing の仕組み - Kubernetes側からは「どのPodがどのPodへ通信を送り得るのかが判断で きない」 - Zoneに存在するNodeのリソース数がそのZoneが生成するトラフィック量に 比例すると仮定
26. 26 Kubernetes: Topology Aware Routing の仕組み NodeのCPUの総量が zoneA:zoneB:zoneC = 3:3:5 → 生み出されるトラフィックの量も zoneA:zoneB:zoneC = 3:3:5 になると仮定
27. 27 Kubernetes: Topology Aware Routing の仕組み Endpointが3:3:5で存在していれば 完璧なZone aware routingになる 3 3 5
28. 28 Kubernetes: Topology Aware Routing の仕組み ただ、もしEndpointの数が偏っていると …? 3 3 5
29. 29 Kubernetes: Topology Aware Routing の仕組み ControllerはZone黄のPodが余ってい ると判断する 3 3 5
30. 30 Kubernetes: Topology Aware Routing の仕組み Zone青 → Zone黄 への Inter zone egressが発生する 3 3 5
31. 31 Zone aware routing
32. 32 どちらの機能が使用できるか 通信を送るPodが... - Istio sidecarを持っている場合 → Istio Locality Load Balancing - Istio sidecarを持ってない場合 → K8s Topology Aware Routing
33. 33 どちらの機能が使用できるか 通信を送るPodが... - Istio sidecarを持っている場合 → Istio Locality Load Balancing - Istio sidecarを持ってない場合 → K8s Topology Aware Routing 「よし、んじゃあ設定するだけやな」 「ほんまに大丈夫か？」
34. 34 どちらの機能が使用できるか 通信を送るPodが... - Istio sidecarを持っている場合 → Istio Locality Load Balancing - Istio sidecarを持ってない場合 → K8s Topology Aware Routing 「よし、んじゃあ設定するだけやな」 「Podはほんまにすべての Zoneに存在するんか？」
35. 35 博士「PodはほんまにすべてのZoneに存在するんか？」 …確かに
36. 36 博士「PodはほんまにすべてのZoneに存在するんか？」 …何も考えずにPod作ったらどこかのZoneに全くPodが存在しない、みたいなこと もあり得るなぁ
37. 37 博士「PodはほんまにすべてのZoneに存在するんか？」 アイデア: Pod Topology Spreadの使用 - Pod Topology Spreadを使用してすべてのZoneに均等にPodを配置 - HPAでMinReplicasを3に設定 - (K8sの方だと9にする必要あり)
38. 38 博士「PodはほんまにすべてのZoneに存在するんか？」 アイデア: Pod Topology Spreadの使用 - Pod Topology Spreadを使用してすべてのZoneに均等にPodを配置 - HPAでMinReplicasを3に設定 「よし、これでPodが全部のZoneにスケジュールされ るはずやな」 「ほんまに大丈夫か？」
39. 39 博士「PodはほんまにすべてのZoneに存在するんか？」 アイデア: Pod Topology Spreadの使用 - Pod Topology Spreadを使用してすべてのZoneに均等にPodを配置 - HPAでMinReplicasを3に設定 「よし、これでPodが全部のZoneにスケジュールされ るはずやな」 「スケジューリング制約を常に信じてしまってええん か？」
40. 40 博士「Scheduling制約を常に信じていいんか？」 …確かに
41. 41 博士「Scheduling制約を常に信じていいんか？」 - Scheduling制約は”Podのスケジュール時”に有効 - Scale downの際には考慮されないので、Scale downの際にZoneXの Podがすべて消えてしまうケースもあり得る
42. 42 博士「Scheduling制約を常に信じていいんか？」 アイデア: Deschedulerの使用 - 定期的にPodの状態をみて、Schedulingの制約に反している状態の場合は Podをevictしてくれる。 - EvictされたPodはSchedulerによって再度スケジュールされる
43. 43 博士「Scheduling制約を常に信じていいんか？」 アイデア: Deschedulerの使用 - 定期的にPodの状態をみて、Schedulingの制約に反している状態の場合は Podをevictしてくれる。 - EvictされたPodはSchedulerによって再度スケジュールされる 「よし、これでPodが全部のZoneに常におる はずやな」 「ほんまに大丈夫か？」
44. 44 博士「Scheduling制約を常に信じていいんか？」 アイデア: Deschedulerの使用 - 定期的にPodの状態をみて、Schedulingの制約に反している状態の場合は Podをevictしてくれる。 - EvictされたPodはSchedulerによって再度スケジュールされる 「よし、これでPodが全部のZoneに常におる はずやな」 「そもそも各Zoneが生み出すトラフィックの 量って等しいんか？」
45. 45 博士「各Zoneが生み出すトラフィックの量って等しい？」 ……等しくないかもなぁ 「仮にいくつかのPodだけ通信を多めに受け取ったら HPAや ばいんちゃうんか？」
46. 46 博士「仮にいくつかのPodだけ通信を多めに受け取ったらHPA やばいんちゃうんか？」 …確かにHPAは全体の使用率をみてるしなぁ
47. 47 博士「仮にいくつかのPodだけ通信を多めに受け取ったらHPA やばいんちゃうんか？」 …確かにHPAは全体の使用率をみてるしなぁ …通信の偏りが出たら、特定のZoneのPodだけ通信受け取りすぎて死ぬ、みたい な可能性あるなぁ
48. 48 博士「仮にいくつかのPodだけ通信を多めに受け取ったらHPA やばいんちゃうんか？」 アイデア: 通信を送っているPodにもPodTopologySpread+deschedulerを設 定する これによってZoneごとに通信量の偏りをなくすことができる
49. 49 現状の整理
50. 50 現状の整理 すべてのZoneが等しい数のPodをもっており、 等しい量のトラフィックを送る
51. 51 現状の整理 「よし、これで全部解決やな」 「ちょっと前のスライド戻るで」
52. 52 Kubernetes: Topology Aware Routing の仕組み NodeのCPUの総量が zoneA:zoneB:zoneC = 3:3:5 → 生み出されるトラフィックの量も zoneA:zoneB:zoneC = 3:3:5 になると仮定 「…」 「そもそも、ほんまにこの仮定って信じていい んか？」
53. 53 メルカリのNode達 いくつかのサービスは特定のZoneで動作する必要がある。 ↓ そのサービス向けに特化したNodePoolを用意しており、 そのNodePoolはそのサービスのPodしか動作しないようになっている （Taints）
54. 54 メルカリのNode達 いくつかのサービスは特定のZoneで動作する必要がある。 ↓ そのサービス向けに特化したNodePoolを用意しており、 そのNodePoolはそのサービスのPodしか動作しないようになっている （Taints） ↓ Nodeの数がZoneごとに偏りがある
55. 55 Cluster Autoscaler (GKE) - location_policy: BALANCED を使うことで、Zone間でのNodeの数のば らつきを抑えてくれる - 常に均等であると保証はされない - Scale Downの際にはZoneは考慮されない。単純に 使用率が低いNodeから削除される
56. 56 理想 すべてのZoneが等しい数のPodをもっており、 等しい量のトラフィックを送る
57. 57 現実 (zone黄だけNodeが少ないとする) Zone黄から生み出されるトラフィックは小さい はず、と判断されるのでZone黄に割り当てられ るEndpointの数が少ない
58. 58 現実 (zone黄だけNodeが少ないとする) Zone黄のいくつかのPodたちが他と比べて トラフィックを多く受ける
59. 59 現実 (zone黄だけNodeが少ないとする) HPAは全体の使用率を見るので、 ScaleUpが行われないかも
60. 60 ここまでの話し - PodはPod Topology Spread(w/ descheduler)を使えばZoneに均等 に割り振れる - 通信を送る側、受け取る側両方に設定の必要がある - IstioのLocality Load Balancingはこれで大丈夫そ う
61. 61 ここまでの話し - PodはPod Topology Spread(w/ descheduler)を使えばZoneに均等 に割り振れる - 通信を送る側、受け取る側両方に設定の必要がある - IstioのLocality Load Balancingはこれで大丈夫そ う - ただ、K8sのTopology Aware Routingは各ZoneのNodeの総core数が Endpointの割り振りに影響する - そして、ZoneごとにNodeの総core数を均一にするの はどうしても難しい
62. 62 メルカリでの結論
63. 63 メルカリでの結論 　　　 　　　　　　「Deployment 1つじゃどうしようもなくね？」
64. 64 メルカリでの結論 アイデア: ZoneごとにHPA、Deploymentをセットアップする - 問題だったのは、特定のZoneのPodへ通信が集中しても、HPAが全ての Zoneの全てのPodをみているせいでScaleUpが起きない可能性があること - ZoneごとにDeploymentとHPAを設定することで、各Zone内のPodsごと にScaleUpが可能
65. 65 現実 (zone黄だけNodeが少ないとする) 各ZoneのPod毎にScalingが行われれば、 特定のZoneに通信が集まってもScaleされるはず
66. 66 追加のメリット Pod Topology Spread と Deschedulerのセットアップが全く必要ない - メルカリでは一つのマイクロサービスが複数のマイクロサービスから通信を受け る と言う場合も多い - 送る側のマイクロサービス全てにこれらをセットアップするのは実はしんどい
67. 67 検証
68. 68 検証内容 - Google Cloud metricsのpod_flow/egress_bytes_countを使用 - どのNamespaceからどのNamespaceへどのくらい の通信量があるかが見える
69. 69 検証内容 - Google Cloud metricsのpod_flow/egress_bytes_countを使用 - どのNamespaceからどのNamespaceへどのくらい の通信量があるかが見える - これを使用して通信量が多いサービス間通信を検証の ターゲットに
70. 70 検証内容 - Google Cloud metricsのpod_flow/egress_bytes_countを使用 - どのNamespaceからどのNamespaceへどのくらい の通信量があるかが見える - これを使用して通信量が多いサービス間通信を検証の ターゲットに - K8sのTopology Aware Routingを使用 - Istioの方は別途検証中
71. 71 グラフ: zone-cのPodが各Zoneから受けてい るTraffic量
72. 72 有効後、zone-cから受けるトラフィックの割合 が急増
73. 73 将来の展望
74. 74 マニフェスト管理 サービス開発者側でのZone Aware Routing有効化のためのオペレーションのコ ストをできるだけ減らしたい - HPA、Deploymentの複数作成/管理がめんどい - Zone毎にほぼ全く同じHPA、Deploymentの作成が 必要 - 必要な設定もわかりづらい - Istioの機能、K8sの機能どちらを使えばいいのか
75. 75 Kubernetes Kit メルカリにはKubernetes Kitと呼ばれる抽象化レイヤーがあり、 開発者はそれを通してKubernetesのマニフェストを管理している
76. 76 Kubernetes Kit
77. 77 Kubernetes Kit 裏で必要な設定 + 必要な数のHPA、 Deploymentの生成を行う
78. 78 Wanna know more about Kubernetes Kit?
79. 79 KEP-2433: PreferZone Heuristic PreferZone と言う新たな Heuristic がKEP-2433に追加で提案されている Zoneごとの総core数の割合を見て、EndpointのZoneへの割り当てをするので はなく、Zone-xのEndpointをZone-xへ常に割り当てる (シンプル!)
80. 80 v1.29で入る…?
81. 81 まとめ
82. 82 まとめ - Zone Aware Routing (Istio/K8s)はただ設定をいじるだけで有効になる が、単純に有効にするだけでは問題の種になり得る - Pod Topology Spread (w/ descheduler)を使うのは一つの手ではある が、K8sのZone Aware Routingを使う時はNodeの数に注意が必要 - また、サービスの数によっては、セットアップのめんどさ もある - Zone毎にDeploymentとHPAを作るのがシンプルでいいかも - ただ、マニフェスト管理等のめんどさもある - メルカリではKubernetes Kitを通して解決予定 (WIP)
83. 83 We are めっちゃ hiring!!! Platformで働く仲間をめっちゃ探しています！！！！ 今回話したこと以外にも、めっちゃ色んな面白いことやってます！！！ - istioとかのnetworkらへん - 内製しているCI/CD基盤開発 - 開発者向けの内製抽象化レイヤーの開発 - etc…. ! 「メルカリ Platform 採用」でいますぐ検索！