次の方法で共有

Azure Well-Architected SaaS ワークロード

  • [アーティクル]

Microsoft Azure 上でサービスとしてのソフトウェア (SaaS) をビルドおよび運用するには、他の種類のソフトウェアとは異なるアプローチが必要です。 独立系ソフトウェア ベンダー (ISV) は、自社の SaaS ソリューションによってビジネスを推進しているため、クラウド エコシステムにおいて独自の地位を占めています。 彼らは自社の製品を企業に販売 ("企業間 (B2B)") または顧客に販売 ("企業対消費者 (B2C)") しています。 ISV は通常、自らビルドした SaaS ソリューションをホストおよび保守します。 その顧客が製品を構成し、データを管理します。

Well-Architected フレームワークを使用してビルドされたソリューションは、ワークロードを大規模に運用できることが保証されます。 この一連の記事では、Azure 上でスケーラブルでパフォーマンスが高く、信頼性が高く、安全な SaaS ソリューションを作成するための重要な分析情報を提供します。 Well-Architected フレームワークにまだ精通していない場合は、ある程度時間をかけてその原則を学習することをお勧めします。

「Microsoft Azure Well-Architected フレームワークの柱」を参照してください。

SaaS ワークロードとは

ワークロードという用語は、共通のビジネス目標または共通のビジネス プロセスの実行をサポートするアプリケーション リソースのコレクションを指します。これらは、API やデータ ストアなどの複数のサービスが連携して特定のエンド ツー エンド機能を提供します。

SaaS という用語は、サービスとしてのソフトウェアを提供するビジネス モデルを指します。 ベンダーは、ソリューション全体の提供と運用に責任を負います。 顧客の分離、セキュリティ、コンプライアンスの要件を満たしながら、大規模な顧客環境を慎重に管理する必要があります。 SaaS ソリューションは、多くの場合、リソースが複数の顧客間で共有されるマルチテナント アーキテクチャに依存します。 このアプローチは、リソースの設計とデプロイ、および顧客に提供される価格モデルに影響します。

一般的な課題とは

Microsoft Azure は、SaaS を提供するための優れたプラットフォームであり、必要な弾力性とスケーラビリティを提供します。 また、SaaS 配信のさまざまな側面を自動化する機能も提供しています。 ただし、Azure 上で SaaS を提供するには、次のような独自の課題が伴います。

  • 顧客の期待は高く、品質、セキュリティ、回復性を求めています。 B2B ソリューションの場合、基本的には顧客の IT 部門の延長となり、自社のソリューションを正常に運用し続ける責任を負います。 これには、単なるソフトウェアの開発から大規模な運用へのシフトが必要です。

  • SaaS を提供することは、自社のビジネス ニーズと顧客のビジネス ニーズのバランスを取ることを意味しますが、時にはこれらが対立することもあります。 顧客はソリューションに対してさらに多くのことを要求する一方で、売却済商品の原価 (COGS) を削減し、効率性を高めるプレッシャーに直面することになります。

  • SaaS は多くの場合、大規模にまたは積極的な成長目標を掲げて運用されます。 規模を拡大していく際には、運用の複雑さを軽減しながらパフォーマンスと信頼性を維持することが重要になります。 手動操作は現実的でないため、自動化と構造化されたプロセスが必要であり、ある程度の運用の成熟度が求められます。

  • 顧客間でインフラストラクチャを共有する場合、分離は重要な要件となります。 顧客は、他の顧客の活動に関係なく、自身のデータが安全であり、一貫したパフォーマンスと信頼性を得られることを期待しています。 ベンダーには、他の顧客からの情報も含め、顧客のデータとワークロードを保護する重大な責任があります。

SaaS を構築するための成熟度モデルとは

SaaS 製品を構築する組織は、通常、次のとおりです。

  • スタートアップまたはその他の小規模な組織。 通常、これらは人員も少なく、リソースも少なくなります。 組織の規模に関係なく、SaaS では顧客の高い期待に応えるために、ある程度の成熟度が必要です。 顧客は、組織がデータやその他の資産を保護することを信頼しています。 また、業務の重要な部分でソリューションに依存することもあります。 そのため、オペレーショナル エクセレンスと信頼性は、ソリューションの重要な側面になります。

    スタートアップはまず、顧客にとって最も影響力のある要素を優先する必要があります。 同時に、自動化、テナント管理、コスト削減、セキュリティと信頼性の向上など、将来のアーキテクチャの強化も計画する必要があります。 最初は実用的ではないと思われるかもしれませんが、この戦略的計画は段階的な実装と継続的な改善のための青写真として機能します。 スタートアップが成長するにつれて、効果的に規模を拡大し、顧客の信頼を維持するために、プロセスを適応および調整し、新しいテクノロジを採用し、進化するコンプライアンス基準を満たす必要があります。

  • 確立された組織。 既存のソリューションを最新化しようとしている確立された組織は、多くの場合、SaaS モデルに移行します。 組織が持つリソースは増えるかもしれませんが、課題は複雑になります。 既存の顧客をサポートしながら新しい SaaS ソリューションを開発しなければならず、これにより運用上のオーバーヘッドが発生する可能性があります。 この移行には、技術アーキテクチャ、スキル セット、全体的なビジネス運用の変更が必要です。 現在の顧客への影響を最小限に抑え、顧客が同等以上の信頼性、セキュリティ、パフォーマンスを確実に得られるようにすることに焦点を当てる必要があります。 レガシ ソリューションの負担が軽減されると、組織は新しい機能と改善点を優先させることができます。

このガイダンスを使用する方法

✔ 設計手法から始めます。ここでは技術的および運用的な領域における根拠と繰り返されるテーマを概説しています。 この体系的なアプローチは、要件と設計戦略を定義するのに役立ちます。 不確実な選択に直面したときには、ワークロードの全体的な目標に沿った状態を維持するためにこの手法を再検討してください。 また、マーケティングや営業のチームと連携して技術的な決定を検証し、顧客からのフィードバックを取り入れて継続的な改善を図るためのフレームワークも提供されます。

✔ 設計原則に進み、成長の進化を考慮して、SaaS 設計手法が Well-Architected フレームワークの中核となる柱とどのように一致しているかを確認します。 すべての柱の基礎となる原則を、トレードオフも含めて総合的に評価します。

✔ ソリューションに最も大きな影響を与える設計領域に焦点を当てます。 各領域には、設計の意思決定を導くための考慮事項と推奨事項が含まれています。

設計領域
請求とコスト管理: 請求戦略とそれが売却済商品の原価 (COGS) に与える影響を評価します。 SaaS ビジネスの規模の変化に応じたコストの変動をモデル化し、予測します。 クラウド リソースの費用を最適化する方法を探します。
ガバナンス: クラウド サービスの使用を管理および規制して、安全な Azure 環境を確立します。
リソースの編成: スケールとコストの要件をサポートするためにリソースをデプロイする方法を計画します。
ID およびアクセス管理: マルチテナント SaaS 環境での ID 管理の課題を理解します。 適切な ID プロバイダーを選択し、顧客の ID システムとのフェデレーションの必要性を検討します。
コンピューティング: ニーズを満たすコンピューティング プラットフォームを選択します。 顧客の分離、スケーラビリティ、回復性を計画します。
ネットワーク: トポロジや防御を含むネットワーク展開を計画します。 顧客間でリソースを分離し、顧客のネットワークとの統合や顧客の環境へのリソースの展開など、顧客の接続ニーズを満たします。
データ: 適切なデータ ストアを選択し、運用効率を維持しながら顧客データを分離することを計画します。 規模と成長に基づいて容量計画を検討し、データが顧客の回復性要件を満たしていることを確認します。
DevOps プラクティス: テナント モデルに従って、顧客ごとにインフラストラクチャとアプリケーションをデプロイします。 段階的なロールアウトを含む構造化されたアプローチを使用して変更を行います。
インシデント管理: 組織内で SaaS を運用する責任と必要な文化的要素を確立します。 調査、修復、コミュニケーションのためのツールとプロセスに投資して、インシデントに備えます。

✔ Assessment Review Tool を使用して、最適化された SaaS ワークロードの運用環境での準備状況を評価します。

ヒント

すべてのアーキテクチャ上の決定には、さまざまな考慮事項と、フレームワークのさまざまな側面のバランスを取る一連の認識された妥協点が伴います。 これらのトレードオフは、このアイコンで示されます。 .

使用可能なリソース

マルチテナントは、SaaS ワークロードを設計するための主要なビジネス手法です。 詳細については、これらの追加のリソースを参照してください。

次のステップ

Azure で SaaS ワークロードを設計するときに従う手法を理解します。

設計手法