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

Don't try to tame your autoscalers, tame Tortoises!

sanposhiho
December 13, 2023
520

Don't try to tame your autoscalers, tame Tortoises!

sanposhiho

December 13, 2023
Tweet

More Decks by sanposhiho

Transcript

  1. 2 Mercari JP Platform team / 2022卒新卒 Kubernetes approver (SIG-Scheduling)

    Kubernetes Contributor award 2022/2023 winner Kensei Nakada / sanposhiho
  2. 15 1) Incident時のHPAのScale in問題 - UpstreamのサービスがIncidentで落ちる - Downstreamのサービスに通信が行かなくなる - DownstreamのサービスのCPU使用量が下がる

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

    sidecar: 80%/app container: 80% この場合、HPAはどちらかのcontainerのresource utilizationが80%を 大きく超えた時にスケールアウトを行う。 ↓ これによって、sidecar or app のどちらかのリソースが常に余っているということに なり得る。
  4. 25 4) Multiple containers Pod with HPAめんどくさい問題 80% 80% App

    Sidecar リソース使用量が増えて いく 50%
  5. 26 4) Multiple containers Pod with HPAめんどくさい問題 80% 80% App

    Sidecar SidecarのUtilizationが 80%に達したので、HPA はPodの数を増やす 50%
  6. 27 4) Multiple containers Pod with HPAめんどくさい問題 80% 80% App

    Sidecar 50% Appは30%のリソース余 している…
  7. 29 4) Multiple containers Pod with HPAめんどくさい問題 80% 80% App

    Sidecar 80% Appのresource request を下げる 同時に80%に達するの が一番リソースの無駄 がない
  8. 32 5) HPAのtarget utilization決めるの難しすぎ問題 HPAのtarget utilizationによって与えられる、「余分なリソース」は - Containerごとのリソース使用量のばらつき - スケールアウトの時間稼ぎ

    の対応のため リソース使用率の平均値が80%だとしても、いくつかのPodではcontainerの使用 率は100%を超えている可能性もある
  9. 34 5) HPAのtarget utilization決めるの難しすぎ問題 0. トラフィックが増えるにつれて、リソース使用量が増えていく 1. リソース使用率が閾値に達する 2. HPAが気がついてスケールアウトを実行する

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

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

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

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

    Multiple containers Pod with HPAめんどくさい問題 5. HPAのtarget utilization決めるの難しすぎ問題 無理じゃね…?
  14. 43 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!
  15. 45 Horizontal Scaling 過去の振る舞いを元にHPAを調整し続ける - minReplicas: ½ * {過去数週間の同 時刻の最大レプリカ数}

    - maxReplicas: 2 * {過去数週間の同時 刻の最大レプリカ数} - HPA target utilization: 推奨の値を計 算し、設定
  16. 46 Horizontal Scaling 過去の振る舞いを元にHPAを調整し続ける - minReplicas: ½ * {過去数週間の同 時刻の最大レプリカ数}

    - maxReplicas: 2 * {過去数週間の同時 刻の最大レプリカ数} - HPA target utilization: 推奨の値を計 算し、設定 前述のdynamic minReplicasと 同様の振る舞い
  17. 48 Horizontal Scaling 過去の振る舞いを元にHPAを調整し続ける - minReplicas: ½ * {過去数週間の同 時刻の最大レプリカ数}

    - maxReplicas: 2 * {過去数週間の同 時刻の最大レプリカ数} - HPA target utilization: 推奨の値を計 算し、設定 Bug等の想定外ケースの際に、 無制限にscale upするのを防ぐ
  18. 49 Horizontal Scaling 過去の振る舞いを元にHPAを調整し続ける - minReplicas: ½ * {過去数週間の同 時刻の最大レプリカ数}

    - maxReplicas: 2 * {過去数週間の同時 刻の最大レプリカ数} - HPA target utilization: 推奨の値を 計算し、設定 How?
  19. 56 Tortoise のresource utilization計算の仕組み 80% 80% App Sidecar 50% 実際にはPodごとに利

    用率のばらつきがある + Scale upが完了するま でラグがある
  20. 60 Tortoise のresource utilization計算の仕組み 80% 90%-80% = 10% App Sidecar

    10%が必要な余分リソース → target utilization: 90%がベスト 50%
  21. 61 Horizontal Scaling 過去の振る舞いからコンテナサイズも調整: - ほぼ常にレプリカ数が3で、リソース使用率 が小さい時、一時的にVerticalに切り替 え、HPAが動作するようにする - 現在のコンテナサイズが小さく、かつピーク

    時にレプリカ数が多すぎる傾向にあると、コ ンテナサイズを大きくする - 片方のコンテナのリソース使用率が常に小 さい時、そのコンテナサイズを小さくする
  22. 62 Horizontal Scaling 過去の振る舞いからコンテナサイズも調整: - ほぼ常にレプリカ数が3で、リソース使用率 が小さい時、一時的にVerticalに切り替 え、HPAが動作するようにする - 現在のコンテナサイズが小さく、かつピーク

    時にレプリカ数が多すぎる傾向にあると、コ ンテナサイズを大きくする - 片方のコンテナのリソース使用率が常に小 さい時、そのコンテナサイズを小さくする
  23. 64 Horizontal Scaling 過去の振る舞いからコンテナサイズも調整: - ほぼ常にレプリカ数が3で、リソース使用率 が小さい時、一時的にVerticalに切り替 え、HPAが動作するようにする - 現在のコンテナサイズが小さく、かつピーク

    時にレプリカ数が多すぎる傾向にあると、コ ンテナサイズを大きくする - 片方のコンテナのリソース使用率が常に小 さい時、そのコンテナサイズを小さくする
  24. 66 Horizontal Scaling 過去の振る舞いからコンテナサイズも調整: - ほぼ常にレプリカ数が3で、リソース使用率 が小さい時、一時的にVerticalに切り替 え、HPAが動作するようにする - 現在のコンテナサイズが小さく、かつピーク

    時にレプリカ数が多すぎる傾向にあると、コ ンテナサイズを大きくする - 片方のコンテナのリソース使用率が常に小 さい時、そのコンテナサイズを小さくする
  25. 67 [復習] Multiple containers Pod with HPAめんどくさい問題 例: HPAのtarget utilization:

    sidecar: 80%/app container: 80% この場合、HPAはどちらかのcontainerのresource utilizationが80%を大きく超 えた時にスケールアウトを行う。 ↓ これによって、sidecar or app のどちらかのリソースが常に余っているということに なり得る。
  26. 68 [復習] Multiple containers Pod with HPAめんどくさい問題 80% 80% App

    Sidecar 50% Appは30%のリソース余 している…
  27. 69 [復習] Multiple containers Pod with HPAめんどくさい問題 80% 80% App

    Sidecar 80% Appのresource request を下げる 同時に80%に達するの が一番リソースの無駄 がない
  28. 71 Emergency mode apiVersion: autoscaling.mercari.com/v1alpha1 kind: Tortoise metadata: name: nginx-tortoise

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