SaaS on AWS を成功に導くためのポイントとは ? 第 2 回

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

2021-05-07
ビジネス x クラウド

.櫻谷 広人

こんにちは、パートナーソリューションアーキテクトの櫻谷です。

SaaS on AWS の連載第二回ということで、今回から各テーマについて掘り下げる Dive Deep シリーズとしてまず初めに「テナント分離」について見ていきたいと思います。


テナント分離とは

初回の連載でご紹介したように、SaaS においては頻繁に「テナント」という概念が登場します。何が「テナント」の単位になるかは、会社であったり部署であったり、貴社が提供するサービスによって異なるかとは思いますが、基本的なテナント分離の考え方は変わりません。

本稿では、テナントの分離 (または共有) 方法にはどのようなパターンがあるのか、そして、クロステナントアクセスを防ぎセキュリティを担保するためのメカニズムについて、実装例を交えながら解説していきます。

img_tenant-isolation_01

テナント分離の目的

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

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

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

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

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


分離パターンとそれぞれの利点 / 欠点

テナント分離には大きく 2 つのパターンがあります。サイロモデルとプールモデルです。

サイロモデルは、テナントごとに個別の環境を用意して専用のリソースを立ち上げる方法で、シングルテナントとも呼ばれます。対してプールモデルは、1 つの環境を共有して複数テナントが使用するマルチテナント型のモデルを指します。

どちらのモデルにもトレードオフがあり、ビジネス要件に応じて選択をしていくことになりますが、ここでは各モデルが適している例をもとに、それぞれのモデルの利点 / 欠点を考えてみましょう。

img_tenant-isolation_02

1. サイロモデル : セキュリティ要件として、他社と隔離された環境でデータを保存する必要がある金融業界向け SaaS

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

一言にサイロモデルといっても、その分け方は複数あります。AWS においては、テナントごとに AWS アカウントを用意するパターン、AWS アカウントは共通のものを使用してその中でテナントごとに専用の VPC を作成するパターン、VPC も共通化してサブネット単位で分離するパターンなどがあります。

共有度を高めてプールモデルに近づけば近づくほど、コストメリットや運用効率が上がってきますが、それだけ分離性は薄くなります。

img_tenant-isolation_03

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

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

2. プールモデル : テナントの数が数千を超える大規模 SaaS

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

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

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

3. サイロ + プールモデル : 少数の大規模顧客の利用がトラフィックの大半を占め、システム全体に負荷がかかることがある SaaS

この例が示しているのは、いわゆるノイジーネイバーと呼ばれる問題です。特定のテナントの利用動向が他のテナント全体にも影響を及ぼしてしまうもので、基盤のリソースを共有しているからこそ起きる、プールモデルの潜在的な課題です。これを回避するために、利用量の多いテナントのみを個別の環境に分離するという戦略を取ることができます。

img_tenant-isolation_04

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

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


テナント分離の実装例

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

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

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

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

IAM ロールのレイヤーで制御をかけていたらどうなるでしょうか ? 

各テナント固有のテーブルにスコープを絞った IAM ポリシーとそれをアタッチした IAM ロールを作成して、それぞれのインスタンスに割り当てれば、意図しないアクセスを AWS API の呼び出しの認可レイヤーで防ぐことができます。これが IAM を利用したテナント分離の一つの方法です。

EC2 以外のサービスを利用する場合でも基本的な考え方は同じで、AWS Lambda であれば関数の実行ロールになりますし、Amazon ECS であれば タスク用の IAM ロールとなります。

img_tenant-isolation_05

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

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


まとめ

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

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


bbuilders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

プロフィール

photo_sakuraya-hiroto

櫻谷 広人
アマゾン ウェブ サービス ジャパン株式会社
パートナーソリューションアーキテクト

大学 4 年から独学でプログラミングを習得。新卒で SIer に入社して Web アプリケーションの受託開発案件を中心にバックエンドエンジニアとして働いた後、フリーランスとして複数のスタートアップで開発を支援。その後、toC 向けのアプリを提供するスタートアップで執行役員 CTO を務める。現在は SaaS 担当のパートナーソリューションアーキテクトとして、主に ISV のお客様の SaaS 移行を支援。

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
フィルタ
フィルタ
1

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する