SaaS における料金プランとメータリング、ビリング

メータリングとは、テナントやユーザーが SaaS をどのように利用しているかを計測し、評価することです。SaaS は契約形態や利用状況によって利用できる機能に上限があることや、従量課金制により請求する金額が変わることがあるため、メータリングが必要になります。

第 7 回の連載 では、SaaS におけるメトリクスの取得と可視化について解説しました。
メトリクスを取得することとメータリングの違いは何でしょうか。

一見同じような概念に思われがちですが、利用目的が異なります。メトリクスの取得は、収集した情報をもとに SaaS 利用者がどの機能をどのように利用しているか、負荷に対してシステムは適切に対応できているかなどを分析するために用いられます。

一方で、メータリングは、メータリングにより収集された情報をビリングに利用することを目的としています。

メトリクスの取得とメータリングにおいて、アプリケーションから収集されるデータには重なりがありますが、利用目的やその後の使われ方によって呼び方が変わるということです。

ビリングとは、SaaS の料金プランや課金形態に応じてテナントに対して利用料金を請求することです。

ユーザーごとの利用状況をメータリングで集めた情報を手動で取得して、請求書の発行により手動で課金処理を行う方法もありますが、これではビジネスの成長に追いつかず、スケールが効きません。さらなる成長には自動化が必須となります。

ではメータリングとビリングを自動化して請求処理をスケールするためにはどのように実装すれば良いでしょうか ?

メータリングで得られたサービスの利用量やアクティビティ、その他様々なパラメータをテナントごとの利用プランに紐付け、課金額を算出します。

メータリングで評価する対象やビリングの方法はビジネスやそのドメインによって異なります。まずはどんな料金プランの設計が自社で展開するビジネスに合うのかを考える必要があります。その上で、料金プランに関係し指標となるデータをシステムから収集する必要があります。最後に、収集データから自動的に請求する仕組みを整えます。

そこで本稿では、上記の流れに沿って、架空の企業 AnyCompany 社を想定し、SaaS における料金プランの設計、メータリング、ビリングの方法について解説します。最後に AWS サービスやアーキテクチャについても触れるので、是非ご一読ください !

AnyCompany 社が提供する SaaS は、画像の編集と、編集した画像を特定のフォーマットで書き出す機能を持ちます。

このサービスの価値は、書き出しにおいて幅広いフォーマットに対応しており、拡張性のあるクラウドストレージをあわせ持つことです。インターネットに接続できれば、いつでも好きなデータにアクセスし、画像の編集と書き出しを行うことができます。また、他のユーザーとリアルタイムでデータを共有し共同編集できる機能もあります。

サービスのローンチに向けて、料金プランの設計とメータリング、ビリングについて考えていきます。

SaaS における料金プランの設計で最も重要なことは、提供する SaaS の価値がどこにあるのか ? を主軸に考えることです。

必ずしも AWS の各種リソースの利用料を、そのまま SaaS の課金額に反映させる必要はありません。

前回の連載 では、コストやアーキテクチャの最適化の観点から、テナントごとの利用量の把握と分析が重要だと説明しましたが、必ずしも AWS の各種リソースの利用料を直接的に SaaS の課金額に反映させる必要はありません。SaaS のユーザーからしてみたら、基盤となる AWS リソースの料金が関係するとは限らないからです。

サービスの価値を軸として考え、月ごとの書き出し数の上限がプランによって変わっています。また追加ストレージも、初期ストレージ容量から従量課金でストレージ容量を追加できるようになっています。

また、プランごとにユーザー数や共同編集機能の有無といった違いがあるのもポイントです。ライトプランやスタンダードプランでの利用に満足してもらい、将来的に上位のプレミアムに変更してもらうため、プラン間の差を明確化することで、より魅力的な料金プランを実現しています。

サービスの価値となり、料金プランを考える上で主軸となる指標の組み合わせをビリングユニットと呼びます。

AnyCompany 社の場合、ビリングユニットは以下になります。

• 書き出し数
• ストレージ容量
• ユーザー数
• 共同編集機能

ビリングユニットが定まると、メータリングによって計測対象となるデータも自ずと決まります。

AnyCompany 社の場合、書き出し機能を使うための API が呼び出されるたびに、利用者のテナント ID をタイムスタンプとともにデータベースやログに記録します。

ストレージ利用量に関しても、保存されたデータの容量をユーザーごとに集計して合計サイズを保持しておきます。デフォルトで付与されるストレージ容量を超えた従量課金分に関しては、保持されたデータから課金額を算出します。

ユーザー数は、登録しているユーザーの数を保持しておき、上限に達している場合は新規の登録を受け付けないように実装します。

共同編集機能はプランによって利用可否が決まるため、フラグを用いてプランごとに利用できる機能を制御します。これを 機能フラグパターン と呼びます。ユーザーごとに設定されたフラグを参照し、契約プランに紐づいたフラグに応じてフロントの画面描画やバックエンドの API 呼び出しを制御します。

AnyCompany 社の料金プラン設計とビリングユニットが決まり、記録対象のデータも定まりました。記録の仕組みが整った後に、具体的にビリングを行う方法を決定します。

ビリングを行うには自前でシステムを構築する方法と、サードパーティ (ビリングプロバイダー) が提供するサービスを使用する方法があります。いずれにせよ、実際に支払いを処理するコンポーネントはメインのサービスとは別システムとして独立させておくのが望ましいです。SaaS として提供するサービスと実際にビリングを処理するシステムでは目的や処理の内容などのスコープが違うからです。

システムを分離させ、疎結合なアーキテクチャを採用することで、仮に SaaS のメインシステムに大きな負荷がかかっても、ビリングの処理は継続できるメリットがあります。

AnyCompany 社の開発者が本来集中したいことは、提供するサービスの機能改善や新機能の追加です。そのため AnyCompany 社では、サービスの核ではないビリング部分にサードパーティのサービスを使っています。サードパーティのサービスを使うことで、価値提供にフォーカスし、ビジネスを効率化できます。

AWS SaaS Boost では、ビリングプロバイダとして Stripeとの統合例が挙げられています。AWS SaaS Boost は、独立系ソフトウェアベンダ (ISV) としての SaaS への移行を加速させるのに役立つ、オープンソースのリファレンス環境です。

サードパーティのサービスを利用する場合は、そのサービス側にもユーザーやサブスクリプションの情報を持ちます。管理が 2 箇所に分散するため、これを同期しないと不整合が起きます。例えば、ユーザーの料金プランをスタンダードからプレミアムに変更する場合には、SaaS 側の情報とサードパーティの情報を同期する必要があります。

更新の処理には API を都度叩く方式もありますが、課金には厳密な同期性が求められないため、イベント駆動のアーキテクチャを選択できます。イベント駆動で非同期な実装の方が、ビリングシステムへのアクセス頻度を安定させることができ、スケーラブルなアーキテクチャが組めます。イベントを機に SaaS のサービス側にも情報を連携させるためには、サーバーレスイベントバスで、イベント駆動型アプリケーションの大規模な構築を容易にする Amazon EventBridge が利用可能です。実際、SaaS Boost でもEventBridge との連携 が行われています。

AWS 上で SaaS を構築する場合、AWS Marketplace を利用してサービスを販売する方法もあります。サービスが動く基盤とビリングプロバイダーの両方において AWS を利用することで管理や運用を簡潔にできます。AWS Marketplace では、毎月の利用量に基づく従量課金や、月や年単位の前払い方式、またはその組み合わせで SaaS を販売できます。SaaS ベースの製品をAWS Marketplace 上で販売する方法について詳しく知りたい方は AWS Marketplace 販売者ガイドの SaaS (Software as a Service) ベースの製品ページ をご覧ください。

ここでは、メータリングとビリングを実現するためのアーキテクチャの例をご紹介します。

メータリング対象のデータに関連するビリングユニットについて再度触れておきましょう。ビリングユニットは、料金プランを設計においてベースとなるデータの組み合わせのことです。

メータリング API を別途用意し、SaaS のサービスやその機能の利用をイベントとして記録します。上の画像の例では、1) ユーザーが SaaS を利用した時に、アプリケーション内部から 2) Amazon API Gateway に対してリクエストを送ります。このリクエストにはどの機能を利用したのかを表すメソッドとタイムスタンプが含まれます。API Gateway はその後リクエストを 3) AWS Lambda に送り、Lambda 関数を起動します。この Lambda 関数内の処理では、4) イベントの情報を NoSQL データベースである Amazon DynamoDB に格納しています。

格納する情報は一例ですが、ここではサービスの API エンドポイントとメソッドをタイムスタンプとともにテナントごとに記録しています。AnyCompany 社の料金プランでは、画像の書き出し数の上限や、デフォルトのストレージ容量を超えた分の従量課金が設定されているので、現在の利用状況を集計した値も 別途データベースに持たせておく必要があります。ビリングを行う際には、この集計された値をもとに最終的な請求処理を行います。

メータリングにおけるデータの取得はその後の課金処理に関わるため非常に重要な部分です。AnyCompany 社の場合は画像の書き出しやストレージ容量の記録には、ユーザーが不利にならないようにするためにも正確性が求められます。一方で、ビリングに関係ない部分に関しては、一部ログの欠損なども許されることから通常のロギングの範疇で記録します。

記録する情報やその粒度はメータリングの対象となるデータによります。もちろん場合によりますが、設定した料金プランに合わせて必要十分な情報を取得するのにとどめるのが良いでしょう。

続いて、メータリングで取得した情報をもとに、ビリングプロバイダーと連携して実際に課金するためのアーキテクチャをご紹介します。

上図のアーキテクチャでは、1) サービスからビリングに必要な情報をまとめたイベントデータを JSON として、EventBridge に渡しています。ここでは、Lambda サービスが EventBridge と統合されており、2) Lambda サービスは EventBridge から受け取ったイベントデータを元に Lambda 関数を起動します。この Lambda 関数は 3) DynamoDB にメータリングで格納されたテナントごとの情報を集約し、4) 集約後の情報をビリングプロバイダーへと連携しています。

AnyCompany 社の料金プランでは、プランごとにデフォルトで付与されるストレージ容量を超えた分に関しては、超過分が従量課金で請求されるため、この段階で課金額の算出も行います。

サードパーティーのビリングプロバイダーを利用するために、API キーを Lmabda 関数内で使用しています。5) API キーのような機密情報の管理、取得には AWS Secrets Manager を用いることで、セキュアに保つことができます。

月次のように課金を定期的に行うケースでは、このように、EventBridge を使ってAWS のサービスをスケジュールに従って実行できます。

今回の連載では架空の企業である AnyCompany 社を想定し、SaaS における料金プランの設計からメータリングとビリングの方法を、簡単なアーキテクチャについて触れながら解説しました。

SaaS 事業者は提供するサービスの価値を主軸として、ユーザーのニーズを満たすような料金プランを設計する必要があります。今回の AnyCompany 社のプラン設計にはありませんが、長期の利用をコミットすることを条件に料金の交渉などに応じるケースもあります。これは提供者にとっても一定の売り上げを確約できますし、利用者にとってもディスカウントが得られるので双方にとってメリットがあります。

料金プランが設計できるとメータリングで取得するデータが決まります。ビリングにおいてはサードパーティーのシステムを使うことで、提供するサービスの価値向上にフォーカスでき、ビジネスを加速できます。

最初に決めた料金プランは変更されることもあるでしょう。重要なのはビジネスのフェーズを考慮しユーザーの声を反映させたプランとなっていることです。AnyCompany 社の料金プラン設計は一例です。料金プランの設計の仕方や、メータリングやビリングといった考え方について少しでも理解の助けとなれば幸いです。

次回はいよいよ連載最終回です ! これまでの連載を振り返りつつ、楽しみにお待ちください !!