Azure での SaaS ワークロードの設計手法
独立系ソフトウェア ベンダー (ISV) において、ソリューションが "自社のビジネスである" 場合、サービスとしてのソフトウェア (SaaS) ソリューションの要件を慎重に計画する必要があります。 ソリューションの直接ユーザーは、他の企業や個々のコンシューマーなどのビジネス顧客です。 このビジネス モデルでは、ワークロード要件と顧客のニーズの両方を設計のアーキテクトとして考慮する必要があるため、期待値が高くなります。
この記事では、要件を体系的に定義して調整するために使用できる設計手法について説明します。 常にビジネスの要件に合うように、さまざまな設計上の意思決定やテクノロジのオプションが不明なときには、この手法を見直してください。 SaaS ワークロードの構築は反復的なプロセスであり、進化する市場や顧客のニーズに柔軟に適応する必要があります。 このフレームワークは、マーケティングや営業のチームと協力して技術的な意思決定を検証し、顧客のフィードバックを評価して継続的な改善を行うのに役立ちます。
ビジネス モデルの設計
ビジネスの要件がソリューションのダウンストリームにどのように影響するかを理解することが重要です。 意思決定の際は、次の点を考慮してください。
リソースをデプロイする場所によって、使用できるアーキテクチャのパターンが制限されます。 Azure サブスクリプション内のすべてのリソースをデプロイすることも、顧客がソリューションを購入してそれを独自の Azure サブスクリプションにデプロイすることもできます。 もしくは、ワークロードで、顧客が独自の Azure サブスクリプションにデプロイするリソースを使用できます。
たとえば、顧客の環境にソフトウェアをデプロイする場合、各顧客が専用のリソースを含む独自のスタンドアロン環境を持っているため、共有リソースのみに基づくアーキテクチャのパターンを使用することはできません。
詳細については、ISV デプロイ モデルに関する記事を参照してください。
価格モデルによって、ビジネスの収益が決まります。これは、許容される売却済商品の原価に影響します。 この動きは、技術的なアーキテクチャに直接影響します。
詳細については、価格モデルに関する記事を参照してください。
提供する機能または製品が、アーキテクチャに影響を与える可能性があります。 特定の機能を選択するときに、技術的なアーキテクチャに変更や追加を行わなければならない場合があります。 顧客ごとに異なる製品を提供する場合、これらのバリエーションをサポートする必要があるため、より複雑なアーキテクチャになる可能性もあります。
顧客の要件の設計
顧客の要件を念頭に置いて、ソリューションを設計しましょう。 顧客がソリューションに追加の要件を持つことがあり、その場合はソリューションが満たす必要があるスーパーセットが作成されます。 このような追加要件は、ビジネスのニーズや他の顧客のニーズと競合する場合があります。 これらの要件がビジネスのニーズと異なる場合や、新たな制限を生じさせる場合、ソリューションの意思決定が困難になる場合があります。 たとえば、あなたのソリューションがセキュリティ標準を満たしていても、顧客が自社のビジネスを保護するために満たさなければならない、より厳しいセキュリティ要件を持っている場合があります。
このような追加要件に対応するように、柔軟なアーキテクチャを作成しましょう。 顧客の要件が独自の要件に影響しない場合は、それらをビジネス モデルに統合してみてください。 これらの調整のコストを計算しましょう。 顧客固有の要件で追加コストが発生する場合は、それに応じた請求を行うことを検討してください。
顧客の期待に応える現実的な信頼性の目標があることを確認し、それらを実現するためのアーキテクチャを設計します。
テナント モデルを設計する
ほとんどの SaaS ソリューションは、コスト効率を最大化するための主要な技術戦略としてマルチテナントに依存しています。 マルチテナントには、標準パターンを持たないさまざまな選択肢があります。 テナント モデルは、管理オーバーヘッド、コスト、データの分離など、アーキテクチャの側面に影響します。 ソリューションに適したバランスを見つけてください。 選択するテナント モデルは、顧客とビジネスのニーズのバランスを取る必要があるため、重要です。
次の記事が、情報に基づいた意思決定を行ううえで役立ちます。
アーキテクチャには、新規の、または今後の顧客の要件に基づいてテナント モデルを変更できる柔軟性が必要です。 たとえば、完全にマルチテナントのアーキテクチャを使用しながら、追加のセキュリティが必要な、規制が厳しい業界の新しい顧客を獲得する場合があります。 デプロイを垂直にパーティション化して、専用のスタンプを提供することができます。 この変更により、他のテナントよりも請求が必要かどうかに関するビジネス上の意思決定が発生します。 この設定によりリソースのコストと複雑さが増すため、請求が増えるのは理にかなっています。
Well-Architected への設計
SaaS ワークロードを設計するときは、システムが回復性があり、セキュリティで保護され、効率的で、パフォーマンスが高く、顧客の要件のバランスが取られるように、細心の注意を払ってください。 エンタープライズ アプリケーションとは異なり、SaaS アプリケーションの障害は、ビジネス、顧客、そしてユーザーにも影響を与える可能性があります。
意思決定ごとに、Azure Well-Architected フレームワークの柱の間のトレードオフを評価してください。 柱ごとの戦略的アプローチについて詳しくは、設計原則に関する記事を参照してください。
操作のための設計
SaaS ワークロードの運用には別の観点が必要です。 サポート可能性などの要因を考慮する必要があります。 どのようにして終日のプラットフォーム サポートを提供し、適切なスキル セットを持つ人材を採用するかを決定しましょう。 後知恵で運用したり、新機能の構築だけに集中したりしないでください。 運用しやすい設計を最初から考えましょう。 顧客が増えるにつれてプロセスをどのようにスケーリングするかを検討しましょう。 たとえば、手動での運用は最初はうまくいくかもしれませんが、通常は時間の経過とともにうまくスケーリングしなくなります。
レガシ プラットフォームがある場合は、顧客を新しい SaaS プラットフォームに移行するかどうかや、その方法を検討してください。 ビジネス変革中も顧客を常に満足させるには、スムーズな移行パスが鍵となります。