この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

はじめに

　とりあえずで作成した自テナントだけで動作する Azure AD 対応 Web アプリを公開する…アプリが複数顧客で受け入れられ、サービスとして成り立ってくると、各々のテナントにデプロイする工数や修正時の運用工数が増大している、自動化していても各種設定ファイルの管理が大変になっていることに気付く…というのはありがちな例ですが、上記のような例や、あるいは各顧客のテナント内の情報を取り扱うものの提供するサービスに差のない SaaS である場合、マルチテナント対応アプリケーションが作成時の考慮に入ってきます。

　ここでは、マルチテナントに対応するアプリケーションを作成するために考慮すべき点と各テナントに対しどんな処理が必要なのかをまとめていきます。

マルチテナントアプリケーションの仕組み

　マルチテナントアプリケーションの一般的定義を以下から引用します。
・参考URL：
Microsoft ID プラットフォーム開発者向け用語集 – マルチテナントアプリケーション

クライアントが登録されたテナントに限らず、任意の Azure AD テナントにプロビジョニングされたユーザーによるサインインと同意を有効にするアプリケーションのクラス。

　アプリケーション用としてもう少し踏み込むと、サービス提供者のテナント (自テナント) のアプリ (アプリケーションオブジェクト) を顧客テナント内のユーザーが同意することで、顧客テナントに自テナントのアプリを登録し (=サービスプリンシパルが登録される) そのアプリに対して顧客テナントの権限が付与され、その権限内で顧客リソースを自テナントのアプリが扱えるようになること、です。

　このような構成にする場合、自テナントのアプリケーションオブジェクトとアプリケーションの実体は 1 つですが、顧客は複数テナントの可能性があり、アプリケーションオブジェクトに対するサービスプリンシパルは複数存在します。

　言い換えると、顧客テナントには自テナントのアプリケーションオブジェクトのサービスプリンシパルはあるものの、実体は自テナントにあります。また顧客テナントにアプリ用リソースをデプロイすることなく、顧客テナント内の当該サービスプリンシパルによって、自テナント内に顧客テナントのデータを引き込めることになります。

　以下 URL にサンプルシナリオがあります。
・参考URL：
Azure Active Directory のアプリケーション オブジェクトとサービス プリンシパル オブジェクト

　顧客テナントにアプリケーションをデプロイせずアプリ用リソースの料金を顧客が支払わないため SaaS として価格モデルは整理されますが、一方でデータも顧客リソースに存在しないため、アプリやデータの取り扱いには十分注意する必要があります。

アプリケーションの登録

　マルチテナントアプリケーションに対応させるには、まずアプリケーションの登録を変更する必要があります。
　以下 URL にまとめられておりますが難しいところはなく、基本的にはアプリの登録にて「任意の組織のディレクトリ内のアカウント」、「任意の組織のディレクトリ内のアカウントと、個人用の Microsoft アカウント」のいずれかを選択すること、サインインリクエストを 「https://login.microsoftonline.com/common」に送ることで可能です。　
・参考URL：
新しいマルチテナント アプリケーションを構成する方法
クイック スタート:Microsoft ID プラットフォームにアプリケーションを登録する

　Functions の場合、参考手順は以下となります。
・参考URL：
Azure AD でセキュリティ保護されたマルチテナント エンタープライズ API の作成

　そのほか、アプリケーションの登録で登録したアプリを他のテナントへ登録させる事も可能です。
・参考URL：
Azure テナント間でギャラリー VM イメージを共有する

データベースの分離

　次に、もっとも考慮すべき点としてデータストアがあるでしょう。データベースであれば拡張性、テナントの分離、コスト、開発/運用の複雑さ、スキーマ管理、カスタマイズ性など考えるべき点が多々あります。

　例えば、各々のテナントを一つずつシングルデータベースとして持つとテナントの分離は可能ですが運用コストが非常に高くなります。一方で逆にひとつにまとめてしまうと、低コストですがテナントの分離が犠牲になり事故の元になりますし、迷惑な隣人によるパフォーマンス問題や件数が増えた場合のスケールアップに限界があります。

　下記 URL では、リソースを複数の DB で使用するエラスティックデータベースや、いくつかの顧客ごとにデータベースを分離しつつも同じ DB としてアクセス可能なシャードが有効な記載があります。

・参考URL：
マルチテナント SaaS データベース テナント パターン
弾力性データベース ツールと行レベルのセキュリティを使用したマルチテナント アプリケーション
Wingtip Tickets SaaS アプリケーション (アプリケーションサンプル)

　あるいは、データベースではなく KVS や Document 型 DB などの NoSQL にパーティションを分けて格納し水平スケールするようにしておき、データに関してはアプリケーション内で関連付けする方法も考えられますし、アプリも DB もコンテナーにして AKS (VM or ACI) で動作させる、なども考えられます。

まとめ

　文章のみで長々と記述してきましたが、これらの話は、アプリの SLA や掛けられるコスト、どの程度の拡張性を持たせるか、技術の将来性などの要因によって変わってきます。
　この記事にて、何が良いのかを考慮してみるきっかけになれば幸いです。