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
3.1k
マルチテナントにおけるテナント増加時のデータベース分離の体験談例(仮)
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
470
BtoB SaaS開発基礎講座
yaggy
0
130
テナント分離⽅式の使い分けとバランス (SaaS Engineering Meetup キックオフイベント)
yaggy
3
4.3k
AWS Proton を使って(もらって)快適な開発環境をあげよう(もらおう)!
yaggy
1
1.4k
Build Fullmesh VPN by VyOS with Serf! VyOS Users Meeting Japan #1 LT
yaggy
1
1.5k
Vyattaでやってます! Multi Region VPN on Amazon Web Services #jvum2014s
yaggy
1
580
Other Decks in Technology
See All in Technology
API提供者のためのMCPサーバー設計ガイド / MCP Server Design Guide for API Providers
yokawasa
0
230
Trust as Infrastructure
bcantrill
0
120
インサイト情報からどこまで自動化できるか試してみた
takas0522
0
120
PythonとLLMで挑む、 4コマ漫画の構造化データ化
esuji5
0
120
サプライチェーン攻撃に学ぶModuleの仕組みと セキュリティ対策
kuro_kurorrr
3
790
RailsのPostgreSQL 18対応
yahonda
0
1.2k
VCC 2025 Write-up
bata_24
0
140
Azure SynapseからAzure Databricksへ 移行してわかった新時代のコスト問題!?
databricksjapan
0
110
stupid jj tricks
indirect
0
7.5k
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用 / A low-effort Rails workflow that combines “Complex Data Processing × Static Sites”
hogelog
3
1.3k
Deep Research と NotebookLM を使い倒す!レガシーリプレイスの技術選定と学習コスト削減術
tet0h
0
2.8k
北海道の人に知ってもらいたいGISスポット / gis-spot-in-hokkaido-2025
sakaik
0
190
Featured
See All Featured
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.2k
Why Our Code Smells
bkeepers
PRO
339
57k
Designing for humans not robots
tammielis
254
25k
Documentation Writing (for coders)
carmenintech
75
5k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
YesSQL, Process and Tooling at Scale
rocio
173
14k
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. “⽇本のソフトウェアエンジニアを 憧れの職業へ”