ちょっとした打ち合わせがあり、そこでマルチテナントアプリケーションのS3 Bucketの使い方についての相談をいただきました。
打ち合わせの中で、マルチテナントなアプリについてはなかなかアーキテクチャレベルでの選択肢やそのメリット・デメリットが自分の中でモデル化できていないということを実感しました。 ちょうど最近SmartHRさんのマルチテナントアプリのスライドを拝見しアーキテクチャレベルの興味が沸いていたという背景もあります。
そういうわけで、どのようなモデルがあるのだろうというのを調べていたところ、マルチテナントの戦略を整理しているAWSのWhitePaperを見つけました。
こちらの内容から、各戦略のメリット・デメリットを整理してみます。
戦略
早速、SaaS Storage Strategiesから、その戦略を引用してみます。
ここでは3種類の戦略が紹介されています。
- Silo
- Bridge
- Pool
Siloは、テナントごとにストレージレイヤのレベルで独立させるという戦略です。RDSであればインスタンスごと別にするという立て付けで、データ分離がインフラレベルで実現されます。 また環境分離が実現できるため、他テナントの影響も及びません。 一方でこの戦略は集約とは逆方向を向いているためクロステナントでの状況把握が難しく、コスト最適化も困難になります。
Bridgeは、インスタンスは共用したうえで、データベースレベルで分離させるというアイデアです。SmartHRさんの当初アーキテクチャはまさにこのBridgeでした。 ちなみにSmartHRさんの資料で興味深かったのは「テナントをDatabaseレベルで分離した場合、マイグレーションに時間がかかる問題は並列でマイグレーションしても解決しない」というところです。 ご興味ある方は上述の資料をぜひ。
Poolは、単一Databaseの単一のスキーマで全テナントのデータの保持するという方法です。インフラ・スキーマを共用できているが故に、新しいテナントが追加されたときの対応が最速です。 もちろん、デプロイや運用も楽でしょう。一方で特定テナントの影響が全体へと及びます。この影響というのは、別にトラフィックといった話だけでもなく、データ特性も含むでしょう。
これらのメリット・デメリットは以下の図で語られています。
データマイグレーション
SiloやBridgeモデルでは、マイグレーションは当然テナントごとに実施します。 テナントごとのマイグレーションタイミング等をコントロールできるのは、場合によってはサービス提供側に都合が良いものでしょう。 一方で運用の複雑さは増します。 逆にPoolモデルでは一度マイグレーションすれば全テナントにその内容が反映されます。 それはビジネス的に良いことであったり悪いことであったりするでしょう。
このあたりの観点は、ビジネス要件見合いになるんでしょう。
まとめ
簡単にまとめてみましたが、ホワイトペーパー自体はセキュリティやモニタリング等まで踏み込んだ、かなり汎用的な内容を含んでいます。 マルチテナントのアーキテクチャに悩んでいる方は、ぜひご一読いただけると良いのではないでしょうか。
