TIPSTARを支えるCloud Spanner

会津大学の学生団体「Zli」が主催するLT大会に参加し、MIXIのエンジニア職採用・技術文化に関する企業PRを実施した時の資料です。

Transcript

1. ©MIXI TIPSTARを支える Cloud Spanner 2025/10/18 株式会社MIXI 若松丈人
2. ©MIXI 2 自己紹介 2023年度に新卒として入社。 入社から2025年8月まで TIPSTAR のバックエンド開発・運用に携わる。 2025年8月から mixi2 のバックエンド開発 若松丈人 登録してね ->
3. ©MIXI 会津若松
4. ©MIXI 僕と親和性が高そうな土地ですね
5. ©MIXI 5 今回お話しすること TIPSTAR を支える Cloud Spanner
6. ©MIXI 6 TIPSTAR とは 全国の公営競技（競輪/オートレース）にネット投票できるサービス
7. ©MIXI 7 Cloud Spanner とは NewSQL
8. ©MIXI 8 New SQL とは RDB のトランザクション特性（ACID特性）を持ちながら NoSQL のように水平スケール可能なDB
9. ©MIXI 9 なぜCloud Spannerが必要だったのか リリース前（開発初期）は Cloud SQL で開発されていたが、大量の r/w が予想されCloud Spanner へ 1. 定常的なユーザーアクセスに伴う r/w（read メイン） 2. レースの度に数万〜数十万件のデータの r/w（write メイン） 朝のレース（8時30分ごろ）から深夜のレース（0時前後）まで 10〜20 分間隔で発生
10. ©MIXI 10 なぜCloud Spannerが必要だったのか リリース前（開発初期）は Cloud SQL で開発されていたが、大量の r/w が予想されCloud Spanner へ 1. 定常的なユーザーアクセスに伴う r/w（read メイン） 2. レースの度に数万〜数十万件のデータの r/w（write メイン） 朝のレース（8時30分ごろ）から深夜のレース（0時前後）まで 10〜20 分間隔で発生 2024年末に開催された競輪グランプリ（1年で1番大きいレース） - 発生したデータ書き込み：100万件以上 - 車券データ - ミッションデータ - ボーナスデータ - etc…
11. ©MIXI Cloud Spanner すごい
12. ©MIXI 12 なぜRDB だと水平スケールが難しい？ RDB ・読み込み負荷：リードレプリカを増やして分散可能 ・書き込み負荷：マスター1台に集中
13. ©MIXI 13 なぜRDB だと水平スケールが難しい？ RDB ・読み込み負荷：リードレプリカを増やして分散可能 ・書き込み負荷：マスター1台に集中 書き込み用のノードを追加すると整合性を担保するための課題が発生 ・どの更新が最新なのか ・どのノードを正とするのか
14. ©MIXI 14 なぜRDB だと水平スケールが難しい？ RDB ・読み込み負荷：リードレプリカを増やして分散可能 ・書き込み負荷：マスター1台に集中 書き込み用のノードを追加すると整合性を担保するための課題が発生 ・どの更新が最新なのか ・どのノードを正とするのか 分散トランザクションなどで解決することも可能だが、運用が複雑に -> データの整合性の担保と水平スケールはトレードオフ
15. ©MIXI 15 Spannerの仕組み Split ・テーブル全体をキー範囲で自動的に分割したもの ・各 Split 単位でディスク上に配置され、レプリカを持つ ・Split 単位で読み書き可能 CREATE TABLE Singers( SingerId INT64 NOT NULL PRIMARY KEY, FirstName STRING(1024), LastName STRING(1024), SingerInfo BYTES(MAX), ); 図引用元: Google Cloud 公式ドキュメント『Schema and Data Model』
16. ©MIXI 16 Spannerの仕組み UPDATE Singers SET FirstName = “xxx” WHERE SingerId = 1 Split A Zone A (Key 1–3) Application Spanner Server Split B Zone A (Key 4–5) Split A Zone B Split A Zone C Split B Zone B Split C Zone C
17. ©MIXI 17 Spannerの仕組み UPDATE Singers SET FirstName = “xxx” WHERE SingerId = 1 Split A Zone A (Key 1–3) Application Spanner Server Split A Zone B Split A Zone C 1. Leader が対象キー範囲にロックを取得 2. Leader が更新を follower にブロードキャスト 3. follower はロックを取得できたかをリーダーに返す 4. 全体で過半数のロックが取得できた場合、 Leader がコミット可能と判断
18. ©MIXI 18 Spannerの仕組み TrueTime API 「現在時刻の不確実性（ ±ε）」を含む時間範囲を返す Spanner は全てノード間で時間のズレが ±7ms の範囲内に抑えられている。 → リーダーの Split が動作しているノードで取得した時刻 ±7ms の範囲内に、クラスタ内すべてのノードの実際 の時刻が収まっていることが保証されている ノードAの現在時刻 時間軸 ノードA ノードB ノードC ±7ms 以内 ノードBの現在時刻 ノードCの現在時刻
19. ©MIXI 19 Spannerの仕組み TrueTime API で取得した時間範囲のうち最も未来の時間が経過してからコミットすることで どのノードから見ても「すでに確定済み」として見える → ノード間の整合性問題を解決 ノードAの現在時刻 時間軸 ノードA ノードB ノードC ±7ms 以内 ノードBの現在時刻 ノードCの現在時刻 コミット
20. ©MIXI Cloud Spanner 面白そう https://techbookfest.org/product/2URkJbKFnJ9axX3vmmqNvK?productVariantID=8rXyaFRiBNwt9StPJFTk7c
21. ©MIXI 興味を惹かれた方は直接見に来てください Welcome Dive into MIXI