マルチテナントにおけるテナント増加時のデータベース分離の体験談例(仮)

2022/04/20 SaaS.tech #2
https://saas-tech.connpass.com/event/243204/
でのLT発表

Transcript

1. © 2022 Anti-Pattern Inc. All rights reserved. マルチテナントにおける テナント増加時の データベース分離の体験談例(仮) 2022/04/20 於 SaaS.tech #2 株式会社アンチパターン ⽮ヶ崎哲宏
2. ⾃⼰紹介 2 ⽮ヶ崎 哲宏(Akihiro YAGASAKI) 株式会社アンチパターン 取締役 CTO兼COO 役割︓⽇本のソフトウェアエンジニアを憧れの職業に するためのいろいろ 経歴︓アマゾン ウェブサービス ジャパン にて SaaSシニアパートナーソリューションアーキテクト Webメディア/SaaSベンダーにて技術責任者ボードメンバー ⼤⼿SIerグループ会社にて情シス責任者 アニメソングのコーラス など いまイチオシ︓AWS Well-Architected Framework SaaS Lens https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-lens.html 1975年⽣まれ
3. © 2022 Anti-Pattern Inc. All rights reserved. SaaSっていろいろ考えないといけないですよね〜 とくにマルチテナントは全部に関わってきて⼤変 特によくあるのはDBの分離のお話ですよね ということで、今⽇はDB分離のお話 どんなSaaSだったか、特性、規模 DB分離の種類 どう分離していたか、どんな問題があったか︖ どう解決したか︖ 本 ⽇ の お し な が き
4. © 2022 Anti-Pattern Inc. All rights reserved. SaaS っていろいろ考えないといけないですよね 認証・認可 請求 料⾦プラン 新機能追加 セキュリティ 可⽤性 性能 利⽤量計測 ユーザ体験 分析 移⾏
5. © 2022 Anti-Pattern Inc. All rights reserved. SaaS っていろいろ考えないといけないですよね ｘ テナント︕ 認証・認可 請求 料⾦プラン 新機能追加 セキュリティ 可⽤性 性能 利⽤量計測 ユーザ体験 マルチテナントの難しさ (もちろん場合によってはシングルテナントｘ複数もあり) 分析 移⾏
6. © 2022 Anti-Pattern Inc. All rights reserved. SaaS っていろいろ考えないといけないですよね ｘ テナント︕ 認証・認可 請求 料⾦プラン 新機能追加 セキュリティ 可⽤性 性能 利⽤量計測 ユーザ体験 マルチテナントの難しさ (もちろん場合によってはシングルテナントｘ複数もあり) 分析 移⾏ テナントの概念が⼊ると ⼀気にめんどくさくなる たとえば
7. © 2022 Anti-Pattern Inc. All rights reserved. SaaS っていろいろ考えないといけないですよね ｘ テナント︕ 認証・認可 請求 料⾦プラン 新機能追加 セキュリティ 可⽤性 性能 利⽤量計測 ユーザ体験 マルチテナントの難しさ (もちろん場合によってはシングルテナントｘ複数もあり) 分析 移⾏ テナントの概念が⼊ると ⼀気にめんどくさくなる メジャーな マルチテナントの 悩みポイント︖ たとえば
8. © 2022 Anti-Pattern Inc. All rights reserved. SaaS っていろいろ考えないといけないですよね ｘ テナント︕ 認証・認可 請求 料⾦プラン 新機能追加 セキュリティ 可⽤性 性能 利⽤量計測 ユーザ体験 マルチテナントの難しさ (もちろん場合によってはシングルテナントｘ複数もあり) 分析 移⾏ テナントの概念が⼊ると ⼀気にめんどくさくなる メジャーな マルチテナントの 悩みポイント︖ 今回はこのメジャーなとこ DBの分離についての体験談を お話しいたします たとえば
9. © 2022 Anti-Pattern Inc. All rights reserved. 今回のお話のSaaSの特徴 • 細かなデータのWriteが多い • 特にUpdateではなくInsertが多く、レコードがどんどん増えていく • それに伴い、更新のための少量のReadも多い • レポートやダッシュボード出⼒のための集計処理もある • ダッシュボードは毎回即時集計 • DBはPostgreSQL(当時9.6)のみ • OLTP/OLAP全部これ１つ • テナントごとにスキーマ(DBユーザ)にて分離 • スキーマ分離しているので物理DBサーバも複数インスタンスで構成 • １テナントでおおよそ100テーブル • テナント数は400くらいの時代 • 400のうち、特に⼤きいテナントは10くらい • 中くらいは300くらい • あとは利⽤量が少ない • その後⼀気にテナント数2,000くらいまで増加 • 1,500くらいは利⽤量少ない
10. © 2022 Anti-Pattern Inc. All rights reserved. 今回のお話のSaaSの特徴 • 細かなデータのWriteが多い • 特にUpdateではなくInsertが多く、レコードがどんどん増えていく • それに伴い、更新のための少量のReadも多い • レポートやダッシュボード出⼒のための集計処理もある • ダッシュボードは毎回即時集計 • DBはPostgreSQL(当時9.6)のみ • OLTP/OLAP全部これ１つ • テナントごとにスキーマ(DBユーザ)にて分離 • スキーマ分離しているので物理DBサーバも複数インスタンスで構成 • １テナントでおおよそ100テーブル • テナント数は400くらいの時代 • 400のうち、特に⼤きいテナントは10くらい • 中くらいは300くらい • あとは利⽤量が少ない • その後⼀気にテナント数2,000くらいまで増加 • 1,500くらいは利⽤量少ない 事業の⽴ち上げ時にはこれで⼗分 と思っていたものが 事業のステージによって変化していく︕
11. © 2022 Anti-Pattern Inc. All rights reserved. DB分離⽅法と出てきた問題 テナント テナント テナント テナント テナント テナント アプリケーション スキーマ分離あるある • コネクションプールがうまく使えない • DB接続コストが⼤きい • 項⽬追加などのスキーマ変更が⼤変 • テナント数分だけ全部にALTERや CREATEをしないといけない 新たな問題 • 終わらないVACUUM • １DBにテーブル数が多すぎて 循環しきらない • パフォーマンス劣化 ⼤きいテナントは1DB数社＆⼤ きいインスタンス 普通のテナントは1DB数⼗社＆ 中くらいのインスタンス 利⽤量少のテナントは1DB数百社＆ 中くらいのインスタンス
12. © 2022 Anti-Pattern Inc. All rights reserved. 主な原因を究明 テナント テナント アプリケーション いろいろ調べて パフォーマンス劣化の原因を特定 ・各テナントのデータアクセスのたびに、複数のブ ロックを読み書きすることになる ・PostgreSQLは8KB単位でI/Oするため、少 量のデータアクセスでもI/Oのオーバーヘッドが ⼤きい ・読み書きするブロックの数が増加すると、キャッ シュに乗り切らなくなる可能性が⾼まる ・結果として、ディスクI/Oが増加する ・そしてパフォーマンスが劣化する テナント テナント 8KB Block でも読むのは 1KBとか 8KB 8KB 8KB 8KB
13. © 2022 Anti-Pattern Inc. All rights reserved. 解決に向けたアプローチ テナント1 アプリケーション じゃあ、 テーブルをまとめちゃおうじゃないか︕ という作戦 ・近々読むであろうデータが⼀緒にブロックに⼊っ てくるかも ・キャッシュにのりやすい︕ ・結果として、ディスクI/Oが減る ・そしてパフォーマンスが改善する 1,000スキーマ分割と1スキーマ統合を検証した ところ、I/O量が最⼤5倍の差になった でも、まとめちゃっていいんだっけ︖ テナント2 テナント3 テナント4 テナントID テナント5 8KB
14. © 2022 Anti-Pattern Inc. All rights reserved. データ分離のいろいろ(RDB編) テナント1 テナント2 テナント3 テナント4 テナントID テナント5 テナント テナント テナント テナント テナント テナント テナント データベース分離 スキーマ(orテーブル)分離 ⾏分離 セキュリティ要件と性能 運⽤負荷などのバランスで選定
15. © 2022 Anti-Pattern Inc. All rights reserved. 実際に選んだ構成 テナント1 アプリケーション でも、⾏分離ってセキュリティ⼤丈夫ですか︖ SQL分間違えちゃったら、別のテナントにアクセ スしちゃうのでは︖︖︖ そこで採⽤したのが PostgreSQLのRow Level Security(RLS) WHERE句を間違えても、該当のテナントにし かアクセスできない︕そのため、テナント分離に 近いセキュリティレベルを確保できる︕ テナント2 テナント3 テナント4 テナントID テナント5 テナント6 テナント7 テナント8 テナント6 テナントID テナント7
16. © 2022 Anti-Pattern Inc. All rights reserved. データ移⾏ テナント1 アプリケーション すでにたくさんのテナントが使っているのに、ど うやってデータ移⾏するの︖ テナント単位でちょっとづつ停⽌して移⾏ 書き込み頻度が⾼く、データの⽋損が許されな い部分は「キュー」で吸収 お客様へのご連絡例︓ １︓００〜５︓００で最⼤３０分間アク セスできない時間が発⽣します テナント2 テナント3 テナント4 テナントID テナント5 テナント1 テナント2 テナント ごとに 同期 キュー 移⾏前のテナントは 旧DBへアクセス 移⾏後のテナントは 新DBへアクセス
17. © 2022 Anti-Pattern Inc. All rights reserved. おまけ テナント1 アプリケーション おまけ︓ でも、テーブルサイズが⼤きくなっちゃうからそ の点での性能とか⼤丈夫ですか︖ パーティショニング＋RLS＋パーティションプルー ニングでカバー︕ 今⽇はLTなので詳細は割愛しますｍｍ そもそもRDBだけでいくというのには無理があ るので、適材適所のデータベースやストレー ジを選んでいくのが良いと思います︕が、既 にお客様がたくさんいる既存SaaSの場合は 移⾏の難易度が上がるので悩ましいところで すね。。。 テナント2 テナント3 テナント4 テナントID テナント5 テナント6 テナント6 テナント7 テナント7 テナントID テナント7 パーティション パーティション
18. © 2022 Anti-Pattern Inc. All rights reserved. そんなこんなでこんなSaaSを創ってます 認証・認可 請求 料⾦プラン コミュニケーション セキュリティ 利⽤量計測 x テナント管理 分析 業務ロジック 業務ナレッジ ベストプラクティス SaaSの直接的な価値を⽣む ここの実装に集中︕ ここはまかせるのじゃ SaaSを作るためのSaaS まだクローズドα版です 鋭意作成中︕
19. Copyright © 2022 Anti-Pattern Inc. All rights reserved. “⽇本のソフトウェアエンジニアを 憧れの職業へ”