人間によるKubernetesリソース最適化の”諦め” そこに見るリクガメの可能性

Kubernetes活用の手引き 私たちの基盤構築・運用事例 Lunch LT
https://findy.connpass.com/event/307447/

Transcript

1. 1 Confidential 人間によるKubernetesリソース最適化の”諦め” そこに見るリクガメの可能性 Kensei Nakada / @sanposhiho
2. 2 Mercari JP Platform team / 2022卒新卒 Kubernetes approver (SIG-Scheduling) Kubernetes Contributor award (2022, 2023) Kensei Nakada / sanposhiho
3. 3 Kubernetes in Mercari
4. 4 Kubernetes in Mercari • 一つのClusterで、Mercari/Merpayほぼ全てのWorkloadが動いている • 1000+ Deployment • PlatformチームがCluster adminとして運用 MercariではFinOpsを全社的な目標に掲げており、Platformチームが行う施 策は影響力が非常に大きい。
5. 5 これまでのリソース使用率改善の取組
6. 6 メルカリの Kubernetes リソース最適化の今 • Kubernetes リソース最適化にはKubernetesに関わる深い知識が必要 • アプリケーション開発チーム全員にその知識を求めるのは現実的ではない → Platformがリソース最適化のためのツールやガイドラインを提供
7. 7 Resource Recommender Resource Recommenderと呼ばれるSlack botが動作している → リソース最適化を簡略化することを目標としている Hoge deployment appcontainer XXX XXX
8. 8 Resource Recommenderの課題点 • 適応の状況が良くない ・Developerがその推奨値を適用してくれるかは分からない。 ・適応してくれたかを測るのも難しい。 • 推奨値はすぐに変わりうる ・推奨値は本来送られた瞬間が賞味期限。 ・メッセージを送った数日後には推奨値が変わっている可能性がある。場 合によっては、OOMKilledなど危険な状況につながりうる。
9. 9 Autoscalers in Kubernetes Kubernetesには以下のオートスケーラーが存在 • HorizontalPodAutoscaler(HPA): Podのリソース使用量に応じて、Pod の数を増減する。 • VerticalPodAutoscaler(VPA): Podのリソース使用量に応じて、Podが使 用できるリソース量(= Resource Request)を増減する。
10. 10 HPAの例 このように、Containerに対して リソース使用率の閾値を設定す ると、HPAが自動でそれに近いリ ソース使用率に維持してくれる minReplicas とよばれる、最低 Pod数を決めるパラメーター など その他細かいものも多く存在
11. 11 Autoscalers in Kubernetes Kubernetesには以下のオートスケーラーが存在 • HorizontalPodAutoscaler(HPA): Podのリソース使用量に応じて、Pod の数を増減する。 • VerticalPodAutoscaler(VPA): Podのリソース使用量に応じて、Podが使 用できるリソース量(= Resource Request)を増減する。 HPA (cpu) がメルカリでは普及している
12. 12 HPA最適化？ • HPAに管理されているからと言って、CPU使用率が高くなるわけではない。 HPAを最適化しない限り、CPU使用率は上がらない。 • HPAの最適化 = リソース使用率の閾値を上げれば終わりではない • Resource recommenderはHPAの最適化には対応しておらず、未だにユー ザーがメトリクス等から自身の判断で手動の最適化を行う必要がある
13. 13 HPA最適化における難しさ • 実際のリソース使用率から、HPAのそれぞれのパラメータの最適な値を計算す るには様々なメトリクスの確認と適切な知識が必要。 ・考慮すべきシナリオが多く、Recommenderに実装することはおろか、ド キュメント化して簡潔なステップに収めることが難しい。 ・HPAの最適化のためにリソースのRequestを調整する必要がある場合 がある。 • サービスが動き続ける限り、状況は変化し得る、最適なパラメータの値も変化し 得る = 最適化をし続ける必要がある。
14. 14 HPA最適化における難しさ • 実際のリソース使用率から、HPAのそれぞれのパラメータの最適な値を計算す るには様々なメトリクスの確認と適切な知識が必要。 ・考慮すべきシナリオが多く、Recommenderに実装することはおろか、ド キュメント化して簡潔なステップに収めることが難しい。 ・HPAの最適化のためにリソースのRequestを調整する必要がある場合 がある。 • サービスが動き続ける限り、状況は変化し得る、最適なパラメータの値も変化し 得る = 最適化をし続ける必要がある。 無理じゃね…?
15. 15 🐢を使用した Autoscaling
16. 16 mercari/tortoise
17. 17 これからはリクガメに任せる時代です。 過去のWorkloadの振る舞いを記 録し、Podの数、resource request/limitの全てをいい感じに 調節してくれる。
18. 18 [復習] HPA最適化における難しさ • 実際のリソース使用率から、HPAのそれぞれのパラメータの最適な値を計算す るには様々なメトリクスの確認と適切な知識が必要。 ・考慮すべきシナリオが多く、Recommenderに実装することはおろか、ド キュメント化して簡潔なステップに収めることが難しい。 ・HPAの最適化のためにリソースのRequestを調整する必要がある場合 がある。 • サービスが動き続ける限り、状況は変化し得る、最適なパラメータの値も変化し 得る = 最適化をし続ける必要がある。
19. 19 mercari/tortoiseのモチベ • 実際のリソース使用率から、HPAのそれぞれのパラメータの最適な値を計算す るには様々なメトリクスの確認と適切な知識が必要。 ・考慮すべきシナリオが多く、Recommenderに実装することはおろか、ド キュメント化して簡潔なステップに収めることが難しい。 ・HPAの最適化のためにリソースのRequestを調整する必要がある場合 がある。 • サービスが動き続ける限り、状況は変化し得る、最適なパラメータの値も変化し 得る = 最適化をし続ける必要がある。 メトリクスの確認、そこからの適切なパラメータの計 算はそもそも人間様がやる必要はない。
20. 20 mercari/tortoiseのモチベ • 実際のリソース使用率から、HPAのそれぞれのパラメータの最適な値を計算す るには様々なメトリクスの確認と適切な知識が必要。 ・考慮すべきシナリオが多く、Recommenderに実装することはおろか、ド キュメント化して簡潔なステップに収めることが難しい。 ・HPAの最適化のためにリソースのRequestを調整する必要がある場合 がある。 • サービスが動き続ける限り、状況は変化し得る、最適なパラメータの値も変化し 得る = 最適化をし続ける必要がある。 システムであれば、常に変化を監視して、最 適化を続けられる。
21. 21 Tortoiseがなぜ必要か ユーザー目線: • リソースの設定/最適化から完全に逃れることができる ＝ リソース最適化の責務を各サービスオーナーからPlatformチーム (Tortoise)に移す。 • Emergency modeや動的なMinReplicaの調整など、追加機能の存在。 Platform目線: • 新たな技術への移行の簡単さ
22. 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. 23 mercari/tortoiseの現状 • Platformで積極的に開発しており、検証段階。 • 開発環境では実際にAutoモードでの使用が始まっている。 • 最終的には全てのPodをTortoiseで管理することをゴールにしている。
24. 24 Have a better life with cute Tortoises.