テナントのインサイト

企業がマルチテナントのモデルに移行するにつれ、テナントがどのようにアプリケーションを使用するかのインサイトを取得し表面化させることは、ますます難しくなります。これは、テナントによって共有される SaaS 環境のリソースについて、特に当てはまります。

同時に、すべてのテナントが潜在的に 1 つの共有環境で実行されている状態で、テナントのアクティビティと消費をはっきりと把握できることは、堅牢な SaaS サービスの構築に不可欠です。製品のテナントが使用している機能を知り、テナントが環境のアーキテクチャをどのようにプッシュしているかを知り、テナントの異なる階層がどのようにスケーリングしているかを把握することは、SaaS 企業が健全な SaaS ビジネスを運用できるようにするために必要なインサイトの一部です。

SaaS 指標の範囲は意図的に広くなっています。これは、指標が、SaaS 組織内の異なる役割によって複数のコンテキストで消費されるためです。つまり、インフラストラクチャの健全性を超えて考える必要があります。SaaS 指標には、ビジネスの俊敏性、機能の消費、マイクロサービスのアクティビティ、スケーリングの傾向などがあります。テナントと階層の使用傾向を取得し、アプリケーションと消費アクティビティと相互に関連させます。

このデータを消費するさまざまな役割の、さまざまなダッシュボードがあることを想像してください。例えば、製品マネージャーが機能指向指標に対するインサイトを必要としています。一方、運用スタッフはこのデータを使用して個々のテナントと階層の健全性と消費傾向を評価します。

図 11: SaaS 指標の取り込みと視覚化

このデータを取得し表面化させるアーキテクチャは、比較的単純です。これらの SaaS 指標を伝え、発行し、取り込み、集約し、視覚化するために必要なメカニズムすべてが含まれています。図 11 は、SaaS 指標環境を AWS で構築するために使用できる、アーキテクチャ図を示しています。

取得する指標データのソースは多様となります。図が示すように、ソリューションはネイティブの AWS ソース (例えば CloudWatch) から指標の一部を取得する必要がある場合があります。ただし、このデータの大部分は、SaaS アプリケーションに実装したコードからのものです。ドメインのデータのビジネスおよび運用上の価値を最大限にできるインサイトを的確に取得する指標の発行に投資します。

ソースからのデータは、通常はアプリケーションのさまざまな種類の消費 (カウント、期間、機能など) を表すことができる、一般的なスキーマとともに表されます。この例では、このデータは Amazon Data Firehose を使用して取り込まれ、データを Amazon Redshift に発行します。最後に、Amazon Quick が、テナントと階層の傾向を確認するために組織全体で使用される、さまざまなダッシュボードの構築に使用されます。