いわさです。
AWS では SaaS アーキテクチャーの設計ガイダンスが提供されていますが、Azure でも SaaS アーキテクチャー設計ガイダンスが提供されています。（AWS ではホワイトペーパーや SaaS レンズ、Azure ではアーキテクチャーセンター）
これらの設計ガイダンスですが、中身を見てみると AWS も Azure もどちらも本質的には同じことを伝えてみます。
SaaS アーキテクチャーは、主にマルチテナントの実現方法と SaaS ビジネスの成長モデルを中心として、たくさんのトレードオフの中でアーキテクチャーを決めていきます。
どちらも参考になるのでどちらも読みましょうという感じではあるのですが、この 2 つでテナント分離モデルに関する用語の意味が違っているものがありましたので紹介したいと思います。
それぞれのガイダンスを参照する際には読み替えというか、用語の違いがあるという点を理解しておくと混乱しなくて良いと思います。
テナント分離
SaaS の特徴のひとつとして、複数のテナント（ここでは SaaS の契約者とします）が同一のシステムを利用します。
その関係で、あるテナントが別のテナントのデータにアクセスしてしまう「クロステナントアクセス」のインシデントが発生しないようにするなどの対策が必要で、その対策のためのアプローチを「テナント分離」と呼んだりします。
コンピューティングリソースやデータベースリソースなどのインフラを複数テナントで共用させるか、テナントごとに専用のインフラを用意するかというのがマルチテナントを考える上ではじめに出てきます。
このブログではどういう時にどういう選択するのが良いかという点について言及しません。
Azure のテナントモデルについては次に記載があります。
AWS のテナントモデルについては次の記載があります。
テナントごとにインフラを用意する方式
Azure - シングルテナント
まずはテナントごとのインフラを用意する方式です。
これは非 SaaS なアプリケーションを SaaS 提供へ移行しやすい方式だと思います。
Azure では、テナントごとにインフラを用意する方式を「シングルテナント」と呼んでいます。
引用元：マルチテナント ソリューションのテナント モデル - Azure Architecture Center | Microsoft Learn
実装が楽な反面、インフラや運用面などのコスト効率が良くないです。（技術的にカバー出来る部分もあるが）
また、パブリッククラウドの場合だと作成可能なリソース数のハードリミットが設けられているので無限にテナントを増やすことは出来ません。ハードリミットの把握と対処方法を設計段階で検討しておく必要もあります。
上記から、テナント数が多くなるとつらさが出てきます。
ただし、テナント分離性が高いのでコンプライアンス関係やノイジーネイバー問題の対策としてあえてこのモデルを選択するパターンもあります。テナントごとのパフォーマンスやコストのトレースがしやすいというメリットもあります。
AWS - サイロ
AWS では、この方式を「サイロ」モデルと呼んでいます。
引用元：サイロ分離 - SaaS レンズ
また、後述しますが AWS の定義としてはマルチテナントです。シングルテナントという用語はほとんど使われていません。
複数テナントで共用インフラを利用する方式
Azure - マルチテナント
先程と異なり、複数のテナンスで同じインフラを共用利用する方式を Azure では「マルチテナント」と呼んでいます。
引用元：マルチテナント ソリューションのテナント モデル - Azure Architecture Center | Microsoft Learn
パブリッククラウドにおいてはスケーリングが容易なので、コスト効率がよく、デプロイや監視の対象も少ないので運用効率もよくなります。
一方でクロステナントアクセス保護のために各レイヤーで追加対策が必要になります。例えばデータベースだと RLS とか、クラウドリソースへのアクセスであればテナントスコープに絞った権限に動的に昇格させたりと、アプリの実装にミドルウェアやクラウドリソースの概念が混在してきて、なかなか苦労します。
このあたりの対策が出来ずに SQL の Where 句だけで頑張ってしまっているケースもよく見かけるのですが、アプリ側の実装バグひとつでクロステナントアクセス違反が発生する恐れがあります。セキュリティと同じで多層防御でリスクを減らしていく対策が重要だなぁと常々思ってます。
AWS - プール
AWS ではこの形を「プール」モデルと呼んでいます。
次の構成図ではテナント共有リソースの周囲に Onboarding や Identity などのコンポーネントが配置されてますが、このブログ記事のコンテキスト上は無視して良いです。
引用元：プール分離 - SaaS レンズ
これらはコントロールプレーンと呼ばれる、マルチテナントを管理する部分です。
一方でテナントが利用するアプリケーション本体をアプリケーションプレーンとか、データプレーンと呼んだりします。
Azure のマルチテナントモデルの図には明記されていませんが、Azure 側でもコントロールプレーンの概念はあります。
テナントでリソースを共有したりしなかったりが混合されてる
大きくは「シングルテナント/サイロ」と「マルチテナント/プール」に分類されますが、この 2 つが混在されることも多いです。
AWS ではサイロとプールが混在した構成を「ブリッジモデル」と呼んでいます。
混在の仕方は様々でどのレイヤー、どのコンポーネントをサイロ化して、どこをプール化するかは定義として決まっていません。
個人的によく見るのはデータベースだけサイロ化されテナントごとに用意されていて、アプリケーション側で接続先を切り替えるパターンです。
Azure ではこのパターンは「水平方向のパーティション分割」として扱われています。
引用元：マルチテナント ソリューションのテナント モデル - Azure Architecture Center | Microsoft Learn
あるいは、別のドキュメントでは「ハイブリッド」という呼ばれ方をしている場合もあります。
混在型に関しては他にも色々なパターンがあり、テナントごとに共用だったり独立だったりを分ける場合もあります。
Azure では次の構成図で表現されており「垂直方向のパーティション分割」として扱われています。
引用元：マルチテナント ソリューションのテナント モデル - Azure Architecture Center | Microsoft Learn
AWS でもこのパターンについて言及されており、ユースケースとしてはインフラを共用するフリープランと、独立させるプレミアムプランを SaaS の価格モデルとして提供する場合が例としてよく挙げられています。
他にもマイクロサービスアーキテクチャーで、サービスごとに混在させるケースもあります。
多いパターンだと認証基盤や外部 SaaS 連携を行う部分はテナント共用させて、それ以外のサービスは独立させる場合はよく見ます。
[余談] SaaS on AWS ではシングルテナントと呼ばない
実は SaaS on AWS では、次のドキュメントに記載されているようにシングルテナントという用語を使わないようにしています。
また、次のドキュメントにも記載されており「マルチテナント=プールモデル」ではないよねということが説明されています。
（私の解釈が間違っていなければ）コントロールプレーンと呼べなくもないものが存在おりマルチテナントを横断的に管理する概念が何かあれば、それはインフラがサイロ化されていたとしてもマルチテナントだろうということです。
さいごに
本日は Azure と AWS の SaaS テナント分離の用語について整理してみました。
呼び方は正直どちらでも良いと私は思っているのですが、現状は「マルチテナント」という用語は聞く人によって認識する内容が違う場合があるので注意が必要ですねというのが一番言いたかったです。
サイロとかマルチテナントとかそれらしく聞こえる単語よりも「テナントAとテナントBは同じデータベースの同じテーブルにアクセスしますか？」みたいな、そういう説明をしたいなと思いました。用語が決まってたほうが楽ではあるのですけどね。
0
