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

Slide 1

Slide 1 text

1 Conﬁdential MercariにおけるKubernetesのリソース最適化のこれまでとこれから Kensei Nakada / @sanposhiho

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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 ﬁne tuning b. 🐢を使用したWorkload Autoscaling 04

Slide 4

Slide 4 text

4 Kubernetes Cluster Overview Workloads on cluster + FinOps

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

8 Node Level Optimization Cluster Autoscaling

Slide 9

Slide 9 text

Slide 10

Slide 10 text

10 余分なNodeを減らしたい

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

19 Node Level Optimization Node instance type

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

26 レプリカ数を増やす

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

33 DatadogMetricの設定

Slide 34

Slide 34 text

34 External metricsとしてHPAから参照

Slide 35

Slide 35 text

35 For more detail ↓

Slide 36

Slide 36 text

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

45 Workload Level Optimization HPA ﬁne tuning

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

47 Incident時のHPAのScale in問題 - UpstreamのサービスがIncidentで落ちる - Downstreamのサービスに通信が行かなくなる - DownstreamのサービスのCPU使用量が下がるこの場合にDownstreamのサービスではHPAによるScale inが発生する ↓ Upstreamのサービスが復活した時に、一気にトラフィックが流れて Downstreamのサービスが死ぬというインシデントが稀に発生

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

49 dynamic minimum replica num 1週間前の同じ時間のレプリカ数の1/2のレプリカ数をsuggestする DatadogMetricsを全てのHPAに導入 ↓ HPAは複数の指標のレプリカ数の提案から一番大きいものを採用するため、 Incidentの時など通常に比べて異常にレプリカ数が減少している時にのみ動作する

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

67 🐢を使用したWorkload Autoscaling

Slide 68

Slide 68 text

68 🤔

Slide 69

Slide 69 text

69 mercari/tortoise

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

71 mercari/tortoiseのモチベ - 人間の手で先ほどの最適化を全て行うのは厳しい - 最適化後もアプリケーションの変化に伴い、定期的な見直しが必要 - Platform推奨の設定や新しい機能適応への移行のコスト - 現状、PRを全てのHPAに送りつけたりしている。めんどい - Datadog metricを含む外部サービスにautoscalingを依存させたくない - 外部サービスの障害の間、HPAが正しく動かず眠れぬ夜を過ごすことになる

Slide 72

Slide 72 text

72 Simpliﬁed conﬁguration apiVersion: autoscaling.mercari.com/v1alpha1 kind: Tortoise metadata: name: nginx-tortoise namespace: tortoise-poc spec: updateMode: Auto targetRefs: deploymentName: nginx-deployment Deployment name ONLY!

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

74 mercari/tortoiseの機能 - HPA optimization - 前章で「無理じゃね…?」と言ってたやつを全部自動で行う - VPA optimization - HPAとVPAがうまいこと同時に動けるように調整 - Emergency mode

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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