Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kubernetes水平オートスケーリング実践入門 / A Practical Guide to Horizontal Autoscaling in Kubernetes

hhiroshell
September 08, 2020

Kubernetes水平オートスケーリング実践入門 / A Practical Guide to Horizontal Autoscaling in Kubernetes

CloudNative Days Tokyo 2020 (#CNDT2020) での発表資料です。

Kubernetesの水平オートスケーリングを使っていこうという話。

hhiroshell

September 08, 2020
Tweet

More Decks by hhiroshell

Other Decks in Technology

Transcript

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

    View full-size slide

  2. 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
    登壇
    • ⾃作キーボード沼

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  15. 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リソース

    View full-size slide

  16. 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

    View full-size slide

  17. 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リソース
    スケール量を決定

    View full-size slide

  18. 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

    View full-size slide

  19. 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

    View full-size slide

  20. 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

    View full-size slide

  21. 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

    View full-size slide

  22. 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

    View full-size slide

  23. 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

    View full-size slide

  24. 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  29. 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) 取得
    • スケーリング実⾏

    View full-size slide

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

    View full-size slide

  31. 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

    View full-size slide

  32. 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  35. 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倍の頻度で値が更新されている
    (これの理由は後述)

    View full-size slide

  36. 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]

    View full-size slide

  37. 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,メモリ)取得

    View full-size slide

  38. 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使⽤量の平均値が低く評価され、
    スケール量が抑えられてしまう

    View full-size slide

  39. 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,メモリ)取得

    View full-size slide

  40. 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を超えないようにスケーリングをおこなう

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  43. 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追加

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  46. Cloud Native Developers JP
    Fin.
    46

    View full-size slide

  47. Cloud Native Developers JP
    Appendix.
    参考⽂献
    47

    View full-size slide

  48. 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

    View full-size slide

  49. 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

    View full-size slide

  50. 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

    View full-size slide