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

カスタムコントローラを利用したスパイクに耐えるオートスケーリングの仕組みを構築

 カスタムコントローラを利用したスパイクに耐えるオートスケーリングの仕組みを構築

ユーザベースのSaaS事業におけるSREチームの位置付けと責務を紹介し、SREの業務で行われている事例を紹介する。事例の内容は、サービスの信頼性を担保する上で必要なスケーラビリティについて取り上げる。特に、Kubernetes環境を題材としており、特定のPodに対する一時的な負荷に対してどのような対策をすべきか、SREの視点で検討した内容を記載している。

TomoyukiSugiyama

September 06, 2023
Tweet

Other Decks in Technology

Transcript

  1. カスタムコントローラを利用した
    スパイクに耐えるオートスケーリ
    ングの仕組みを構築
    2023/08/29 SaaSプロダクトを支えるSREの取り組み
    1

    View Slide

  2. 杉山 智之 / すぎやま ともゆき
    経歴
    2015年   (株)デンソートリム入社 生産技術部
    2016年   (株)デンソーに1年間出向
    2017年   設備設計、自動化ラインの立ち上げ
    2021年   再び、(株)デンソーに1年間出向
    2022年   検査の標準化
    2022年11月  (株)ユーザベースへ入社 SRE
    工場のインフラ から Webサービスのインフラ へ
    2
    自己紹介

    View Slide

  3. ユーザベースのSaaS事業
    SaaS事業の開発組織とSREの位置付け
    SREでの実験的な取組み事例紹介
    本日お伝えすること
    ● Webエンジニア歴10ヶ月
    SREとの向き合い方
    01
    02
    03
    3
    Product
    Development
    Team
    SRE
    ※実装までの内容であり、運用に至っていないです

    View Slide

  4. | 01 |
    ユーザベースのSaaS事業
    4

    View Slide

  5. NewsPicks事業
    5
    経済情報の力で、誰もがビジネスを楽しめる世界をつくる
    SaaS事業

    View Slide

  6. | 02 |
    SaaS事業の
    開発組織とSREの位置付け
    6

    View Slide

  7. 技術力で、ビジネスをリードする
    7
    SaaS事業の開発組織について
    規模・在籍メンバー属性
    約100名
    ※2022年4月時点
    ソフトウェアエンジニア
    SRE
    テストエンジニア
    データサイエンティスト
    開発チーム構成
    各プロダクト・機能ごとに開発チームを作り
    ペアプロ、TDDで開発
    A チーム
    (4 ~ 5 名)
    B チーム
    (4 ~ 5 名)
    C チーム
    (4 ~ 5 名)
    and more …

    View Slide

  8. 開発チーム
    8
    開発組織におけるSREの位置付け
    SREチーム
    在籍メンバー・責務 責務
    各開発チーム (4~5 名) が
    機能の開発・運用する
    7 名
    各開発チームが機能の開発・運用
    できるようにサポートする
    各開発チームにSREの考え方を
    伝承する
    各開発チームが自律的に信頼性の高いサービスを開発・運用できることを目指す

    View Slide

  9. サービスの構成
    マイクロサービスアーキテクチャを採用
    9
    マイクロ
    サービス
    Kubernetes 環境 (以下、K8s)
    マイクロ
    サービス
    マイクロ
    サービス
    マイクロ
    サービス
    マイクロ
    サービス
    マイクロ
    サービス
    安定運用のために導入する仕組み
    GitOps :Argo CD
    B/Gデプロイ :Istio
    監視 :Prometheus、Grafana
    SLO/SLI :Datadog
    IaC :Terraform
    上記の構成により、開発チームの運用負荷を抑え、サービスの成長を加速する
    ただし、信頼できるサービスの実現には、多くの要求を満たす必要がある

    View Slide

  10. 信頼できるサービスに求められること
    スケーラビリティ
    高可用性
    災害対策
    高セキュリティ
    10
    信頼できるサービスの実現
    開発チーム
    機能の開発に注力する必要があるため、機能以外の要件を全て満たすことは困難
    SREチーム
    効率よく、機能以外の要件を満たす仕組みを提供

    View Slide

  11. | 03 |
    SREでの実験的な取組み事例紹介
    11
    ※実装までの内容であり、運用に至っていないです

    View Slide

  12. 大規模研修の実施
    12
    SaaS事業においても、通常以上の負荷が特定の箇所に集中することがある
    ユーザベースのSaaS事業における負荷が高い状況
    研修時でも耐えられるキャパシティの確保が必要

    View Slide

  13. 改善方法による違い
    13
    制限なく必要十分なキャパシティを確保するためには
    ● 速いアプリケーションに書換え
    ● キャッシュ
    ● スケールアウト(、スケールアップ)
    改善効果 効率
    スケールアウト(水平スケーリング)は、 改善効果が得にくい ものの、簡単に導入できる
    K8s標準のHPAを例に、説明する

    View Slide

  14. 水平スケーリング (HPA : Horizontal Pod Autoscaler )
    HPA は、PodのメモリやCPUのリソース、リクエスト数を指標として、
    実際のリソースの使用量に合わせて、Podの台数を動的に変更する仕組み
    14
    K8s標準のHPAの利用(1/2)
    急激なリクエストの増加に合わせてスケールすることは困難
    → リクエストが増加する前に、事前にスケールしておくことで解決
    pods
    minReplicas
    maxReplicas
    時間

    View Slide

  15. 事前にスケールしてもスケーラビリティが失われては意味がない
    15
    K8s標準のHPAの利用(2/2)
    通常時・研修時でレンジ(minReplicas/maxReplicas)を変更することで、
    スケーラビリティを確保できるが、標準のHPAで対応できない
    pods
    minReplicas
    maxReplicas
    時間
    通常時 研修時

    View Slide

  16. HPAの拡張
    ● 急激なリクエストの増加に合わせてスケールすることは困難  → ①メトリクスを用意
    ● 事前にスケールしてもスケーラビリティが失われては意味がない  → ②Replicas を動的に変更
    16
    ここまでの整理
    pods
    minReplicas
    maxReplicas
    時間
    通常時 研修時
    メトリクス


    メトリクスに応じて、minReplicas/maxReplicas を動的に変更

    View Slide

  17. カスタムコントローラを利用して HPA を拡張した
    Custom Horizonral Pod Autoscaler (以下、CustomHPA)
    を実装する
    17
    https://github.com/TomoyukiSugiyama/custom-horizontal-pod-autoscaler

    View Slide

  18. カスタムリソースとカスタムコントローラ
    機能を拡張する仕組み
    カスタムリソース:Kubernetes API を拡張
    カスタムコントローラ:カスタムリソースで定義したあるべき状態を維持し管理する仕組み
    18
    カスタムコントローラとは

    View Slide

  19. サスティナブルな仕組み
    ● 掃除のし易さ
    CustomHPAが不要になっても、容易に削除可能
    ● 拡張容易性
    Prometheus以外でも対応しやすい構造
    ● 監視性
    コントローラの状態をGrafanaで確認できる
    19
    CustomHPAを実装する上で考慮した点

    View Slide

  20. 掃除のし易さ:容易に削除可能
    20
    CustomHPAの構成
    ①メトリクスを登録
    ②メトリクスに応じて、
     minReplicas/maxReplicasを変更

    View Slide

  21. 拡張容易性:Prometheus以外に対応しやすい構造
    21
    CustomHPAコントローラの実装
    メトリクスを取得
    HPAの状態を変更

    View Slide

  22. 22
    監視性:Grafana で監視
    参考:コントローラの状態確認

    View Slide

  23. 実装を通して得たもの
    ● 10ヶ月のエンジニア ( Webエンジニア歴 , SRE歴 , K8s歴 ) がカスタムコントローラを実装
    K8sの基本的な仕組みを少し学ぶことができた
    ● SREの位置付けや責務を学ぶきっかけになった
    23
    最後に

    View Slide

  24. 最後までご清聴ありがとうございました。
    Thank you
    24

    View Slide