こんにちは、Anti-Patternの塚本です。
\n突然ですが、みなさんマルチテナントアーキテクチャってご存知ですか？
\n複数の企業データを扱うシステムで、リソースや運用コストなどを最大限に抑えて管理することなのですが、これを検討するのは大変です。
\nこのブログは、あるマルチテナントデータの見直しについて、書きたいと思います。
\nでは、どんな方法があるのでしょう？
\n1.複数データベース（単一インスタンス）
\nテナント毎に物理的にインスタンスを分けたデータベース管理
\n2.単一データベース＋複数スキーマ
\n物理的に一つのインスタンスで同じデータベースを、テナント毎にスキーマを分けて管理
\n3.単一データベース＋単一スキーマ
\n物理的に一つのインスタンスで全テナントを、一つのデータベースで管理する
\nそれぞれ、メリット・デメリットはありそうです。安全性を考えると、1.が良さそうですが、お金かかりそうですよね。また、システムの規模、テナント数とかにも左右されそうです。
\n私が携わったシステムでは、運用から数年でこんな症状が出始めました。
\nそのため、マルチテナントデータの見直しに着手しました。
\n私が行ったのは、“単一データベース＋複数スキーマ”から
\n“単一データベース＋単一スキーマ”への変更です。
\n複数スキーマの各テナントデータを、単一スキーマに統合するためにデータを寄せる必要があります。そのために、PostgreSQLの行セキュリティポリシー(ROW LEVEL SECURITY)を利用しました。
\n\n\n\n
CREATE POLICY sample_table_policy_view ON sample_table\n FOR ALL\n USING (tenant_id = current_tenant_id())\n WITH CHECK (tenant_id = current_tenant_id());\nALTER TABLE sample_table ENABLE ROW LEVEL SECURITY;\nsample_tableには、tenant_id(テナントID)を設定しています。tenant_idはDBのroleと一致します。
\nそのため、テナントが接続した際にコンテキストのユーザ名（CURRENT_USER）からtenant_idをcurrent_tenant_id()で取得しできる仕組みです。
\nUSINGでデータ参照のできる範囲、WITH CHECKでデータ参照、データ更新の範囲が抑止されています。
\nテナント毎のスキーマ定義で実現していたセキュリティは、これで担保することができました。
\n複数スキーマを統合したことにより、データ量が肥大化したテーブルが幾つかできてしまいました。トランザクションデータが格納されるテーブルのため、更にデータが増加する可能性が高く、Indexだけは対応できません。そのため、テーブルのパーティショニングを利用しました。
\n\n\nhttps://www.postgresql.jp/document/10/html/ddl-partitioning.html
\n
CREATE TABLE parent_table (\n id bigserial,\n tenant_id integer DEFAULT current_tenant_id() NOT NULL,\n partition_id SMALLINT NOT NULL DEFAULT partition_id(current_tenant_id())\n) PARTITION BY LIST (partition_id);\nPARTITION BY LISTで分割キーを指定します。
\nCREATE POLICY partition_parent_table_view ON parent_table\n FOR ALL\n USING (tenant_id = current_tenant_id() AND\n partition_id = partition_id(current_tenant_id()))\n WITH CHECK (tenant_id = current_tenant_id() AND\n partition_id = partition_id(current_tenant_id()));\nALTER TABLE parent_table ENABLE ROW LEVEL SECURITY;\nまずは、親テーブル（継承元）に対してRLSを設定します。
\n-- 分割キー(partition_id)の値(0)格納するテーブル\nCREATE TABLE partition_0 PARTITION OF parent_table FOR VALUES IN (0);\nCREATE POLICY partition_parent_table_view ON partition_0\n FOR ALL\n USING (tenant_id = current_tenant_id() AND\n partition_id = partition_id(current_tenant_id()))\n WITH CHECK (tenant_id = current_tenant_id() AND\n partition_id = partition_id(current_tenant_id()));\nALTER TABLE partition_0 ENABLE ROW LEVEL SECURITY;\n-- 分割キー(partition_id)の値(1)格納するテーブル\nCREATE TABLE partition_1 PARTITION OF parent_table FOR VALUES IN (1);\nCREATE POLICY partition_parent_table_view ON partition_1\n FOR ALL\n USING (tenant_id = current_tenant_id() AND\n partition_id = partition_id(current_tenant_id()))\n WITH CHECK (tenant_id = current_tenant_id() AND\n partition_id = partition_id(current_tenant_id()));\nALTER TABLE partition_1 ENABLE ROW LEVEL SECURITY;\n-- 分割キー(partition_id)の値(2)格納するテーブル\nCREATE TABLE partition_2 PARTITION OF parent_table FOR VALUES IN (2);\nCREATE POLICY partition_parent_table_view ON partition_2\n FOR ALL\n USING (tenant_id = current_tenant_id() AND\n partition_id = partition_id(current_tenant_id()))\n WITH CHECK (tenant_id = current_tenant_id() AND\n partition_id = partition_id(current_tenant_id()));\nALTER TABLE partition_2 ENABLE ROW LEVEL SECURITY;\n分割キー(partition_id)の値が0の値を格納する、子テーブル（partition_0）を作成しRLSを設定します。分割キーは、partition_id(current_tenant_id())で取得します。同様に分割キー(partition_id)の値が1、2 の値を格納する子テーブルをそれぞれ作成します。
\nこの設定で、tenant_idから計算されたパーティションテーブルへデータが格納されます。そして、行セキュリティポリシーに従ったデータ参照、更新が可能となりました。
\nデータを一つのスキーマに寄せた後が大変でした。
\n実行計画を確認すると、ビックリする程、高コストだったり、Indexが効かない、設定しても逆にコストがかかったりと。
\n多段に ネストするクエリの実行計画・・・
\n一部を除き、何とかなるところまでチューニングを繰り返しました。
\nさらっと書いてますが、大変でした！
\n大変でしたが、収穫も大きく。
\n後輩が実行計画を読んで、クエリをチューニングし、Index設定をしている姿はちょっと感動しました。（初めての挑戦です）
\nそれと、このブログに書いた内容は、PostgreSQL有識者の永安氏に大変お世話になってます。ありがとうございました！！
\n\n\n\n\n","url":"https://ghost.tech.anti-pattern.co.jp/postgresqlwoshi-tutamarutitenantodetawojian-zhi-su/","canonical_url":null,"uuid":"e8b68513-afc5-48d4-be9e-173264be745f","page":null,"codeinjection_foot":null,"codeinjection_head":null,"codeinjection_styles":null,"comment_id":"610e30223986b000013a5503","reading_time":3}},"pageContext":{"slug":"postgresqlwoshi-tutamarutitenantodetawojian-zhi-su"}}, "staticQueryHashes": ["176528973","2358152166","2561578252","2731221146","4145280475"]}