SaaS におけるメトリクスの取得と可視化

SaaS ビジネスにとって、メトリクスを集めて可視化し分析することはビジネスサイド、技術サイドどちらの視点からも重要なトピックです。

例えばビジネスサイドの視点では、SaaS 利用者がどの機能をどのように利用しているか、どのようなトレンドがありサービス利用や収益に繋がっているのかなどが重要なポイントになります。また技術サイドの視点では、負荷に対してシステムは適切に対応できているか、テナントごとの稼働はどのような状況なのかなどが重要なポイントになります。

SaaS ビジネスを進めるにあたって役立つメトリクスは多岐に渡ります。ここでは開発者向けに、1) 開発 / 運用の俊敏性、2) ユーザーエクスペリエンス、3) システム / テナント内でのパフォーマンス、4) システム / テナントの稼働状況について、どのようなメトリクスがあり役立てることができるかを説明していきます。

ここまでご紹介したように、SaaS に関わるメトリクスは多岐に渡ります。特に SaaS の場合は、テナントに関連したメトリクスが必要なのが特徴的です。そのため SaaS ではテナントに関連付けたメトリクスの取得を行うことを考えなければなりません。また全てのメトリクスを追うのではなく、展開している SaaS ビジネスにとって重要な指標を判断し活用していくことも重要です。

SaaS ビジネスを進めるにあたって取り扱うメトリクスは多くありますが、ここでは SaaS におけるメトリクスというところで、テナントごとのメトリクスをどのように収集するかを説明していきます。

各テナントのメトリクスを得るためには、アプリケーション内でそのメトリクスがどのテナントに紐付くか特定し、メトリクス収集時にテナント情報を付与する必要があります。ここで重要な考え方となるのが 第 3 回、第 4 回 でも取り扱ったテナントコンテキストです。JWT トークンには、テナントコンテキストとしてユーザーやテナント情報が含まれています。JWT からテナントコンテキストを取り出すことで、そのリクエストがどのテナントによるものなのか判断できるようになります。

メトリクスを出力する場合には、このテナントコンテキストの情報をメトリクスに含めることで、そのメトリクスがどのユーザーでどのテナントに関するものなのか分類できるようになります。

以下の図は、JWT からユーザーやテナント情報を取り出し、Amazon CloudWatch や AWS X-Ray にテナントに関連付けたデータを渡すアーキテクチャーの例になります。CloudWatch は、ログやメトリクスといったモニタリングデータを収集し、統合されたビューをユーザーに提供するサービスです。AWS X-Ray はアプリケーションのリクエスト処理に関するデータを収集して分析できるようにすることで、パフォーマンスの問題やエラーの根本原因の特定を助けるサービスになります。以下の図の AWS Lambda では、JWTからテナントコンテキストを取り出し、メトリクスとトレースデータにテナントコンテキストを紐づけて CloudWatch と X-Ray にメトリクスを渡しています。CloudWatch と X-Ray のどちらもフィルタリングの機能を提供していますので、メトリクスに紐付けたテナントコンテキストの情報から、そのメトリクスがどのテナントによるものなのか判断することができます。

CloudWatch に集められたメトリクスは、AWS マネジメントコンソール上の CloudWatch  コンソールから確認することができます。CloudWatch にメトリクスを送信する際にメトリクスデータの Dimensions にテナント ID が定義されていれば、テナント ID でフィルタをしたり、複数のテナント ID のメトリクスを同時に一つのグラフで表示できたりします。また出力したメトリクスは、後に様々な種類の分析にかけられるよう、データレイクにも保存するのもおすすめです。

データレイクとは、構造化データと非構造化データのすべてを保存できる大規模な一元化されたデータリポジトリです。AWS のサービスでは Amazon S3 を活用することで、簡単にデータレイクを構築することができます。Amazon S3 はスケーラビリティのあるオブジェクトストレージのサービスであり、Amazon S3 にもメトリクスを保存することで、ビッグデータ処理、リアルタイム分析、機械学習などの多様な分析ができる下地を整えていくことができます。

メトリクスを収集しただけでは、SaaS のビジネス的、技術的な判断に活かすことはできません。集めた情報を整理し分析することで、SaaS ビジネスの全体像の把握とビジネス判断に繋げることができるようになります。

可視化をすることは、直感的な理解を助け、意思決定を早める点でとても有効です。可視化を実現する手段にはダッシュボードがよく使われます。ダッシュボードとは、重要な分析結果を集めて、一目で理解できるようにまとめて見える化したものです。ダッシュボードを使うことで、関係者の間で迅速かつシンプルにポイントとなる分析結果を共有することができます。

このアーキテクチャーでは、SaaS のアプリケーションから Amazon Kinesis Data Firehose を介してメトリクスが集められ、Amazon Redshift データベースに保存し、Amazon QuickSight を使って可視化を行っています。

Kinesis Data Firehose はストリームデータをデータレイクやデータストアなどに送るサービスです。Kinesis Data Firehose はストリーミングデータをキャプチャして変換し、リアルタイムにデータの転送ができます。Amazon Redshift はデータウェアハウスのサービスになります。データウェアハウスとは分析するために時系列に整理された構造化データを保管することができる保管庫です。そのため Amazon Redshift は大量のデータを短時間で読み出し・分析することに最適化されています。QuickSight では Amazon Redshift に保管されたデータを使ってダッシュボードを構築しています。

QuickSight は BI ツールのサービスです。BI とはビジネス・インテリジェンスの略称で色々なデータを収集、蓄積、分析することでビジネスの意思決定に役立てることを意味します。QuickSight を使うことで SaaS ビジネスおよびアーキテクチャーの分析に役立つカスタマイズしたダッシュボードを構築できるようになります。

Kinesis Data Firehose に取り込まれたデータが Amazon Redshift にストリーミングされる流れですが、Kinesis Data Firehose はまずデータを Amazon S3 のバケットにストリーミングします。そしてデータが S3 に保存された後に、Kinesis Data Firehose は Amazon Redshift の COPY コマンドを発行して、Amazon S3 バケットから Amazon Redshift 内にデータをロードします。

ストレージ使用量にテナント ID が関連付けられているため、テナントごとのストレージ使用量の違いが一目で分かります。

一目で分析結果の特徴が分かるのは素早い判断に大いに役立てることができます。例えば急激にシステム全体のストレージ使用量が増加した際に、このテナントごとのストレージ使用量のグラフを見て、まず上位 3 つのテナントのストレージの利用状況の詳細を調査してみようといった活用ができます。

また QuickSight は、Amazon Redshift 以外にもマネージドリレーショナルデータベースの Amazon Aurora や Amazon S3 のデータを SQL で分析できる Amazon Athena など、様々なサービスと連携できるようになっています。システムに合わせて QuickSight と連携していただき、重要な情報となる分析を進め、SaaS ビジネスの様々な意思決定に役立てることができます。

今回は SaaS におけるメトリクスと可視化というところで、SaaS に関連するメトリクスの説明からテナントと紐付けたメトリクスの取得、メトリクスの可視化と解説を行いました。

メトリクスの分析と可視化は SaaS ビジネスを成長させるために必要不可欠な要素であり、ビジネス面、技術面どちらにおいても有用な判断軸を与えてくれるものです。また今回のアーキテクチャ例では AWS サービスを利用したアーキテクチャーをご紹介させていただきましたが、他にも様々な AWS サービスやサードパーティー・ソリューションを活用することもできます。重要なのは SaaS ビジネスのドメインに合った指標をメトリクスの収集と分析から得て、ダッシュボードを使って可視化し、素早くビジネス上の意思決定に役立てていただくことです。定期的に今の環境はどうだろうかと振り返っていただき、自身の SaaS ビジネスに合ったメトリクス・インフラストラクチャーになっているかを見直していただき、これからの SaaS ビジネスの改善に繋げていっていただければと思います。

それでは次回の連載もお楽しみに !