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

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

Transcript

1. カスタムコントローラを利用した スパイクに耐えるオートスケーリ ングの仕組みを構築 2023/08/29 SaaSプロダクトを支えるSREの取り組み 1
2. 杉山　智之 / すぎやま　ともゆき 経歴 2015年　　　(株)デンソートリム入社　生産技術部 2016年　　　(株)デンソーに１年間出向 2017年　　　設備設計、自動化ラインの立ち上げ 2021年　　　再び、(株)デンソーに１年間出向 2022年　　　検査の標準化 2022年11月　 (株)ユーザベースへ入社　SRE 工場のインフラ から Webサービスのインフラ へ 2 自己紹介
3. ユーザベースのSaaS事業 SaaS事業の開発組織とSREの位置付け SREでの実験的な取組み事例紹介 本日お伝えすること • Webエンジニア歴１０ヶ月 SREとの向き合い方 01 02 03 3 Product Development Team SRE ※実装までの内容であり、運用に至っていないです
4. | 01 | ユーザベースのSaaS事業 4
5. NewsPicks事業 5 経済情報の力で、誰もがビジネスを楽しめる世界をつくる SaaS事業
6. | 02 | SaaS事業の 開発組織とSREの位置付け 6
7. 技術力で、ビジネスをリードする 7 SaaS事業の開発組織について 規模・在籍メンバー属性 約100名 ※2022年4月時点 ソフトウェアエンジニア SRE テストエンジニア データサイエンティスト 開発チーム構成 各プロダクト・機能ごとに開発チームを作り ペアプロ、TDDで開発 A チーム (4 ~ 5 名) B チーム (4 ~ 5 名) C チーム (4 ~ 5 名) and more …
8. 開発チーム 8 開発組織におけるSREの位置付け SREチーム 在籍メンバー・責務 責務 各開発チーム (4~5 名) が 機能の開発・運用する 7 名 各開発チームが機能の開発・運用 できるようにサポートする 各開発チームにSREの考え方を 伝承する 各開発チームが自律的に信頼性の高いサービスを開発・運用できることを目指す
9. サービスの構成 マイクロサービスアーキテクチャを採用 9 マイクロ サービス Kubernetes 環境 (以下、K8s) マイクロ サービス マイクロ サービス マイクロ サービス マイクロ サービス マイクロ サービス 安定運用のために導入する仕組み GitOps ：Argo CD B/Gデプロイ ：Istio 監視 ：Prometheus、Grafana SLO/SLI ：Datadog IaC ：Terraform 上記の構成により、開発チームの運用負荷を抑え、サービスの成長を加速する ただし、信頼できるサービスの実現には、多くの要求を満たす必要がある
10. 信頼できるサービスに求められること スケーラビリティ 高可用性 災害対策 高セキュリティ 10 信頼できるサービスの実現 開発チーム 機能の開発に注力する必要があるため、機能以外の要件を全て満たすことは困難 SREチーム 効率よく、機能以外の要件を満たす仕組みを提供
11. | 03 | SREでの実験的な取組み事例紹介 11 ※実装までの内容であり、運用に至っていないです
12. 大規模研修の実施 12 SaaS事業においても、通常以上の負荷が特定の箇所に集中することがある ユーザベースのSaaS事業における負荷が高い状況 研修時でも耐えられるキャパシティの確保が必要
13. 改善方法による違い 13 制限なく必要十分なキャパシティを確保するためには • 速いアプリケーションに書換え • キャッシュ • スケールアウト（、スケールアップ） 改善効果 効率 スケールアウト（水平スケーリング）は、 改善効果が得にくい ものの、簡単に導入できる K8s標準のHPAを例に、説明する
14. 水平スケーリング (HPA : Horizontal Pod Autoscaler ) HPA は、PodのメモリやCPUのリソース、リクエスト数を指標として、 実際のリソースの使用量に合わせて、Podの台数を動的に変更する仕組み 14 K8s標準のHPAの利用(1/2) 急激なリクエストの増加に合わせてスケールすることは困難 →　リクエストが増加する前に、事前にスケールしておくことで解決 pods minReplicas maxReplicas 時間
15. 事前にスケールしてもスケーラビリティが失われては意味がない 15 K8s標準のHPAの利用(2/2) 通常時・研修時でレンジ(minReplicas/maxReplicas)を変更することで、 スケーラビリティを確保できるが、標準のHPAで対応できない pods minReplicas maxReplicas 時間 通常時 研修時
16. HPAの拡張 • 急激なリクエストの増加に合わせてスケールすることは困難　 →　①メトリクスを用意 • 事前にスケールしてもスケーラビリティが失われては意味がない　 →　②Replicas を動的に変更 16 ここまでの整理 pods minReplicas maxReplicas 時間 通常時 研修時 メトリクス ① ② メトリクスに応じて、minReplicas/maxReplicas を動的に変更
17. カスタムコントローラを利用して HPA を拡張した Custom Horizonral Pod Autoscaler (以下、CustomHPA) を実装する 17 https://github.com/TomoyukiSugiyama/custom-horizontal-pod-autoscaler
18. カスタムリソースとカスタムコントローラ 機能を拡張する仕組み カスタムリソース：Kubernetes API を拡張 カスタムコントローラ：カスタムリソースで定義したあるべき状態を維持し管理する仕組み 18 カスタムコントローラとは
19. サスティナブルな仕組み • 掃除のし易さ CustomHPAが不要になっても、容易に削除可能 • 拡張容易性 Prometheus以外でも対応しやすい構造 • 監視性 コントローラの状態をGrafanaで確認できる 19 CustomHPAを実装する上で考慮した点
20. 掃除のし易さ：容易に削除可能 20 CustomHPAの構成 ①メトリクスを登録 ②メトリクスに応じて、 　minReplicas/maxReplicasを変更
21. 拡張容易性：Prometheus以外に対応しやすい構造 21 CustomHPAコントローラの実装 メトリクスを取得 HPAの状態を変更
22. 22 監視性：Grafana で監視 参考：コントローラの状態確認
23. 実装を通して得たもの • １０ヶ月のエンジニア ( Webエンジニア歴 , SRE歴 , K8s歴 ) がカスタムコントローラを実装 K8sの基本的な仕組みを少し学ぶことができた • SREの位置付けや責務を学ぶきっかけになった 23 最後に
24. 最後までご清聴ありがとうございました。 Thank you 24