$30 off During Our Annual Pro Sale. View Details »

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. 1
    Confidential
    MercariにおけるKubernetesのリソース最適化
    のこれまでとこれから
    Kensei Nakada / @sanposhiho

    View Slide

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



    Kubernetes upstream reviewer (SIG-Scheduling)

    Kubernetes Contributor award 2022 winner

    Kensei Nakada / sanposhiho


    View Slide

  3. 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

    View Slide

  4. 4
    Kubernetes Cluster Overview
    Workloads on cluster + FinOps

    View Slide

  5. 5
    Kubernetesクラスター概要
    - GKEを使用 (Standard mode)
    - 一つのClusterで、Mercari/Merpayほぼ全てのWorkloadが動いている
    - namespace: 500+ / deployment 1000+
    - PlatformチームがCluster adminとして運用

    View Slide

  6. 6
    Workload について
    - ほとんどがGoで実装されたWorkload
    - この登壇に含まれる調査結果等はGoのWorkloadと
    いうことを前提としてください
    - その他、ElasticSearch, php 等も居る
    - Istioを一部namespaceで使用 (全体の半分ほど) (拡大予定)
    - sidecarコンテナーがついているPodが割と存在する
    - ほとんどの大規模workloadがHPAを使用 (全体の半分ほど) (拡大予定)

    View Slide

  7. 7
    FinOps!
    - 直近メルカリでは全社的な目標としてFinOpsを掲げている
    - Monolith -> Microserviceのマイグレーションを経
    て、アーキテクチャを洗練していくフェーズ
    - Platformチームでもインフラリソースの効率化を推進
    - 殆どのサービスが乗っているのでインパクトが超絶大き

    - あくまでも安全性を担保しつつ、リソースの効率化を行う

    View Slide

  8. 8
    Node Level Optimization
    Cluster Autoscaling

    View Slide

  9. 9

    View Slide

  10. 10
    余分なNodeを減らしたい

    View Slide

  11. 11
    Probably, we want to
    change the placement for
    cost reduction.
    新しいPodが来た時には

    View Slide

  12. 12
    But… what if new Pods
    come after reducing
    Nodes?
    もう一度Nodeを増やした

    View Slide

  13. 13
    Automated way: Cluster Autoscaler
    Cluster Autoscalerがいい感じに:
    - リソースがスカスカだったら、Podを詰めてNodeを減らす
    - Unschedulable Podsが居たら、Nodeを増やす
    をやってくれる

    View Slide

  14. 14
    Trade-off: Cost 💴 vs Reliability🛡
    Nodeの空きを常に余裕を持っておくことで
    -> 👍 🛡 Nodeの障害やリソースの需要の急増に強くなる
    -> 👎 💸 常に余分にお金がかかる

    View Slide

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

    View Slide

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

    View Slide

  17. 17
    overprovisioning Pods
    Nodeに空きが無くなりすぎるのを防ぐoverprovisioning Podsを採用
    - overprovisioning Pods = 低いPriorityのPod
    - 他のPodがunschedulableになるとoverprovisioning Podsが
    Preemptされ、リソースに空きを生んでくれる
    - Cluster AutoscalerはUnschedulableになった
    overprovisioning Podsに気がついてNodeを増や

    View Slide

  18. 18
    overprovisioning Pods
    Overprovisioning Podsが多すぎると、bin Packingの意味が無い
    → Overprovisioning Podsの数をNodeの全体数に対して自動で調整
    (sigs/cluster-proportional-autoscaler)
    将来的にはもう少し賢く調整したい
    (先週のNode数の変化から需要の変化の予測とかできそう、等のアイデアはある)

    View Slide

  19. 19
    Node Level Optimization
    Node instance type

    View Slide

  20. 20
    Node machine type
    現状MercariではE2 machine typeを広く使用している。
    → コスパがいいと評判の、新たに追加されたTau T2Dの検討

    View Slide

  21. 21
    Tau T2D migration
    いくつかの大きなWorkloadのmachine typeをE2からT2Dに変更
    - T2Dのinstance単位の単価はE2よりも高い
    - しかし、パフォーマンスが高く、多くのWorkloadでCPU使用量の減少を確認
    - プログラミング言語等の様々な要素によってCPU使用量の減少率が違う
    - Goの場合、大体 ~50%の減少
    - HPAが正しく動作している場合、CPU使用量の減少はそのままPod数の減少に
    つながる
    → 総合的に見てコスパ 👍👍👍 (migration後のnodepoolではコスト3割削減)

    View Slide

  22. 22
    Workload Level Optimization
    Workload Autoscaling (HPA & VPA) / Resource recommender

    View Slide

  23. 23

    View Slide

  24. 24
    レプリカ数を減らして
    utilizationを上げる

    View Slide

  25. 25
    Traffic が増えるにつれ
    て、utilizationが大きくなる

    View Slide

  26. 26
    レプリカ数を増やす

    View Slide

  27. 27
    HorizontalPodAutoscaler: resource utilizationをベースに
    いい感じにScalingしてくれる
    Automated way: HorizontalPodAutoscaler
    CPU utilizationが常に
    54 - 66%になるように調
    整してくれる

    View Slide

  28. 28
    HPA for multi-containers Pods
    type: Resource は個々のcontainerのresource utilizationではなく、Pod
    全体でのresource utilizationを使用する

    View Slide

  29. 29
    HPA for multi-containers Pods
    type: Resource は個々のcontainerのresource utilizationではなく、Pod全体
    でのresource utilizationを使用する
    → 複数のcontainerがPod内に存在する場合、正確にScalingできない場合があ

    View Slide

  30. 30
    The container based HPA
    type: ContainerResourceの使用を
    検討

    View Slide

  31. 31
    The beta graduation is done in v1.27
    UpstreamでのBeta graduationを推進 (GKEではalpha機能が使えないため)

    View Slide

  32. 32
    Then, what’s alternative for now?
    現状DatadogMetric(external metrics)を使用して、type:
    ContainerResourceを実現している
    DatadogMetric: Datadogのqueryの結果をHPAのexternal metricsから
    参照できる

    View Slide

  33. 33
    DatadogMetricの設定

    View Slide

  34. 34
    External metricsとしてHPAから参照

    View Slide

  35. 35
    For more detail ↓

    View Slide

  36. 36

    View Slide

  37. 37
    各Podのsizeを小さくしたい

    View Slide

  38. 38
    使用量が上がってきたら …

    View Slide

  39. 39
    それに応じてもう一度大きく
    したい

    View Slide

  40. 40
    リソースの使用量を常に確認し、良さげなresource request/limitの推奨値を計
    算して、設定してくれる。
    memoryの場合OOM Killも考慮に入れられる
    Automated way: VerticalPodAutoscaler

    View Slide

  41. 41
    Resource Recommender
    Resource Recommenderと呼ばれるSlack botが動作している
    ユーザーは月に一度リソースの推奨のresource requestの値を受け取る
    Hoge deployment
    appcontainer
    XXX
    XXX

    View Slide

  42. 42
    Resource Recommender
    Resource Recommenderは過去1ヶ月のVPAの推奨値の最大値を取得し、
    「プラットフォーム推奨のresource request」としてユーザーに送っている

    View Slide

  43. 43
    Resource Recommender
    HPAが設定されているPodのresourceにはRecommendationを適応してはい
    けないため、送らない等の工夫
    XXX
    XXX
    Fuga Deployment   
    appcontainer  

    View Slide

  44. 44
    Multidimensional Pod autoscaling
    Multidimensional Pod autoscalingという
    HPAをCPUにVPAをMemoryに使用するAutoscalerがGKEに存在
    Mercariでもいくつかのサービスで検証を行い、
    今後はこの方針に舵を切りつつある
    (MPAを直接使用するのではなく、HPA(CPU) + VPA(mem)を設定する)
    将来的にRecommenderはautoscalerが設定されていないサービス向けになる

    View Slide

  45. 45
    Workload Level Optimization
    HPA fine tuning

    View Slide

  46. 46
    Incident時のHPAのScale in問題
    - UpstreamのサービスがIncidentで落ちる
    - Downstreamのサービスに通信が行かなくなる
    - DownstreamのサービスのCPU使用量が下がる
    この場合にDownstreamのサービスではHPAによるScale inが発生する

    View Slide

  47. 47
    Incident時のHPAのScale in問題
    - UpstreamのサービスがIncidentで落ちる
    - Downstreamのサービスに通信が行かなくなる
    - DownstreamのサービスのCPU使用量が下がる
    この場合にDownstreamのサービスではHPAによるScale inが発生する

    Upstreamのサービスが復活した時に、一気にトラフィックが流れて
    Downstreamのサービスが死ぬというインシデントが稀に発生

    View Slide

  48. 48
    Setting higher minReplicas?
    minReplicasを高めに設定しておけば、
    解決になるがHPAの機能性を損なうので❌
    例: Pods数が通常のオフピーク時に3個/ピーク時に20個、targetUtilizationが70%の場合、ピー
    ク時に障害という最悪のケースを考慮すると、minReplicasを14に設定する必要がある

    View Slide

  49. 49
    dynamic minimum replica num
    1週間前の同じ時間のレプリカ数の1/2のレプリカ数をsuggestする
    DatadogMetricsを全てのHPAに導入

    HPAは複数の指標のレプリカ数の提案から一番大きいものを採用するため、
    Incidentの時など通常に比べて異常にレプリカ数が減少している時にのみ動作す

    View Slide

  50. 50
    dynamic minimum replica num
    このDatadogMetricsで高めに設定されていたMinReplicasを安全に下げること
    にも繋がった (一律で3に変更)

    View Slide

  51. 51
    HPAがレプリカ増やしすぎる問題
    Deploymentのresource requestが小さすぎると、ピーク時のレプリカ数がとて
    も多くなる。

    View Slide

  52. 52
    HPAがレプリカ増やしすぎる問題
    Deploymentのresource requestが小さすぎると、ピーク時のレプリカ数がとて
    も多くなる。
    この際、Podのサイズを大きくし、レプリカ数を小さく抑えた方が、省エネになる場合
    がある。
    とあるサービスでは、この最適化を行うことで、GKEコストが40%減少
    (ピーク時のレプリカ数が200->30に変化)

    View Slide

  53. 53
    HPAがレプリカ全然増やさない問題
    Deploymentのresource requestが大きすぎると、HPAを設定していても
    「レプリカ数がずっとminReplicasで制限されてる」みたいなケースが起こりうる
    この場合、HPAが機能していないに等しいためCPU使用率も低くなる

    View Slide

  54. 54
    HPAがレプリカ全然増やさない問題
    この場合、
    - Podのサイズを十分に小さくしてHPAが動作するようにする
    - VPAにCPUも任せる
    等を考える必要がある

    View Slide

  55. 55
    Multiple containers Pod with HPAめんどくさい問題
    例: HPAのtarget utilization: sidecar: 80%/app container: 80%
    この場合、HPAはどちらかのcontainerのresource utilizationが88%を超え
    た時にスケールアウトを行う。

    これによって、sidecar or app のどちらかのリソースが常に余っているということに
    なり得る。

    View Slide

  56. 56
    Multiple containers Pod with HPAめんどくさい問題
    HPAを設定していても、CPU 使用量を確認しつつ、片方のcontainerの使用量が
    常に低い場合、contianerのsizeを調整する必要がある。

    View Slide

  57. 57
    HPAのtarget utilization決めるの難しすぎ問題
    メルカリでは、HPAのtarget utilizationは70%-80%に設定されていることが多
    い。

    View Slide

  58. 58
    HPAのtarget utilization決めるの難しすぎ問題
    メルカリでは、HPAのtarget utilizationは70%-80%に設定されていることが多
    い。
    なぜ20%-30%の余分なCPUを与えておく必要があるのか?

    View Slide

  59. 59
    HPAのtarget utilization決めるの難しすぎ問題
    HPAのtarget utilizationによって与えられる、「余分なリソース」は
    - Containerごとのリソース使用量のばらつき
    - スケールアウトの時間稼ぎ
    の対応のため

    View Slide

  60. 60
    HPAのtarget utilization決めるの難しすぎ問題
    HPAのtarget utilizationによって与えられる、「余分なリソース」は
    - Containerごとのリソース使用量のばらつき
    - スケールアウトの時間稼ぎ
    の対応のため
    リソース使用率の平均値が80%だとしても、いくつかのcontainerの使用率は
    100%を超えている可能性もある

    View Slide

  61. 61
    HPAのtarget utilization決めるの難しすぎ問題
    HPAのtarget utilizationによって与えられる、「余分なリソース」は
    - Containerごとのリソース使用量のばらつき
    - スケールアウトの時間稼ぎ
    の対応のため
    → (次スライド)

    View Slide

  62. 62
    HPAのtarget utilization決めるの難しすぎ問題
    0. ピークタイムが近づくにつれて、リソース使用量が増えていく
    1. リソース使用率が閾値に達する
    2. HPAが気がついてスケールアウトを実行する
    3. (Cluster AutoscalerがNodeを増やす)
    4. 新しいPodが実際に動き出し、READYになる
    (1) → (4)にかかる時間の間もリソース使用量が増えているため、
    この間の時間稼ぎの必要性

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  67. 67
    🐢を使用したWorkload Autoscaling

    View Slide

  68. 68
    🤔

    View Slide

  69. 69
    mercari/tortoise

    View Slide

  70. 70
    これからはリクガメに任せる時代です。
    過去のWorkloadの振る舞いを記
    録し、HPA, VPA, Pod resource
    request/limitの全てをいい感じ
    に調節してくれる
    Kubernetes controller
    https://github.com/mercari/
    tortoise

    View Slide

  71. 71
    mercari/tortoiseのモチベ
    - 人間の手で先ほどの最適化を全て行うのは厳しい
    - 最適化後もアプリケーションの変化に伴い、定期的な見直しが必要
    - Platform推奨の設定や新しい機能適応への移行のコスト
    - 現状、PRを全てのHPAに送りつけたりしている。めんど

    - Datadog metricを含む外部サービスにautoscalingを依存させたくない
    - 外部サービスの障害の間、HPAが正しく動かず眠れぬ夜
    を過ごすことになる

    View Slide

  72. 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!

    View Slide

  73. 73
    Simplified configuration
    - ユーザーは対象のdeploymentの指定のみを行う。
    - Optional なフィールドはその他少し存在するが基本使用不要
    - HPA, VPA, resource req/limの全ては🐢がいい感じに設定する
    - 「コーナーケースのために柔軟な設定を与える」ことはしない
    - 一つのTortoiseを設定する => HPA, VPAを全てのcontainerの全てのリ
    ソースに常に最適化された状態で設定が完了

    View Slide

  74. 74
    mercari/tortoiseの機能
    - HPA optimization
    - 前章で「無理じゃね…?」と言ってたやつを全部自動で行

    - VPA optimization
    - HPAとVPAがうまいこと同時に動けるように調整
    - Emergency mode

    View Slide

  75. 75
    Horizontal Scaling
    過去の振る舞いを元にHPAを調整し続ける
    - minReplicas: ½ * {過去数週間の同
    時刻の最大レプリカ数}
    - maxReplicas: 2 * {過去数週間の同
    時刻の最大レプリカ数}
    - HPA target utilization: 推奨の値を
    計算し、設定 (計算ロジックは複雑なので説明割愛)

    View Slide

  76. 76
    Horizontal Scaling
    過去の振る舞いからコンテナサイズも調整:
    - ほぼ常にレプリカ数が3で、リソース使用率
    が小さい時、一時的にVerticalに切り替え

    - 現在のコンテナサイズが小さく、かつピーク
    時にレプリカ数が多すぎる傾向にあると、コ
    ンテナサイズを大きくする
    - 片方のコンテナのリソース使用率が常に小
    さい時、そのコンテナサイズを小さくする

    View Slide

  77. 77
    Emergency mode
    緊急時に一時的にレプリカ数を十分に
    大きく変更してくれる
    - minReplicasをmaxReplicas
    と同じ値に一時的に変更
    - OFFにした際に、安全のため適切
    にゆっくりスケールダウンを行う

    View Slide

  78. 78
    Emergency mode
    緊急で十分にスケールアウトしたい時に使用する
    - 通常にはないようなトラフィックの増加を観測している場合 (テレビ, bot等)
    - インフラサイドのincidentが発生し、念の為あげておきたい場合 (datadog,
    GCP等)

    View Slide

  79. 79
    Emergency mode
    apiVersion: autoscaling.mercari.com/v1alpha1
    kind: Tortoise
    metadata:
    name: nginx-tortoise
    namespace: tortoise-poc
    spec:
    updateMode: Emergency
    targetRefs:
    deploymentName: nginx-deployment

    View Slide

  80. 80
    mercari/tortoiseの現状
    - Platformで開発しており、検証段階
    - 実際に本番で使用はしていない

    View Slide

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

    View Slide