マルチテナントを想定したアーキテクチャを考える際のメモ
マルチテナントの目的
同じシステムアーキテクチャを複数の顧客へ提供することで安価にシステム導入を行い、ストックビジネスを展開できる。
マルチテナント提供モデル
リソース共有モデル
各テナントでリソースを共有する。
デパートにおけるテナント。階段やエレベーター、トイレなどのリソースは共有される。
キャンプ場。水道、トイレは共有される。
レンタルサーバの共有サーバ方式。CPU,メモリは共有される。
リソース独立モデル
各テナントごとにリソースを完全に分離する。
分譲住宅。
RDB
単一DBか分散DBか
単一DB
- パーティションキーで分ける
テナント別DB
- テナントごとにDBを分ける
Pros/Cons
| RDB | 単一 | テナント別 | コメント |
|---|---|---|---|
| テナントキー | パーティションキー | -(上流で定義) | 単一DBでは、常にテナントキーの考慮が必要。 |
| 開発コスト | 中〜高 | 低〜中 | 単一DBにおける開発（設計・実装等）はマルチテナントアーキテクチャをDBに実装する点で高コスト。 |
| マスタデータ管理コスト | 低 | 低〜高 | テナント別DBにおけるマスタデータは、マスタースレーブのような管理形態を取れればコストは下げられる余地がある。 |
運用
| 単一 | テナント別 | コメント | |
|---|---|---|---|
| テナント追加の難易度 | 低〜中 | 低 | 何れの場合も定型化。 |
| データ更新 | 高 | 低 | 単一DBでは、常に他テナントの影響を考える。 |
所感
テナント別DB一択。
ピンポイントだが、Aurora Serverlessを用いれば、テナント別DBとしつつ、使われなければColdスタンバイ、使われても従量課金でコストも下げられる。
結論ありきということでもないが、１DB内でマルチテナントを実現する、というのは札束で解決できるところをわざわざアプリケーション開発に負荷を掛けて解決する、というふうに見えてしまう。
WEB
サブドメイン＋LBで分ける。
テナントキー
サブドメインをベースに管理するのが良さそう。
サブドメイン：テナント＝１：１。
Hostヘッダーでルーティングやトレースが可能。