Movatterモバイル変換

Takayuki Shimizukawa2021/7/3(土)DjangoCongress JP 2021RLSを用いたマルチテナント実装for Django1

@shimizukawa （清水川）● BeProud 取締役 / IT Architect○ 受託開発（Webアプリ / 機械学習 / 数理最適化）○ 自社サービス（connpass / PyQ / TRACERY）○ Python研修（Python基礎、Django、Pandas、その他）● 一般社団法人PyCon JP Association 会計理事○ PyCon JP 年次イベントの見守り○ Python Boot Camp 主催● Sphinx （コミッター休業中）おまえ誰よ / Who are you2

1版: 2010/5/282版: 2018/2/263版: 2021/7/301版: 2013/09/122版: 2017/10/202018/02/232020/02/271版: 2012/03/272版: 2015/02/273版: 2018/06/12執筆・翻訳した書籍3NEW年

このトークで紹介することマルチテナントアーキテクチャにおけるデータ分割アプローチのひとつ「共有アプローチ」を、PostgresのRow LevelSecurity (RLS)を用いてDjangoで安全に実現する方法を紹介します。またこの方法のメリット、デメリットを紹介します。4

アジェンダ● マルチテナント概要と課題● RLS: Row Level Security● DjangoではRLSどうなるの？● Djangoデモ● マルチテナントの開発と運用● まとめ● 参考資料5

マルチテナントの概要と課題6

マルチテナントの概要マルチテナントは、複数のテナント（チーム・組織）向けにサービスを提供するシステムです。● マルチテナント○ 1つのシステムに複数の顧客○ 顧客同士はデータが隔離されている○ 顧客同士は存在を知らない● 対義語: シングルテナント○ 1つのシステムに1つの顧客● それ以外:○ 複数の組織/グループがサービス上共存している7

Multi-Tenant Magic: Under the Covers of the Force.com dataArchitecture より8シングルテナントアーキテクチャユーザー企業ごとにデータベースを用意すると、データベースごとに管理者が必要となるため多くのシステム管理者が必要となり、またインフラの利用効率をあげることも難しい。マルチテナントアーキテクチャ全ユーザーが1つのインフラを共有するため管理者が少なくて済み、インフラの稼働効率も高くなる

マルチテナントの課題マルチテナントによって、運用時の費用を下げたい。しかし導入においては、テナント相互の情報分離、つまりデータ混濁が発生しないと保証されていることが大事です。「各プログラマが努力して実装する」戦略でもマルチテナントを実現できますが、努力だけでデータ混濁を避けるのはとても難しいです。9小難易度大大運用コスト小図は Web アプリケーションをマルチテナント型 SaaS ソリューションに変換するより引用

データ混濁提供するデータに期待しないデータが混ざり込むこと。ある顧客データのなかに別の顧客データが混ざりこむ等。● 個人情報が他の会社に見えちゃった● 売上額の集計値に他の会社の売上が混ざるマルチテナントアーキテクチャは、データ混濁を避けるための戦略10

マルチテナントアーキテクチャデータ混濁を避ける、複数のマルチテナントアーキテクチャが考案されています。マルチテナント SaaS パターン - Azure SQL Database | Microsoft Docs による分類では、マルチテナントは以下の3つのモデルに分けられる。1. スタンドアロンアプリ2. テナント単位データベース3. シャードマルチテナント図は Web アプリケーションをマルチテナント型 SaaS ソリューションに変換するより引用 11

マルチテナントアーキテクチャ1. スタンドアロンアプリ（DB分離、アプリ分離）○ DB・アプリもテナント毎に用意、ユーザーには極めて柔軟○ 運用コストはもっともかかる2. テナント単位データベース（DB分離/準分離、アプリ共有）○ DBは分けつつ、アプリは共有○ 運用は、アプリが分かれてない分楽○ （清水川所感：Web記事、スライド等ではこのパターンが多い）3. シャードマルチテナント（DB共有、アプリ共有）○ 同じDB・アプリのリソースを利用○ 最も効率的で「真のマルチテナント」と呼ばれる○ （今日紹介するのはこの方式）12

DB分割アプローチDB層でデータ混濁を避けるための、3つのDB分割アプローチ1. 分離(isolated)○ DBを分ける（≒ シングルテナントDB）2. 準分離(semi-isolated)○ DBは1つ、スキーマ/名前空間を分ける3. 共有(shared)○ DB/スキーマを分けない13

DB準分離アプローチの特徴● 1つのDBインスタンス内に、テナント別スキーマ○ ただし、一部のテーブルはPublicスキーマに配置● 仕組みが複雑で、通常運用が基本大変● アプリからは、スキーマ指定でDBにアクセス○ Django拡張いくつかあり採用例は多いが、保守停止時間はテナント数に比例● マイグレーション 30秒 x 5,000テナント = 42時間● 例: つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側DB準分離アプローチ14

DB共有アプローチDB共有アプローチの特徴● DB、スキーマが全体で1つ● 仕組みがシンプルで、通常運用が基本楽● WHERE句にTenantIDを指定必須○ Django拡張はあまりない採用を避ける理由● ミスると、データ混濁が発生○ ORM実装で、WHERE句付け忘れ○ 保守で生SQLを書いて、WHERE句付け忘れ● 直感に反する（分かれてないので、危なそう）15

DB分割アプローチ, Pros, Cons5000テナントの場合の例(django-easy-tenants · PyPIを元に追記)16

メリット● テーブルがスキーマ単位で分かれている（データ隔離）○ データ混濁が発生しにくい、複数スキーマのデータが混在しない● テナント個別の制御がしやすい○ バックアップ、リストアが容易○ 負荷が高いテナントがあるとき、DB分離に切り替えやすいデメリット● テーブルがスキーマ単位で分かれている（同じテーブルがたくさん）○ 各スキーマにマイグレーションが必要、時間はテナント数に比例● テナント個別の制御が必要○ 管理ユーザーが、テナントそれぞれに必要○ 管理コストがテナントの数だけかかるDB準分離アプローチのメリデメ17by @kashew_nuts

メリット● スキーマはひとつ、テーブル構造もひとつ● テナント個別の制御が不要○ 管理ユーザーは、テナントをまたいで管理しやすい○ 大抵はマルチテナントを忘れられるため、通常の実装 & 管理コストが低いデメリット● テナント個別の制御がしづらい○ バックアップ・リストア○ 特定テナントだけをメンテナンス○ 個別カスタマイズ■ 保守運用が死ぬので、どのアプローチでもやめましょう！JSON型カラムで回避● ミスった時のデータ混濁が致命的○ RLS: Row Level Security （行レベルアクセス制御）を導入しましょう！18DB共有アプローチのメリデメby @shimizukawa

DB準分離 vs DB共有19django-tenantsのような拡張も公開されてますし！コードレベルで変更が必要な箇所は分かってます！準分離はテナント数が増えた場合の運用コストが大きい！DB共有なら省リソース・省コストで、RLSを使えば安全に実現できるはず！（真のマルチテナント、やってみたいなー）

RLS: Row Level Securityとは● Row Level Security = 行レベルのアクセス制御● データベース層でデータ混濁を回避する技術○ SQL実行時に、アクセス権限のある行だけが返される○ WHERE句の指定は不要○ アクセス権限は、DB接続ユーザーまたはロールで決まるRLSを使えば、「シャードマルチテナント（真のマルチテナント）」を安全に実現できる21

customers テーブルid name tenant_id1 customer_1 22 customer_2 23 customer_3 34 customer_4 15 customer_5 36 customer_6 17 customer_7 18 customer_8 2tenant=2 でログイン2SELECT * FROM customers;RLS利用時は権限のある行のみ取得22SQL実行時に、WHERE句を指定しなくても、アクセス権限のある行だけが返される。tenant_id =2 の全行つまり、アプリ各所でのSQL書き換えが不要■User ■Role ■RLS

db=# CREATE TABLE rls (id SERIAL PRIMARY KEY, tenant_id INTEGER);db=> INSERT INTO rls (tenant_id) VALUES (1),(2),(3),(1),(2),(3);db=> SELECT * FROM rls;id | tenant_id----+-----------1 | 12 | 2...6 | 3(6 rows)実験用テーブル rls を作る24rls テーブルid tenant_id1 12 23 34 15 26 3

db=# CREATE ROLE “1”; -- tenant_id=1 の行のみアクセスできるROLE（予定）db=# SET ROLE “1”;db=> SELECT * FROM rls;ERROR: permission denied for table customersdb=# RESET ROLE; -- 接続ユーザー権限に戻る新規のロール "1" を作る25rls テーブルid tenant_id1 12 23 34 15 26 3Postgres users“db” User“1” RoleOKNG■User ■Role ■RLShttps://www.postgresql.org/docs/13/sql-set-role.htmlUSER でも ROLE でも可能ですが、ROLE で制御する理由は29スライド付近で説明します。PostgreSQLのロール - Qiita

db=# GRANT ALL ON ALL TABLES IN SCHEMA public TO ”1”;db=# GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO ”1”;db=# SET ROLE “1”;db=# SELECT * FROM rls;1 | 12 | 2...6 | 3(6 rows)db=# RESET ROLE; -- 接続ユーザー権限に戻る"1" に全権限を付ける26全権限があるので、全行見えてます rls テーブルid tenant_id1 12 23 34 15 26 3Postgres users“db” User“1” RoleOKOK■User ■Role ■RLShttps://www.postgresql.org/docs/13/sql-grant.html

db=# ALTER TABLE rls ENABLE ROW LEVEL SECURITY;db=# SET ROLE “1”;db=# SELECT * FROM rls;id | tenant_id----+-----------(0 rows)db=# RESET ROLE; -- 接続ユーザー権限に戻るrls テーブルのRLSを有効化27SELECT権限はありますが、RLSによって制限されましたrls テーブルid tenant_id1 12 23 34 15 26 3Postgres users“db” User“1” RoleOKOKだが1行も見えない■User ■Role ■RLShttps://www.postgresql.org/docs/13/ddl-rowsecurity.html

db=# CREATE POLICY foo ON rls USING(tenant_id::text = current_user);db=# SET ROLE “1”;db=# SELECT * FROM rls;id | tenant_id----+-----------1 | 14 | 1(2 rows)rls テーブルのRLSポリシーを設定28rls テーブルid tenant_id1 12 23 34 15 26 3Postgres users“db” User“1” RoleSELECT権限がありますが、RLSポリシーによって対象行が制限されましたOKOK■User ■Role ■RLShttps://www.postgresql.org/docs/13/ddl-rowsecurity.html

DjangoではRLSどうなるの？29

tenant=2 でログイン2dbで接続セッションでのSELECT30全行■User ■Role ■RLScustomers テーブルid name tenant_id1 customer_1 22 customer_2 23 customer_3 34 customer_4 15 customer_5 36 customer_6 17 customer_7 18 customer_8 2Postgres users“db” User“1” User“2” User“3” UserSELECT * FROM customers;

customers テーブルid name tenant_id1 customer_1 22 customer_2 23 customer_3 34 customer_4 15 customer_5 36 customer_6 17 customer_7 18 customer_8 2tenant=2 でログイン2Postgres users“db” User“1” User“2” User“3” Userセッション+RLSでのSELECT31CREATE POLICY foo ON customers USING(tenant_id::text = session_user);接続Userで制御■User ■Role ■RLSSELECT * FROM customers;tenant_id =2 の全行“2” で接続ログインユーザー毎に、DjangoからDBへ接続するユーザーを切り替えるのは難しい

tenant=2 でログイン2tenant_id =2 の全行Postgres users“db” User“1” Role“2” Role“3” Roledbで接続SET ROLE “2”;SELECT * FROM customers;RLS+Roleを介したSELECT（Role密結合）32CREATE POLICY foo ON customers USING(tenant_id::text = current_user);CREATE ROLE “1”;GRANT ALL ON TABLES ... TO “1”;GRANT ALL ON SCHEMAS ... TO “1”;-- 2, 3, 以下繰り返しcustomers テーブルid name tenant_id1 customer_1 22 customer_2 23 customer_3 34 customer_4 15 customer_5 36 customer_6 17 customer_7 18 customer_8 2Roleで制御■User ■Role ■RLSログインユーザーのHTTPリクエスト毎に、Roleを切り替えるMiddlewareを用意DjangoからDBへの接続は、常に1つのuser/passwordを使う

customers テーブルid name tenant_id1 customer_1 22 customer_2 23 customer_3 34 customer_4 15 customer_5 36 customer_6 17 customer_7 18 customer_8 2tenant=2 でログイン2Postgres users“db” User“tenantuser” Role“1” Role“2” Role“3” Roledbで接続SET ROLE “2”;SELECT * FROM customers;RLS+Roleを介したSELECT（Role疎結合）33CREATE POLICY foo ON customers USING(tenant_id::text = current_user);CREATE ROLE “tenantuser”;GRANT ALL ON TABLES … TO “tenantuser”;GRANT ALL ON SCHEMAS … TO “tenantuser”;GRANT “tenantuser” TO "1";-- 以下繰り返しRoleで制御■User ■Role ■RLSテナントのRoleは、代理ロール ”tenantuser” 経由でテーブルへのアクセスが許可されるtenant_id =2 の全行

Django でRLSを使うには（まとめ）34初期化1. 代理ROLEを作成し、全テーブルのGRANT ALLを設定2. テナント制御するテーブルにRLS有効化&ポリシー設定都度1. CREATE ROLE -- テナント追加時2. SET ROLE -- テナント判別し、ROLEを設定■User ■Role ■RLS

1 & 2. 初期化35db=# CREATE ROLE “tenantuser”;db=# GRANT ALL ON ALL TABLES IN SCHEMA public TO ”tenantuser”;db=# GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO ”tenantuser”;※ 初期化は、後から追加されたテーブルにも個別適用が必要■User ■Role ■RLS-- for <table> in <tables_to_enable_rls>:db=# ALTER TABLE <table> ENABLE ROW LEVEL SECURITY;db=# CREATE POLICY <name> ON <table> USING(tenant_id::text = current_user);1. 代理ROLEを作成し、全テーブルのGRANT ALLを設定2. テナント制御するテーブルにRLS有効化&ポリシー設定

3. CREATE ROLE -- テナント追加時36■User ■Role ■RLSfrom django.db.models.signals import post_savedef on_create_tenant(sender, instance, created, **kwargs):if created: # レコード追加時tenant_id = instance.tenant_idwith connection.cursor() as cursor:cursor.execute(f'CREATE ROLE "{tenant_id}"')cursor.execute(f'GRANT "tenantuser" TO "{tenant_id}"')# DBにレコードが追加された後に実行するpost_save.connect(on_create_tenant, sender=models.Tenant)https://docs.djangoproject.com/ja/3.2/topics/signals/

4. SET ROLE -- Middlewareでテナント判別37■User ■Role ■RLShttps://docs.djangoproject.com/ja/3.2/topics/http/middleware/class RlsMiddleware:def __init__(self, get_response):self.get_response = get_responsedef __call__(self, request):tenant_id = getattr(request.user, 'tenant_id', None)if tenant_id: # テナントに所属しないスーパー管理者はROLE設定不要with connection.cursor() as cursor:cursor.execute(f'SET ROLE "{tenant_id}" ')response = self.get_response(request)return response※ Middlewareを通らない処理では個別に SET ROLE が必要

4. SET ROLE -- Middleware以外でもテナント設定38■User ■Role ■RLShttps://django-tenants.readthedocs.io/en/latest/use.html#tenant_context@contextmanagerdef tenant_context(tenant_id: int):with connection.cursor() as cursor:cursor.execute(f'SET ROLE "{tenant_id}" ')Yieldcursor.execute(f'RESET ROLE')# バッチや非同期呼び出し等、Middlewareを経由しない場合の呼び出しdef some_command(tenant_id):with tenant_context(tenant_id): # SET ROLE されるobjs = DjangoModel.objects.all()

マルチテナントの開発と運用40

各RDBMSのRLS対応状況2021/05 調査時点● PostgreSQL 9.5 (2016) 以降○ https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html設定方法などのサンプルコード付き● SQL Server 2016 (13.x) 以降○ https://docs.microsoft.com/ja-jp/sql/relational-databases/security/row-level-security?view=sql-server-ver15● Oracle 10g Release 2 (10.2) (2005) 以降○ https://docs.oracle.com/cd/B19306_01/network.102/b14267/intro.htm● MySQL○ 8.0.25 (2021-05-11) では非対応● MariaDB○ 10.5.10 (2021-05-07) では非対応● SQLite○ 3.36.0 (2021-06-18) 非対応41

シングルテナント < マルチテナント● 分離 = シングルテナントの場合○ データ混濁について考える必要はない● 準分離（スキーマ分離）アプローチにした場合○ 共有するテーブルと分離するテーブルを管理し、専用のマイグレーション手順を用意● 共有アプローチにした場合○ 複数テナントを前提にしたテーブル設計が必要、RLSの導入が必要開発コスト42DB分離アプローチDB共有アプローチ

テナント数の増加に合わせて変化● 運用では、テナント数と管理対象が比例する● DBやアプリのインスタンス毎に担当者が必要運用コスト43少テナント数多大 DB数小大運用・改修コスト小大リソース小

● パフォーマンス測定を行い、N+1等は解消しておく○ RLSにより負荷は上がるため、顕著になってしまう● 作り方によってはINDEXが効かない等の問題がある○ ROLE名によるPOLICY適用時に、フルスキャンが発生等● コネクションをテナント別に用意しない（できない）○ そもそもDBの接続数上限を100や1000にするのは厳しい（デフォルトは10）○ Postgresは、コネクション生成コストが高いため、都度生成は負荷が高い○ データ混濁を避けたいとしても、コネクションは共有するしかない○ （なお、Djangoではテナント別コネクション利用がそもそも難しい）● Citus / Hyperscale の利用を検討する○ 特定カラムの値(tenant_id等)をキーに、ノード分散によって負荷分散できるRLS利用時の負荷対策44

● ROLE設定を忘れないようにする○ 今回のデモではMiddlewareで自動設定した○ 管理コマンド等Middlewareを通らないケースがあるので、そこは実装で努力○ ROLE設定を忘れると、「全テナントのデータが漏洩する」■ SET ROLEを忘れたら全部見れない方が安全 -> 今後の課題● バックアップをテナント単位でやりたい○ DB全体のバックアップで。リストア方法は要検討● PITR（Point In Time Recovery）をテナント単位でやりたい○ DB内の特定レコード群だけを巻き戻す、のは難しい。○ DB準分離ならスキーマ単位で独立のため、多少楽（publicスキーマのデータとの不整合に注意）● 高負荷テナントのリソースを隔離をしたい○ Citus / Hyperscale の利用を検討する■ 特定カラムの値(tenant_id等)をキーに、ノード分散によって負荷分散できるRLS/DB共有のデメリット対策45

まとめRLSのメリット● コンピューターリソースを無駄なく最大限活用できる● マイグーレーション時間が線形増加しない● テナント個別の特別対応をしない、という潔さRLSのデメリット● クエリ負荷の上昇は避けられない● テナント個別の特別対応が難しい○ バックアップ、リストア、負荷の高いテナントの分離46

参考資料マルチテナント● マルチテナント SaaS パターン - Azure SQL Database | Microsoft Docs● Web アプリケーションをマルチテナント型 SaaS ソリューションに変換する IBM Developer Works (WebArchive)● Multi-Tenant Data Architecture Microsoft (WebArchive)● つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018 - SpeakerDeckRLS● Django + RLS でマルチテナント - 清水川のScrapbox /デモコード https://github.com/shimizukawa/django-pg-rls● Using Postgres Row-Level Security in Python and Django● 行レベルのセキュリティ - SQL Server● PostgreSQL の行レベルのセキュリティを備えたマルチテナントデータの分離 | Amazon Web Services ブログ● Row Level Securityはマルチテナントの銀の弾丸になりうるのか / Row Level Security is silver bullet for multitenancy? - Speaker Deck● PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントのユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring)Citus (Hyperscale)● Azure Database for PostgreSQL Hyperscale(Citus)しらべてみた - Qiita● チュートリアル:マルチテナントデータベースを設計する - Hyperscale (Citus) - Azure Database for PostgreSQL | Microsoft Docs47

Special Thanks! -- Review頂いたみなさんBeProud slack● kashew, delhi09, susumuis, tell-k, mtb_beta, altnightdjango-ja Discord● hirokiky, tokibito48

and…Thanks for all attendees!!by @shimizukawa49

Movatterモバイル変換

Change Language

RLSを用いたマルチテナント実装 for Django

Embed presentation

Recommended

More Related Content

What's hot

Similar to RLSを用いたマルチテナント実装 for Django

More from Takayuki Shimizukawa

RLSを用いたマルチテナント実装 for Django