220419_LT#3 急成長プロダクトのSREがぶち当たったスケーラビリティの壁（5周年記念イベント）/Scalability Barrier in Rapidly Growing Products

atama plus創業5周年記念イベント・第2夜「急拡大したプロダクトの「技術課題」への向き合い方 〜開発チームの5年間・大公開SP～」にて、SREの塚本が登壇した際の資料です。
ぜひご覧ください。

▼イベント当日の動画はこちら
https://atamaplus-5th.studio.site/3-1

******
atama plusでは、新しい教育を創り、社会を変えていく仲間を募集しています。
ご興味もっていただいた方はぜひご応募ください！

▼採用サイト
https://recruiting.atama.plus/
▼募集職種一覧
https://herp.careers/v1/atamaplus

Transcript

1. 急成⻑するサービスのSREが ぶち当たった スケーラビリティの壁 塚 本 純 ⼀ 2022.4.19
2. ⾃⼰紹介 2018.1〜 atama plus株式会社 Architecture チーム PO SRE チーム PO SREエンジニア Webエンジニア 2015.01〜2017.12 ヤフー株式会社 基盤エンジニア 2013.01〜2014.12 FFRI株式会社 開発エンジニア 2007.04〜2012.12 トレンドマイクロ株式会社 開発エンジニア 2 塚 本 純 ⼀ #アタマプラス5周年
3. ⓒ 2022 atama plus Inc. Culture Code序⽂ atama plusはなぜ存在するのか。答えは 明快です。「Missionを実現するため」、 それ以外にありません。 社会のまんなか を新しくするために、限られた⽣徒では なく、数億という規模の⽣徒に良い教育 を届けていく。 3 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁
4. ⓒ 2022 atama plus Inc. はじめに 2019年から2020年の間で⾏ったatama+ COACHのバックエンドにおけるスケーラ ビリティの問題とその対応について話します 4 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 ここら辺の話 ここら辺の話 #アタマプラス5周年
5. ⓒ 2022 atama plus Inc. atama＋ COACH 5 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 不正解時に解説をきちんと⾒て いない可能性があります ジュンジ君 不定詞の問題に標準の2倍以上の 時間がかかっています マコさん マコさん 先⽣ 「2次⽅程式」 合格しそう！ 眠く なってきた… ジュンジ君 解説読むの ⾯倒くさい！ シンイチ君 2次⽅程式の合格間近です！ 褒める準備をしましょう！ シンイチ君 #アタマプラス5周年
6. atama＋ COACH バックエンド構成
7. ⓒ 2022 atama plus Inc. atama＋ COACHバックエンドで採⽤している主な技術 • Firebase Realtime Database • マネージドなNoSQLクラウドデータベース • クライアント間でデータをリアルタイム同期する機能を提供 • Cloud Functions For Firebase • Firebaseにおけるサーバーレスの実⾏環境 • AWSの各種サービス 7 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
8. ⓒ 2022 atama plus Inc. atama＋ COACH バックエンド構成 • atama＋ • 学習状況をRealtime Databaseに書き 込む • Realtime Database/Cloud Functions • Realtime Databaseへの書き込みを トリガーにCloud Functionsが実⾏ • データの⾮正規化 • 学習の状況に基づいてアラートを⽣成 • atama＋ COACH • Realtime Databaseの情報に基づきリ アルタムな学習状況を表⽰ 8 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
9. 急成⻑するサービスがぶち当たった スケーラビリティの3つの壁
10. ⓒ 2022 atama plus Inc. 10 1つめの壁 ユーザ数増加に Realtime Databaseの性能が追いつかない
11. ⓒ 2022 atama plus Inc. ユーザ数増加にRealtime Databaseの性能が追いつかない • 時期 • 2019年4⽉頃 (SRE/Infraチームが まだ存在しなかった) • 発⽣した事象と原因 • Realtime Databaseが⼀時的に過 負荷になった • 学習状況が表⽰されない/アラート が表⽰できない 11 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
12. ⓒ 2022 atama plus Inc. シャード化 Realtime Databaseを複数インスタンス利⽤して負荷を分散するシャード化を実施 ( https://firebase.google.com/docs/database/usage/sharding ) 12 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
13. ⓒ 2022 atama plus Inc. 13 インスタンスを追加すれば スケールできる構成を⼿に⼊れた やったぜ! #アタマプラス5周年
14. ⓒ 2022 atama plus Inc. 14 2つめの壁 シャーディング化で発⽣したツラミ #アタマプラス5周年
15. ⓒ 2022 atama plus Inc. デプロイ速度のツラミ ツラミ • FirebaseのデプロイはCloud Functionsの数に⽐ 例して遅くなる • Realtime Databaseのインスタンスを追加すると Cloud Functionsがインスタンスの数だけ増える • Realtime Databaseのインスタンス数がNで、 Cloud Functionsの種類がM個ある場合、NxM個 のCloud Functionsをデプロイする必要がある 対策 • Realtime Databaseのインスタンス単位でデプロ イを並列化 15 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
16. ⓒ 2022 atama plus Inc. デプロイ速度のツラミ2 ツラミ • 並列化したらデプロイで利⽤するAPI callのRate Limitにひっかかる (上限緩和 できない) • https://firebase.google.com/docs/functions/quotas#rate_limits 対策 • 並列数を制御しつつ、リトライも使いながら可能な限り速度を上げる 16 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
17. ⓒ 2022 atama plus Inc. 17 シャード化で発⽣したツラミも解消 やったぜ! #アタマプラス5周年
18. ⓒ 2022 atama plus Inc. 18 3つめの壁 シャーディングしたのに スケールアウトできない #アタマプラス5周年
19. ⓒ 2022 atama plus Inc. スケールアウトできない • 最初の緊急事態宣⾔下でオンラインでの授 業のニーズが⾼まりユーザ数の増加スピー ドも上昇した時期 • ボトルネックになる可能性があるリソース やサービスの制約の洗い出しを実施 • Cloud Functionsの数に対する制約が問題 になりそうなことが判明 19 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
20. ⓒ 2022 atama plus Inc. スケールアウトできない • Firebaseはprojectという単位でリソースを 管理 • 1 projectあたりCloud Functionsの数に上限 が存在 • Realtime Databaseのインスタンス数を増や すとCloud Functionsの数も増える 20 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
21. ⓒ 2022 atama plus Inc. 解決策 • firebaseプロジェクトを複数使う構成 に変更 • デプロイ速度の問題を緩和することに も成功 21 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
22. ⓒ 2022 atama plus Inc. 22 数億の⽣徒にWowを届けられる スケーラビリティを atama＋ COACHは⼿に⼊れた！ #アタマプラス5周年
23. ⓒ 2022 atama plus Inc. まとめ • スケーラビリティの3つの壁 • ユーザ数増加にRTDBの性能が追いつかない • シャーディング化で発⽣したツラミ • シャーディングしたのにスケールアウトできない • これから戦う壁 • 学習データを保存するDBのスケーラビリティ • 開発のスケーラビリティ 23 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
24. ⓒ 2022 atama plus Inc. Appendix • 【学びを⽌めるな】10万⼈以上の⽣徒の学習から⼤規模オンライン模試まで⽀ えるチームの紹介 • https://note.com/jtsukamoto/n/n427f6337fe5f • atama plusのSREのこれまでとこれから • https://note.com/atamaplus_dev/n/ne3d4af6ab4d7?magazine_key=m8 99b04c64c1a 24 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
25. ⓒ 2022 atama plus Inc. Appendix • 検討しなかったけどやらなかったこと • Firestore対応 • シャーディングしているという現状を踏まえると書き込みの性能は FirestoreよりもRTDBのほうが上だった • https://firebase.google.com/docs/firestore/rtdb-vs-firestore?hl=ja • https://firebase.google.com/docs/firestore/quotas?hl=ja#writes_and _transactions 25 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
26. ⓒ 2022 atama plus Inc. Appendix -その他に実施した性能改善策 - • multi path update • https://firebase.blog/posts/2015/09/introducing-multi-location- updates-and_86 26 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
27. ⓒ 2022 atama plus Inc. Appendix -その他に実施した性能改善策 - • ⽣徒とコーチアプリが接続するRTDBを分離し、シャーディングロジックを分 割する • シャードによって負荷のバラツキが激しかたった • 2倍くらい開きがあった • ⽣徒側の書き込み処理が重く、コーチ側の読み込み処理にあまり負荷がな いという特性があった • ⽣徒とコーチ⽤のRTDBを分離し、⽣徒側のシャードへの割り振りをユーザ の識別⼦単位で分割する • 負荷が平準化された 27 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年
28. ⓒ 2022 atama plus Inc. Appendix ‒ その他のツラミ - • ツラミ • Realtime Databaseに状態を保持しアプリケーションから利⽤していたため、 インスタンス追加時にリバランシング作業が必要だった • 対策 • 状態の保持をRealtime DatabaseからAWS上のDBに移動しインスタンス追 加時にリバランシングが不要なように変更 28 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年