Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マルチテナントにおけるテナント増加時のデータベース分離の体験談例(仮)
Search
YAGASAKI Akihiro
April 20, 2022
Technology
3
3k
マルチテナントにおけるテナント増加時のデータベース分離の体験談例(仮)
2022/04/20 SaaS.tech #2
https://saas-tech.connpass.com/event/243204/
でのLT発表
YAGASAKI Akihiro
April 20, 2022
Tweet
Share
More Decks by YAGASAKI Akihiro
See All by YAGASAKI Akihiro
AWS CDK を活用した 大量 AWS アカウントへのプロビジョニング例 〜 SaaSus Platform の場合 〜 於 JAWS-UG CDK支部 #17
yaggy
1
450
BtoB SaaS開発基礎講座
yaggy
0
100
テナント分離⽅式の使い分けとバランス (SaaS Engineering Meetup キックオフイベント)
yaggy
2
4.1k
AWS Proton を使って(もらって)快適な開発環境をあげよう(もらおう)!
yaggy
1
1.3k
Build Fullmesh VPN by VyOS with Serf! VyOS Users Meeting Japan #1 LT
yaggy
1
1.4k
Vyattaでやってます! Multi Region VPN on Amazon Web Services #jvum2014s
yaggy
1
570
Other Decks in Technology
See All in Technology
How Community Opened Global Doors
hiroramos4
PRO
1
120
フィンテック養成勉強会#54
finengine
0
180
BigQuery Remote FunctionでLooker Studioをインタラクティブ化
cuebic9bic
3
320
AIとともに進化するエンジニアリング / Engineering-Evolving-with-AI_final.pdf
lycorptech_jp
PRO
0
110
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
110
Yamla: Rustでつくるリアルタイム性を追求した機械学習基盤 / Yamla: A Rust-Based Machine Learning Platform Pursuing Real-Time Capabilities
lycorptech_jp
PRO
3
130
25分で解説する「最小権限の原則」を実現するための AWS「ポリシー」大全 / 20250625-aws-summit-aws-policy
opelab
9
1.2k
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
4
740
あなたの声を届けよう! 女性エンジニア登壇の意義とアウトプット実践ガイド #wttjp / Call for Your Voice
kondoyuko
4
470
より良いプロダクトの開発を目指して - 情報を中心としたプロダクト開発 #phpcon #phpcon2025
bengo4com
1
3.1k
Node-REDのFunctionノードでMCPサーバーの実装を試してみた / Node-RED × MCP 勉強会 vol.1
you
PRO
0
120
PostgreSQL 18 cancel request key長の変更とRailsへの関連
yahonda
0
120
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
173
14k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
4 Signs Your Business is Dying
shpigford
184
22k
KATA
mclloyd
29
14k
GraphQLとの向き合い方2022年版
quramy
48
14k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
5
220
Git: the NoSQL Database
bkeepers
PRO
430
65k
Become a Pro
speakerdeck
PRO
28
5.4k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
700
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Transcript
© 2022 Anti-Pattern Inc. All rights reserved. マルチテナントにおける テナント増加時の データベース分離の体験談例(仮)
2022/04/20 於 SaaS.tech #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年⽣まれ
© 2022 Anti-Pattern Inc. All rights reserved. SaaSっていろいろ考えないといけないですよね〜 とくにマルチテナントは全部に関わってきて⼤変 特によくあるのはDBの分離のお話ですよね
ということで、今⽇はDB分離のお話 どんなSaaSだったか、特性、規模 DB分離の種類 どう分離していたか、どんな問題があったか︖ どう解決したか︖ 本 ⽇ の お し な が き
© 2022 Anti-Pattern Inc. All rights reserved. SaaS っていろいろ考えないといけないですよね 認証・認可
請求 料⾦プラン 新機能追加 セキュリティ 可⽤性 性能 利⽤量計測 ユーザ体験 分析 移⾏
© 2022 Anti-Pattern Inc. All rights reserved. SaaS っていろいろ考えないといけないですよね x
テナント︕ 認証・認可 請求 料⾦プラン 新機能追加 セキュリティ 可⽤性 性能 利⽤量計測 ユーザ体験 マルチテナントの難しさ (もちろん場合によってはシングルテナントx複数もあり) 分析 移⾏
© 2022 Anti-Pattern Inc. All rights reserved. SaaS っていろいろ考えないといけないですよね x
テナント︕ 認証・認可 請求 料⾦プラン 新機能追加 セキュリティ 可⽤性 性能 利⽤量計測 ユーザ体験 マルチテナントの難しさ (もちろん場合によってはシングルテナントx複数もあり) 分析 移⾏ テナントの概念が⼊ると ⼀気にめんどくさくなる たとえば
© 2022 Anti-Pattern Inc. All rights reserved. SaaS っていろいろ考えないといけないですよね x
テナント︕ 認証・認可 請求 料⾦プラン 新機能追加 セキュリティ 可⽤性 性能 利⽤量計測 ユーザ体験 マルチテナントの難しさ (もちろん場合によってはシングルテナントx複数もあり) 分析 移⾏ テナントの概念が⼊ると ⼀気にめんどくさくなる メジャーな マルチテナントの 悩みポイント︖ たとえば
© 2022 Anti-Pattern Inc. All rights reserved. SaaS っていろいろ考えないといけないですよね x
テナント︕ 認証・認可 請求 料⾦プラン 新機能追加 セキュリティ 可⽤性 性能 利⽤量計測 ユーザ体験 マルチテナントの難しさ (もちろん場合によってはシングルテナントx複数もあり) 分析 移⾏ テナントの概念が⼊ると ⼀気にめんどくさくなる メジャーな マルチテナントの 悩みポイント︖ 今回はこのメジャーなとこ DBの分離についての体験談を お話しいたします たとえば
© 2022 Anti-Pattern Inc. All rights reserved. 今回のお話のSaaSの特徴 • 細かなデータのWriteが多い
• 特にUpdateではなくInsertが多く、レコードがどんどん増えていく • それに伴い、更新のための少量のReadも多い • レポートやダッシュボード出⼒のための集計処理もある • ダッシュボードは毎回即時集計 • DBはPostgreSQL(当時9.6)のみ • OLTP/OLAP全部これ1つ • テナントごとにスキーマ(DBユーザ)にて分離 • スキーマ分離しているので物理DBサーバも複数インスタンスで構成 • 1テナントでおおよそ100テーブル • テナント数は400くらいの時代 • 400のうち、特に⼤きいテナントは10くらい • 中くらいは300くらい • あとは利⽤量が少ない • その後⼀気にテナント数2,000くらいまで増加 • 1,500くらいは利⽤量少ない
© 2022 Anti-Pattern Inc. All rights reserved. 今回のお話のSaaSの特徴 • 細かなデータのWriteが多い
• 特にUpdateではなくInsertが多く、レコードがどんどん増えていく • それに伴い、更新のための少量のReadも多い • レポートやダッシュボード出⼒のための集計処理もある • ダッシュボードは毎回即時集計 • DBはPostgreSQL(当時9.6)のみ • OLTP/OLAP全部これ1つ • テナントごとにスキーマ(DBユーザ)にて分離 • スキーマ分離しているので物理DBサーバも複数インスタンスで構成 • 1テナントでおおよそ100テーブル • テナント数は400くらいの時代 • 400のうち、特に⼤きいテナントは10くらい • 中くらいは300くらい • あとは利⽤量が少ない • その後⼀気にテナント数2,000くらいまで増加 • 1,500くらいは利⽤量少ない 事業の⽴ち上げ時にはこれで⼗分 と思っていたものが 事業のステージによって変化していく︕
© 2022 Anti-Pattern Inc. All rights reserved. DB分離⽅法と出てきた問題 テナント テナント
テナント テナント テナント テナント アプリケーション スキーマ分離あるある • コネクションプールがうまく使えない • DB接続コストが⼤きい • 項⽬追加などのスキーマ変更が⼤変 • テナント数分だけ全部にALTERや CREATEをしないといけない 新たな問題 • 終わらないVACUUM • 1DBにテーブル数が多すぎて 循環しきらない • パフォーマンス劣化 ⼤きいテナントは1DB数社&⼤ きいインスタンス 普通のテナントは1DB数⼗社& 中くらいのインスタンス 利⽤量少のテナントは1DB数百社& 中くらいのインスタンス
© 2022 Anti-Pattern Inc. All rights reserved. 主な原因を究明 テナント テナント
アプリケーション いろいろ調べて パフォーマンス劣化の原因を特定 ・各テナントのデータアクセスのたびに、複数のブ ロックを読み書きすることになる ・PostgreSQLは8KB単位でI/Oするため、少 量のデータアクセスでもI/Oのオーバーヘッドが ⼤きい ・読み書きするブロックの数が増加すると、キャッ シュに乗り切らなくなる可能性が⾼まる ・結果として、ディスクI/Oが増加する ・そしてパフォーマンスが劣化する テナント テナント 8KB Block でも読むのは 1KBとか 8KB 8KB 8KB 8KB
© 2022 Anti-Pattern Inc. All rights reserved. 解決に向けたアプローチ テナント1 アプリケーション
じゃあ、 テーブルをまとめちゃおうじゃないか︕ という作戦 ・近々読むであろうデータが⼀緒にブロックに⼊っ てくるかも ・キャッシュにのりやすい︕ ・結果として、ディスクI/Oが減る ・そしてパフォーマンスが改善する 1,000スキーマ分割と1スキーマ統合を検証した ところ、I/O量が最⼤5倍の差になった でも、まとめちゃっていいんだっけ︖ テナント2 テナント3 テナント4 テナントID テナント5 8KB
© 2022 Anti-Pattern Inc. All rights reserved. データ分離のいろいろ(RDB編) テナント1 テナント2
テナント3 テナント4 テナントID テナント5 テナント テナント テナント テナント テナント テナント テナント データベース分離 スキーマ(orテーブル)分離 ⾏分離 セキュリティ要件と性能 運⽤負荷などのバランスで選定
© 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
© 2022 Anti-Pattern Inc. All rights reserved. データ移⾏ テナント1 アプリケーション
すでにたくさんのテナントが使っているのに、ど うやってデータ移⾏するの︖ テナント単位でちょっとづつ停⽌して移⾏ 書き込み頻度が⾼く、データの⽋損が許されな い部分は「キュー」で吸収 お客様へのご連絡例︓ 1︓00〜5︓00で最⼤30分間アク セスできない時間が発⽣します テナント2 テナント3 テナント4 テナントID テナント5 テナント1 テナント2 テナント ごとに 同期 キュー 移⾏前のテナントは 旧DBへアクセス 移⾏後のテナントは 新DBへアクセス
© 2022 Anti-Pattern Inc. All rights reserved. おまけ テナント1 アプリケーション
おまけ︓ でも、テーブルサイズが⼤きくなっちゃうからそ の点での性能とか⼤丈夫ですか︖ パーティショニング+RLS+パーティションプルー ニングでカバー︕ 今⽇はLTなので詳細は割愛しますmm そもそもRDBだけでいくというのには無理があ るので、適材適所のデータベースやストレー ジを選んでいくのが良いと思います︕が、既 にお客様がたくさんいる既存SaaSの場合は 移⾏の難易度が上がるので悩ましいところで すね。。。 テナント2 テナント3 テナント4 テナントID テナント5 テナント6 テナント6 テナント7 テナント7 テナントID テナント7 パーティション パーティション
© 2022 Anti-Pattern Inc. All rights reserved. そんなこんなでこんなSaaSを創ってます 認証・認可 請求
料⾦プラン コミュニケーション セキュリティ 利⽤量計測 x テナント管理 分析 業務ロジック 業務ナレッジ ベストプラクティス SaaSの直接的な価値を⽣む ここの実装に集中︕ ここはまかせるのじゃ SaaSを作るためのSaaS まだクローズドα版です 鋭意作成中︕
Copyright © 2022 Anti-Pattern Inc. All rights reserved. “⽇本のソフトウェアエンジニアを 憧れの職業へ”