Tweet
Tweet

Slide 1

Slide 1 text

急成⻑するサービスのSREが ぶち当たった スケーラビリティの壁 塚 本 純 ⼀ 2022.4.19

Slide 2

Slide 2 text

⾃⼰紹介 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周年

Slide 3

Slide 3 text

ⓒ 2022 atama plus Inc. Culture Code序⽂ atama plusはなぜ存在するのか。答えは 明快です。「Missionを実現するため」、 それ以外にありません。 社会のまんなか を新しくするために、限られた⽣徒では なく、数億という規模の⽣徒に良い教育 を届けていく。 3 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁

Slide 4

Slide 4 text

ⓒ 2022 atama plus Inc. はじめに 2019年から2020年の間で⾏ったatama+ COACHのバックエンドにおけるスケーラ ビリティの問題とその対応について話します 4 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 ここら辺の話 ここら辺の話 #アタマプラス5周年

Slide 5

Slide 5 text

ⓒ 2022 atama plus Inc. atama＋ COACH 5 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 不正解時に解説をきちんと⾒て いない可能性があります ジュンジ君 不定詞の問題に標準の2倍以上の 時間がかかっています マコさん マコさん 先⽣ 「2次⽅程式」 合格しそう！ 眠く なってきた… ジュンジ君 解説読むの ⾯倒くさい！ シンイチ君 2次⽅程式の合格間近です！ 褒める準備をしましょう！ シンイチ君 #アタマプラス5周年

Slide 6

Slide 6 text

atama＋ COACH バックエンド構成

Slide 7

Slide 7 text

ⓒ 2022 atama plus Inc. atama＋ COACHバックエンドで採⽤している主な技術 • Firebase Realtime Database • マネージドなNoSQLクラウドデータベース • クライアント間でデータをリアルタイム同期する機能を提供 • Cloud Functions For Firebase • Firebaseにおけるサーバーレスの実⾏環境 • AWSの各種サービス 7 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年

Slide 8

Slide 8 text

ⓒ 2022 atama plus Inc. atama＋ COACH バックエンド構成 • atama＋ • 学習状況をRealtime Databaseに書き 込む • Realtime Database/Cloud Functions • Realtime Databaseへの書き込みを トリガーにCloud Functionsが実⾏ • データの⾮正規化 • 学習の状況に基づいてアラートを⽣成 • atama＋ COACH • Realtime Databaseの情報に基づきリ アルタムな学習状況を表⽰ 8 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年

Slide 9

Slide 9 text

急成⻑するサービスがぶち当たった スケーラビリティの3つの壁

Slide 10

Slide 10 text

ⓒ 2022 atama plus Inc. 10 1つめの壁 ユーザ数増加に Realtime Databaseの性能が追いつかない

Slide 11

Slide 11 text

ⓒ 2022 atama plus Inc. ユーザ数増加にRealtime Databaseの性能が追いつかない • 時期 • 2019年4⽉頃 (SRE/Infraチームが まだ存在しなかった) • 発⽣した事象と原因 • Realtime Databaseが⼀時的に過 負荷になった • 学習状況が表⽰されない/アラート が表⽰できない 11 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年

Slide 12

Slide 12 text

ⓒ 2022 atama plus Inc. シャード化 Realtime Databaseを複数インスタンス利⽤して負荷を分散するシャード化を実施 ( https://firebase.google.com/docs/database/usage/sharding ) 12 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年

Slide 13

Slide 13 text

ⓒ 2022 atama plus Inc. 13 インスタンスを追加すれば スケールできる構成を⼿に⼊れた やったぜ! #アタマプラス5周年

Slide 14

Slide 14 text

ⓒ 2022 atama plus Inc. 14 2つめの壁 シャーディング化で発⽣したツラミ #アタマプラス5周年

Slide 15

Slide 15 text

ⓒ 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周年

Slide 16

Slide 16 text

ⓒ 2022 atama plus Inc. デプロイ速度のツラミ2 ツラミ • 並列化したらデプロイで利⽤するAPI callのRate Limitにひっかかる (上限緩和 できない) • https://firebase.google.com/docs/functions/quotas#rate_limits 対策 • 並列数を制御しつつ、リトライも使いながら可能な限り速度を上げる 16 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年

Slide 17

Slide 17 text

ⓒ 2022 atama plus Inc. 17 シャード化で発⽣したツラミも解消 やったぜ! #アタマプラス5周年

Slide 18

Slide 18 text

ⓒ 2022 atama plus Inc. 18 3つめの壁 シャーディングしたのに スケールアウトできない #アタマプラス5周年

Slide 19

Slide 19 text

ⓒ 2022 atama plus Inc. スケールアウトできない • 最初の緊急事態宣⾔下でオンラインでの授 業のニーズが⾼まりユーザ数の増加スピー ドも上昇した時期 • ボトルネックになる可能性があるリソース やサービスの制約の洗い出しを実施 • Cloud Functionsの数に対する制約が問題 になりそうなことが判明 19 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年

Slide 20

Slide 20 text

ⓒ 2022 atama plus Inc. スケールアウトできない • Firebaseはprojectという単位でリソースを 管理 • 1 projectあたりCloud Functionsの数に上限 が存在 • Realtime Databaseのインスタンス数を増や すとCloud Functionsの数も増える 20 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年

Slide 21

Slide 21 text

ⓒ 2022 atama plus Inc. 解決策 • firebaseプロジェクトを複数使う構成 に変更 • デプロイ速度の問題を緩和することに も成功 21 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年

Slide 22

Slide 22 text

ⓒ 2022 atama plus Inc. 22 数億の⽣徒にWowを届けられる スケーラビリティを atama＋ COACHは⼿に⼊れた！ #アタマプラス5周年

Slide 23

Slide 23 text

ⓒ 2022 atama plus Inc. まとめ • スケーラビリティの3つの壁 • ユーザ数増加にRTDBの性能が追いつかない • シャーディング化で発⽣したツラミ • シャーディングしたのにスケールアウトできない • これから戦う壁 • 学習データを保存するDBのスケーラビリティ • 開発のスケーラビリティ 23 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年

Slide 24

Slide 24 text

ⓒ 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周年

Slide 25

Slide 25 text

ⓒ 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周年

Slide 26

Slide 26 text

ⓒ 2022 atama plus Inc. Appendix -その他に実施した性能改善策 - • multi path update • https://firebase.blog/posts/2015/09/introducing-multi-location- updates-and_86 26 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年

Slide 27

Slide 27 text

ⓒ 2022 atama plus Inc. Appendix -その他に実施した性能改善策 - • ⽣徒とコーチアプリが接続するRTDBを分離し、シャーディングロジックを分 割する • シャードによって負荷のバラツキが激しかたった • 2倍くらい開きがあった • ⽣徒側の書き込み処理が重く、コーチ側の読み込み処理にあまり負荷がな いという特性があった • ⽣徒とコーチ⽤のRTDBを分離し、⽣徒側のシャードへの割り振りをユーザ の識別⼦単位で分割する • 負荷が平準化された 27 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年

Slide 28

Slide 28 text

ⓒ 2022 atama plus Inc. Appendix ‒ その他のツラミ - • ツラミ • Realtime Databaseに状態を保持しアプリケーションから利⽤していたため、 インスタンス追加時にリバランシング作業が必要だった • 対策 • 状態の保持をRealtime DatabaseからAWS上のDBに移動しインスタンス追 加時にリバランシングが不要なように変更 28 急成⻑するサービスのSREがぶち当たったスケーラビリティの壁 #アタマプラス5周年