はじめに
以前、お仕事でマルチテナントSaaSの新規開発に途中参画することがありました。
その時は既に前任者が作っていたアーキテクチャにそこまで違和感なかったのですが、去年夏頃に「MySQLを使ってると会社が潰れる」っていう内容が少しSNSで流行り、少し私の考え方も変わってきました。
ちなみに、「MySQL使うとが会社潰れる」とは思いませんが、そもそもRLSを知らなかった自分がマルチテナントSaaSを構築することの方が会社を潰してしまいそうです。
３月にJAWS初登壇させていただく予定ができたので、この件をテーマにしようと思い、事前にQiitaでまとめていきたいと思います！
マルチテナントSaaSってなに？
複数（マルチ）の顧客（テナント）にサービスを提供するアーキテクチャの総称です。
１つのお客様のみに提供するSaaSでない限り、SaaS＝マルチテナントでは？と思ったのですが、下記サイトでは分けて考えるべきというような記載がありました。
ざっくりまとめると、SaaSはビジネスモデルとサービス提供の形態を表し、マルチテナントはそのSaaSを実現するための技術的な実装方法の一つと考えることを推奨しているようです。
マルチテナントの考慮点。
マルチテナントはSaaSの実装方法の一つだと紹介しましたが、マルチテナントを採用するかどうかの判断材料をいくつか紹介します。
コスト観点
シングルテナントと比べ、圧倒的に有利なのがコストメリットです。
一つのリソースを複数のテナントで利用するからですね。
マルチテナントが有利な点というのは、リソースおよび、運用にかかるコスト面が中心になってきそうです。
この後の比較は、すべてマルチテナントを考える上の難しさを表すものとなります。
可用性観点
すべてのテナントが１つのインフラを利用する為、１つの障害がすべての顧客に影響してしまうデメリットがあります。
また、顧客単位で求められる可用性のレベルが異なる場合、その実装方法が複雑になりそうですね。
パフォーマンス問題
総称して「うるさい隣人（ノイジーネイバー）問題」です。
浮遊リソースがない代わりに、一つのテナントが利用可能なリソースを多く占有してしまう可能性があります。
それぞれのテナントで利用できるリソースの上限を指定するなどもできますが、システムの複雑さを生み出しそうです。
コンプライアンス観点
システム外のところで、そもそも共有していいんだっけ？という議論もあります。
自社サービスならこちらで決めてしまえばよいですが、受託案件等の場合は要考慮です。
特に公共系の案件なんかはここらの制限や、データは日本国内のデータセンターに置くことみたいなのもありますね。
セキュリティ観点
マルチテナントはDBのようなストレージも共用する場合があります。
このケースで一番気にしないといけないのは、許可されていないテナント間のアクセスです。
特にこのケースでアクセスできてしまうのが顧客情報などの個人情報だったりするので、普通に会社が潰れます。
「MySQL使うとが会社潰れる」は、MySQLにはPostgreSQLにあるRow Level Security(RLS)がないことを言いたかったんだと思いますが、データのテナント分離方法はもちろんこれだけではないので、間違いです。
拡張性観点
新規顧客が増える時は、マルチテナントの方がテナント追加にかかるコストと時間が少なくて済みそうです。
特に小規模の顧客を大量に獲得していくような形態はマルチテナントな構成が最適かと思います。
まとめ
ビジネスとしてシステムを作る以上、コストパフォーマンスは無視できません。
マルチテナントの難しさは物理的な集約と論理的な分離をどうやっていくか？というところで色々な選択肢があるので、アーキテクチャを考えるは楽しそうですね！