運用

組織の顧客すべてが共有インフラストラクチャモデルにデプロイされる可能性がある共有マルチテナント環境では、より詳細な正常性の運用ビューを必要とすることが SaaS ビジネスの成功と成長に不可欠です。停止や正常性の問題はシステムの全テナントに連鎖し、全顧客の SaaS サービスがダウンする可能性があります。つまり、SaaS 組織は、運用チームが SaaS 環境の絶えず変化するワークロードを効果的に分析して対応できるよう、運用経験を積むことに重点を置く必要があります。

堅牢なマルチテナントの運用経験を積むために、SaaS 企業は SaaS 環境で必要とされる正常性とアクティビティのきめ細かなビューを導入するツールを作成またはカスタマイズする必要があります。これは、多くの場合、既存のツールとカスタムソリューションの組み合わせを使用し、運用経験で最優先される概念としてテナンシー層とテナント層に対応するエクスペリエンスを作成することを意味します。

例えば、SaaS オペレーションダッシュボードにはテナントおよびテナント層のレンズを通して表示される正常性のビューを含める必要があります。正常性のグローバルビューの表示もこのエクスペリエンスの一部ですが、SaaS 運用チームはテナントのアクティビティの正常性も確認できる必要があります。図 12 に示す概念ビューは、SaaS プロバイダーが最優先構造としてテナントアクティビティを特定する方法の 1 つです。

この図の簡易化されたビューでは、マルチテナント環境の価値を高める運用ビューのサンプルがいくつか示されています。ページの左上には、最もアクティブなテナントの正常性が表示されます。表示されているカラーインジケータにより、正常性のグローバルビューを確認する際に、特定されていない問題が発生している可能性のあるテナントに注意を向けることができます。これにより、テナントに対して完全には明示されない可能性のある問題に対して、オペレーションで事前に対応できるようになります。

図 12: テナント対応オペレーションビュー

このビューの右上に、テナントのリソース消費に関するデータが表示されます。ここでは、テナントごとに AWS リソースの消費を表示し、特定のテナントがどのように特定のサービスを実行しているのかを確認することが目的です。下部には、テナントがアプリケーションのさまざまなマイクロサービスをどのように消費しているのかを表す消費のビューが表示されます。このデータにより、オペレーションで、システムのさまざまなサービスをテナントがどのように消費しているのかを表示し、特定のテナントまたは層が特定のマイクロサービスが飽和する可能性を判断できます。

テナントアクティビティのこの汎用ビューを提供するだけでなく、運用経験には、個々のテナントと層の運用データをドリルダウンする機能も含める必要があります。特定のテナントまたはテナント層で問題が発生しているサポートシナリオを想定してみます。この場合、運用データにアクセスして、その特定のテナントまたは層のレンズを通してデータを確認できる必要があります。これは、マルチテナント設定で問題をトラブルシューティングして診断するために不可欠です。

これらの運用ビューを作成するには、テナント別またはテナント層別に洞察を分析できる運用ビューの作成に必要なテナントと階層化コンテキストを含む運用データにアクセスする必要があります。これを行うために、正常性イベントとアクティビティイベントの記録に使用されるさまざまなメカニズムにテナントコンテキストを挿入する方法と場所を、SaaS アーキテクトが慎重に検討する必要があります。例えば、テナントコンテキスト (テナント識別子や層など) がシステムのログデータに必ず挿入されるようにするメカニズムをログに含める必要があります。

ただし、作成するビューは、アプリケーションの設計とアーキテクチャの性質によって異なります。一般に、チームは、運用チームがテナントの傾向を効果的にモニタリングし、最初の段階から計装を環境に組み込める運用ビューについて検討する必要があります。これらの概念を開発プロセスの後半でアプリケーションに追加するのは難易度が高く、開発経験と運用経験の両方が損なわれる可能性があります。

SaaS ソリューションは俊敏性とイノベーションの最大化に重点を置いています。テナントのオンボーディングはこの俊敏性の事例において重要な役割を担います。スムーズで再現性のあるオンボーディングプロセスを促進するアーキテクチャを作成することにより、SaaS 組織は新しいテナントを SaaS 環境に導入する機能を合理化、最適化、拡張できます。これにより、SaaS 企業は急速な成長に対応して、価値実現までの全体的な時間を短縮するエクスペリエンスを顧客に提供できます。

自動化されたオンボーディングは B2C 環境と B2B SaaS 環境の両方に適用されることに注意してください。一部の SaaS 製品にはセルフサービスのオンボーディング手続きが含まれていない場合がありますが、これによってスムーズなオンボーディング手続きの必要性が減少することはありません。オンボーディングが社内で実行されるプロセスでも、テナント作成のすべての要素を自動化する必要があります。摩擦を低減する必要性は、SaaS ベストプラクティスに沿ったソリューション作成の基礎となります。

一般に、SaaS アプリケーションのオンボーディングプロセスには、新しいテナントの導入に必要なリソースすべてを構成してプロビジョニングすることのできる一連の共有サービスの調整が必要です。図 13 は、一連のマイクロサービスを介してこのオンボーディングを実装する方法の概要です。

この図に示されているオンボーディング手続きのフローは、テナントを導入して SaaS システムの使用を開始するのに必要なすべてのステップが網羅されています。このプロセスの前に、テナントは登録サービスに問い合わせて、新規テナントの作成を依頼します。それ以降、登録サービスはオンボーディングプロセスの中間に位置し、新しいテナント環境の作成に必要なすべてのサービスを調整します。

このプロセスの次のステップで、新規ユーザーを作成します。この新規ユーザーは、この新規テナントの管理者を表します。このプロセスをサポートするために、ユーザー管理サービスが追加されました。このサービスではユーザーに関するデータが保存されませんが、ID プロバイダー (この場合、Amazon Cognito) でユーザーが作成されます。また、このテナントの分離要件に対応するために必要な任意の IAM ポリシーが作成されます。

図 13: スムーズなテナントオンボーディング

このモデルでは、テナントごとに個別の Amazon Cognito ユーザープールを使用する戦略も利用しました。これにより、システムの各テナントを識別する手続き (パスワードポリシー、多要素認証など) をカスタマイズできます。このアプローチを選択する場合、各ユーザー ID を対応するユーザープールにマッピングする必要があります。このマッピングはユーザー管理サービスで管理されます。

ユーザーが作成されると、プロセスでテナントが作成されます。個別のサービスとしてのテナント隔離は SaaS 環境に不可欠です。そのテナントに関連付けられているユーザーから完全に分離されたテナントの状態と属性を一元的に管理できます。例えば、テナントの層やステータスはテナント管理サービスによって制御されます。

オンボーディングの一環として、SaaS システムは請求システムにフットプリントを確立する必要があります。この例では、新しいテナントを作成していることについて、請求統合サービスに知らせていることがわかります。これにより、このサービスでは、請求プロバイダーで新しいアカウントを作成する責任が想定されます。これには、テナントのプランまたは層の構成が含まれます (無料、ブロンズ、プラチナなど)。

図に示すプロセスの最後のステップは、テナントインフラストラクチャのプロビジョニングに関連します。一部の SaaS アーキテクチャには専用のテナントリソースが含まれます。これらのシナリオでは、テナントをアクティブ化する前に、オンボーディングプロセスでこれらの新しいリソースをプロビジョニングする必要があります。

ここに示すフローは環境の特性によって異なる可能性がありますが、ここに示す概念はオンボーディングプロセスで共通しています。テナントリソースの作成、構成、プロビジョニングの自動化は、機能豊富でスケーラブルなマルチテナントエクスペリエンスを作成する基礎となります。

SaaS アーキテクトが直面する重要課題の 1 つは、すべてのテナントが同じバージョンの製品を実行していることを確認する必要があることです。これは特に、SaaS に移行しており、1 回限りの製品バージョンを通じた独自の顧客要件への対応に慣れている企業に当てはまります。

これは効果的に思われますが、顧客管理、運用、サポート、デプロイの統合されたエクスペリエンスから離れた動作が行われると、SaaS 組織の全体的な俊敏性が直接損なわれます。新しいカスタム環境が導入されるたびに、SaaS 組織はゆっくりと従来のソフトウェアモデルへの移行を進めます。最終的には、これが SaaS ビジネスモデルの中核となるコスト、運用効率、一般的なイノベーションの目標を損なうことになります。

次の課題は、製品のフォークバージョンを作成せずに、不定期に発生する 1 回限りの必要性を満たすことができる戦略を見つけることです。ここでは、製品全体に追加されるカスタマイズオプションの導入によって妥協点を調整できます。そのため、個別のバージョンをスピンオフするのではなく、すべての顧客が利用できるようにこれらの新機能を追加する方法を見つける時間と労力をさらに費やす必要があります。次に、テナント設定でこれらの新機能を有効にするテナントを決定できます。

この問題の一般的なアプローチでは機能フラグを使用します。機能フラグは、実行時にさまざまな機能を有効/無効にするフラグを用いた共通のコードベースで複数の実行パスを使用する方法として、アプリケーションデベロッパーによって一般的に使用されます。この手法は、一般的な開発戦略としてよく使用され、SaaS 環境にカスタマイズを導入する効果的な方法です。各機能フラグは、テナント設定オプションに関連付けられます。この設定は実行時に評価され、各テナントで有効にする機能に影響します。

図 14 に示す概念ビューは、これらのフラグがどのように適用されるのかを示しています。個々のテナントに対して一連のフラグがオンまたはオフになり、テナントで有効にする機能が決定されます。これらの設定オプションは、テナントが SaaS サービスの新機能にサインアップすると変更されます。これらのフラグは (個々のテナントではなく) 層に関連付けることもできます。

図 14: テナントの管理には機能フラグが必要

機能フラグはこれを達成する 1 つの方法にすぎません。ここで重要なのは、1 つのテナントに固有の機能が必要な場合でも、その機能をコアプラットフォームのカスタマイズとして導入する必要がある点です。そのカスタマイズの適用方法はシステムのスタックと設計によって異なる場合があります。目的は、製品の 1 つのバージョンを確実にデプロイして管理できるようにすることです。

これは効果的な構造ですが、適用する場合は注意する必要があります。機能フラグを導入すると、最終的にすべてのテナントが独自のエクスペリエンスを持つ複雑なオプションの迷路を作成することになり、すぐにシステムで管理できなくなります。これらのフラグの導入方法とタイミングは慎重に選択してください。経験則として、このフラグを組織が新規顧客に 1 回限りのカスタマイズを提供可能にする販売ツールと見なすべきではありません。