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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

⾃⼰紹介 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年⽣まれ

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

© 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くらいは利⽤量少ない

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2022 Anti-Pattern Inc. All rights reserved. DB分離⽅法と出てきた問題テナントテナントテナントテナントテナントテナントアプリケーションスキーマ分離あるある • コネクションプールがうまく使えない • DB接続コストが⼤きい • 項⽬追加などのスキーマ変更が⼤変 • テナント数分だけ全部にALTERや CREATEをしないといけない新たな問題 • 終わらないVACUUM • １DBにテーブル数が多すぎて循環しきらない • パフォーマンス劣化⼤きいテナントは1DB数社＆⼤きいインスタンス普通のテナントは1DB数⼗社＆中くらいのインスタンス利⽤量少のテナントは1DB数百社＆中くらいのインスタンス

Slide 12

Slide 12 text

© 2022 Anti-Pattern Inc. All rights reserved. 主な原因を究明テナントテナントアプリケーションいろいろ調べてパフォーマンス劣化の原因を特定・各テナントのデータアクセスのたびに、複数のブロックを読み書きすることになる・PostgreSQLは8KB単位でI/Oするため、少量のデータアクセスでもI/Oのオーバーヘッドが⼤きい・読み書きするブロックの数が増加すると、キャッシュに乗り切らなくなる可能性が⾼まる・結果として、ディスクI/Oが増加する・そしてパフォーマンスが劣化するテナントテナント 8KB Block でも読むのは 1KBとか 8KB 8KB 8KB 8KB

Slide 13

Slide 13 text

© 2022 Anti-Pattern Inc. All rights reserved. 解決に向けたアプローチテナント1 アプリケーションじゃあ、テーブルをまとめちゃおうじゃないか︕ という作戦・近々読むであろうデータが⼀緒にブロックに⼊ってくるかも・キャッシュにのりやすい︕ ・結果として、ディスクI/Oが減る・そしてパフォーマンスが改善する 1,000スキーマ分割と1スキーマ統合を検証したところ、I/O量が最⼤5倍の差になったでも、まとめちゃっていいんだっけ︖ テナント2 テナント3 テナント4 テナントID テナント5 8KB

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 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

Slide 16

Slide 16 text

© 2022 Anti-Pattern Inc. All rights reserved. データ移⾏テナント1 アプリケーションすでにたくさんのテナントが使っているのに、どうやってデータ移⾏するの︖ テナント単位でちょっとづつ停⽌して移⾏書き込み頻度が⾼く、データの⽋損が許されない部分は「キュー」で吸収お客様へのご連絡例︓ １︓００〜５︓００で最⼤３０分間アクセスできない時間が発⽣しますテナント2 テナント3 テナント4 テナントID テナント5 テナント1 テナント2 テナントごとに同期キュー移⾏前のテナントは旧DBへアクセス移⾏後のテナントは新DBへアクセス

Slide 17

Slide 17 text

© 2022 Anti-Pattern Inc. All rights reserved. おまけテナント1 アプリケーションおまけ︓ でも、テーブルサイズが⼤きくなっちゃうからその点での性能とか⼤丈夫ですか︖ パーティショニング＋RLS＋パーティションプルーニングでカバー︕ 今⽇はLTなので詳細は割愛しますｍｍそもそもRDBだけでいくというのには無理があるので、適材適所のデータベースやストレージを選んでいくのが良いと思います︕が、既にお客様がたくさんいる既存SaaSの場合は移⾏の難易度が上がるので悩ましいところですね。。。テナント2 テナント3 テナント4 テナントID テナント5 テナント6 テナント6 テナント7 テナント7 テナントID テナント7 パーティションパーティション

Slide 18

Slide 18 text

Slide 19

Slide 19 text