1 Confidential 人間によるKubernetesリソース最適化の”諦め” そこに見るリクガメの可能性 Kensei Nakada / @sanposhiho

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

3 Kubernetes in Mercari

4 Kubernetes in Mercari ● 一つのClusterで、Mercari/Merpayほぼ全てのWorkloadが動いている ● 1000+ Deployment ● PlatformチームがCluster adminとして運用 MercariではFinOpsを全社的な目標に掲げており、Platformチームが行う施 策は影響力が非常に大きい。

5 これまでのリソース使用率改善の取組

6 メルカリの Kubernetes リソース最適化の今 ● Kubernetes リソース最適化にはKubernetesに関わる深い知識が必要 ● アプリケーション開発チーム全員にその知識を求めるのは現実的ではない → Platformがリソース最適化のためのツールやガイドラインを提供

7 Resource Recommender Resource Recommenderと呼ばれるSlack botが動作している → リソース最適化を簡略化することを目標としている Hoge deployment appcontainer XXX XXX

8 Resource Recommenderの課題点 ● 適応の状況が良くない ・Developerがその推奨値を適用してくれるかは分からない。 ・適応してくれたかを測るのも難しい。 ● 推奨値はすぐに変わりうる ・推奨値は本来送られた瞬間が賞味期限。 ・メッセージを送った数日後には推奨値が変わっている可能性がある。場 合によっては、OOMKilledなど危険な状況につながりうる。

9 Autoscalers in Kubernetes Kubernetesには以下のオートスケーラーが存在 ● HorizontalPodAutoscaler(HPA): Podのリソース使用量に応じて、Pod の数を増減する。 ● VerticalPodAutoscaler(VPA): Podのリソース使用量に応じて、Podが使 用できるリソース量(= Resource Request)を増減する。

10 HPAの例 このように、Containerに対して リソース使用率の閾値を設定す ると、HPAが自動でそれに近いリ ソース使用率に維持してくれる minReplicas とよばれる、最低 Pod数を決めるパラメーター など その他細かいものも多く存在

11 Autoscalers in Kubernetes Kubernetesには以下のオートスケーラーが存在 ● HorizontalPodAutoscaler(HPA): Podのリソース使用量に応じて、Pod の数を増減する。 ● VerticalPodAutoscaler(VPA): Podのリソース使用量に応じて、Podが使 用できるリソース量(= Resource Request)を増減する。 HPA (cpu) がメルカリでは普及している

12 HPA最適化？ ● HPAに管理されているからと言って、CPU使用率が高くなるわけではない。 HPAを最適化しない限り、CPU使用率は上がらない。 ● HPAの最適化 = リソース使用率の閾値を上げれば終わりではない ● Resource recommenderはHPAの最適化には対応しておらず、未だにユー ザーがメトリクス等から自身の判断で手動の最適化を行う必要がある

13 HPA最適化における難しさ ● 実際のリソース使用率から、HPAのそれぞれのパラメータの最適な値を計算す るには様々なメトリクスの確認と適切な知識が必要。 ・考慮すべきシナリオが多く、Recommenderに実装することはおろか、ド キュメント化して簡潔なステップに収めることが難しい。 ・HPAの最適化のためにリソースのRequestを調整する必要がある場合 がある。 ● サービスが動き続ける限り、状況は変化し得る、最適なパラメータの値も変化し 得る = 最適化をし続ける必要がある。

14 HPA最適化における難しさ ● 実際のリソース使用率から、HPAのそれぞれのパラメータの最適な値を計算す るには様々なメトリクスの確認と適切な知識が必要。 ・考慮すべきシナリオが多く、Recommenderに実装することはおろか、ド キュメント化して簡潔なステップに収めることが難しい。 ・HPAの最適化のためにリソースのRequestを調整する必要がある場合 がある。 ● サービスが動き続ける限り、状況は変化し得る、最適なパラメータの値も変化し 得る = 最適化をし続ける必要がある。 無理じゃね…?

15 🐢を使用した Autoscaling

16 mercari/tortoise

17 これからはリクガメに任せる時代です。 過去のWorkloadの振る舞いを記 録し、Podの数、resource request/limitの全てをいい感じに 調節してくれる。

18 [復習] HPA最適化における難しさ ● 実際のリソース使用率から、HPAのそれぞれのパラメータの最適な値を計算す るには様々なメトリクスの確認と適切な知識が必要。 ・考慮すべきシナリオが多く、Recommenderに実装することはおろか、ド キュメント化して簡潔なステップに収めることが難しい。 ・HPAの最適化のためにリソースのRequestを調整する必要がある場合 がある。 ● サービスが動き続ける限り、状況は変化し得る、最適なパラメータの値も変化し 得る = 最適化をし続ける必要がある。

19 mercari/tortoiseのモチベ ● 実際のリソース使用率から、HPAのそれぞれのパラメータの最適な値を計算す るには様々なメトリクスの確認と適切な知識が必要。 ・考慮すべきシナリオが多く、Recommenderに実装することはおろか、ド キュメント化して簡潔なステップに収めることが難しい。 ・HPAの最適化のためにリソースのRequestを調整する必要がある場合 がある。 ● サービスが動き続ける限り、状況は変化し得る、最適なパラメータの値も変化し 得る = 最適化をし続ける必要がある。 メトリクスの確認、そこからの適切なパラメータの計 算はそもそも人間様がやる必要はない。

20 mercari/tortoiseのモチベ ● 実際のリソース使用率から、HPAのそれぞれのパラメータの最適な値を計算す るには様々なメトリクスの確認と適切な知識が必要。 ・考慮すべきシナリオが多く、Recommenderに実装することはおろか、ド キュメント化して簡潔なステップに収めることが難しい。 ・HPAの最適化のためにリソースのRequestを調整する必要がある場合 がある。 ● サービスが動き続ける限り、状況は変化し得る、最適なパラメータの値も変化し 得る = 最適化をし続ける必要がある。 システムであれば、常に変化を監視して、最 適化を続けられる。

21 Tortoiseがなぜ必要か ユーザー目線: ● リソースの設定/最適化から完全に逃れることができる ＝ リソース最適化の責務を各サービスオーナーからPlatformチーム (Tortoise)に移す。 ● Emergency modeや動的なMinReplicaの調整など、追加機能の存在。 Platform目線: ● 新たな技術への移行の簡単さ

22 シンプルなInterface apiVersion: autoscaling.mercari.com/v1beta3 kind: Tortoise metadata: name: nginx-tortoise namespace: tortoise-poc spec: updateMode: Auto targetRef: scaleTargetRef: kind: Deployment name: nginx-deployment Deployment name ONLY!

23 mercari/tortoiseの現状 ● Platformで積極的に開発しており、検証段階。 ● 開発環境では実際にAutoモードでの使用が始まっている。 ● 最終的には全てのPodをTortoiseで管理することをゴールにしている。

24 Have a better life with cute Tortoises.