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
110
A Tale of Two Plugins: Safely Extending the Kubernetes Scheduler with WebAssembly
sanposhiho
0
95
Don't try to tame your autoscalers, tame Tortoises!
sanposhiho
0
630
メルカリにおけるZone aware routing
sanposhiho
2
920
A tale of two plugins: safely extending the Kubernetes Scheduler with WebAssembly
sanposhiho
1
430
メルカリにおけるプラットフォーム主導のKubernetesリソース最適化とそこに生まれた🐢の可能性
sanposhiho
1
770
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
Designing for Performance
lara
604
68k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
28
2k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Scaling GitHub
holman
458
140k
Raft: Consensus for Rubyists
vanstee
136
6.6k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
100
BBQ
matthewcrist
85
9.3k
Embracing the Ebb and Flow
colly
84
4.5k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
840
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.