一般的な設計の原則

SaaS アーキテクチャに万能の解は存在しない: SaaS を使ったビジネスのニーズ、各ドメインの性質、コンプライアンス要件、マーケットセグメント、ソリューションの特性など、すべての要素が SaaS 環境のアーキテクチャに明確な影響を与えます。すべての SaaS アーキテクチャは、SaaS 製品として成功するために必要な、俊敏性と SaaS の基本原則を実現する運用および顧客エクスペリエンスを提供するものである必要があります。システムはその設計方法にかかわらず、1 つの画面でオンボーディング、管理、オペレーションを実施できる機能をテナントに提供し、SaaS ビジネスを構築するための基盤となる俊敏性およびスケールメリットを、SaaS 組織が達成できるようにする必要があります。

マルチテナントのワークロードと分離の特性に基づいてサービスを分解する: システムをサービスに分解する場合は、その分解方法の判断にあたって、マルチテナントのワークロード、テナントの階層、分離の要件が、システムの一部であるサービスにどのように影響するかを検討する必要があります。このようなケースでは、各サービスを独立させて考えなければなりません。例えば、あるサービスではデータの保存にプールを使用できたとしても、別のサービスではコンプライアンスや「他のテナントによる影響」の課題を考慮してデータの保存にサイロ化が必要である場合もあります。ほかにも、テナントの階層構造を実現させるため、サイロモデルでデプロイすべきサービスもあるかもしれません。例えば、プレミアム顧客であるテナントに対しては、プレミアム階層への価値提供の一部として、一部のサービスをサイロモデルで提供する場合があります。

すべてのテナントリソースを分離する: SaaS システムの成功は、テナントリソースをクロステナントアクセスから保護するセキュリティモデルにかかっています。堅牢な SaaS アーキテクチャは、すべてのレイヤーにわたって分離戦略を導入し、テナントリソースにアクセスするときには、現在のテナントコンテキストのみがアクセス可能な特別な構造を持っています。

成長のためのデザイン: SaaS モデルへの移行は、多くの場合 SaaS 組織の成長を意味します。SaaS 製品のアーキテクチャおよびオペレーションの範囲を定義するときには、必ずその環境が、加速するテナント数の増加に対応できるかどうかを考える必要があります。SaaS のアーキテクトは、テナントのオンボーディングの急増をオペレーション費用の追加なしで処理できる、俊敏な対応力のあるスムーズな環境を構築する必要があります。このような考え方によって、顧客ベースが急成長しても、SaaS 環境のオペレーションやインフラストラクチャの規模を拡大する必要性はなくなります。

ツールを配備してテナントのメトリクスの取得と分析を行う: 複数のテナントをサービス環境に配置するとき、特にこれが共有環境である場合は、テナントによるシステムの使用状況を明確に可視化することが課題となります。SaaS チームは、テナントが使用している機能、システムに存在するワークロード、テナントが直面するボトルネック、アクティビティのコスト内容などに関するインサイトを画面で表示できるメトリクスツールに投資する必要があります。このデータは、SaaS 企業のビジネス・アーキテクチャ・オペレーションの健全性に直接的な影響を与え、企業戦略に情報をフィードバックするトレンド分析の中核となります。

テナントを再現可能な自動一括プロセスでオンボーディングする: SaaS とは、俊敏性を実現することに他なりません。この俊敏性の点で重要なポイントは、テナントのオンボーディングプロセスです。堅牢な SaaS システムには、システムに新しいテナントをオンボーディングするためのスムーズで再現可能なプロセスが必要です。これはスケーリングを容易にすると同時に、成長を促進するために不可欠です。また、新規顧客に迅速に価値を提供することにもつながります。

複数テナントの機能のサポートを計画する: SaaS のマーケットおよび顧客には、さまざまなタイプがあります。SaaS 企業はほとんどの場合、アーキテクチャやオペレーションにさまざまな要望を出す多様なテナントをサポートする必要があります。SaaS プロバイダーおよびアーキテクトとしては、このようなテナントのペルソナをモデル化することによって、各ニーズに合わせた個々のバージョンの SaaS 製品を用意する必要がなく、幅広いテナントのユースケースをカバーできる構造とメカニズムを備えた 1 つの総合的な環境を構築することが重要です。また、ビジネスにおいて複数のセグメントにリーチできる製品階層を用意し、その階層によって顧客のレベルアップを推進するような、システムにおける提供価値の境界線を特定することも重要です。

グローバルなカスタマイズで 1 回限りの要件に対応: SaaS の俊敏性とイノベーションは、すべての顧客に 1 つの環境を提供することによって達成されます。アップデート、管理、オペレーションをすべての顧客に対してまとめて実行できることが SaaS の基本です。ただし現実には、一部の顧客からカスタマイズを要望されることもあります。このようなカスタマイズは、他の顧客にも提供できる設定オプションとして導入すべきです。このような機能を製品の核とすれば、SaaS 企業はビジネスの俊敏性、オペレーション効率、イノベーションの目標を犠牲にすることなく、1 回限りのニーズに対応できるようになります。

ユーザーアイデンティティをテナントアイデンティティと関連付ける: データロギング、メトリクスの記録、データへのアクセスなどを実行するテナントのコンテキストの概念は、程度は異なるもののアーキテクチャのすべてのレイヤーで必要になります。つまり、他のサービスを呼び出すことなく、アプリケーションのレイヤーによって解決および簡単にアクセスできる構造として、テナントコンテキストを最優先する必要があるということです。ソリューションの認証および承認プロセスは、テナントアイデンティティ (およびその他テナント属性も必要なケースも) と承認済みユーザーのアイデンティティを関連付ける必要があります。これによってシステムのすべてのレイヤーで利用できる SaaS アイデンティティが生成され、テナントコンテキストへのアクセスが可能になります。

インフラ消費とテナントアクティビティを一致させる: SaaS 環境におけるテナントアクティビティは、ほとんど予測不可能です。テナントが消費するリソースの種類は、その消費方法や消費するタイミングなどを含めて、大きく変化する可能性があります。システムにおけるテナントの数も、日常的に変化します。このような要素はスケーリングの課題となる一方、堅牢な SaaS アーキテクチャでは、オーバープロビジョニングを制限するポリシーを実装し、アプリケーションのインフラ消費をテナントアクティビティのリアルタイムトレンドに合わせます。こうすることで、テナントのワークロードと SaaS インフラストラクチャ全体のコストプロファイルの乖離を防ぐことができます。

デベロッパーがマルチテナントの概念を意識する範囲を制限する: テナンシーはアーキテクチャのすべてのレイヤーに通じるものですが、目標はデベロッパーがテナントを意識する範囲を制限することです。経験則として、デベロッパーがマルチテナントサービスを構築するときにすることは、テナントの概念がないサービスを構築することとそれほど変わりません。もしデベロッパーがコード全体にテナントの情報を追加する必要があったとしたら、アプリケーションのマルチテナントポリシーおよびメカニズムにおけるコンプライアンスのコントロールと適用は困難になるでしょう。つまり、テナントの詳細が表示されないようにしながら、デベロッパーにライブラリや再利用可能な構造を提供するということです。

SaaS は技術的な実装方法ではなくビジネス戦略である: SaaS 環境およびその基盤となるテクノロジーの選択肢は、ビジネスの俊敏性、イノベーション、競争的なニーズによって直接決定されます。このポイントとマインドセットは、ダウンタイムなし、定期的なアップデート、顧客との密接なコネクションといった、顧客のためのサービス体験を生み出すための軸として展開します。つまり、継続的な進化とマーケットデマンドへの迅速な対応を推進できるようなアーキテクチャおよびオペレーションの規模を設計するということです。技術的には堅牢でも、俊敏性、イノベーション、オペレーション効率を考慮していないアーキテクチャは、特に他に競合の SaaS プロバイダーがいれば、競争の激しいマーケットで戦うことができないでしょう。

テナント対応オペレーションビューを作成する: オペレーションチームは、マルチテナント環境において新しい課題に直面しています。システムの健全性およびアクティビティのグローバルビューを提供することは SaaS 環境においても重要である一方、堅牢な SaaS のオペレーションでは、これに特定のテナントやテナント階層によるシステムの利用状況に関するインサイトも追加されます。SaaS のオペレーションチームは、ダッシュボードおよび個別テナントのアクティビティとワークロードを分析してプロファイリングできるビューを構築する必要があります。個別テナントのレベルで利用状況を確認してトラブルシューティングできる機能は、プロアクティブで効率的なマルチテナントオペレーションに欠かせないものです。

個別テナントによるコストへの影響を測定する: SaaS 企業の経営チーム、アーキテクトチーム、オペレーションチームは、テナントが SaaS 環境のコストにもたらす影響について明確な共通認識を持つ必要があります。例えば、ベーシック階層に属するテナントには、プレミアム階層のテナントよりも高いコストがかかっていますか? テナントの消費パターンや特徴は、SaaS 環境のコスト内容に影響を与えていますか? これらは、テナントのコスト内容を明確に把握していればしっかりと応えられる質問の例です。これはテナントリソースが複数のテナントによって共有されているケースで特に重要となる内容です。このようなデータを収集して表示すれば、SaaS 企業のアーキテクチャやビジネスモデルの形成に役立つ貴重なインサイトを提供できるようになります。