Cloud Native Developers JP Kubernetes ⽔平オートスケーリング 実践⼊⾨ @hhiroshell 1

Cloud Native Developers JP 宣伝 • 感染対策をしっかりやって遊舎⼯房に⾏きましょう 2 遊舎⼯房さんの店舗はこちら→ ↓現在の@hhiroshellのキーボード #crkbd ⾃⼰紹介 @hhiroshell 早川 博 （はやかわ ひろし） • Cloud Nativeなインフラを開 発するエンジニア。 Yahoo Japan Corporation 所属 • エンジニアコミュニティ 「Cloud Native Developers JP」 オーガナイザー • Developers Summit 2018 Japan Container Days 12.18 CloudNative Days Tokyo 2019 登壇 • ⾃作キーボード沼

Cloud Native Developers JP ⽬次 1. イントロダクション 2. ⽔平オートスケーリングの課題と現実解 3. Kubernetesの⽔平オートスケーリングの仕組み 4. ケーススタディ 3

Cloud Native Developers JP ⽬次 1. イントロダクション 2. ⽔平オートスケーリングの課題と現実解 3. Kubernetesの⽔平オートスケーリングの仕組み 4. ケーススタディ 4

Cloud Native Developers JP 5 Kubernetesとオートスケーリングに対する期待 たくさん負荷がきてもいい感じに さばけるようにしてくれ。 くーばねてすなら簡単なんでしょ？ ※ 丸投げのイラスト

Cloud Native Developers JP このセッションのゴール • オートスケールで⾃動で負荷をさばけたらかっこいい。ロマンある。 • だが、現実は…。 • まずはKubernetesで地に⾜のついた⽔平オートスケーリングの設計が できることを⽬指そう。 • 以下のような内容を話します。 – ⼀般的なオートスケーリングの課題と考慮事項 – Kubernetesでの⽔平オートスケーリングの実現⽅法 – ケーススタディ 6

Cloud Native Developers JP ⽬次 1. イントロダクション 2. オートスケーリングの課題と現実解 3. Kubernetesの⽔平オートスケーリング仕組み 4. ケーススタディ 7

Cloud Native Developers JP オートスケーリングとは 1. 「⼀定の条件をトリガーに」 – 何らかのメトリクスを元に条件判定をおこなう 2. 「必要なリソースを必要分」 – 所定のロジックに従って、増強 / 縮退するリソースの種類と量を 決定する 3. 「⾃動的に増強 / 縮退する」 – プラットフォームのAPIを呼ぶなどしてスケーリングを実⾏する ⼀定の条件をトリガーに、必要なリソースを必要分、⾃動的に増強/縮退する機能 8 繰り返し 1 2 3

Cloud Native Developers JP • スケーリングが間に合わない！ – スケーリングのトリガーが遅い – リソースの払い出しが遅い • スケールしても効果がない！ – ボトルネックの箇所に効いていない – リソースを追加したのに期待ほどの戦⼒に なっていない 9 • スケールし過ぎ／⾜りない！ – 負荷の変動に追従できていない – IaaSの契約の上限に当たってしまいそれ以 上増強できない • スケールアウトしたのに戻っちゃっ た！ – 負荷の減少に対して感度が良すぎる 実際にはいろいろな問題が起こります…。 これらすべてのパターンに⼀度に対処するのは現実的ではない ※ 頭を抱えて悩んでいる人のイラスト（男性）

Cloud Native Developers JP オートスケーリングの設計の出発点 • 負荷の変動の傾向を調べることから始める • 傾向がつかめた負荷のうちコストに⾒合うもの⾒極めて⾃動化する すべてを⾃動化しようとしせず、できるところから 10 予測可能 な負荷 ⾃動化して 対処するもの ⾃動化は 避けるもの 負荷のパターンの全体 どこまで やろうかな…？ ※ 将来のことを考える人のイラスト（男性）

Cloud Native Developers JP • スケーリングが間に合わない！ – スケーリングのトリガーが遅かった – リソースの払い出しが遅かった • スケールしても効果がない！ – ボトルネックの箇所に効いていなかった – リソースを追加しても期待ほどの戦⼒にな らなっていなかった 11 • スケールし過ぎ／⾜りない！ – 負荷の変動においついていなかった – IaaSの契約の上限に当たってしまいそれ以 上増強できなかった • スケールアウトしたのに戻っちゃっ た！ – 負荷の減少に対して感度が良すぎた 相⼿（負荷）を知ったら対策を打ちやすくなります マトを絞って対策を打てる ※ 踊るお殿様のイラスト

Cloud Native Developers JP • スケーリングが間に合わない！ – スケーリングのトリガーが遅かった – リソースの払い出しが遅かった • スケールしても効果がない！ – ボトルネックの箇所に効いていなかった – リソースを追加しても期待ほどの戦⼒にな らなっていなかった 12 • スケールし過ぎ／⾜りない！ – 負荷の変動においついていなかった – IaaSの契約の上限に当たってしまいそれ以 上増強できなかった • スケールアウトしたのに戻っちゃっ た！ – 負荷の減少に対して感度が良すぎた ⼰(=Kubernetes)を知るとやれることの限界がわかります Kubernetesの機能だけではできないこともある ※ 踊るお殿様のイラスト Safe Harbor Statement 実は がついていない箇所はKubernetes単体の機能ではあまりできる対策がありません

Cloud Native Developers JP オートスケーリングを正しく活⽤した世界 • 起こりうる負荷変動に対して、オートスケーリングの適⽤範囲を⾒ 極められている • 低コストでSLAを達成するための道具と捉え、活⽤できている – 運⽤オペレーションのコスト削減 – ダウンタイムの削減 – 平常時のリソース利⽤量の最適化 ⽬標を達成するための⼿段の1つと捉えて賢く使おう 13

Cloud Native Developers JP ⽬次 1. イントロダクション 2. ⽔平オートスケーリングの課題と現実解 3. Kubernetesの⽔平オートスケーリングの仕組み 4. ケーススタディ 14

Cloud Native Developers JP Kubernetes API Server kube-controller-manager Kubernetesの⽔平オートスケーリングの仕組み 15 Horizontal Pod Autoscaler Custom Metrics API Server (Pod, Object) metrics-server app pod app pod app pod kubelet Custom Metrics API Server (External) metrics source metrics source HPAリソースをウォッチ メトリクス取得 Deploymentなどの リソースを操作 HorizontalPodAutoscalerリソース API Serviceリソース

Cloud Native Developers JP Kubernetes API Server kube-controller-manager Kubernetesの⽔平オートスケーリングの仕組み 16 Horizontal Pod Autoscaler Custom Metrics API Server (Pod, Object) metrics-server app pod app pod app pod kubelet Custom Metrics API Server (External) metrics source metrics source HPAリソースをウォッチ メトリクス取得 Deploymentなどの リソースを操作 HorizontalPodAutoscalerリソース API Serviceリソース CPU, Mem

Cloud Native Developers JP Kubernetes API Server kube-controller-manager Kubernetesの⽔平オートスケーリングの仕組み 17 Horizontal Pod Autoscaler Custom Metrics API Server (Pod, Object) metrics-server app pod app pod app pod kubelet Custom Metrics API Server (External) metrics source metrics source HPAリソースをウォッチ メトリクス取得 Deploymentなどの リソースを操作 HorizontalPodAutoscalerリソース API Serviceリソース スケール量を決定

Cloud Native Developers JP HorizontalPodAutoscalerリソース • ⽔平オートスケーリングの振る舞いを定義するリソース • minRepricas / maxRepricas – 最⼩／最⼤ replica 数 • scaleTargetRef – スケールを⾏うWorkloadリソースの指定 • metrics – スケーリングの条件判定に利⽤する メトリクスを指定 • behavior – 1回のスケーリングでのリソースの増減幅の指定 18 apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: my-app-hpa spec: minReplicas: 1 maxReplicas: 10 scaleTargetRef: (...snip...) metrics: (...snip...) behavior: (...snip...) 1 2 3 4 5 6 7 8 9 10 11 12 13

Cloud Native Developers JP HPAリソースのtargetフィールド • スケーリングを⾏う対象を指定するフィールド • 以下のリソース種別のみが指定でき、これらの replicas がHPAによって調整される – Deployment – ReplicaSet – ReplicationController 19 HorizontalPodAutoscaler では Podの増減しかできないため、他の箇所のボトルネックには 対処できません ! scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app 1 2 3 4

Cloud Native Developers JP HPAリソースのmetricsフィールド • スケーリングで使うメトリクスを指定する領域 • type: – メトリクス種別の指定（後述） • Resource / Pods / Object / External: – metric: • メトリクスを識別するための情報 – target: • スケーリングをトリガーする閾値 – describedObject: • メトリクスに紐づくK8sリソースの指定 （type=Object のみ） 20 metrics: type: Object object: metric: name: requests-per-second target: type: Value value: 2k describedObject: apiVerion: networking.k8s.io/v1beta1 kind: Ingress name: my-app-route 1 2 3 4 5 6 7 8 9 10 11 12

Cloud Native Developers JP メトリクス種別による違い ”type” メトリクス メトリクスの収集源 Kubernetesリソースとの 関連 評価ロジック Resources CPU使⽤量、 Memory使⽤量 metrics-serverがkubelet から収集した値を利⽤ Podリソースに紐づいた メトリクスとして扱う 個々のPod毎に値が収集さ れる前提で、それ⽤の評価 ロジックが採⽤される Pods 任意 Aggregation Layerで追加 した任意のEndpoint Podリソースに紐づいた メトリクスとして扱う 個々のPod毎に値が収集さ れる前提で、それ⽤の評価 ロジックが採⽤される Object 任意 Aggregation Layerで追加 した任意のEndpoint 任意のKubernetesリソー スと紐付いたメトリク スとして扱う 単⼀の値を使った評価ロ ジックとなる External 任意 Aggregation Layerで追加 した任意のEndpoint Kubernetes外から取得し た値を利⽤する 単⼀の値を使った評価ロ ジックとなる 21

Cloud Native Developers JP 【参考】merticsフィールドとAPIパスの関係 • HorizontalPodAutoscalerはAPI Serverからメトリクスを取得している • メトリクスを取得しにいくPathはHPAリソースのmetricsフィールドに よって決まる。カスタムメトリクスEndpointはこのPathへのリクエス ト対してメトリクスを返す必要がある • 例）Serviceオブジェクトに対応するメトリクスの場合 – /apis/custom.metrics.k8s.io/v1beta2/namespaces/my-ns/... ... services/my-app-svc/my-app-metric • 詳しい仕様はDesign Proposalsを参照(-> Appendix.) 22 APIバージョン namespace k8sオブジェクト メトリクス名 metrics: type: Object object: metric: name: my-app-metric describedObject: apiVerion: v1 kind: Service name: my-app-svc

Cloud Native Developers JP カスタムメトリクスの実装 • kubernetes/metricリポジトリ配下にCustom Metric API Serverのいくつ かの実装が紹介されている。 – https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md • Prometheus Adapter – PrometheusのメトリクスをCustom Metric API Serverとして利⽤可能にするアダプター • Kube Metrics Adapter – Prometheusの他、Kubernetes外のメトリクス供給源にも対応したアダプター • Custom Metrics Adapter Server Boilerplate – Custom Metrics API Serverを実装するためのライブラリ 23

Cloud Native Developers JP HPAリソースのbehaviorフィールド • 1回のスケーリングでのリソースの増減 幅を指定するフィールド – 注: v1.18.x 〜 から追加 • scaleDown: – stabilizationWindowSeconds: • Podの増減の後そのreplicasの値を必ず維持する時間 – policies: • 指定の時間幅の中で増減可能な最⼤Pod数を指定する – selectPolicy: • 複数のPolicyを設定した場合にどれが採⽤されるかを指 定する • scaleup: – 配下のフィールドはscaleDownと同じ 24 behavior: scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 scaleup: stabilizationWindowSeconds: 0 policies: - type: Percent value: 100 periodSeconds: 15 - type: Pods value: 4 periodSeconds: 15 selectPolicy: Max 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Cloud Native Developers JP 25 HPAによる⽔平オートスケーリング挙動まとめ [要求レプリカ数] = [現在のレプリカ数] * ([メトリクス値] / [要求メトリクス値]) （切り上げ） replica 数 要求レプリカ数 実際のレプリカ数 bahavior で指定 された増加幅 bahavior で指定された減少幅 bahaviorで指定された 1回の増加にかける時間 bahaviorで指定された 1回の減少にかける時間 bahaviorで 指定された 待機時間

Cloud Native Developers JP • スケーリングが間に合わない！ – スケーリングのトリガーが遅かった – リソースの払い出しが遅かった • スケールしても効果がない！ – ボトルネックの箇所に効いていなかった – リソースを追加しても期待ほどの戦⼒にな らなっていなかった 26 • スケールし過ぎ／⾜りない！ – 負荷の変動においついていなかった – IaaSの契約の上限に当たってしまいそれ以 上増強できなかった • スケールアウトしたのに戻っちゃっ た！ – 負荷の減少に対して感度が良すぎた もう⼀度オートスケーリングの課題を確認…。 Kubernetesの機能だけではできないこともある ※ 踊るお殿様のイラスト Safe Harbor Statement 実は がついていない箇所はKubernetes単体の機能ではあまりできる対策がありません

Cloud Native Developers JP ⽬次 1. イントロダクション 2. ⽔平オートスケーリングの課題と現実解 3. Kubernetesの⽔平オートスケーリングの仕組み 4. ケーススタディ 27

Cloud Native Developers JP ここでとり扱うケース • アプリケーション – REST APIサーバー – CPUバウンドな処理特性 – Kubernetes上にDeploymentとして展開 • 想定する負荷変動 – 突発的なアクセス増（スパイク）を想定 – 平常時から 3 分程度でピーク値 (1000[rps]) までリクエスト数が増加。その後 3分経過した後に平常に戻る • 検証環境を作るためのmanifest: https://github.com/hhiroshell/k8s-hpa-experiment 28 検証環境のためあまり⼤規模な実験ではありませんので、適宜整数倍するなどして補正 をお願いします m(_ _)m !

Cloud Native Developers JP 29 システム構成 Gatling （負荷⽣成器） Nginx Ingress Controller API Server kube-metrics-adaptor metrics-server Prometheus app pod app pod app pod kubelet Horizontal Pod Autoscaler Kubernetes クラスター kubectl で メトリクスを観察 ロードバランサー メトリクス取得 メトリクス(rps)取得 メトリクス （CPU,メモリ）取得 • メトリクス (rps, CPU, mem) 取得 • スケーリング実⾏

Cloud Native Developers JP ⽔平オートスケーリングを設定するまでの流れ • Pod以外のボトルネックをチェックする • 平常時、ピーク時のPod数を決める • オートスケーリングで使うメトリクスを選ぶ • オートスケーリングの感度を調整する 30 1 2 3 4

Cloud Native Developers JP Pod以外のボトルネックをチェックする • HPAではPod数しか⾃動調整できないため、それ以外のボトルネック が先に顕在化しない構成になっていることを確認する – Pod数を⼗分⼤きめにして負荷をかけ、エラーや⼤きな遅延なくトラフィック が捌けるかどうかをみる – 今回のケースではNginx Ingress Controllerの処理能⼒が不⾜していたため、 replicas: 1 -> 2 に増強 31 Gatling （負荷⽣成器） Nginx Ingress Controller app pod app pod app pod Kubernetes クラスター ロードバランサー Nginx Ingress Controller 1

Cloud Native Developers JP 平常時、ピーク時に必要なPod数を決める • 平常時、ピーク時に相当する負荷をかけ、安定してトラフィックを 処理できるPod数を決定する • ここで決めた値をHPAリソースの minReplicas, masReplicasに設定する 32 2 ! • PodのresourceLimits, resourceRequestsも忘れずに設定しましょう – これによりreplicas数をもって処理性能を調整するという前提が整う – 処理特性に応じてCPU, Memory利⽤量のバランスも合わせて調整する (...snip...) spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: cowweb minReplicas: 2 maxReplicas: 10 (...snip...) 1 2 3 4 5 6 7 8 9

Cloud Native Developers JP オートスケーリングで使うメトリクスを選ぶ • 監視で使う⼀般的なメトリクスから候補を決める • リソースレベルのメトリクス: – Utilization: CPU、メモリ使⽤量 – Saturation: 飽和度。キューに詰まっている量（e.g. ロードアベレージ） • アプリケーションレベルのメトリクス: – Rate: スループット、秒間リクエスト数 – Duration: レスポンス時間パーセンタイル、サービス時間 – Error Rate : エラー率 – Queue Length: アプリケーションが処理すべきジョブキューのジョブ数 33 3

Cloud Native Developers JP • 対象とする負荷に確実 に反応する • 負荷が反映されるまで のタイムラグが短い 34 • ⽬的の負荷以外のノイ ズが少ない オートスケーリングに適したメトリクスの特性 • 必要なリソース量を⾒ 積もりやすい • 収集する仕組みを作り やすい • 安定して収集できる ※ 走る作業員のイラスト（男性） ※ 豆腐メンタルのイラスト ※ 耳栓をつけた人のイラスト ※ そろばんを使う男の子のイラスト ※ 工事現場のイラスト ※ バケツリレーイラスト（荷物）

Cloud Native Developers JP 負荷をかけながらメトリクスの推移を⾒た結果 35 0.0 20.0 40.0 60.0 80.0 100.0 120.0 140.0 0.0 200.0 400.0 600.0 800.0 1000.0 1200.0 23:58:59 23:59:08 23:59:17 23:59:26 23:59:35 23:59:44 23:59:53 0:00:02 0:00:11 0:00:20 0:00:29 0:00:38 0:00:47 0:00:56 0:01:05 0:01:14 0:01:23 0:01:32 0:01:41 0:01:50 0:01:59 0:02:08 0:02:17 0:02:26 0:02:35 0:02:44 0:02:53 0:03:02 0:03:11 0:03:20 0:03:29 0:03:38 0:03:47 0:03:56 0:04:05 0:04:14 0:04:23 0:04:32 0:04:41 0:04:50 0:04:59 0:05:08 0:05:17 0:05:26 0:05:35 0:05:44 0:05:53 0:06:02 0:06:11 0:06:20 0:06:29 0:06:38 0:06:47 0:06:56 0:07:05 0:07:14 0:07:23 0:07:32 0:07:41 0:07:50 0:07:59 0:08:08 0:08:17 0:08:26 0:08:35 0:08:44 0:08:53 0:09:02 0:09:11 0:09:20 0:09:29 0:09:38 0:09:47 0:09:56 0:10:05 rps cpu [rps] [Milisec / Pod] • CPU使⽤量はリクエスト量（実際の負荷の量）によく追従している • リクエスト量はCPU使⽤量に⽐べて2倍の頻度で値が更新されている （これの理由は後述）

Cloud Native Developers JP 負荷をかけながらメトリクスの推移を⾒た結果 36 0 5,000 10,000 15,000 20,000 25,000 30,000 23:58:59 23:59:08 23:59:17 23:59:26 23:59:35 23:59:44 23:59:53 0:00:02 0:00:11 0:00:20 0:00:29 0:00:38 0:00:47 0:00:56 0:01:05 0:01:14 0:01:23 0:01:32 0:01:41 0:01:50 0:01:59 0:02:08 0:02:17 0:02:26 0:02:35 0:02:44 0:02:53 0:03:02 0:03:11 0:03:20 0:03:29 0:03:38 0:03:47 0:03:56 0:04:05 0:04:14 0:04:23 0:04:32 0:04:41 0:04:50 0:04:59 0:05:08 0:05:17 0:05:26 0:05:35 0:05:44 0:05:53 0:06:02 0:06:11 0:06:20 0:06:29 0:06:38 0:06:47 0:06:56 0:07:05 0:07:14 0:07:23 0:07:32 0:07:41 0:07:50 0:07:59 0:08:08 0:08:17 0:08:26 0:08:35 0:08:44 0:08:53 0:09:02 0:09:11 0:09:20 0:09:29 0:09:38 0:09:47 0:09:56 0:10:05 メモリ使用量（Podごとの平均） • メモリ使⽤量は負荷が増えてもほとんど変化しない [KiB]

Cloud Native Developers JP リソースレベルのメトリクスの⽋点 1/2 • リソースレベルのメトリクスは、過負荷になったときに値が取れな くなるリスクが⾼い – スケーリングの対象（負荷がかかる対象）が値の供給源となっている 37 Gatling （負荷⽣成器） Nginx Ingress Controller API Server kube-metrics-adaptor metrics-server Prometheus app pod app pod app pod kubelet ロードバランサー メトリクス取得 メトリクス(rps)取得 メトリクス （CPU,メモリ）取得

Cloud Native Developers JP 過負荷状態でのCPU利⽤量 • 過負荷状態に伴ってOOMKillなどによるPodの再起動が発⽣すると、 NotReadyかつメトリクス値として0が取得されるPodが出てくる • HPAの仕様によりこのようなPodはスケール量を抑える⽅向に作⽤す るため、⼀刻も早くPodを増やしたい状況では都合が悪い ※ https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details 38 0 50 100 150 200 250 1:38:31 1:38:41 1:38:52 1:39:03 1:39:14 1:39:24 1:39:35 1:39:45 1:39:56 1:40:07 1:40:18 1:40:29 1:40:39 1:40:55 1:41:06 1:41:17 1:41:27 1:41:37 1:41:48 1:41:58 1:42:09 1:42:19 1:42:30 1:42:40 1:42:51 1:43:01 1:43:17 1:43:27 1:43:38 1:43:48 1:43:59 1:44:09 1:44:20 1:44:31 1:44:42 1:44:52 1:45:03 1:45:13 1:45:24 1:45:34 1:45:45 1:45:56 1:46:06 1:46:17 1:46:28 1:46:38 1:46:49 1:46:59 1:47:10 1:47:20 1:47:30 1:47:41 1:47:51 1:48:02 1:48:12 1:48:23 1:48:33 1:48:44 1:48:55 1:49:05 1:49:17 1:49:32 1:49:43 1:49:53 PodのCPU使用量の平均 CPU使⽤量の平均値が低く評価され、 スケール量が抑えられてしまう

Cloud Native Developers JP リソースレベルのメトリクスの⽋点 2/2 • マネージドサービスを利⽤する場合、metrics-serverのパラメータや デプロイ構成の⾃由が効かない（ことが多い） – メトリクスの更新頻度を上げたり、可⽤性構成をとったりすることが難しい 39 Gatling （負荷⽣成器） Nginx Ingress Controller API Server kube-metrics-adaptor metrics-server Prometheus app pod app pod app pod kubelet ロードバランサー メトリクス取得 メトリクス(rps)取得 メトリクス （CPU,メモリ）取得

Cloud Native Developers JP メトリクスをrpsにするHPA設定 • kube-metrics-adapterの使い⽅に 沿って、PromQLで取得した値を利 ⽤するように設定 40 (...snip...) metadata: annotations: metric-config.external. prometheus-query.prometheus/rps: | sum by (job) (rate(nginx_ingress_ controller_nginx_process_requests_ total[1m]) (...snip...) spec: (...snip...) metrics: - type: External external: metric: name: prometheus-query selector: matchLabels: query-name: rps target: type: Value averageValue: ”100" 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 • metadata.annotations.metric-config.external.[ph]: – Prometheusに対するクエリを指定する – Nginx Ingress Controllerで観測されたrps値を取得している • spec.metrics.external: – anntotationsに記述したクエリと、target（利⽤するメトリク スの指定）を対応づける設定を記述 • spec.metrics.target: – Prometheusから取得したメトリクスをPod数で割った値が 100を超えないようにスケーリングをおこなう

Cloud Native Developers JP 最後は要件に合わせてメトリクスを決定 • 急激な負荷がかかる状況において安定したスケーリングしたいこと から、リクエスト量[rps]を採⽤ 41 メトリクス 負荷に確実 に反応する タイムラグ ノイズの 影響 必要リソースの ⾒積もりやすさ 収集する仕組み の構築しやすさ メトリクス収集 の安定性 CPU使⽤量 [Milisec per pod] ○ ○ ? ○ ○ × メモリ使⽤量 [KiB per Pod] × N/A ? N/A ○ × リクエスト量 [rps] ○ ○ ○ × × ○ (...snip...)

Cloud Native Developers JP オートスケーリングの感度を調整する • ピーク時は安定しているが、負荷増加時にスケールが間に合わずエ ラーとなっている • 負荷の増加に対して早めにスケールするよう調整が必要 42 4 負荷の増加に replica 数が追いつ かず、エラーとなっている状態 replica 数が最⼤値に調整され、 処理が安定した状態

Cloud Native Developers JP スケーリングの感度を決めるHPA設定 • spec.behavorで感度を上げる – やりすぎると無⽤なリソースを消費しやすくなる ので注意 • 平常時のPod数（待機Pod数）を上げる • スケールダウンでは感度を落としてオシ レーションを防⽌する 43 spec: (...snip...) minReplicas: 4 metrics: - type: External external: metric: name: prometheus-query selector: matchLabels: query-name: rps target: type: Value averageValue: "70” behavior: scaleUp: stabilizationWindowSeconds: 0 policies: - type: Pods value: 4 periodSeconds: 5 scaleDown: (...snip...) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 • spec.metris.external.target.averageValue: – Podあたりのrps値が70を超えた時点でスケールを開始 • spec.behavior.scaleup.stabilizationWindowSeconds: – 前回のスケール後、間を置かず次のスケーリングを実⾏ • spec.behavior.scaleup.policies: – 5秒以内に最⼤4Pod追加

Cloud Native Developers JP Congrats ! • 無事にスパイクに対処できる設定ができました！ 44

Cloud Native Developers JP まとめ • この絵を再掲してまとめとしたく。 • ご利⽤は計画的に…。Happy Autoscaling !! 45 予測可能 な負荷 ⾃動化して 対処するもの ⾃動化は 避けるもの 負荷のパターンの全体 どこまで やろうかな…？ ※ 将来のことを考える人のイラスト（男性）

Cloud Native Developers JP Fin. 46

Cloud Native Developers JP Appendix. 参考⽂献 47

Cloud Native Developers JP 【参考⽂献】 • Kubermetes公式ドキュメント – Horizontal Pod Autoscaler • https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ – Horizontal Pod Autoscaler Walkthrough • https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/ – Extending the Kubernetes API with the aggregation layer • https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ – Configure the Aggregation Layer • https://kubernetes.io/docs/tasks/access-kubernetes-api/configure-aggregation-layer – Resource metrics pipeline • https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/ – kube-controller-manager （オプションの参照先） • https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/ • Kubernetes APIリファレンス – HorizontalPodAutoscaler v2beta2 autoscaling: • https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#horizontalpodautoscaler-v2beta2-autoscaling 48

Cloud Native Developers JP 【参考⽂献】 • GitHubリポジトリ上のドキュメント – Repository top • https://github.com/kubernetes/metrics – Implementations • https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md – Metrics Server • https://github.com/kubernetes-sigs/metrics-server – Design Proposals • https://github.com/kubernetes/community/tree/master/contributors/design-proposals/instrumentation – Custom Metrics API 仕様 • https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics- api.md • https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics- api.md 49

Cloud Native Developers JP 【参考⽂献】 • Custom Metrics API Serverの実装 – Custom Metrics Adapter Server Boilerplate • https://github.com/kubernetes-sigs/custom-metrics-apiserver – kube-metrics-adapter • https://github.com/zalando-incubator/kube-metrics-adapter – Prometheus Adapter for Kubernetes Metrics APIs • https://github.com/directxman12/k8s-prometheus-adapter • 論⽂ – Auto-Scaling Web Applications in Clouds: A Taxonomy and Survey • https://dl.acm.org/doi/abs/10.1145/3148149 • コミュニティや有志の資料 – 監視って何だっけ？/@ryota¥_hnk • https://docs.google.com/presentation/d/1jc0voGfNCpDumTCTna1aqyV1NARxLKXS0LUYEfGOroY – 【暫定版】 Kubernetesの性能監視で必要なメトリクス⼀覧とPrometheusでのHowTo • https://kashionki38.hatenablog.com/entry/2020/08/06/011420 50