マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy

# 実装の参考資料
- https://soudai.hatenablog.com/entry/2022/11/11/110825

# 類似の登壇内容の動画
- https://www.youtube.com/watch?v=PXy6I-AeI-I

Transcript

1. マルチテナントの実現における DB設計とRLS ~ PostgreSQLを添えて ~ リンケージ×enechain toBシステム開発勉強会 ~ PostgreSQLからReactまで
2. マルチテナント
 
 
 What is it?
3. マルチテナント
 ↓
 人類の夢
 What is it?
4. ひとつのリソースで
 
 複数のテナントを管理したい！
 What is it?
5. What is it? Webサービス リソース
6. しかし…マルチテナントには
 
 様々な課題がある…
 What is it?
7. 今日は様々な課題を乗り換えた
 
 リンケージの設計の話をします
 What is it?
8. 1. 自己紹介
 2. マルチテナントのアンチパターン
 3. Row Level Securityと権限
 4. マルチテナントの勘所
 5. まとめ
 あじぇんだ
9. 1. 自己紹介
 2. マルチテナントのアンチパターン
 3. Row Level Securityと権限
 4. マルチテナントの勘所
 5. まとめ
 あじぇんだ
10. 自己紹介
 曽根 壮大（39歳）
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO
 
 そ　 ね　　 たけ とも
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます（長女、次女、長男）
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き
11. 突然の宣伝
 
予防医療のリンケージ
 
 
 • リモートワークの不安を数値にするストレスチェック • 女性の健康課題をサポートする • リモートワーク、ちょっとした心配を相談できる安心をご提供 

12. 1. 自己紹介
 2. マルチテナントのアンチパターン
 3. Row Level Securityと権限
 4. 今、PostgreSQLを使うべきか
 5. まとめ
 あじぇんだ
13. マルチテナントのパターン
 
 
 マルチテナントのアンチパターン
14. マルチテナントのアンチパターン https://docs.aws.amazon.com/ja_jp/whitepapers/latest/multi-tenant-saas-storage-strategies/saas-partitioning-models.html
15. Silo
 
 金がかかる
 マルチテナントのアンチパターン
16. Bridge
 
 運用が大変
 マルチテナントのアンチパターン
17. pool
 
 コストメリット大きいけど
 開発と障害対応が大変
 マルチテナントのアンチパターン
18. SiloとBridge
 
 
 マルチテナントのアンチパターン
19. テーブル変更→テナントの数 * ALTER
 
 テーブル追加→テナントの数 * CREATE
 マルチテナントのアンチパターン
20. • テナントが増えるとDBに変更・追加が必要な リリースの時間も伸びる
 • デプロイフロー、ロールバックなどが
 複雑になりやすい
 • 監視対象が無限に増える
 マルチテナントのアンチパターン
21. BridgeとPool
 
 
 マルチテナントのアンチパターン
22. • 特定のユーザの利用が他のユーザにも影響 を与える
 • 突然のテーブルロックでサービス障害
 • ホットスポット問題
 マルチテナントのアンチパターン
23. 金があるならSiloが楽
 
 開発を考えるとBridgeが楽
 
 運用を考えるとPoolが楽
 マルチテナントのアンチパターン
24. 楽という理由で選ぶな！！！
 
 
 マルチテナントのアンチパターン
25. 楽という理由で選ぶな！！！
 ↓
 サービス特性で選びましょう
 マルチテナントのアンチパターン
26. • テナントの影響範囲はどこまで許す？
 • リリース頻度はどれくらい？
 • 個別カスタマイズはどこまでやる？
 マルチテナントのアンチパターン
27. • テナントの影響範囲はどこまで許す？
 • リリース頻度はどれくらい？
 • 個別カスタマイズはどこまでやる？
 マルチテナントのアンチパターン
28. 個別カスタマイズはやめましょう
 
 
 マルチテナントのアンチパターン
29. 突然！！！
 
 共通DBを作り始める！！！
 マルチテナントのアンチパターン
30. お父さん怒らないから
 
 共通DBとテナントDBでJOINした人
 
 手を上げなさい。
 マルチテナントのアンチパターン
31. 共通DBとテナントDBが
 
 密結合すると地獄の始まり
 マルチテナントのアンチパターン
32. 1. 自己紹介
 2. マルチテナントのアンチパターン
 3. Row Level Securityと権限
 4. 今、PostgreSQLを使うべきか
 5. まとめ
 あじぇんだ
33. リンケージは
 
 Poolアーキテクチャ
 Row Level Securityと権限
34. Poolを実現するために
 
 一つのDBの中で、テナントidで分ける
 Row Level Securityと権限
35. ？？？「ifで分岐して出し分けます」
 
 
 Row Level Securityと権限
36. ？？？「ifで分岐して出し分けます」
 ↓
 バグで他店を出してしまう...
 Row Level Securityと権限
37. そこで
 
 Row Level Security
 Row Level Securityと権限
38. Row Level Securityと権限 https://speakerdeck.com/soudai/pgcon2022-tutorial
39. Row Level Security（RLS）とは
 
 
 RLSの概要と実際の活用方法
40. Row Level Security（RLS）とは
 ↓
 ロール単位で行のアクセスを制御する
 RLSの概要と実際の活用方法
41. • テーブル単位はロール
 • 列単位はVIEW
 • 行単位はRLS
 RLSの概要と実際の活用方法 表示の制限

42. RLSの概要と実際の活用方法 テーブルA テーブルB ロールでアクセス制限
43. RLSの概要と実際の活用方法 ID NAME ROLE email 1 test admin aa@hoge.com 2 hoge user bb@hoge.com 3 fuga user cc@hoge.com 4 foo admin dd@hoge.com 5 bar user ee@hoge.com Viewで列を制限 ID NAME ROLE 1 test admin 2 hoge user 3 fuga user 4 foo admin 5 bar user SELECT id,name,role FROM hoge;
44. RLSの概要と実際の活用方法 ID NAME ROLE email 1 test admin aa@hoge.com 2 hoge user bb@hoge.com 3 fuga user cc@hoge.com 4 foo admin dd@hoge.com 5 bar user ee@hoge.com RLSで行を制限 SELECT *　FROM hoge; 例えばrole=userだけの結果を返す
45. • 今日の説明はこちらの記事を使います
 • 記事はすでに公開されています
 • RLSの基本的な実装方法を記載しています
 詳細の使い方はこちら https://soudai.hatenablog.com/entry/2022/11/11/110825
46. デモ
 
 
 Row Level Securityと権限
47. PostgreSQLのアカウントの
 
 基本を学ぶ
 Row Level Securityと権限
48. 基本的なロールの概念から注意点まで広くまと まった素晴らしい資料。 
 今日は基本的なところしか説明しないので詳しく 知りたい人は是非読みましょう。 
 あとはNTTデータさんに感謝しながら資料を読 みましょう。
 https://www.slideshare.net/nttdata-tech/postgresql-roles-osc2022-online-osaka-nttdata
49. アカウント作成と権限の基本 https://www.slideshare.net/nttdata-tech/postgresql-roles-osc2022-online-osaka-nttdata/18
50. ロール管理はセキュリティに直結
 
 
 セキュリティにおけるGRANTの注意点
51. アプリケーションから
 
 スーパーユーザを使うのはやめましょう
 セキュリティにおけるGRANTの注意点
52. 1. 自己紹介
 2. マルチテナントのアンチパターン
 3. Row Level Securityと権限
 4. マルチテナントの勘所
 5. まとめ
 あじぇんだ
53. 結論、設計がすべて
 
 
 マルチテナントの勘所 それは本当にそう

54. テーブルロックを極力無くす
 
 
 マルチテナントの勘所
55. テーブルロックを極力無くす
 ↓
 正規化して責務を分散する
 マルチテナントの勘所
56. ここまでシンプルな実装を目指しましょうと強調してきました が、「シンプルな実装」とはなんでしょうか。RDBMSを使う上で シンプルな実装のヒントは正規化です。正規化のコツは次の ように表現できます。 
 • 事実だけを保存する 
 • 重複がない
 • 不整合がない
 • nullがない
 これらを意識して設計していくとシンプルな設計に近づいてい きます。
 また正規化を行う際はここまで説明したとおり、種別と状態を 考えることも重要です。ライフサイクルが違うデータは往々に して状態や種別が異なります。 場合によってはnullになるよう なカラムやUPDATEが必要なレコードは状態を持っている可 能性があります。こうしたテーブルが見つかった場合はより 深く考察する必要があります。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000
57. そして最後にINDEXの数にも注目しましょう。主キーは必ずあ りますが、外部キー制約とユニーク制約を除いたINDEXは主 に検索のために必要なINDEXです。検索のWHEREの対象の 数だけそのテーブルの責務が大きいといえ、4つ以上の INDEXが必要な場合も同じく深く考察する必要があります。隠 れた状態をWHEREで絞り込んでいたり、種別をWHEREで絞り 込んでいるケースが見えてくることがあります。 
 このようにシンプルな設計を目指して考察を繰り返していくこ とが重要です。そして同じくらい重要なこととして認識すべき はイージーとシンプルは両立できる、ということです。 シンプ ルを目指し考察を繰り返すことがまさにデータモデリングであ り、変化に強い設計につながっていくのです。 
 https://agilejourney.uzabase.com/entry/2022/07/28/103000
58. ビジネスモデル、ちゃんと考えておく
 
 
 マルチテナントの勘所
59. ビジネスモデル、ちゃんと考えておく
 ↓
 ビジネスに口を突っ込む必要がある
 マルチテナントの勘所 選択したアーキテクチャは 
 ビジネスモデルにめちゃ依存する 
 CTO相当の人がいないと交渉が大変かも 

60. 基本的に更新はスケールしないから
 
 うまいこと設計してくれ
 マルチテナントの勘所 例えば非同期処理

61. つまり初期設計が大事
 
 
 マルチテナントの勘所
62. リンケージのアーキテクチャは
 
 Bridge、Siloにも容易に変更可能
 マルチテナントの勘所
63. 腕の見せどころは
 
 そういうところ
 マルチテナントの勘所
64. 1. 自己紹介
 2. マルチテナントのアンチパターン
 3. Row Level Securityと権限
 4. 今、PostgreSQLを使うべきか
 5. まとめ
 あじぇんだ
65. まとめ
66. まとめ
67. 自分たちの解きたい問題に合わせて
 
 必要なアーキテクチャを選びましょう
 まとめ
68. まとめ
69. シンプルな設計を
 
 実現するのは腕の見せどころ
 まとめ
70. 例えば
 
 制約を使ってデータを守る
 まとめ
71. SimpleとEasyは両立する
 
 
 まとめ
72. ご清聴ありがとうございました
 
 
 まとめ