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

Slide 1

Slide 1 text

マルチテナントの実現における DB設計とRLS ~ PostgreSQLを添えて ~ リンケージ×enechain toBシステム開発勉強会 ~ PostgreSQLからReactまで

Slide 2

Slide 2 text

マルチテナント      What is it?

Slide 3

Slide 3 text

マルチテナント  ↓  人類の夢  What is it?

Slide 4

Slide 4 text

ひとつのリソースで    複数のテナントを管理したい！  What is it?

Slide 5

Slide 5 text

What is it? Webサービスリソース

Slide 6

Slide 6 text

しかし…マルチテナントには    様々な課題がある…  What is it?

Slide 7

Slide 7 text

今日は様々な課題を乗り換えた    リンケージの設計の話をします  What is it?

Slide 8

Slide 8 text

1. 自己紹介  2. マルチテナントのアンチパターン  3. Row Level Securityと権限  4. マルチテナントの勘所  5. まとめ  あじぇんだ

Slide 9

Slide 9 text

1. 自己紹介  2. マルチテナントのアンチパターン  3. Row Level Securityと権限  4. マルチテナントの勘所  5. まとめ  あじぇんだ

Slide 10

Slide 10 text

自己紹介  曽根壮大（39歳）  Have Fun Tech LLC 代表社員  株式会社リンケージ CTO    そ　ね　　たけとも  ● 日本PostgreSQLユーザ会勉強会分科会担当  ● 3人の子供がいます（長女、次女、長男）  ● 技術的にはWeb/LL言語/RDBMSが好きです  ● コミュニティが好き

Slide 11

Slide 11 text

突然の宣伝   予防医療のリンケージ      ● リモートワークの不安を数値にするストレスチェック ● 女性の健康課題をサポートする ● リモートワーク、ちょっとした心配を相談できる安心をご提供  

Slide 12

Slide 12 text

1. 自己紹介  2. マルチテナントのアンチパターン  3. Row Level Securityと権限  4. 今、PostgreSQLを使うべきか  5. まとめ  あじぇんだ

Slide 13

Slide 13 text

マルチテナントのパターン      マルチテナントのアンチパターン

Slide 14

Slide 14 text

マルチテナントのアンチパターン https://docs.aws.amazon.com/ja_jp/whitepapers/latest/multi-tenant-saas-storage-strategies/saas-partitioning-models.html

Slide 15

Slide 15 text

Silo    金がかかる  マルチテナントのアンチパターン

Slide 16

Slide 16 text

Bridge    運用が大変  マルチテナントのアンチパターン

Slide 17

Slide 17 text

pool    コストメリット大きいけど  開発と障害対応が大変  マルチテナントのアンチパターン

Slide 18

Slide 18 text

SiloとBridge      マルチテナントのアンチパターン

Slide 19

Slide 19 text

テーブル変更→テナントの数 * ALTER    テーブル追加→テナントの数 * CREATE  マルチテナントのアンチパターン

Slide 20

Slide 20 text

● テナントが増えるとDBに変更・追加が必要なリリースの時間も伸びる  ● デプロイフロー、ロールバックなどが  複雑になりやすい  ● 監視対象が無限に増える  マルチテナントのアンチパターン

Slide 21

Slide 21 text

BridgeとPool      マルチテナントのアンチパターン

Slide 22

Slide 22 text

● 特定のユーザの利用が他のユーザにも影響を与える  ● 突然のテーブルロックでサービス障害  ● ホットスポット問題  マルチテナントのアンチパターン

Slide 23

Slide 23 text

金があるならSiloが楽    開発を考えるとBridgeが楽    運用を考えるとPoolが楽  マルチテナントのアンチパターン

Slide 24

Slide 24 text

楽という理由で選ぶな！！！      マルチテナントのアンチパターン

Slide 25

Slide 25 text

楽という理由で選ぶな！！！  ↓  サービス特性で選びましょう  マルチテナントのアンチパターン

Slide 26

Slide 26 text

● テナントの影響範囲はどこまで許す？  ● リリース頻度はどれくらい？  ● 個別カスタマイズはどこまでやる？  マルチテナントのアンチパターン

Slide 27

Slide 27 text

Slide 28

Slide 28 text

個別カスタマイズはやめましょう      マルチテナントのアンチパターン

Slide 29

Slide 29 text

突然！！！    共通DBを作り始める！！！  マルチテナントのアンチパターン

Slide 30

Slide 30 text

お父さん怒らないから    共通DBとテナントDBでJOINした人    手を上げなさい。  マルチテナントのアンチパターン

Slide 31

Slide 31 text

共通DBとテナントDBが    密結合すると地獄の始まり  マルチテナントのアンチパターン

Slide 32

Slide 32 text

1. 自己紹介  2. マルチテナントのアンチパターン  3. Row Level Securityと権限  4. 今、PostgreSQLを使うべきか  5. まとめ  あじぇんだ

Slide 33

Slide 33 text

リンケージは    Poolアーキテクチャ  Row Level Securityと権限

Slide 34

Slide 34 text

Poolを実現するために    一つのDBの中で、テナントidで分ける  Row Level Securityと権限

Slide 35

Slide 35 text

？？？「ifで分岐して出し分けます」      Row Level Securityと権限

Slide 36

Slide 36 text

？？？「ifで分岐して出し分けます」  ↓  バグで他店を出してしまう...  Row Level Securityと権限

Slide 37

Slide 37 text

そこで    Row Level Security  Row Level Securityと権限

Slide 38

Slide 38 text

Row Level Securityと権限 https://speakerdeck.com/soudai/pgcon2022-tutorial

Slide 39

Slide 39 text

Row Level Security（RLS）とは      RLSの概要と実際の活用方法

Slide 40

Slide 40 text

Row Level Security（RLS）とは  ↓  ロール単位で行のアクセスを制御する  RLSの概要と実際の活用方法

Slide 41

Slide 41 text

● テーブル単位はロール  ● 列単位はVIEW  ● 行単位はRLS  RLSの概要と実際の活用方法表示の制限 

Slide 42

Slide 42 text

RLSの概要と実際の活用方法テーブルA テーブルB ロールでアクセス制限

Slide 43

Slide 43 text

RLSの概要と実際の活用方法 ID NAME ROLE email 1 test admin [email protected] 2 hoge user [email protected] 3 fuga user [email protected] 4 foo admin [email protected] 5 bar user [email protected] 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;

Slide 44

Slide 44 text

RLSの概要と実際の活用方法 ID NAME ROLE email 1 test admin [email protected] 2 hoge user [email protected] 3 fuga user [email protected] 4 foo admin [email protected] 5 bar user [email protected] RLSで行を制限 SELECT *　FROM hoge; 例えばrole=userだけの結果を返す

Slide 45

Slide 45 text

● 今日の説明はこちらの記事を使います  ● 記事はすでに公開されています  ● RLSの基本的な実装方法を記載しています  詳細の使い方はこちら https://soudai.hatenablog.com/entry/2022/11/11/110825

Slide 46

Slide 46 text

デモ      Row Level Securityと権限

Slide 47

Slide 47 text

PostgreSQLのアカウントの    基本を学ぶ  Row Level Securityと権限

Slide 48

Slide 48 text

基本的なロールの概念から注意点まで広くまとまった素晴らしい資料。   今日は基本的なところしか説明しないので詳しく知りたい人は是非読みましょう。   あとはNTTデータさんに感謝しながら資料を読みましょう。  https://www.slideshare.net/nttdata-tech/postgresql-roles-osc2022-online-osaka-nttdata

Slide 49

Slide 49 text

アカウント作成と権限の基本 https://www.slideshare.net/nttdata-tech/postgresql-roles-osc2022-online-osaka-nttdata/18

Slide 50

Slide 50 text

ロール管理はセキュリティに直結      セキュリティにおけるGRANTの注意点

Slide 51

Slide 51 text

アプリケーションから    スーパーユーザを使うのはやめましょう  セキュリティにおけるGRANTの注意点

Slide 52

Slide 52 text

1. 自己紹介  2. マルチテナントのアンチパターン  3. Row Level Securityと権限  4. マルチテナントの勘所  5. まとめ  あじぇんだ

Slide 53

Slide 53 text

結論、設計がすべて      マルチテナントの勘所それは本当にそう 

Slide 54

Slide 54 text

テーブルロックを極力無くす      マルチテナントの勘所

Slide 55

Slide 55 text

テーブルロックを極力無くす  ↓  正規化して責務を分散する  マルチテナントの勘所

Slide 56

Slide 56 text

ここまでシンプルな実装を目指しましょうと強調してきましたが、「シンプルな実装」とはなんでしょうか。RDBMSを使う上でシンプルな実装のヒントは正規化です。正規化のコツは次のように表現できます。   ● 事実だけを保存する   ● 重複がない  ● 不整合がない  ● nullがない  これらを意識して設計していくとシンプルな設計に近づいていきます。  また正規化を行う際はここまで説明したとおり、種別と状態を考えることも重要です。ライフサイクルが違うデータは往々にして状態や種別が異なります。場合によってはnullになるようなカラムやUPDATEが必要なレコードは状態を持っている可能性があります。こうしたテーブルが見つかった場合はより深く考察する必要があります。   https://agilejourney.uzabase.com/entry/2022/07/28/103000

Slide 57

Slide 57 text

そして最後にINDEXの数にも注目しましょう。主キーは必ずありますが、外部キー制約とユニーク制約を除いたINDEXは主に検索のために必要なINDEXです。検索のWHEREの対象の数だけそのテーブルの責務が大きいといえ、4つ以上の INDEXが必要な場合も同じく深く考察する必要があります。隠れた状態をWHEREで絞り込んでいたり、種別をWHEREで絞り込んでいるケースが見えてくることがあります。   このようにシンプルな設計を目指して考察を繰り返していくことが重要です。そして同じくらい重要なこととして認識すべきはイージーとシンプルは両立できる、ということです。シンプルを目指し考察を繰り返すことがまさにデータモデリングであり、変化に強い設計につながっていくのです。   https://agilejourney.uzabase.com/entry/2022/07/28/103000

Slide 58

Slide 58 text

ビジネスモデル、ちゃんと考えておく      マルチテナントの勘所

Slide 59

Slide 59 text

ビジネスモデル、ちゃんと考えておく  ↓  ビジネスに口を突っ込む必要がある  マルチテナントの勘所選択したアーキテクチャは   ビジネスモデルにめちゃ依存する   CTO相当の人がいないと交渉が大変かも  

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

つまり初期設計が大事      マルチテナントの勘所

Slide 62

Slide 62 text

リンケージのアーキテクチャは    Bridge、Siloにも容易に変更可能  マルチテナントの勘所

Slide 63

Slide 63 text

腕の見せどころは    そういうところ  マルチテナントの勘所

Slide 64

Slide 64 text

1. 自己紹介  2. マルチテナントのアンチパターン  3. Row Level Securityと権限  4. 今、PostgreSQLを使うべきか  5. まとめ  あじぇんだ

Slide 65

Slide 65 text

まとめ

Slide 66

Slide 66 text

まとめ

Slide 67

Slide 67 text

自分たちの解きたい問題に合わせて    必要なアーキテクチャを選びましょう  まとめ

Slide 68

Slide 68 text

まとめ

Slide 69

Slide 69 text

シンプルな設計を    実現するのは腕の見せどころ  まとめ