【第05回】Deep Dive マルチテナントSaaS on AWS - 第4章振返り
はじめに
本記事では、「マルチテナント SaaS アーキテクチャの構築 ― 原則、ベストプラクティス、AWS アーキテクチャパターンの第 4 章「オンボーディングとアイデンティティ」の内容を振り返り、自分なりに要点を整理していきます。
4 章では、著者は本書籍を通して、がマルチテナント SaaS アプリケーションはコントロールプレーンから取り掛かるべきだと繰り返し主張しており、本章で取り上げられれているテナントのオンボーディングとアイデンティティはコントロールプレーンの中でも真っ先に取り組むべきビルディングブロックであると言います。
ベースライン環境の構築
オンボーディングとアイデンティティの機能の話に入る前に、まずはそれらを実行するためのベースライン環境について考えるところから始める必要があります。ベースライン環境とは、テナントのオンボーディングをコントロールプレーン上で実行するために必要な、環境に一度だけプロビジョニングされる一通りのリソース群を意味します。
ベースライン環境は DevOps ツール等を通した自動化スクリプト、言い換えれば単一の再現可能な自動化モデルを通して構築されることを目指します。
例えば AWS 上に構築されるベースライン環境の概念図は以下のようになります。
この時、コントロールプレーン及びアプリケーションプレーン用のリソースだけでなく、システムを管理するための UI である管理コンソールとそのコンソール上で作業するための、システム管理者用のアイデンティティも一緒にプロビジョニングされる必要があります。
ベースライン環境が構築されることで、セルフサービス式にせよシステム管理者が管理コンソール経由にせよ、テナントをオンボーディングするための準備が整いました。
オンボーディング体験
ベースライン環境が用意できたので、次は本題のオンボーディングについて考えていきます。
重要なのは、オンボーディングのプロセルはサービスの一部であり、SaaS 体験の最も基本的な要素の一つであると認識することです。
オンボーディングは、顧客に与える第一印象を左右するビジネス的な側面と、テナントのデプロイやルーティング、ティアリング戦略といった機能に影響を与えるという技術的な側面の両方で非常に重要な役割を担っています。
この点はセルフサービス方式(エンドユーザーが必要事項を入力してサインアップする方式)のオンボーディングだけでなく、内部オンボーディング(システム管理者が管理コンソール上でテナントを登録する方式)であっても例外ではなく、顧客のタイムトゥーバリューを最大化することに重点を置き、完全に自動化された再現可能なオンボーディングプロセスを構築することがいずれの方式でも重要です。
オンボーディングプロセスの中核を担う具体的且つ代表的なプロセスは以下の通りです、
- テナント管理 : 一意のテナント識別子(GUID)を払い出し、必要情報(ティアや会社名)と共にテナント情報を作成する。
- テナントプロビジョニング : テナントごとに必要なリソースをプロビジョニングする。ベースライン環境構築時と同様、DevOps ツールの自動化コードを通して実現される
- 請求 : 請求システムにて、テナントに適用すべき請求モデルを関連づける。
- ユーザー管理 : テナント管理者をそのテナントの初期ユーザとして作成し、アイデンティティプロバイダに登録する。移行はテナント管理者が追加のユーザを作成出来るようになる。全ての工程が完了したら、テナントのステータスをアクティブに更新する
1.の時点(初期状態)ではテナントのステータスは非アクティブに設定し、全てのプロセスが完了したらアクティブにするこようにして、プロセスの再試行やフォールバック戦略が可能にすることが重要です。また、特に複雑なオンボーディングプロセスが必要な場合は、オンボーディングの進捗状況やエラー原因を細かく把握し分析出来るような設計が必要になります。
オンボーディングの具体的なプロセスは、採用するティアリング戦略やデプロイモデルから大きく影響を受けます。例えば３章で紹介したように、ティアによってサイロデプロイモデルとプールデプロイモデルのいずれかを選択可能な場合、両ティアの必要なオンボーディングプロセスと難易度は大きく異なります。また、(ティアによる差別化が無くとも、)一部のリソースをサイロ化し、一部のリソースをプール化しているような混合デプロイモデルの場合も、オンボーディングで必要になるプロセスは複雑なものになることが予想出来ます。
また、テナント専用のリソースは、システムの更新や運用といった様々な場面で参照出来るよう、識別・追跡可能な状態に保つ必要もあります。
オンボーディングプロセスで発生する障害は、その SaaS アプリケーションにとって重大な損失をもたらす可能性があるため、フォルトトレランスな仕組みを高い品質で作り込むことが求められます。具体的には一部のプロセスを非同期化してバックグラウンドで再試行可能にしたり、オンボーディングプロセスのテストにしっかりと投資したりです。
SaaS アイデンティティの作成
次に、オンボーディングの過程で作成されるアイデンティティについて、具体的な設定方法や、アイデンティティが SaaS アプリケーションのユーザ体験に与える影響を見ていきます。
マルチテナント SaaS アプリケーションでは、従来の認証体験を損なうことなく、ユーザとテナントとを関連付け、SaaS アイデンティティという単一のユニットとしてアクセス・共有・管理出来るようなアイデンティティのモデルを実現することが必要です。この SaaS アイデンティティが、システムの全ての要素にテナントコンテキストを伝えるための手段になります。
次に、主要な認証仕様である OAuth と OIDC にて SaaS アイデンティティをどの様に作成・活用出来るかを考えます。
一般に OIDC 準拠のアイデンティティプロバイダで認証を行うと、後続の認可プロセスで必要なコンテキスト(クレーム)が埋め込まれた JWT(Json Web Token)形式のアイデンティティトークンとアクセストークンが返されます。この JWT こそが、SaaS アイデンティティモデルの基盤となります。具体的には、カスタムクレームとして JWT にテナントコンテキストを埋め込みます。
具体的に追加するテナントアイデンティティ(カスタムクレーム)の属性はアイデンティティプロバイダに事前に設定しておき、テナントのオンボーディング時及びオンボーディング後のユーザ作成時に、ユーザアイデンティティと一緒に追加されます。
SaaS アイデンティティ(ユーザアイデンティティとテナントアイデンティティとのマッピング)の実現方法として、JWT のカスタムクレームを使用する以外の方法もあります。例えばユーザアイデンティティとテナントアイデンティティとのマッピングを行う、専用のサービスを設け、テナントコンテキストの参照が必要になるたびにこのサービスを利用する、といった方式です。ただしこの方式では、テナントとユーザの関係性を個別に管理する必要が生じたり、サービスに対するリクエストが膨大になり得ることが予想されるなどの問題が伴うことから、基本的には JWT のカスタムクレームを使用した方式が第一の選択肢となります。
ここまでの話は、SaaS アプリケーションの管理下にある単一のアイデンティティプロバイダが使用できるという前提でしたが、実際のビジネスでは顧客が管理するアイデンティティプロバイダとのフェデレーションも実現したいという要件に直面する可能性があります。このような場合、前述したようにアイデンティティプロバイダにカスタムクレームを設定するといった対応は難しくなり、代わりに、アイデンティティプロバイダから払いだされた JWT をテナントコンテキストで拡張出来るような仕組みが求められます。
使用するアイデンティティプロバイダによっては、JWT 以外の方法でユーザとテナントのマッピングを可能にするものもあります。例えば Amazon Cognito ユーザープールを使用している場合であれば、テナントごとにユーザープールを個別に作成する、といった具合です。この方式は拡張性の面に難がある一方で、テナントごとに異なる認証体験をサポート出来るというメリットもあります。ここでも重要なのは、唯一の正解は無く、アプリケーションやドメインに基づいて適切なマッピングの方式を確立することです。
また重要な点として、テナントコンテキストに基づいた認証を実現したことは必ずしもテナント分離を実現したことを意味しないという点です。テナントコンテキストが埋め込まれた JWT を認証時に払い出せたとしても、そのテナントコンテキストに基づいて(テナントの境界を超えないように)リソースへのアクセスを認可する仕組みは別途実装する必要があります。
終わりに
本章では、SaaS アプリケーションにテナントの概念を導入する上で中核となる、オンボーディングとアイデンティティについて整理しました。繰り返しになりますが、アプリケーションプレーンよりも前にこれらのビルディングブロックに取り組み、アーキテクチャの中心にテナントの概念を据えることが何よりも重要です。
Discussion