Azure での SaaS ワークロードの設計原則

[アーティクル]
11/05/2024

SaaS ソリューションを提供する独立系ソフトウェアベンダー (ISV) は、ソリューションのアーキテクチャの卓越性について責任があり、顧客と責任を共有します。顧客は ISV のソリューションに依存しているため、顧客側で問題が連鎖的に発生する可能性があります。組織が成熟しており、確立された顧客ベースがある場合、信頼性とセキュリティが最大の懸念事項かもしれません。ダウンタイムとセキュリティ侵害は、会社の収益と評判に悪影響を及ぼす可能性があります。

しかし、多くの ISV (特にスタートアップ ISV) は、コストを最小限に抑えるために限られたリソースで運用しています。組織がスタートアップフェーズにある場合、成長の次のフェーズに進むには積極的なトレードオフが必要な場合があります。ガバナンス、セキュリティ、またはデプロイの自動化のための専任のチームがない場合もありますが、将来の成長のために計画することを忘れないようにする必要があります。リスクを取る必要がある場合、計算したうえで意思決定を行います。

小規模なスケールで動作するソリューションの設計方法は、大規模なソリューションとは異なります。急速な成長をサポートするために、柔軟性と適応性を備えた SaaS ワークロードアーキテクチャを設計する必要があります。この記事では、そのような成長の進化を考慮したうえで、基になる原則について説明します。 トレードオフを含め、Well-Architected フレームワークの 5 つの柱をすべて一緒に検討してください。 すべての柱に最低限の基準があるため、それぞれを検討します。これらの原則を適用しない場合、財務損失が発生し、顧客の信頼を弱めてしまう可能性があります。

信頼性

設計原則	考慮事項
可用性を優先します。	ソリューションはビジネスそのものです。高可用性を可能な限り維持します。ソリューションで障害が発生した場合、その影響は顧客だけでなく顧客の顧客にも影響を与える可能性があります。
顧客に提供するサービスレベルアグリーメント (SLA) を明確にします。	顧客に対して金銭的な補償を伴う SLA を作成するときは、それらを満たせることと、依存するコンポーネントがそれに対応できることを確認します。 SLA の設計プロセスの一環として、基になる Azure サービスの複合 SLA を確認します。憶測は避けてください。共同責任モデルを SLA に反映します。

トレードオフ: 信頼性とコスト。多くの場合、高い信頼性を実現するには追加のリソースをデプロイする必要があります。たとえば、複数の可用性ゾーンやリージョンにリソースを分散させるかもしれません。一部の Azure サービスでは組み込みの geo レプリケーションやゾーン間レプリケーションが提供されますが、多くの場合、これらの機能には高いコストがかかります。

予算内で可能な回復性レベルについて、情報に基づいた意思決定を行います。ワークロード内の一部のコンポーネントやフローの信頼性に財務上の影響がない場合、回復性を向上させる機会のうち低コストな選択肢を検討します。たとえば、プラットフォームサービスの可用性ゾーンを利用したり、定期的にデータを別の物理的な場所にバックアップしたりできます。コードとしてのインフラストラクチャ (IaC) を使用して復旧プロセス中にリソースをすばやく再デプロイすることもできます。

セキュリティ

設計原則	考慮事項
セキュリティの基盤としてガバナンスを確立します。	後で問題に対処するのではなく、最初から適切なガバナンスプラクティスを確立します。多くの要因がセキュリティに影響します。たとえば、ロールの管理、リソースの整理、ポリシーの実装を行う方法などです。堅牢なガバナンスがなければ、セキュリティ制御はシステムを保護しません。
1 日目からクラウドセキュリティベースラインに従います。	顧客からのセキュリティ監査を予期してください。設計の早い段階で監査証跡を組み込みます。
顧客を分離し、セグメントを分離します。	データ分離の戦略としてテナントモデルを使用します。デプロイと環境をセグメント化します。
ゼロトラストから始め、可能な限り最小限のアクセスを提供します。	アクセス権のない立場を既定で設定します。必要な場合にのみ、最小限のアクセス権を使用します。 ID 管理とネットワークトラフィックにこの戦略を使用します。システム内のフローを定期的に確認し、異常に対してアクションを実行します。
可能な限り資格情報を使用しないようにします。資格情報を使用する必要がある場合は保護します。	資格情報を責任として扱います。信頼できる ID プロバイダーと、資格情報のストレージを最小限に抑える手法を使用します。使用する必要がある場合は、セキュリティで保護されたクラウドネイティブアプローチで資格情報を保護します。顧客の資格情報とシークレットを細心の注意を払って扱います。
セキュリティを継続的なプロセスとして採用します。	セキュリティ態勢を繰り返し再評価します。進化する脅威の状況、新しい機能とプロトコル、更新されたコンプライアンスや規制要件を考慮します。

トレードオフ: セキュリティとコストの最適化。セキュリティで保護されたソリューションの設計と運用にはコストがかかります。ただし、適切なガバナンスやセキュリティベースラインへの準拠など、セキュリティに対する重要な手順を最小限またはコストをかけずに実現できます。コスト効率と理想的なセキュリティ態勢のバランスを決定します。

コストの最適化

設計原則	考慮事項
必要な分だけ支払います。	Microsoft Cost Management の機能を利用して、全体的な支出を把握します。さらに確認するために、最もコストの高いリソースカテゴリを優先します。過剰に支払っている可能性がある領域を特定します。
支払い内容を活用します。	支払いに対して使用が少ない可能性があるリソースの価値を最大化します。
コストをモデル化します。	売却済商品の原価を追跡します。ソリューションを顧客に提供するためのコストについて理解します。これは物理的な製品の製造プロセスに似ています。意思決定のための情報を得るために、顧客が生み出す収益に対して各顧客にかかっているコストを監視します。 Azure の支出をすばやく理解して集計するには、優れたリソース編成やタグ付けなどのガバナンスプロセスを実装します。
コストと収益の関連性を理解します。	コストの増加に対して収益が増加しないという状況を回避します。たとえば、無制限の無料ストレージを提供する新機能を追加すると、コストが増加する可能性があります。同様に、ユーザー数に基づいて顧客に請求する場合は、必ず機能をユーザーに関連付けます。

トレードオフ: コスト最適化と信頼性。多くの場合、信頼性の高いソリューションを作成するには、追加のコンポーネントのデプロイ、より多くのデータ転送、回復性の高いキーコンポーネント SKU の使用が必要になり、これらすべてによってコストが増加します。多くの場合、信頼性を高めることには費用の価値がありますが、十分な情報に基づいて意思決定を行う必要があります。これらのコストの増加を相殺するには、他のコンポーネントを効果的に使用し、その価値を最大限に高めます。

オペレーショナルエクセレンス

設計原則	考慮事項
共有責任モデルを理解します。	クラウドプロバイダー、顧客、組織の責任を明確に定義します。誰がどのタスクを担当するかを必ず全員が把握するようにします。
顧客に代わってソリューションを運用する準備をします。	大規模な SaaS の運用をサポートするように、組織、チーム、プロセス、ツールを設定します。
一貫性のあるプロセスを採用します。	デプロイスタンプを使用します。スタンプの構成とアーキテクチャ全体で一貫性を高めます。プロセスを自動化および標準化します。
例外や相違点を形式化します。	さまざまなニーズに合わせてさまざまな SKU を定義します。この方法を使用して、さまざまな顧客のカスタムデプロイ、構成、コードを回避します。
変更を安全にロールアウトします。	段階的公開、継続的な監視、問題が発生した場合にロールバックに使用できる安全なデプロイプロセスを実装します。コード、インフラストラクチャ、構成の変更に一貫したプロセスを使用します。任意の時点でデプロイするソリューションバージョンの数を制御します。

トレードオフ: オペレーショナルエクセレンスと複雑さという代償。自動化された管理操作により、ソリューションの複雑さが増し、ビルドに時間がかかる場合があります。最初は、自動化のコストがメリットを上回る可能性があります。小規模な顧客ベースの場合は特にそうです。しかし、顧客の数が増えるに従って自動化のコストが報われ、メリットが増えます。

パフォーマンス効率

設計原則	考慮事項
グローバルパフォーマンスを実現するためにグローバルスケールを実装します。	マルチリージョンデプロイや高速なトラフィックルーティングを通して、世界中の顧客に優れたエクスペリエンスを提供します。
予想されるスケールを定量化します。	成長シナリオの最適、平均、最悪のケースをモデル化します。傾向を分析し、現実的な予測について販売チームに相談します。さまざまな成長の可能性に対応するために、柔軟なスケーリング戦略を計画します。
スケールポイントについて理解します。	柔軟性が必要な可能性がある場所を特定します。一般的なトリガーには、顧客またはテナント、ユーザー、ユーザーあたりのトランザクションの数が含まれます。ビジネスの成長に伴ってこれらの要因がどのように変化し、アーキテクチャにどのような影響を与えるかを理解します。
スケールアウトを設計します。	スケールアップには限界がありますが、スケールアウトによってさらに拡大できます。すべてがスケールアウトされるわけではないため、デプロイスタンプを使用してソリューションを単位としてスケーリングし、リソースのスケールアップの制限を回避することを検討してください。

トレードオフ: パフォーマンス効率と信頼性。多くの場合、信頼性の高いシステムでは広範な地理的領域にわたるデータレプリケーションが必要です。レプリケーションの設計によっては、このセットアップによって待機時間が長くなり、スループットが低下する可能性があります。たとえば、数百マイル離れた 2 つの Azure リージョン間で重要なデータを同期的にレプリケートする場合、リアルタイムレプリケーションのために応答時間が数百ミリ秒延長する可能性があります。

次のステップ

顧客の請求とコスト管理戦略を最適化して、学習体験を始めましょう。

設計領域: Azure での SaaS ワークロードの請求とコスト管理

次の方法で共有