次の方法で共有

マルチテナント ソリューションの価格モデル

  • [アーティクル]

適切な価格モデルにより、テナントの数が増えたり新しい機能を追加したりしても、収益性を維持することができます。 商用のマルチテナント ソリューションを開発する際の重要な考慮事項は、製品の価格モデルを設計する方法です。 この記事では、考慮できる価格モデルと関連するトレードオフに関する技術的な意思決定者向けのガイダンスを提供します。

収益性を理解する

製品の価格モデルを決定するときは、サービスを提供するために、顧客の "価値に対する利益" (ROV) と "売却済商品の原価" (COGS) のバランスをとる必要があります。 より柔軟な商用モデルを提供すると、顧客の ROV が増加する可能性がありますが、ソリューションのアーキテクチャと商用の複雑さが増し、COGS も増加する可能性があります。

ソリューションの価格モデルを開発する場合は、次の質問を検討してください。

  • COGS はソリューションから得られる利益よりも高くなるか? 不採算の価格モデルアプローチは一定期間機能する可能性がありますが、長期的には持続できません。
  • ユーザーの増加や使用パターンの変化に基づいて、COGS が時間の経過と共に変化する可能性はあるか? COGS と成長をモデル化して、成長に合わせてソリューションが不採算になるかどうかを理解します。
  • 価格モデルの運用に必要な情報の測定と記録は、どの程度の難しさか? たとえば、顧客が行った API 呼び出しの数に基づいて顧客に課金する予定がある場合は、各顧客によって行われた API 呼び出しを測定する方法を特定することが重要です。
  • 価格モデルでは、製品の使用が推奨されませんか? 価格モデルによって、一般的なアクティビティに非常にコストがかかるなど、顧客が製品から達成できる潜在的な価値が低下する状況を避けます。 この構造により、不一致のインセンティブが作成され、顧客へのシグナル伝達が混在する可能性があります。
  • 顧客がソリューションを過剰に使用している場合、それはもう利益にならないことを意味するか? 誤用が心配な場合は、レート制限のようにガードレールを配置します。

収益性に影響を与える、いくつかの重要な要因があります。

  • Azure サービスの価格モデル。 ソリューションを構成する Azure またはサードパーティのサービスの価格モデルは、どのモデルが収益性が高いかに影響を与える場合があります。

  • サービスの使用パターン。 ユーザーは、勤務時間中にしかソリューションにアクセスする必要がない場合や、多数のユーザーのごく一部に過ぎない場合があります。 使用量が少ないときに未使用容量を減らすことで、COGS を減らすことができますか?

  • ストレージの増加。 ほとんどのソリューションは、時間の経過と共にデータを蓄積します。 データが多いほど、データの保存と保護にかかるコストが高くなり、テナントあたりの収益性が低下します。 記憶域クォータを設定したり、データ保持期間を適用したりできますか?

  • テナントの分離。 使用する テナント モデル は、テナント間の分離レベルに影響します。 リソースを共有する場合に、テナントがサービスをどのように過剰に利用したり悪用したりする可能性があるかを考慮する必要がありますか? テナントの分離レベルは、すべてのユーザーの COGS とパフォーマンスにどのように影響しますか?

    一部の価格モデルは、リソース割り当てに関する追加の制御なしでは、収益性は高くありません。 たとえば、定額料金モデルを維持できるようにするために、サービス調整の実装が必要な場合があります。

  • テナントのライフサイクル。 たとえば、顧客離れ率が高いソリューションや、より高いオンボーディング作業を必要とするサービスでは、特に消費ベースのモデルを使用して価格を設定する場合、収益性が低下する可能性があります。

  • サービス レベルの要件。 より高いレベルのサービスを必要とするテナントは、ソリューションにもはや収益性がないことを意味する場合があります。 それに応じて価格モデルを計画できるように、顧客のサービス レベルの期待と義務を明確にすることが重要です。 サービス レベルの要件が異なるお客様には、異なる価格レベルを使用することを検討してください。

一般的な価格モデル

マルチテナント ソリューションでよく使用される価格モデルは多数あります。 これらの価格モデルのそれぞれには、関連する商業上の利点とリスクがあり、アーキテクチャに関する追加の考慮事項が必要です。 これらの価格モデルの違いを理解しておくことが重要です。そうすることで、ソリューションが進化しても収益性を維持できるようになります。

注意

ソリューションに複数のモデルを提供することも、モデルを組み合わせることもできます。 たとえば、ユーザー数がかなり安定している顧客にユーザーごとのモデルを提供したり、使用パターンが変動している顧客に従量課金モデルを提供したりできます。

価格モデルを選択するときは、顧客の観点から何が理にかなっているかを検討してください。 価格モデルが複雑すぎる場合や抽象的な場合は、コストの見積もりに苦労する可能性があります。 テナントのビジネス コンストラクトに価格を結び付けるのを目指します。

使用量ベースの価格

従量課金モデルは、"従量課金制" または "PAYG" と呼ばれることもあります。 サービスの使用が増えると、収益が増えます。

使用量の増加に応じて収益が増加することを示す図。

使用量を測定する際には、ソリューションに追加されるデータの量などの単純な要因を考慮することができます。 または、使用量属性の組み合わせを一緒に検討することもできます。 従量課金モデルには多くの利点がありますが、マルチテナント ソリューションに実装するのは難しい場合があります。

利点: 顧客の観点からは、ソリューションを使用するために必要な先行投資が最小限に抑えられているため、このモデルに新規参入する際の障壁は低くなります。 サービス オペレーターとしての観点からは、顧客の使用量と自分の収益が増加するにつれて、ホスティングと管理のコストが増加します。 この増加により、拡張性の高い価格モデルにすることができます。 従量課金モデルは、ソリューションで使用される Azure サービスも使用量ベースである場合に特に効果的です。

複雑さと運用コスト: 従量課金モデルは、使用量の正確な測定と、この使用量をテナントごとに分割することに依存しています。 これは、多くの分散コンポーネントがあるソリューションでは特に、困難な場合があります。 課金と監査のために詳細な使用量の記録を保持し、また顧客が使用量データにアクセスする方法を提供する必要があります。

リスク: 従量課金では、コストを削減するために、システムの使用量を減らすように顧客に動機付けをすることができます。 さらに、従量課金モデルは予測できない収益源をもたらします。 これは、"容量予約" を提供することで軽減できます。この場合、顧客は、一定レベルの使用量に対して前払いで支払うことになります。 サービス プロバイダーは、この収益を利用して、ソリューションの改善に投資したり、運用コストを削減したり、機能を追加して価値に対する利益を高めたりすることができます。

注意

容量予約を実装してサポートすると、アプリケーション内の請求プロセスが複雑になる場合があります。 また、顧客が払戻を受けたり容量予約を交換したりする方法の検討が必要な場合があります。また、これらのプロセスにより、商業上および運用上の課題が加わる可能性もあります。

ユーザーごとの価格

ユーザーごとの価格モデルでは、サービスを使用しているユーザーの数に基づいて顧客に課金する必要があります。

ユーザー数が増えるにつれて収益が増加することを示す図。

ユーザーごとの価格モデルは、マルチテナント ソリューションでの実装が簡単なため、非常に一般的です。 ただし、それらはいくつかの商業的リスクに関連しています。

利点: ユーザーごとに顧客に請求する場合は、収益源を簡単に計算して予測することができます。 さらに、各ユーザーに対してかなり一貫した使用パターンがあると仮定すると、収益はサービス導入と同じ速度で増加するため、このモデルは成長に応じてスケーラブルになります。

複雑さと運用コスト: ユーザーごとのモデルは実装が簡単な傾向があります。 ただし、状況によっては、ユーザーごとの使用量を測定する必要があります。これにより、1 人のユーザーの COGS が収益性を維持していることを確認するのに役立ちます。 使用量を測定し、それを特定のユーザーに関連付けることで、ソリューションの運用上の複雑さを高めることができます。

リスク: ユーザーの使用パターンが異なると、収益性が低下する可能性があります。 たとえば、ソリューションの使用が多いユーザーは、使用が少ないユーザーよりもサービスにコストがかかる可能性があります。 さらに、ソリューションの価値に対する利益 (ROV) は、購入したユーザー ライセンスの実際の数には反映されません。 多数の受信者にメールを送信するなど、ユーザーに直接関連しない機能がソリューションに含まれている場合、COGS が増加しても収益が増加しない可能性があります。

アクティブ ユーザーごとの価格

このモデルは、 ユーザーの価格に似ていますが、予想されるユーザー数に対して顧客からの事前コミットメントを要求するのではなく、実際にサインインして一定期間にわたってソリューションを使用するユーザーに対してのみ課金されます。

ユーザー数の増加ではなく、アクティブ ユーザー数の増加に伴って収益が増加することを示す図。

これは、意味のある期間であればいつでも測定できます。 月単位の期間が一般的であり、このメトリックは、多くの場合、"月間アクティブ ユーザー" または "MAU" として記録されます。

利点: 顧客の観点からすると、このモデルでは無駄が最小限であるため、投資とリスクが少なくて済みます。未使用のライセンスは課金対象ではありません。 これは、ソリューションをマーケティングしたり、大企業の顧客向けにソリューションを成長させたりするときに特に魅力的です。 サービス所有者としての観点からは、ROV は、月間アクティブ ユーザーの数によって顧客により正確に反映されます。

複雑さと運用コスト: アクティブ ユーザーごとのモデルでは、実際の使用量を記録し、請求書の一部として顧客が利用できるようにする必要があります。 ユーザーごとの使用量を測定すると、1 人のユーザーの COGS で収益性を維持するのに役立ちますが、その場合も、ユーザーごとの使用量を測定するには追加の作業が必要です。

リスク: ユーザーごとの価格と同様に、個々のユーザーのさまざまな使用パターンが収益性に影響を与える可能性があるというリスクがあります。 ユーザーごとの価格と比較すると、アクティブ ユーザーごとのモデルでは、予測できる収益源が少なくなります。 さらに、 割引価格 では、成長を刺激する便利な方法を提供しません。

ユニットあたりの価格

多くのシステムでは、ユーザー数は COGS 全体に最大の影響を与える要素ではありません。 たとえば、"モノのインターネット"、つまり "IoT" とも呼ばれるデバイス指向のソリューションでは、デバイスの数が COGS に最も大きな影響を与えることがよくあります。 これらのシステムでは、ユニットあたりの価格モデルを使用できます。このモデルでは、デバイスなどの "ユニット" を定義します。 次の図を参照してください。

デバイスの数が増えるにつれて収益が増加することを示す図。

さらに、一部のソリューションの使用パターンは非常に多様であり、一部のユーザーは COGS に不相応な影響を与えます。 たとえば、実店舗の小売業者に販売されるソリューションでは、各店舗のユーザー数に関係なく、店舗ごとの価格モデルが適切な場合があります。

利点: 個々のユーザーが COGS にそれほど影響を与えないシステムでは、システムのスケーリングと、結果として生じる COGS への影響の現実を表すには、ユニットあたりの価格が適しています。 また、顧客の実際の使用パターンに合わせて調整することもできます。 各デバイスで予測可能な一定量の使用が発生する多くの IoT ソリューションの場合は、ソリューションの成長に合わせてスケーリングするための効果的なモデルになる可能性があります。

複雑さと運用コスト: 一般に、ユニットあたりの価格は実装が簡単で、運用コストはかなり低くなります。 ただし、デバイスや小売店などの個々のユニットごとに使用量を区別して追跡する必要がある場合は、運用コストが高くなる可能性があります。 ユニットあたりの使用量を測定すると、1 つのユニットの COGS を特定できるため、収益性を維持するのに役立ちます。

リスク: ユニットあたりの価格モデルのリスクは、ユーザーごとの価格に似ています。 一部のデバイスや店舗が他のデバイスよりもソリューションの使用量が多い場合のように、一部のユニットで使用パターンが異なると、収益性が低下する場合があります。

機能およびサービスレベル ベースの価格

さまざまな価格帯でさまざまな機能レベルを備えたソリューションを提供することも選択できます。 たとえば、3 つの月単位の定額または単価を提供し、2 つは使用可能な機能のサブセットを含む基本的なオファリングを提供し、3 つ目はソリューションの機能の包括的なセットを提示します。

3 つのレベル間で収益が段階的に増加することを示す図。

このモデルは、レベルごとに異なるサービス レベル アグリーメントを提供する場合もあります。 たとえば、Basic レベルでは 99.9% の稼働率が得られますが、Premium レベルでは 99.99% の稼働率が得られる可能性があります。 より高いサービス レベル アグリーメント (SLA) は、より高い 可用性の目標を実現するサービスと機能を使用して実装できます。

このモデルは商業的に有益である可能性がありますが、うまく機能するには成熟したエンジニアリング手法が必要です。 慎重に検討すれば、このモデルは非常に効果的です。

利点: 機能ベースの価格は、必要な機能セットまたはサービス レベルに基づいてレベルを選択できるため、多くの場合、顧客にとって魅力的です。 また、追加機能やより高い回復性を必要とする顧客にアップセルを行うための明確なパスも提供します。

複雑さと運用コスト: 機能ベースの価格モデルは、各価格帯で利用可能な機能をソリューションで認識する必要があるため、実装が複雑になる可能性があります。 機能の切り替えは、機能の特定のサブセットへのアクセスを提供する効果的な方法ですが、これには継続的なメンテナンスが必要です。 また、テストするコード パスが増えるため、フィーチャー トグルにより高品質を確保するためのオーバーヘッドが増えます。 一部のレベルでより高いサービス可用性の目標を有効にすると、レベルごとに適切なインフラストラクチャ セットが使用されるようにするために、アーキテクチャがさらに複雑になることがあり、このプロセスによってソリューションの運用コストが増加することがあります。

リスク: レベルやオプションが多すぎると、機能ベースの価格モデルが複雑で混乱を招く可能性があります。 さらに、機能を動的に切り替えることに伴うオーバーヘッドにより、追加機能を提供する速度が遅くなる可能性があります。

フリーミアム価格

基本的な機能を備え、サービス レベルの保証がない、Free レベルのサービスを提供することを選択することもできます。 その後、追加機能と正式なサービス レベル アグリーメントを備えた別の有料レベルを提供することもできます (次の図を参照)。

Free レベルでのゼロから、有料レベルでのより高い金額への収益の増加を示す図。

Free レベルは期間限定の試用版として提供される場合もあり、試用期間中、顧客は完全または限定された機能を利用できる場合があります。 これはフリーミアム モデルと呼ばれ、事実上 機能ベースの価格モデルの拡張です。

利点: 無料の場合、ソリューションを市場に投入するのは非常に簡単です。

複雑さと運用コスト: 機能ベースの価格モデルの複雑さと運用コストのすべての懸念事項が当てはまります。 また、無料のテナントの管理に関連する運用コストも考慮する必要があります。 古いテナントがオフボードまたは削除されていることを確認しなければならない場合があります。また、無料のテナントの場合は特に、明確な保持ポリシーが必要です。 テナントを有料レベルに移行する場合は、より高い SLA を取得するために、Azure サービス間でテナントのデータまたはワークロードを移行することが必要になる場合があります。 また、有料レベルに移行するときは、テナントのデータと構成を保持することも重要です。

リスク: テナントが有料レベルへの切り替えを検討するのに十分な高さの ROV を提供する必要があります。 さらに、Free レベルの顧客にソリューションを提供するためのコストは、有料レベルの顧客からの利益率で賄う必要があります。

売却済商品の原価による価格設定

ソリューションの価格を設定して、各テナントがソリューションを構成するコンポーネントの共有を運用するコストのみを支払い、利益率を追加しないようにすることができます。 このモデル ( パススルー価格 または チャージバック とも呼ばれます) は、利益センターを意図していないマルチテナント ソリューションに使用される場合があります。

使用量の変化に伴い、時間の経過と共に収益が変化する様子を示した図。

売却済商品の原価モデルは、社内向けのマルチテナント ソリューションに適しています。 各組織単位はテナントに対応し、Azure リソースのコストをテナント間で分担します。 また、マルチテナント ソリューションを使用または拡張する他の製品やサービスの売上から収益が得られる場合にも適している場合があります。

利点: このモデルには利益の追加マージンが含まれないため、テナントへのコストは低くなります。

複雑性と運用コスト: 消費モデルと同様に、売却済商品の原価による価格設定は、 使用状況の正確な測定 とこの使用量のテナント別の分割に依存します。 消費量を追跡することは、特に多くの分散コンポーネントがあるソリューションでは、困難な場合があります。 課金と監査のために詳細な使用量の記録を保持し、また顧客が使用量データにアクセスする方法を提供する必要があります。

社内向けのマルチテナント ソリューションの場合、テナントがコストの概算見積もりを受け入れ、課金の監査要件が緩和される可能性があります。 このように要件が緩和される場合、ソリューション運用の複雑性とコストが軽減されます。

リスク: 売却済商品の原価による価格設定では、コストを削減するために、システムの使用量を減らすようにテナントが動機付けられる可能性があります。 ただし、このモデルは利益センターではないアプリケーションに使用されるため、これは問題にならない可能性があります。

定額料金

このモデルでは、ソリューションにアクセスするために、一定期間、テナントに定額料金が請求されます。 サービスの使用量、ユーザー数、接続するデバイス数、またはその他のメトリックに関係なく、同じ価格が適用されます。

使用量に関係なく、一定の収益を示す図。

これは、実装が最も簡単で、顧客が理解できるモデルであり、企業の顧客から求められることがよくあります。 ただし、新しい機能を追加し続ける必要がある場合や、追加の収益なしでテナントの使用量が増加した場合は、収益性が悪くなりやすい可能性があります。

利点: 定額料金は簡単に販売でき、顧客が理解して予算を立てるのも簡単です。

複雑さと運用コスト: 課金対象の顧客は使用量の計測や追跡を必要としないため、定額価格モデルは簡単に実装できます。 ただし、必須ではありませんが、COGS を正確に測定し、収益性を維持するために、テナントごとの使用量を測定することをお勧めします。

リスク: ソリューションを頻繁に使用するテナントがある場合、この価格モデルは収益性が悪くなりがちです。

割引価格

価格モデルを定義したら、割引価格によって成長を促進するための商業戦略を実装することを選択することもできます。 割引価格 は、使用量、ユーザーごと、およびユニットあたりの価格モデルで使用できます。

注意

通常、割引価格では、より複雑な課金構造のサポートを追加する以外に、アーキテクチャ上の考慮事項は必要ありません。 割引の商用上の利点に関する完全な説明は、この記事の範囲外です。

一般的な割引価格パターンは次のとおりです。

  • 固定価格。 購入または使用された量に関係なく、ユーザー、ユニット、または使用量ごとに同じコストがかかります。 これが最も簡単なアプローチです。 ただし、ソリューションを頻繁に使用する顧客は、割引を受けることで規模の経済性の恩恵を受けるべきだと感じるかもしれません。
  • 減衰価格。 顧客が購入または使用するユニットが増えるほど、ユニットあたりのコストが減ります。 これは、顧客にとっては商業的により魅力的です。
  • ステップ価格。 顧客がより多くを購入すると、ユニットあたりのコストが削減されます。 ただし、事前に定義された数量の範囲に基づいて、段階的な変更でこれを行います。 たとえば、最初の 100 人のユーザーの価格を高くし、次に 101 番目から 200 番目のユーザーに価格を下げ、その後でもう一度価格を下げることもできます。 このアプローチは、価格を掘り下げるよりも収益性が高い可能性があります。

次の図にこれらの価格パターンを示します。

価格モデルに適用できるさまざまな割引価格を示す図。

非運用環境の割引

多くの場合、顧客は、テスト、トレーニング、または独自の内部ドキュメントの作成に使用できる非運用環境へのアクセスを必要としています。 非運用環境では、通常、使用の要件と運用コストが低くなります。 たとえば、多くの場合、非運用環境はサービス レベル アグリーメント (SLA) の対象ではなく、 転送率の制限 はより低い値に設定される場合があります。 また、非運用ワークロードをサポートする Azure サービスでは、より積極的な 自動スケーリング を検討することもできます。

同様に、多くの場合、顧客は、非運用環境が運用環境よりも大幅に安価であることを期待しています。 非運用環境を提供する場合は、適切と思われるいくつかの代替手段があります。

  • 有料の顧客に対してすでに行っているような、 フリーミアム レベルを提供します。 これは注意深く監視する必要があります。組織によっては、運用するために追加のリソースを使用する、多くのテストとトレーニングの環境を作成する可能性があるためです。

    注意

    フリーミアム レベルを使用した期間限定の試用版は、通常、テストとトレーニングの環境には適していません。 顧客は通常、運用サービスの有効期間中は、非運用環境を利用できる必要があります。

  • サービスのテストまたはトレーニング レベルを、使用制限を低くして提供します。 このレベルの可用性を、既存の有料テナントを持つ顧客に制限することもできます。
  • 非運用テナントには、サービス レベル アグリーメントが低いかまったくない状態で、 ユーザーごと、 アクティブ ユーザーごと、または ユニットあたり の割引価格を提供します。
  • 定額料金を使用しているテナントの場合、契約の一部として非運用環境が取り決められる場合があります。

注意

機能ベースの価格は、通常、提供される機能が運用環境で提供されるものと同じでない限り、非運用環境には適していません。 これは、テナントでは通常、運用環境で使用できるものと同じ機能すべてについてテストし、トレーニングを行う必要があるためです。

収益性の悪い価格モデル

収益性の悪い価格モデルでは、得られる収益よりもサービスの提供に多くのコストがかかります。 たとえば、サービスの制限なしでテナントごとに定額料金を請求することもありますが、その場合は、使用量ベースの Azure リソースを使用し、テナントごとの 使用制限なしでサービスを構築します。 このような状況では、テナントがサービスを過剰に使用するため、サービス提供の収益性が悪くなるリスクがあります。

通常、収益性が悪い価格モデルは避けたいでしょう。 ただし、次のような状況では、収益性が悪い価格モデルを採用することもできます。

  • 増加を可能にするために無料のサービスが提供されている。
  • サービスまたはアドオン機能によって追加の収益源が提供される。
  • 特定のテナントをホストすると、新しい市場のアンカー テナントとしてそれらを使用するなど、別の商業的価値が得られる。

誤って収益性が悪い価格モデルを作成した場合、それらに関連するリスクを軽減するためのいくつかの方法があります。

  • 使用制限を使用してサービスの使用を制限します。
  • 容量予約の使用を要求します。
  • テナントに上位の機能またはサービス レベルに移行するよう要求します。 テナントの移動を促すために、収益性の高いサービス レベルでのみ新しい機能を利用できるようにすることを検討してください。

リスクの高い価格モデル

ソリューションの価格モデルを実装するときは、通常、それがどのように使用されるかについて想定する必要があります。 これらの想定が正しくないことが判明した場合や、使用パターンが時間の経過と共に変化した場合、価格モデルの収益性が悪くなる可能性があります。 収益性が悪くなるリスクのある価格モデルは、"リスクのある価格" モデルと呼ばれています。 たとえば、ユーザーがソリューションを使用する量を自分で制限すると予想される価格モデルを採用する場合は、リスクの高い価格モデルを実装している可能性があります。

ほとんどの SaaS ソリューションは、定期的に新しい機能を追加します。 これにより、ユーザーに対する ROV が増加し、ソリューションの使用量も増加する可能性があります。 これにより、新しい機能の使用によって使用量が多くなる場合、ソリューションは収益性が悪くなりますが、価格モデルではこれが考慮されていない可能性があります。

たとえば、使用量ベースのリソースを使用する新しいビデオ アップロード機能をソリューションに導入し、その機能のユーザーの取り込みが予想以上に高い場合は、 数の制限 と 機能とサービス レベルの価格の組み合わせを使用して価格リスクを軽減できるかどうかを検討します。

使用制限

"使用制限" を使用すると、価格モデルの収益性が悪くなるのを防いだり、1 つのテナントがサービスの容量を過剰に使用したりするのを防ぐためにサービスの使用を制限したりできます。 これは、1 つのテナントがリソースを過剰に使用することで他のテナントのエクスペリエンスに影響を与える可能性があるマルチテナント サービスで、特に重要になる可能性があります。

注意

使用制限を適用していることを顧客に知らせることが重要です。 顧客に使用制限を知らせずに制限を実装すると、顧客の不満につながります。 つまり、使用制限を前もって特定し、計画することが重要です。 目標は、制限を計画し、必要になる前に制限を顧客に伝えることです。

使用制限は、多くの場合、より高いレベルでより多くの使用量を提供するために、 機能およびサービス レベルの価格と組み合わせて使用されます。 制限は、システムのボトルネックやパフォーマンスの問題を引き起こすコア コンポーネントが過剰に使用された場合に、それらを保護するためにも一般的に使用されます。

転送率の制限

使用制限を適用する一般的な方法は、API または特定のアプリケーション関数に転送率の制限を追加する方法です。 これは、 調整パターンとも呼ばれています。 転送率の制限は、継続的な過剰使用を防ぎます。 これらは、定義された期間にわたって API への呼び出しの数を制限するためによく使用されます。 たとえば、API は 1 分間に 20 回しか呼び出すことができず、これよりも頻繁に呼び出されると、HTTP 429 エラーが返されます。

多くの場合、次のシナリオにはレート制限が含まれます。

  • REST API。
  • 非同期タスク。
  • 時間の影響を受けないタスク。
  • 実行に高いコストがかかる操作。
  • レポートの生成。

転送率の制限を実装するとソリューションの複雑さが増す可能性がありますが、Azure API Management などのサービスでは、 転送率の制限ポリシーを適用することでこれを簡単にすることができます。

価格モデルのライフサイクル

ソリューションの他の部分と同様に、価格モデルにはライフサイクルがあります。 アプリケーションが時間の経過と共に進化するにつれて、価格モデルの変更が必要になる場合があります。 これは、顧客のニーズの変化、商業的要件、またはアプリケーション内の機能の変更によって引き起こされる場合があります。 一般的な価格ライフサイクルの変更には、次のようなものがあります。

  • まったく新しい価格モデルの追加。 たとえば、現在 定額モデルを提供しているソリューションへの 従量課金モデル の追加。
  • 既存の価格モデルの廃止。
  • 既存の価格モデルへのレベルの追加。
  • 既存の価格モデルのレベルの廃止。
  • 価格モデルの機能の使用制限の変更。
  • 機能およびサービス レベルの価格モデルの機能の追加または削除。
  • 企業間 (B2C) の商用モデルから、企業間 (B2B) の商用モデルへの変更。 この変更により、企業の顧客向けの新しい価格構造が必要になります。

通常、多くの異なる価格モデルを一度に実装および管理することは複雑です。 また、これは顧客を混乱させます。 そのため、レベル数の少ない 1 つまたは 2 つのモデルのみを実装することをお勧めします。 これにより、ソリューションへのアクセスが容易になり、管理が容易になります。

注意

価格モデルと課金機能は、システムの他の部分と同じように、理想的には自動テストを使用してテストする必要があります。 価格モデルが複雑になるほど、より多くのテストが必要になるため、開発と運用の複雑さのコストが増加します。

価格モデルを変更する場合は、次の要因を考慮してください。

  • 契約上の影響。 テナントが特定の価格モデルに基づいて契約を結んだ場合は、それらの契約に誤って違反しないようにしてください。
  • 望ましさ。 新しい価格モデルの ROV を既存のテナントに明確に伝えます。 テナントが新しいモデルに移行できるように、新しいモデルを十分に魅力的にしてください。 廃止する予定の古い価格モデルをテナントが使用できないようにする方法を決定します。
  • タイムライン テナントが準備できるように、変更について十分な通知を行います。
  • 移行プロセス。 テナントが新しいモデルに簡単に移行できるようにする。
  • 価格リスクを軽減します。 新しい各価格モデルを評価して、 riskyかどうかを理解します。 たとえば、現在重要なリソースを過剰使用から保護しているレート制限を削除する場合は注意が必要です。 変更を通じて、サービスのパフォーマンスと使用率を監視して、継続的な満足度と収益性を確保できるようにします。
  • 請求書のショック リスクを軽減します。 価格モデルの変更により、 bill shock が発生する可能性があります。これは、予期しない請求に対する否定的な反応です。 価格モデルの変更を明確かつ積極的に伝達します。 変更の前後に各テナントの請求書を計算またはシミュレートして、変更後にテナントの支払額が大幅に増える状況を検出できるようにします。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

その他の共同作成者:

  • Bohdan Cherchyk | FastTrack for Azure のシニア カスタマー エンジニア
  • John Downs | プリンシパル ソフトウェア エンジニア
  • Chad Kittel | プリンシパル ソフトウェア エンジニア
  • Paolo Salvator | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

ソリューション内のテナントごとに 使用量を測定する 方法を検討します。