マルチテナンシーはどう機能しますか？
マルチテナントのアプリケーションは、すべてのリクエストとすべてのレコードにテナント識別子を付けます。ユーザーがサインインすると、アプリはそのユーザーがどのテナントに属するかを特定し、以降のクエリ、バックグラウンドジョブ、メッセージをすべてそのテナントの範囲に絞ります。すべてのテナントは同じサーバー、多くの場合は同じデータベースの上で動くため、テナントあたりの運用コストを低く抑えられます。ただし、分離の強さは、それを強制するコードとデータベースの制約の強さで決まります。
主な分離モデルは？
| 分離モデル | 仕組み | トレードオフ |
|---|---|---|
| 共有データベースとテナントキー | すべての行がテナントIDを持ち、すべてのクエリがそれで絞り込む | 運用コストが最も安い反面、フィルターを1つ漏らすとテナント間でデータが漏れうる |
| テナントごとのスキーマ | 共有データベースの中で、テナントごとに専用のスキーマを持つ | 分離がより強い反面、マイグレーションがテナント数に比例して増える |
| テナントごとのデータベース | テナントごとに専用のデータベースまたはインスタンスを持つ | 分離が最も強い反面、コストと運用負荷が最も高い |
小さなチームにとってマルチテナンシーはなぜ重要ですか？
1つのブランドで1つの製品を運営しているなら、テナンシーを意識することはないかもしれません。重要になるのは、1つのインストールで複数のブランド、クライアントのワークスペース、環境を扱うようになった瞬間です。代理店や小規模なプラットフォームではよくあるケースです。Dittofeedのようなオープンソースのエンゲージメントツールはテナンシーをワークスペースとして扱います。セルフホストのカスタマーエンゲージメントの構成なら、インストール全体が自社のテナント境界になります。顧客のデータが、社外の誰ともインフラを共有しません。
マルチテナンシーでコンプライアンスはどう変わりますか？
共有型のSaaSでは、自社は何千ものテナントの1つにすぎず、ベンダーの分離、データレジデンシーの選択、契約に頼ることになります。セルフホストではそれが逆転します。自社が運用者になるため、テナントごとの分離、保存期間、監査ログを設定するのも、それを証明するのも自社です。どちらのモデルも、それ自体でコンプライアンスを満たすわけではありません。GDPRの義務は、アーキテクチャではなくデータについて回ります。