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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

6 Kubernetes Cluster Overview Workloads on cluster + FinOps

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

11 Node Level Optimization Cluster Autoscaling

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15 text

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

Slide 16

Slide 16 text

16 Node Level Optimization Node instance type

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

24 Workload Level Optimization VPA / Resource recommender

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

30 Workload Level Optimization HPA ﬁne tuning

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

57 🐢を使用したWorkload Autoscaling

Slide 58

Slide 58 text

58 mercari/tortoise

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

95 Thanks for listening!