メルカリにおけるプラットフォーム主導のKubernetesリソース最適化とそこに生まれた🐢の可能性

https://event.cloudnativedays.jp/cndf2023/talks/1846

Transcript

1. 1
   Confidential
   メルカリにおけるプラットフォーム主導の
   Kubernetesリソース最適化と
   そこに生まれた🐢の可能性
   Kensei Nakada / @sanposhiho
   

   View Slide

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

   View Slide

3. 3
   台風6号により沖縄から脱出できませんでした…
   運営の皆様ご迷惑おかけしました‥
   

   View Slide

4. 4
   Mercari Kubernetes Cluster Overview
   Agenda
   01
   Workloads on cluster + About FinOps
   a.
   Node Level Optimization
   02
   Cluster Autoscaling
   a.
   Node machine type
   b.
   Utilize Spot VM instances
   c.
   

   View Slide

5. 5
   Agenda
   Workload Optimization
   03
   VPA / Resource recommender
   a.
   HPA fine tuning
   b.
   🐢を使用したWorkload Autoscaling
   04
   

   View Slide

6. 6
   Kubernetes Cluster Overview
   Workloads on cluster + FinOps
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

10. 10
    このセッションについて
    メルカリではその他GCPリソースに対するFinOps、Datadogに関するFinOps等
    様々行っていますが、
    このセッションではあくまでKubernetes周辺のものだけを取り上げます
    

    View Slide

11. 11
    Node Level Optimization
    Cluster Autoscaling
    

    View Slide

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

    View Slide

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

    View Slide

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

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

    View Slide

16. 16
    Node Level Optimization
    Node instance type
    

    View Slide

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

    View Slide

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

    View Slide

19. View Slide

20. 20
    Node Level Optimization
    Utilize Spot instances (検証段階)
    

    View Slide

21. 21
    Spot VM instances (検証段階)
    Spot VMはかなりの低価格で使用可能なインスタンス (60-91% cost down!)
    ただし...
    1. GKE側の都合で急に停止される可能性がある
    2. いつでも利用可能か保証されていない
    

    View Slide

22. 22
    Spot VM instances (検証段階)
    1. GKE側の都合で急に停止される可能性がある
    　　 → 一旦以下のようなPodのみを対象に利用の拡大を計画
    - 15s以内にシャットダウンできる
    - ステートレスである
    - Batch workloads
    

    View Slide

23. 23
    Spot VM instances (検証段階)
    2. いつでも利用可能か保証されていない
    　　 → Spot VM Nodeの数が足りずPodがスケジュールできない場合は
    　　　on-demand Nodeにスケジュールする (preferred NodeAffinity)
    また、定期的にon-demand上のPodをSpotへ移動し直すようなコンポーネントを実装予
    定
    

    View Slide

24. 24
    Workload Level Optimization
    VPA / Resource recommender
    

    View Slide

25. 25
    リソースの使用量を常に確認し、良さげなresource request/limitの推奨値を計算
    して、設定してくれる。
    →メルカリでは直接VPAはまだあまり使用されていない
    VerticalPodAutoscaler
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

29. 29
    Resource Recommender
    Resource Recommenderは過去1ヶ月のVPAの推奨値の最大値を取得し、
    「プラットフォーム推奨のresource request」としてユーザーに送っている
    CPUやMemoryの推奨値には時間帯等でばらつきがあるため、
    1ヶ月のVPAの推奨値の最大値とすることで安全値をとっている
    

    View Slide

30. 30
    Workload Level Optimization
    HPA fine tuning
    

    View Slide

31. 31
    クラスター上のすべてのサービスにHPAを作成すれば、クラスターのリソース使用率
    も上がる？
    ↓
    現実はそれほど簡単ではない
    ● HPAの各種パラメーターの調整
    ● リソースのRequestの調整
    をしないとHPAがパワーを発揮できない
    HPAの難しさ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

41. 41
    4)Multiple containers Pod with HPAめんどくさい問題
    80%
    80%
    App
    Sidecar
    どちらもTarget: 80%
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

47. 47
    4) Multiple containers Pod with HPAめんどくさい問題
    80%
    80%
    App
    Sidecar
    80%
    Appのresource request
    を下げる
    同時に80%に達するの
    が一番リソースの無駄
    がない
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

57. 57
    🐢を使用したWorkload Autoscaling
    

    View Slide

58. 58
    mercari/tortoise
    

    View Slide

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

    View Slide

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

    View Slide

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

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

70. 70
    Tortoise のresource utilization計算の仕組み
    80%
    80%
    App
    Sidecar
    どちらもTarget: 80%
    

    View Slide

71. 71
    Tortoise のresource utilization計算の仕組み
    80%
    80%
    App
    Sidecar リソース使用量が増えて
    いく
    50%
    30%
    

    View Slide

72. 72
    Tortoise のresource utilization計算の仕組み
    80%
    80%
    App
    Sidecar リソース使用量が増えて
    いく
    50%
    

    View Slide

73. 73
    Tortoise のresource utilization計算の仕組み
    80%
    80%
    App
    Sidecar SidecarのUtilizationが
    80%に達したので、HPA
    はPodの数を増やす
    50%
    

    View Slide

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

    View Slide

75. 75
    Tortoise のresource utilization計算の仕組み
    80%
    80%
    App
    Sidecar
    50%
    実際にはPodごとに利
    用率のばらつきがある
    +
    Scale upが完了するま
    でラグがある
    

    View Slide

76. 76
    Tortoise のresource utilization計算の仕組み
    80%
    実際の最大リソース使用率:90%
    App
    Sidecar
    50%
    実際にはPodごとに利
    用率のばらつきがある
    +
    Scale upが完了するま
    でラグがある
    

    View Slide

77. 77
    VPAがどのように推奨値を計算しているか
    過去のリソースの使用量を記録
    ↓
    p90 - p95 (+ OOMKilledを考慮) の値を「十分なリソースの量」としてResource
    requestに適応
    

    View Slide

78. 78
    Tortoise のresource utilization計算の仕組み
    80%
    90%
    App
    Sidecar
    VPAの推奨値がこの時のリ
    ソース使用量を指している
    とみなす
    50%
    

    View Slide

79. 79
    Tortoise のresource utilization計算の仕組み
    80%
    90%-80% = 10%
    App
    Sidecar
    10%が必要な余分リソース
    → target utilization: 90%がベスト
    50%
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

88. 88
    [復習] Multiple containers Pod with HPAめんどくさい問題
    80%
    80%
    App
    Sidecar
    80%
    Appのresource request
    を下げる
    同時に80%に達するの
    が一番リソースの無駄
    がない
    

    View Slide

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

    View Slide

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

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

    View Slide

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

    View Slide

93. 93
    ● インスタンスタイプやGKEのクラスターレベルの設定から始められるリソース最
    適化もある
    ● 大量のHPAの最適化を人の手で継続的にやり続けるのは難しい
    ○ メルカリでは🐢を検証し育てていく予定です
    ● 台風の時期に沖縄に行くのは慎重になったほうがいい
    まとめ
    

    View Slide

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

    View Slide

95. 95
    Thanks for listening!
    

    View Slide