builderscon 2019の発表資料です
RowLevelSecurityはマルチテナントの銀の弾丸になりうるのか#builderscon 2019 (20 min)
View Slide
⾃⼰紹介@yudppp株式会社HRBrain CTO好きな⾔葉: 冪等性Go / TypeScript / React○△□ - https://blog.yudppp.com/いつかSaaSのDevカンファレンス開くのが夢
⽬標評価管理クラウド
導⼊企業500社以上のHRTechのSaaSを週2リリースのペースで運⽤・改善を⾏なっています。
テナントとは• SaaSを利⽤する組織の単位のこと• HRBrainだと企業のこと• HRBrainだと企業の中にユーザーがいる• テナント間でのデータをやりとりはしない
SaaSのアーキテクチャ
アーキテクチャ• シングルテナントアーキテクチャ(ASP)• マルチテナントアーキテクチャ(SaaS)
シングルテナントアーキテクチャاۀ" اۀ# اۀ$اۀ"͚ "1αʔόʔاۀ"͚ %#اۀ"͚ Πϯϑϥاۀ#͚ "1αʔόʔاۀ#͚ %#اۀ#͚ Πϯϑϥاۀ$͚ "1αʔόʔاۀ$͚ %#اۀ$͚ Πϯϑϥ
シングルテナントのメリット• ⽐較的安全• 特定のテナントでアクセスが増えても場合に他の会社は影響を受けない• DB障害時の影響範囲がテナントごとになる
シングルテナントのデメリット• サーバーが完全に分かれているのでデプロイをテナントごとに⾏う必要がある• テナントごとにサーバーを⽤意するためコストがかかる• 単価がすごく⾼く、リリース頻度が少ないものであれば成り⽴つ
マルチテナントとは• ⼀つのシステムで複数利⽤者組織の情報やアプリケーションを管理することࢀߟ4BB4͚4-"ΨΠυϥΠϯܦࡁ࢈ۀলIUUQXBSQEBOEMHPKQJOGPOEMKQQJEXXXNFUJHPKQDPNNJUUFFNBUFSJBMTEPXOMPBEpMFTHDKQEG
マルチテナントアーキテクチャの種類• クラウド内での単純な仮想化により、ハードウェアのみを共有• 1つのアプリケーションで、テナントごとに異なるデータベースを使⽤• 1つのアプリケーションでデータベースを共有 (最も効率的な真のマルチテナンシー)ࢀߟ8FCΞϓϦέʔγϣϯΛϚϧνςφϯτܕ4BB4ιϦϡʔγϣϯʹม͢ΔIUUQTXXXJCNDPNEFWFMPQFSXPSLTKQDMPVEMJCSBSZDMNVMUJUFOBOUTBBTJOEFYIUNM
１つのクラウドサーバーに全ての企業اۀ" اۀ# اۀ$اۀ"͚ "1αʔόʔاۀ"͚ %#اۀ#͚ "1αʔόʔاۀ#͚ %#اۀ$͚ "1αʔόʔاۀ$͚ %#
１つのクラウドサーバーに全ての企業のメリット• 1テナントごとのスケールはしやすい• アプリケーションのリリースがテナントごとにできる(テナントごとに異なるVersionのアプリケーションがありえる)• 特定のテナントでアクセスが増えても場合に他の会社は影響を受けにくい
１つのクラウドサーバーに全ての企業のデメリット• テナントごとにアプリケーションサーバーやデータベースを個別に⽤意する必要がありコストが⾼い• デプロイをテナントごとに⾏う必要がある。• こちらをシングルアーキテクチャに含めてしまう場合もある
1つのアプリケーションで異なるDBを使⽤اۀ" اۀ# اۀ$اۀ"͚ %#"1αʔόʔاۀ#͚ %#اۀ$͚ %#
• 物理データベースは1つで論理データベースを分けているケースが多そう• アプリケーションは全てのテナントで同じサーバーを利⽤する• DBを⽔平分割している状態に近いのでDB⽬線ではスケールさせやすい1つのアプリケーションで異なるDBを使⽤のメリット
• DBのスキーマ変更のマイグレーションをテナントごとに⾏う必要がある1つのアプリケーションで異なるDBを使⽤のデメリット
1 つのアプリケーションでDBを共有اۀ" اۀ# اۀ$"1αʔόʔ%#
• 最も効率的な真のマルチテナンシー• スキーマの変更のマイグレーションの更新が⼀回で済む• インフラコストが⼀番安くなる1 つのアプリケーションでDBを共有のメリット
• DBに障害が起きた時に全テナントが影響を受ける• アプリケーションが複雑になりやすい• セキュリティに不安がある1 つのアプリケーションでDBを共有のデメリット
どんな不安があるのか• あるテナントが別のテナントのデータを⾒れてしまう可能性がある(data violation)
ձࣾ"ձࣾ#ձࣾ#ձࣾ$こんな感じのusersテーブルがあった時に
ձࣾ"ձࣾ#ձࣾ#ձࣾ$本来Where句を指定するところを4&-&$5'30.VTFST 8)&3&UFOBOU@JElձࣾ#z
ձࣾ"ձࣾ#ձࣾ#ձࣾ$Where句を指定忘れてしまうと4&-&$5'30.VTFST
ձࣾ"ձࣾ#ձࣾ#ձࣾ$Where句を指定忘れてしまうと4&-&$5'30.VTFSTͪΖΜશͯͷձࣾͷϝϯόʔใ͕औΕͯ͠·͏
複雑なアプリケーションになると絶対起きないとはいえない
これらのメリデメを受けて弊社のケースについて考える
導⼊企業500社以上のHRTechのSaaSを週2リリースのペースで運⽤・改善を⾏なっています。弊社のケース(再訂)
ビジネスモデル的に100社導⼊しただけでは会社が成り⽴たない
マルチテナントアーキテクチャ(再訂)• クラウド内での単純な仮想化により、ハードウェアのみを共有• 1つのアプリケーションで、テナントごとに異なるデータベースを使⽤• 1つのアプリケーションでデータベースを共有 (最も効率的な真のマルチテナンシー)
リリース後も継続的に機能追加によってスキーマ変更が必要になることがわかっていた
⽬標や評価の情報はもちろんとても⼤事 (⽬標が他の会社に漏れたら⼤問題)
全ての選択肢がなくなってしまった、、、
何かを犠牲にするしか、、
事例について調べて⾒た
Bit Journeyさん• apartment gemを利⽤• 1つのアプリケーションで、テナントごとに異なるデータベースを使⽤した場合に便利になるライブラリー？ࢀߟSBJMTENͰϚϧνςφϯτɾΣϒΞϓϦͷΛ͠·ͨ͠IUUQTHGYIBUFOBCMPHDPNFOUSZ
SmartHRさん• apartment gemからCitus Cloud(DBaaS)へ移⾏• マイグレーションは⾟くなりがち• なるほど:thinking:ࢀߟͭΒ͘ͳ͍ϚϧνςφϯγʔΛٻΊͯશͯݟͤ·͢ʂ4NBSU)3σʔλϕʔεҠߦϓϩδΣΫτͷཪଆIUUQTTQFBLFSEFDLDPNQVSJOUBJCVJMEFSTDPO
Viewを使ってマルチテナントを実現する⽅法• 最も効率的な真のマルチテナンシーをViewを使って実現する• テナント×テーブルごとにViewを作り権限管理を⾏う。• SELECT/UPDATE/DELETEに対してはViewから⾏う• INSERTはオリジナルのテーブルに⾏う必要があり安全かどうかはアプリケーションの実装依存になってしまう。
他にも⾊んな⼈に聞いたり、調べたりしているうちに⾒つけた
我らの銀の弾丸
Row Level Security
Row Level Securityとは• データベーステーブル内の⾏へのアクセスを制御できる• OracleやPostgreSQL(9.5以上)やSQLServer(13.x以上) などで実装されている• (以降RLSとする。)
権限ごとにRoleを作ってදऔక Ϧʔμʔ ϝϯόʔશͯݟ͑Δਓ ࣗͷνʔϜϝϯόʔͷΈݟ͑ΔਓࣗͷใͷΈݟ͑Δਓ
දऔక։ൃϦʔμʔ։ൃϝϯόʔӦۀこんな感じのusersテーブルがあった時に
දऔకӦۀ代表取締役のロールでアクセスすると4&-&$5'30.VTFST։ൃϦʔμʔ։ൃϝϯόʔ
දऔకӦۀ代表取締役のロールでアクセスするとશͯݟ͑Δ4&-&$5'30.VTFST։ൃϦʔμʔ։ൃϝϯόʔ
දऔకӦۀ開発リーダーのロールでアクセスすると4&-&$5'30.VTFST։ൃϦʔμʔ։ൃϝϯόʔ
දऔకӦۀ開発リーダーのロールでアクセスすると։ൃϝϯόʔͷใͷΈݟ͑Δ4&-&$5'30.VTFST։ൃϦʔμʔ։ൃϝϯόʔ
雑なQuery叩いても 権限範囲のデータしか⾒えなくて安全
マルチテナントに応⽤していく
テナントごとにRoleを作るاۀ"اۀ"ͷใͷΈݟ͑Δاۀ#اۀ#ͷใͷΈݟ͑Δاۀ$اۀ$ͷใͷΈݟ͑Δ
ձࣾ"ձࣾ#ձࣾ#ձࣾ$会社Bのロールでアクセスすると4&-&$5'30.VTFST
ձࣾ"ձࣾ#ձࣾ#ձࣾ$会社Bのロールでアクセスすると4&-&$5'30.VTFSTձࣾ#ͷϝϯόʔͷใͷΈݟ͑Δ
これは安⼼！
Tableの実体⾃体は全てのテナントで共通なのでマイグレーションも楽々
実際に導⼊してみました(PostgreSQL v10.4)
最初の実装や検証が⼤変そうだったけどなんとか導⼊しました。 (リリース三ヶ⽉前に⾃分以外のメンバーが1ヶ⽉くらいで諸々対応してくれた記憶)
どうやっているか①• 全てのテーブルにcompany_idのカラムを⽤意• サブドメインをテナントごとに追加する• Ex) mosquitone.hrbrain.jp
どうやっているか②• テナントごとにロールを⽤意• RLSを利⽤するテーブルに下記のPolicyを追加• テナントごとに別のコネクションを使う
そしてリリース1ヶ⽉半前
⼤量のデータを⼊れて確認していた時に問題が発覚した
GET /usersheets 1.8[sec]
pprofで諸々確認 (GoのPeformance計測ツール)
DBアクセスしている層が想定より数倍遅い
:thinking:
⼀度試しにRLSを使わないでみたら
レイテンシーが4分の1に
RLSを⼊れたことによって起きていることはわかった
ただ安全第⼀ RLSをやめる訳にはいかない
N+1とIndex周りの修正をして1秒以内にできたのでリリース
ただし根本解決はされないまま
リリース後の落ち着いたタイミングで再挑戦
検証結果
コネクションの使い⽅• RLSを利⽤していない時は全てのコネクションプールをまとめて管理していた。• RLSを利⽤時はテナントごとにロールを作っていた結果、コネクション管理が煩雑になっていて、そこでオーバーヘッドが⽣じていた。
リクエストごとにコネクションを張るように変更• Middlewareでコネクションを発⾏して、contextに詰める(本当はcontext使いたくない)• リクエストの終了時にClose
リクエストごとにコネクション貼ってみた結果• 遅かった特定のAPIで調査• 中央値、平均値を⾒る限りすごく速くなった。• 速くなったが詰まる時は詰まってそう。NFBO λΠϧ λΠϧ λΠϧ NBY#FGPSF NT NT NT NT T"GUFS NT NT NT NT NT
テナントごとのロールについて• RLSを適応したい全てのテーブルに下記のようなPOLICYを追加していた。• current_userを⽤いて、dbのユーザーをどの⾏に対して権限があるかを判断していた。
Indexについて• テーブルに下記のUNIQUE INDEXを貼っていた• リクエスト⾃体は• 叩いた時にindexが効いていなかった。
EXPLAIN結果• 全件検索してからFilterしている、、
EXPLAIN結果• company_idを必ずつけるようにすれば問題起きなかった。
USINGしている中⾝がよくない• ロール名に直接company_idではなくprefixをつけていたそのせいで⾃動でINDEX効いていなかった• もともと数字だけでやろうとしていたがロール名に数字始まりはInvalidだった。
ロールの作り⽅を変更した• 下記のようにcurrent_settingを利⽤したPOLICYを作成すればテナントごとのロールが不要だった。• またこの場合はリクエストごとに予めテナントをセットしておく必要がある
EXPLAIN結果• ちゃんとINDEXかかった！• どちらにしてもcompany_id始まりのINDEXを貼るべき
クエリーパフォーマンス• ある簡単なAPIを並列で実⾏した時に1.4倍くらい時間がかかるようになっていたλΠϧ λΠϧ λΠϧ3-4ͳ͠ NT NT NT3-4͋Γ NT NT NT
結論
銀の弾丸ではなかった。
マルチテナントにRLSを使うメリット• 安全に「最も効率的な真のマルチテナンシー」が実現できた。
マルチテナントにRLSを使うデメリット• コネクションの管理が煩雑になってしまった。• パフォーマンスが多少悪くなる。• 導⼊事例が少なく検証しないとわからないことが多い。
この先使う上での不安事項• DBを⽔平分割していく必要が出た場合にどうするか• マイクロサービスにしてDBも垂直分割していく想定はあるが、それでも増えた時にどうするか• 今利⽤されている⼈数の10倍、20倍のテナントが⼊ってきた場合に問題なくRLSが動くのか• テナントをまたがるユーザーを作りたくなった時にどうするか
まとめ• SaaS作る時にパフォーマンスをそこまでシビアに作る必要がないものを安全に作りたいのであればオススメ• データが増えた時にまた別の対策が必要
参考資料• SaaS 向け SLA ガイドライン - 経済産業省 (http://warp.da.ndl.go.jp/info:ndljp/pid/11094748/www.meti.go.jp/committee/materials/downloadfiles/g80207c05j.pdf)• マルチテナント SaaS データベース テナント パターン(https://docs.microsoft.com/ja-jp/azure/sql-database/saas-tenancy-app-design-patterns)• Web アプリケーションをマルチテナント型 SaaS ソリューションに変換する(https://www.ibm.com/developerworks/jp/cloud/library/cl-multitenantsaas/index.html)• PostgreSQL: Documentation: 11: 5.7. Row Security Policies (https://www.postgresql.org/docs/current/ddl-rowsecurity.html)• PostgreSQLのRow Level Securityを使ってマルチテナントデータを安全に扱う -HRBrain blog (https://times.hrbrain.co.jp/entry/postgresql-row-level-security)
yudppp
takesection
minorun365
etaroid
mraible
yoshikiiida
okamototakuyasr2
akkie76
knsg16
leveragestech
yoshimi0227
el_stoffel
sat
addyosmani
cherdarchuk
deanohume
kneath
jlugia
zakiwarfel
ufuk
productmarketing
aarron
ammeep
akosma
kastner