SaaS ビジネスの成否を分けるテナント分離戦略

そもそもテナント分離を行う目的とは何でしょうか ? それは必ず行う必要があるものなのでしょうか ? 答えはもちろん Yes なのですが、ここにまだ疑問を持たれている方は、おそらく認証・認可とテナント分離を混同している可能性があります。まずはこの 3 つの責務の違いを明確にしておきましょう。

認証とは、その操作を行なっている人が「誰」であるか、確かにその本人であるということを証明するための仕組みです。

次に認可ですが、こちらは、認証されたアイデンティティが「何」ができるか、アクセス権限を定義するものになります。アクセスできるデータの範囲と行うことができる操作 (CRUD) のセットで表されることが多いです。SaaS について考えてみると、認可については 2 つのスコープに分けることができます。特定のテナント内の認可と、複数テナントをまたがったクロステナントでの認可です。前者については、例えば部署ごとに権限が分かれていて、自身の所属配下のデータ以外は参照できないというユースケースが考えられます。しかしこれは SaaS に限った話ではなく、一般的なアプリケーションのベストプラクティスを踏襲すればよいでしょう。問題は後者です。あるテナントが別のテナントのデータを参照、あるいは更新できてしまうようなことがあった場合、これは重大なインシデントとなります。これこそが複数テナントが相乗りをしてサービスを使用する SaaS 特有の考慮点です。

テナント分離の対策を何も行わない場合、別のテナントが保有するデータベースに接続をしにいってしまう可能性を完全に排除することができるでしょうか ? アプリケーションの認可を行う部分にバグを埋め込む可能性はゼロであると自信を持って言えるでしょうか ? これはビジネスが成長してコードベースが大きくなるにつれて、どんどん難しくなっていくでしょう。

大事な顧客のデータをアプリケーションロジック一つで守るのには大きなリスクが伴います。少なくとも別のレイヤーで、テナントがアクセスできるスコープを制限する仕組みを導入することが求められます。それを担うのがテナント分離の考え方です。

センシティブな情報を扱うセキュリティ要件の厳しい業界 (金融、ヘルスケアなど) では、インフラストラクチャを共有するプールモデルでは対応ができないコンプライアンス要件を求められることが多々あります。また、AWS IAM ポリシーなどを利用したテナント分離の仕組みを導入することができない AWS のサービスや、同じくテナント分離の仕組みが備わっていないサードパーティのサービスなどを使用する場合は、部分的またはアーキテクチャ全体でサイロモデルを採用して分離性を高める方が良いケースもあります。

また、サービスごとに定義されたクォータ (例 : VPC あたりのサブネットの最大数は 200) にも気をつける必要があるので、将来的なテナント数なども考慮に入れて設計を行うことをおすすめします。

どの分離レベルを採用するにせよ、サイロモデルで一番重要なことはインフラ構築の自動化です。ユーザーがすぐに使い始めることができない、一貫したオペレーションが提供されないというのは、ビジネスの成長を阻む大きな要因になり得ます。再現性のある自動化されたプロセスによって、急激な利用ユーザーの増加にも耐えることができるスケーラビリティを持っていることが、SaaS ビジネスの成否を分ける鍵となります。

プールモデルの最大のメリットは、オペレーションとコストの効率性です。

テナントごとに環境を用意する必要があるサイロモデルの場合、インフラストラクチャのプロビジョニングから、ユーザーの発行・各種設定を含むオンボーディングプロセス、運用に入ってからのシステム監視、トラブルシューティング、新しいバージョンのデプロイまでを考えると、テナントの数が増えるに従ってこの運用業務の負荷も線形に伸びていきます。ある程度自動化が可能とはいえ、管理する場所が増えるということはそれだけ障害が起きる表面積も増すことになるので、安定した効率的なサービス運用という面ではプールモデルの方に軍配が上がります。また、コスト面に関しても、リソースを集約して無駄なく使えるプールモデルでは、サイロモデルに比べて必要なキャパシティが削減できるため大きなコスト削減効果が見込めます。

このスケールメリットは、システムの利用ユーザーが増えるにつれてより顕著になるため、最初はサイロモデルで運用していたシステムでも、ある時点からプールモデルへの移行を検討するといったことも珍しくありません。

特定の顧客はサイロモデル、他の多くのテナントはプールモデルというハイブリッドな構成を取ることで、ノイジーネイバー問題を回避しつつコストや運用効率の最大化を図ることができます。加えて、この「特定のテナントがシステム全体に対して及ぼす影響範囲を最小限に抑える」という考え方は、製品戦略にも大きく関わってきます。どのようなプランを用意していくらでどんな機能を顧客に提供するかという、いわゆるプライシング・パッケージングを検討する際に、SLA (Service Level Agreement) を定義することが近年増えてきていますが、高い SLA を設定すればするほど、プールモデルでの実現は難しくなります。なぜなら、ノイジーネイバーによる影響は予測することが難しいためです。

また、前述したように個別環境での提供は運用やコストの負荷が上がるので、高い SLA を保証するプレミアムプランのような立て付けでサイロモデルでの提供を行うオプションを用意して、ユーザーに選択肢を与えるようにすると、より多くのユーザーのニーズに応えることができるでしょう。

テナント分離の実現方法は、適用するレイヤーや使用するサービスによって様々です。

例として、コンピューティングレイヤーを考えてみましょう。Amazon EC2 を利用している場合は、EC2 インスタンスにアタッチする IAM ロールでアクセス権限のスコープを制限することができます。

サイロモデルを採用していて、一つの Amazon VPC の中にテナント A 用のインスタンスとテナント B 用のインスタンスが存在するケースを考えてみましょう。 

それぞれの EC2 インスタンスから各テナント専用の Amazon DynamoDB テーブルへデータを読み取りに行く必要があるとします。テナント分離を意識せずに DynamoDB の全てのテーブルへの読み取り権限がある IAM ポリシーを IAM ロールにアタッチしていた場合、この状態でアプリケーションに何らかのバグが入り込んでテナント A 用のインスタンスがテナント B 用のテーブルへ接続をしにいってしまう状態になってしまった場合、この意図しないアクセスを止める術はありません。

以上がサイロモデルにおけるやり方です。

ではプールモデルではどうなるでしょうか ?
1 つの EC2 インスタンスに複数のテナントからリクエストが来る場合、事前にアタッチする必要があるインスタンスプロファイルでは対応ができないように思えます。何らかの形でポリシーを動的に適用する必要があるのですが、どのような方法が考えられるでしょうか ? こちらについては次回詳しく見ていきますので、それまでにぜひご自身でも考えてみてください。

ここまでテナント分離の基本的な考え方と、代表的なパターン (サイロモデル、プールモデル)、それぞれのモデルが得意 / 苦手とするところについて見てきました。そして、テナント分離の仕組みを AWS に導入するための具体的な実装として、IAM を利用した基本的な方法をご紹介しました。

次回はさらに Dive Deep して、プールモデルにおける動的なポリシーの生成、テナントコンテキストの注入といった考え方とその実装例を取り上げます。また、データベースやストレージ、ネットワークといったところまでスコープを広げて、アーキテクチャ全体でどうテナント分離を実現していけばよいのか、詳しく見ていきたいと思います。