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
結局requestsとlimitsはどう設定すればいいのか
Search
Nao_Saino
February 15, 2022
1
600
結局requestsとlimitsはどう設定すればいいのか
Nao_Saino
February 15, 2022
Tweet
Share
More Decks by Nao_Saino
See All by Nao_Saino
クラウドネイティブ アプリケーション概論
nao_saino
0
140
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
47
2.1k
The Language of Interfaces
destraynor
154
24k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
It's Worth the Effort
3n
183
27k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
Site-Speed That Sticks
csswizardry
0
24
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Building Applications with DynamoDB
mza
90
6.1k
Building Adaptive Systems
keathley
38
2.3k
GitHub's CSS Performance
jonrohan
1030
460k
Transcript
結局requestsとlimitsは どう設定すればいいのか Kubernetes Novice Tokyo #16 2022/02/15
自己紹介 Saino - 某Web系企業にて昨年10月からSRE担当の新卒一年目 - WebメディアのKubernetes(GKE)運用が主な業務 - Kubernetes歴 = インフラ歴は4ヶ月
- 先月CKADを取得
- Podのリソース設定という基本的な内容を題材に、 - Kubernetes初学者である自分が難しさを感じた部分と - 設定する際に考慮すべきポイントについてお話しします。 本日は...
1. そもそもrequestsとlimitsとは何か 2. requestsとlimitsの何が難しいのか 3. 結局requestsとlimitsはどう設定すればいいのか 今日お話すること
そもそもrequestsとlimits とは何か Kubernetes Novice Tokyo #16
- どちらもPodに割り当てるリソース量を設定するパラメータ - Podのspec.containers[].resources以下でコンテナごとに設定。 - それぞれcpuとmemoryについて設定できる。 requestsとlimitsとは spec: … containers:
… resources: requests: cpu: 50m memory: 300Mi limits: cpu: 200m memory: 500Mi
requestsとは - Podが使用できることを保証される最低のリソース量。 - Podはrequestしたリソース分の空きがあるNodeにスケジュールされる。 - どのnodeにもrequests分の空きがない場合、Podはスケジュールされず、 Pending状態になる。 spec: …
containers: … resources: requests: cpu: 50m memory: 300Mi limits: cpu: 200m memory: 500Mi
limitsとは - Podが使用できる最大のリソース量(Nodeのリソースに空きがあれば)。 - limitsを超えてリソースを使うことはできない。 - memory.limitsを越えればOOM KilledされPodは強制終了する。 - cpu.limitsに達するとthrottleが発生する。
- 設定しなければrequests = limitsになる。 spec: … containers: … resources: requests: cpu: 50m memory: 300Mi limits: cpu: 200m memory: 500Mi
requestsとlimitsの 何が難しいのか Kubernetes Novice Tokyo #16
1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 requestsとlimits設定の何が難しいのか
1. 様々な要素を複合的に考慮して 設定する必要がある。
requests, limitsに関係する様々な要素 - リソース設定の際にはPod以外についても考慮しなければならない。 例えば、、、 - オートスケールを実装する仕組みであるHPA, VPA (水平, 垂直オートスケーラ)
は、「requestsの値に対する実際の使用率の比」を閾値に用いる。 - HPA, VPAを使う場合、requestsの意味合いが増える。 https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
1. 様々な複合的要素を考慮する必要がある 環境で用いる様々なk8sリソースへの影響を考慮して設定しなければならない。 - HPAやVPA (水平, 垂直オートスケーラ) →requestsの値を元にオートスケールの閾値を決定する。 - QoS
(Podの優先度) →requests < limitsであるほど低優先度のPodになる。 - ノードオートスケーラ(GKEなどマネージドk8sの実装) →どのノードにもrequests分の空きがない時、ノード自体が増える。
2. 「ちょうど良い値」を 設定しなければならない。
- そもそもリソース調整とは「小さすぎるとパフォーマンスに響くし、大きすぎてもコス トがかさむ」という中で「ちょうど良い値」を選ぶもの。 - もちろんパフォーマンスを下げてはいけないので、たっぷりとリソースを確保して おきたいが、 - 実際には「ちょうど良い」リソース量を設定して、コストとパフォーマンスの両立を 叶えたいところ。 2.
大きすぎず小さすぎない「ちょうど良い値」
結局requestsとlimitsは どう設定すればいいのか Kubernetes Novice Tokyo #16
1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 requestsとlimitsはどう設定すればいいのか
1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 requestsとlimitsはどう設定すればいいのか
1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 requestsとlimitsはどう設定すればいいのか 1. については学習と慣れで解決するのみ😇 自分の環境ではなにを考慮してrequests, limitsを 設定する必要があるか把握すること。
1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 requestsとlimitsはどう設定すればいいのか
- 負荷試験...? テストシナリオを用意して負荷試験を行い、予め想定負荷に耐えられるよう適当 な値を算出する → 負荷試験と実際のユーザの動きは異なるものの、一定有効。 - 実際のリソース使用量のメトリクスを見る。 「足りないか、足りているか」は分かるが、いくつに設定すればいいか?をどう決 めるか。経験や勘に頼りがち。
→唯一解を探すよりチームとしてノウハウが溜まっているかが大事。 「ちょうど良い値」をどうやって知るか
1. 様々な要素を複合的に考慮して設定する必要がある。 2. 「ちょうど良い値」を設定しなければならない。 →スケールとともに「ちょうど良い値」も変わる。 requestsとlimitsはどう設定すればいいのか
- 一方で「ちょうどいい値」はスケールとともに変化するもの。 - 負荷が増大すれば「ちょうどいい値」も大きくなる。 - 実際弊社でもリリース当初は負荷試験で決めた値をrequests, limitsに設定して いたが、サービスのスケールととも少しずつ足したり、試験時の想定ほど使わな かった分を減らしたりと、気がつけば手動で変更する運用になっていた。 →俗人的な運用に😇
「ちょうど良い値」をどうやって知るか
- 負荷増大のタイミング、規模が事前に分かっている場合 決まった時刻に何かを公開する場合や、サービスがテレビの取材を受け放送時 刻にアクセス増加が見込まれる場合など。 →想定負荷に応じて事前にリソースを増やしておくスケジュールドスケーリングで 対応。 スケールとともに変わる「ちょうど良い値」
- 負荷増大のタイミング、規模が事前に分からない場合。 ①長期的な負荷増加への対応(サービスのグロースなど) レイテンシの閾値でエラーバジェットを設定するなどし、チームで定期的なリソース使 用量の振り返りや負荷試験の機会を設けることで俗人性を排除。 ②短期的な負荷増加への対応(いわゆるスパイク) VPA, HPAなど水平or垂直オートスケーリングで対応。 ※それでもコンテナの起動より速い急激なスパイクには対応できない。 スケールとともに変わる「ちょうど良い値」
HPA, VPAを用いる場合の「ちょうどいい値」 - HPA, VPAを使う場合も「ちょうどいい値」の意味が変わる。 - HPAを用いた場合、Pod数という意味では動的にリソースを調整する仕組みがある ものの、requests, limits自体は固定値のまま。 →まず単一のPodで理想的なパフォーマンスを出せるか?(Novice
Tokyo#5) - VPAを用いた場合、動的にリソース量の書き換えをしてはくれるものの、HPAと併用 できない。 →サービス特性に合わせた選択を。
最後に - requests, limitsだけでパフォーマンスの問題を解決するものでもない。 - K8s単位で言えばnodeSelectorやtopoloogySpreadConstraintsなどを利用し、処 理に合わせた適切なノードを選択するスケジューリング制御も有効。 - アプリケーション側の実装やサービス特性まで広く視点を持つことが重要。
ご清聴ありがとうございました 皆さんのベストプラクティスを是非コメントで教えてください!