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