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

SaaS on AWS を成功に導くためのポイントとは ? 第 7 回

2021-11-02
ビジネス x クラウド

青嶋 智久

こんにちは ! パートナーソリューションアーキテクトの青嶋です。

今回で 7 回目を迎えるということで、いよいよこの連載も中盤に差し掛かってまいりました。本稿では SaaS におけるメトリクスの取得と可視化について解説していきます。メトリクスとは時系列に整理されたデータの集まりです。メトリクスを収集し分析することで、様々な指標を作成しビジネスに活用することができます。

メトリクスのビジネス活用は SaaS ビジネスにおいても重要かつ幅広いテーマになります。本稿では SaaS におけるメトリクス活用の概観を知るために、SaaS において役立つメトリクスの説明、テナントに関連付けたメトリクスの収集、収集したメトリクスの可視化という流れで解説を行なっていきます。

この連載記事のその他の記事はこちら

↓ SaaS on AWS を成功に導くためのポイントとは バックナンバー ↓
  • ↓ SaaS on AWS を成功に導くためのポイントとは バックナンバー ↓
  • 第 1 回 SaaS on AWS を成功に導くためのポイントとは ?
  • 第 2 回 SaaS ビジネスの成否を分けるテナント分離戦略
  • 第 3 回 動的なポリシー生成を使ったテナント分離
  • 第 4 回 SaaS on AWS における認証認可の実装パターンとは ?
  • 第 5 回 SaaS におけるオンボーディングとは ?
  • 第 6 回 SaaS におけるデータパーティショニング設計の勘所
  • 第 7 回 SaaS におけるメトリクスの取得と可視化

SaaS において役立つ様々なメトリクス

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

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

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

1) 開発 / 運用の俊敏性

開発サイクルを素早く回せているか、また障害復旧を短時間で実現できているかなど、SaaS において開発や運用の俊敏性は重要な視点です。日々の開発や運用をメトリクスから分析することで、現状や改善の結果を定量的に把握し、後の決断に役立てることができます。例えば開発であれば、リリースにかかる時間や、リリース頻度などが、運用であれば平均検出時間 (MTTD) があり平均復旧時間 (MTTR) などが挙げられます。

2) ユーザーエクスペリエンス

SaaS アーキテクチャーにおいて、利用者に十分な性能が提供できているか、性能が落ちているテナントはないかは、ユーザーエクスペリエンスに影響する重要な観点です。参考になるものとしては例えばリクエスト/レスポンスのレイテンシーや、CDN のキャッシュヒット率などのメトリクスがあります。メトリクスを常に確認できるようにすることで、レイテンシーが想定より高過ぎるからアーキテクチャーを見直そうなど、改善活動に早期に取り組むことができるようになります。

3) システム / テナント内でのパフォーマンス

利用者のアクティビティのメトリクスから、サービスにどのような負荷がかかっているかを知ることができます。サービスの負荷状況をメトリクスから知ることで、ボトルネックとなっている箇所の特定やアーキテクチャーの改善の判断に役立てることができます。例えば CPU やメモリの使用率の高いリソースを特定し改善するなどです。また SaaS ではテナントごとの利用状況を知ることも重要です。例えばテナントごとの負荷状況の偏りから、テナント分離戦略を再検討することができます。

4) システム / テナントの稼働状況

サービスを提供する際には、そのシステムの稼働状況を知ることは重要なテーマです。例えばアプリケーションのヘルスチェックやリクエスト/レスポンスのエラー率を知ることで、障害復旧やシステム改善をいち早く行えるようになります。またテナントごとの稼働状況を把握することも重要です。テナントごとの稼働状況を把握することで、何かシステムに問題があった際に、どのテナントに影響が出ているか即座に判断ができるようになります。

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


テナントごとのメトリクスの取得

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

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

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

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

img_saas-metrics-visualization_01

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

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


メトリクスの可視化

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

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

SaaS においても、ダッシュボードを使った分析結果の可視化は重要なトピックです。ではこのダッシュボードはどのように構築すればいいのでしょうか。

こちらの図は、AWS のサービスを使ってメトリクスを可視化するアーキテクチャーの例になります。

img_saas-metrics-visualization_02

このアーキテクチャーでは、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 内にデータをロードします。

Amazon Redshift に保存されたデータは、QuickSight から読み出してダッシュボードに表示させる形になります。メトリクスにテナント ID が関連付けられていれば、テナントごとの分析結果をダッシュボード上に表示させることができます。

例えばこちらの図は、プラン (Tier) ごと、テナントごとのストレージ使用量のダッシュボード例です。左側のグラフがプランごとのストレージ使用量、右側のグラフがテナントごとのストレージ使用量になっています。

img_saas-metrics-visualization_03

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

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

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


まとめ

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

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

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

この連載記事のその他の記事はこちら

↓ SaaS on AWS を成功に導くためのポイントとは バックナンバー ↓
  • ↓ SaaS on AWS を成功に導くためのポイントとは バックナンバー ↓
  • 第 1 回 SaaS on AWS を成功に導くためのポイントとは ?
  • 第 2 回 SaaS ビジネスの成否を分けるテナント分離戦略
  • 第 3 回 動的なポリシー生成を使ったテナント分離
  • 第 4 回 SaaS on AWS における認証認可の実装パターンとは ?
  • 第 5 回 SaaS におけるオンボーディングとは ?
  • 第 6 回 SaaS におけるデータパーティショニング設計の勘所
  • 第 7 回 SaaS におけるメトリクスの取得と可視化

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

プロフィール

photo_aoshima-tomohisa

青嶋 智久
アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクト

モバイルアプリケーションエンジニアとしてキャリアをスタートする。その後、ウェブアプリケーション、Mobile Backend as a Service (MBaaS)、DevOps システムに携わり 2021 年にアマゾン ウェブ サービス ジャパン合同会社に入社。
現在は SaaS 担当のパートナーソリューションアーキテクトとして、主に ISV のお客様を支援。

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
1

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する