Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
人間によるKubernetesリソース最適化の”諦め” そこに見るリクガメの可能性
Search
sanposhiho
January 24, 2024
2
1.9k
人間によるKubernetesリソース最適化の”諦め” そこに見るリクガメの可能性
Kubernetes活用の手引き 私たちの基盤構築・運用事例 Lunch LT
https://findy.connpass.com/event/307447/
sanposhiho
January 24, 2024
Tweet
Share
More Decks by sanposhiho
See All by sanposhiho
kube-scheduler: from 101 to the frontier
sanposhiho
1
98
A Tale of Two Plugins: Safely Extending the Kubernetes Scheduler with WebAssembly
sanposhiho
0
94
Don't try to tame your autoscalers, tame Tortoises!
sanposhiho
0
630
メルカリにおけるZone aware routing
sanposhiho
2
900
A tale of two plugins: safely extending the Kubernetes Scheduler with WebAssembly
sanposhiho
1
420
メルカリにおけるプラットフォーム主導のKubernetesリソース最適化とそこに生まれた🐢の可能性
sanposhiho
1
760
MercariにおけるKubernetesのリソース最適化のこれまでとこれから
sanposhiho
8
3.9k
The Kubernetes resource management and the behind systems in Mercari
sanposhiho
0
310
Goにおけるアクターモデルの実現に 向けたライブラリの設計と実装
sanposhiho
5
2.3k
Featured
See All Featured
Agile that works and the tools we love
rasmusluckow
327
21k
Making the Leap to Tech Lead
cromwellryan
132
8.9k
Fontdeck: Realign not Redesign
paulrobertlloyd
81
5.2k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Code Review Best Practice
trishagee
64
17k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
664
120k
Automating Front-end Workflow
addyosmani
1365
200k
The Invisible Side of Design
smashingmag
297
50k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
Transcript
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.