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

MercariにおけるKubernetesのリソース最適化のこれまでとこれから

sanposhiho
April 26, 2023

 MercariにおけるKubernetesのリソース最適化のこれまでとこれから

Kubernetes Meetup Tokyo #57
アーカイブもあります: https://www.youtube.com/watch?v=DczWeNL-4-A

sanposhiho

April 26, 2023
Tweet

More Decks by sanposhiho

Other Decks in Technology

Transcript

  1. 2 Mercari JP Platform Infra team / 2022卒新卒
 
 


    Kubernetes upstream reviewer (SIG-Scheduling)
 Kubernetes Contributor award 2022 winner
 Kensei Nakada / sanposhiho

  2. 3 Mercari Kubernetes Cluster Overview Agenda 01 Workloads on cluster

    + About FinOps a. Node Level Optimization 02 Cluster Autoscaling a. Node machine type b. Workload Optimization 03 Workload Autoscaling (HPA & VPA) / Resource recommender a. HPA fine tuning b. 🐢を使用したWorkload Autoscaling 04
  3. 6 Workload について - ほとんどがGoで実装されたWorkload - この登壇に含まれる調査結果等はGoのWorkloadと いうことを前提としてください - その他、ElasticSearch,

    php 等も居る - Istioを一部namespaceで使用 (全体の半分ほど) (拡大予定) - sidecarコンテナーがついているPodが割と存在する - ほとんどの大規模workloadがHPAを使用 (全体の半分ほど) (拡大予定)
  4. 7 FinOps! - 直近メルカリでは全社的な目標としてFinOpsを掲げている - Monolith -> Microserviceのマイグレーションを経 て、アーキテクチャを洗練していくフェーズ -

    Platformチームでもインフラリソースの効率化を推進 - 殆どのサービスが乗っているのでインパクトが超絶大き い - あくまでも安全性を担保しつつ、リソースの効率化を行う
  5. 9

  6. 11 Probably, we want to change the placement for cost

    reduction. 新しいPodが来た時には
  7. 12 But… what if new Pods come after reducing Nodes?

    もう一度Nodeを増やした い
  8. 14 Trade-off: Cost 💴 vs Reliability🛡 Nodeの空きを常に余裕を持っておくことで -> 👍 🛡

    Nodeの障害やリソースの需要の急増に強くなる -> 👎 💸 常に余分にお金がかかる
  9. 15 GKE Autoscaling profiles GKE では Autoscaling profile を通して optimize-utilization

    💴 or balanced🛡 を選択できる: - Cluster Autoscaler がどのようにNodeを削除していくか - Aggressive 💴 vs Conservative🛡 - SchedulerがどのようにPodをスケジュールするか - MostAllocated(Bin packing) 💴 or LeastAllocated🛡
  10. 16 GKE Autoscaling profiles Mercariではoptimize-utilization 💴を選択 - Cluster Autoscaler がどのようにNodeを削除していくか

    - Aggressive 💴 vs Conservative🛡 - SchedulerがどのようにPodをスケジュールするか - MostAllocated(Bin packing) 💴 or LeastAllocated🛡
  11. 17 overprovisioning Pods Nodeに空きが無くなりすぎるのを防ぐoverprovisioning Podsを採用 - overprovisioning Pods = 低いPriorityのPod

    - 他のPodがunschedulableになるとoverprovisioning Podsが Preemptされ、リソースに空きを生んでくれる - Cluster AutoscalerはUnschedulableになった overprovisioning Podsに気がついてNodeを増や す
  12. 18 overprovisioning Pods Overprovisioning Podsが多すぎると、bin Packingの意味が無い → Overprovisioning Podsの数をNodeの全体数に対して自動で調整 (sigs/cluster-proportional-autoscaler)

    将来的にはもう少し賢く調整したい (先週のNode数の変化から需要の変化の予測とかできそう、等のアイデアはある)
  13. 21 Tau T2D migration いくつかの大きなWorkloadのmachine typeをE2からT2Dに変更 - T2Dのinstance単位の単価はE2よりも高い - しかし、パフォーマンスが高く、多くのWorkloadでCPU使用量の減少を確認

    - プログラミング言語等の様々な要素によってCPU使用量の減少率が違う - Goの場合、大体 ~50%の減少 - HPAが正しく動作している場合、CPU使用量の減少はそのままPod数の減少に つながる → 総合的に見てコスパ 👍👍👍 (migration後のnodepoolではコスト3割削減)
  14. 23

  15. 29 HPA for multi-containers Pods type: Resource は個々のcontainerのresource utilizationではなく、Pod全体 でのresource

    utilizationを使用する → 複数のcontainerがPod内に存在する場合、正確にScalingできない場合があ る
  16. 36

  17. 44 Multidimensional Pod autoscaling Multidimensional Pod autoscalingという HPAをCPUにVPAをMemoryに使用するAutoscalerがGKEに存在 Mercariでもいくつかのサービスで検証を行い、 今後はこの方針に舵を切りつつある

    (MPAを直接使用するのではなく、HPA(CPU) + VPA(mem)を設定する) 将来的にRecommenderはautoscalerが設定されていないサービス向けになる
  18. 47 Incident時のHPAのScale in問題 - UpstreamのサービスがIncidentで落ちる - Downstreamのサービスに通信が行かなくなる - DownstreamのサービスのCPU使用量が下がる この場合にDownstreamのサービスではHPAによるScale

    inが発生する ↓ Upstreamのサービスが復活した時に、一気にトラフィックが流れて Downstreamのサービスが死ぬというインシデントが稀に発生
  19. 55 Multiple containers Pod with HPAめんどくさい問題 例: HPAのtarget utilization: sidecar:

    80%/app container: 80% この場合、HPAはどちらかのcontainerのresource utilizationが88%を超え た時にスケールアウトを行う。 ↓ これによって、sidecar or app のどちらかのリソースが常に余っているということに なり得る。
  20. 62 HPAのtarget utilization決めるの難しすぎ問題 0. ピークタイムが近づくにつれて、リソース使用量が増えていく 1. リソース使用率が閾値に達する 2. HPAが気がついてスケールアウトを実行する 3.

    (Cluster AutoscalerがNodeを増やす) 4. 新しいPodが実際に動き出し、READYになる (1) → (4)にかかる時間の間もリソース使用量が増えているため、 この間の時間稼ぎの必要性
  21. 63 HPAのtarget utilization決めるの難しすぎ問題 - Containerごとのリソース使用率のばらつき - トラフィックの増加のスピード - HPA controllerのリコンサイルの間隔

    - (Nodeに空きができるまでの時間 (via CA or overprovisioning Pods)) - Podが動き出すまでにかかる時間 これらを踏まえて、適切な「余分リソース」をtarget utilizationを通してPodに与え る必要がある
  22. 64 HPAのtarget utilization決めるの難しすぎ問題 - Containerごとのリソース使用率のばらつき - トラフィックの増加のスピード - HPA controllerのリコンサイルの間隔

    - (Nodeに空きができるまでの時間 (via CA or overprovisioning Pods)) - Podが動き出すまでにかかる時間 これらを踏まえて、適切な「余分リソース」をtarget utilizationを通してPodに与え る必要がある 無理じゃね…?
  23. 65 ここまでの話 - Incident時のHPAのScale in問題 - HPAがレプリカ増やしすぎる問題 - HPAがレプリカ全然増やさない問題 -

    Multiple containers Pod with HPAめんどくさい問題 - HPAのtarget utilization決めるの難しすぎ問題
  24. 66 ここまでの話 - Incident時のHPAのScale in問題 - HPAがレプリカ増やしすぎる問題 - HPAがレプリカ全然増やさない問題 -

    Multiple containers Pod with HPAめんどくさい問題 - HPAのtarget utilization決めるの難しすぎ問題 無理じゃね…?
  25. 72 Simplified configuration apiVersion: autoscaling.mercari.com/v1alpha1 kind: Tortoise metadata: name: nginx-tortoise

    namespace: tortoise-poc spec: updateMode: Auto targetRefs: deploymentName: nginx-deployment Deployment name ONLY!
  26. 73 Simplified configuration - ユーザーは対象のdeploymentの指定のみを行う。 - Optional なフィールドはその他少し存在するが基本使用不要 - HPA,

    VPA, resource req/limの全ては🐢がいい感じに設定する - 「コーナーケースのために柔軟な設定を与える」ことはしない - 一つのTortoiseを設定する => HPA, VPAを全てのcontainerの全てのリ ソースに常に最適化された状態で設定が完了
  27. 74 mercari/tortoiseの機能 - HPA optimization - 前章で「無理じゃね…?」と言ってたやつを全部自動で行 う - VPA

    optimization - HPAとVPAがうまいこと同時に動けるように調整 - Emergency mode
  28. 75 Horizontal Scaling 過去の振る舞いを元にHPAを調整し続ける - minReplicas: ½ * {過去数週間の同 時刻の最大レプリカ数}

    - maxReplicas: 2 * {過去数週間の同 時刻の最大レプリカ数} - HPA target utilization: 推奨の値を 計算し、設定 (計算ロジックは複雑なので説明割愛)
  29. 76 Horizontal Scaling 過去の振る舞いからコンテナサイズも調整: - ほぼ常にレプリカ数が3で、リソース使用率 が小さい時、一時的にVerticalに切り替え る - 現在のコンテナサイズが小さく、かつピーク

    時にレプリカ数が多すぎる傾向にあると、コ ンテナサイズを大きくする - 片方のコンテナのリソース使用率が常に小 さい時、そのコンテナサイズを小さくする
  30. 79 Emergency mode apiVersion: autoscaling.mercari.com/v1alpha1 kind: Tortoise metadata: name: nginx-tortoise

    namespace: tortoise-poc spec: updateMode: Emergency targetRefs: deploymentName: nginx-deployment ←