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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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