Upgrade to Pro — share decks privately, control downloads, hide ads and more …

メルカリにおけるZone aware routing

sanposhiho
October 19, 2023
350

メルカリにおけるZone aware routing

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

sanposhiho

October 19, 2023
Tweet

More Decks by sanposhiho

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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


    View full-size slide

  12. 13
    MercariにおけるK8s Cluster

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  18. 19
    Zone aware routing

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  21. 22
    Istio: Locality Load Balancing

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. 31
    Zone aware routing

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  48. 49
    現状の整理

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  52. 53
    メルカリのNode達
    いくつかのサービスは特定のZoneで動作する必要がある。

    そのサービス向けに特化したNodePoolを用意しており、
    そのNodePoolはそのサービスのPodしか動作しないようになっている
    (Taints)

    View full-size slide

  53. 54
    メルカリのNode達
    いくつかのサービスは特定のZoneで動作する必要がある。

    そのサービス向けに特化したNodePoolを用意しており、
    そのNodePoolはそのサービスのPodしか動作しないようになっている
    (Taints)

    Nodeの数がZoneごとに偏りがある

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    - ただ、K8sのTopology Aware Routingは各ZoneのNodeの総core数が
    Endpointの割り振りに影響する
    - そして、ZoneごとにNodeの総core数を均一にするの
    はどうしても難しい

    View full-size slide

  61. 62
    メルカリでの結論

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  71. 73
    将来の展望

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  74. 76
    Kubernetes Kit

    View full-size slide

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

    View full-size slide

  76. 78
    Wanna know more about Kubernetes Kit?

    View full-size slide

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

    View full-size slide

  78. 80
    v1.29で入る…?

    View full-size slide

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

    View full-size slide

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

    View full-size slide