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
3
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
KubeCon + CloudNativeCon Japan 2025 Recap
ren510dev
1
290
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
1
100
Node-RED × MCP 勉強会 vol.1
1ftseabass
PRO
0
170
あなたの声を届けよう! 女性エンジニア登壇の意義とアウトプット実践ガイド #wttjp / Call for Your Voice
kondoyuko
4
500
Node-REDのFunctionノードでMCPサーバーの実装を試してみた / Node-RED × MCP 勉強会 vol.1
you
PRO
0
120
Lambda Web Adapterについて自分なりに理解してみた
smt7174
5
140
LangSmith×Webhook連携で実現するプロンプトドリブンCI/CD
sergicalsix
1
140
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
930
変化する開発、進化する体系時代に適応するソフトウェアエンジニアの知識と考え方(JaSST'25 Kansai)
mizunori
1
260
250627 関西Ruby会議08 前夜祭 RejectKaigi「DJ on Ruby Ver.0.1」
msykd
PRO
2
370
整頓のジレンマとの戦い〜Tidy First?で振り返る事業とキャリアの歩み〜/Fighting the tidiness dilemma〜Business and Career Milestones Reflected on in Tidy First?〜
bitkey
0
170
データプラットフォーム技術におけるメダリオンアーキテクチャという考え方/DataPlatformWithMedallionArchitecture
smdmts
5
670
Featured
See All Featured
Site-Speed That Sticks
csswizardry
10
670
Raft: Consensus for Rubyists
vanstee
140
7k
Code Review Best Practice
trishagee
69
18k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The Invisible Side of Design
smashingmag
300
51k
Building Applications with DynamoDB
mza
95
6.5k
Bash Introduction
62gerente
614
210k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
720
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
17
950
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. “⽇本のソフトウェアエンジニアを 憧れの職業へ”