Azure での SaaS ワークロードのコンピューティング
サービスとしてのソフトウェア (SaaS) アプリケーションは、コンピューティング プラットフォームで実行する必要があります。 これは、アーキテクチャ内の他の構成要素と同様に、ビジネス要件を満たす必要があり、ビジネス モデルに従って設計される必要があります。 コンピューティング プラットフォームの選択は、設計上の重要な決定事項です。 この決定は顧客の分離、パフォーマンス、回復性に影響し、コンピューティング プラットフォームは SaaS ソリューション全体のスケーリングと拡張方法に影響します。
この記事では、ホスティング モデルの選択に関する考慮事項、そのモデルの運用面、サービス レベル アグリーメント (SLA) とサービス レベル目標 (SLO) を満たすのに役立つテクノロジ オプションを最適化する方法について説明します。
コンピューティング プラットフォームを選択する
SaaS ワークロードに適したコンピューティング プラットフォームを選択するのが重要ですが、使用可能な選択肢があまりにも豊富なために、選びきれないと感じることがあります。 最適なプラットフォームは、アプリケーション アーキテクチャ、スケール、パフォーマンスのニーズ、テナント分離モデルなどの要因によって異なります。 あるアプリケーションに最適なものが、別のアプリケーションに適しているとは限りません。
設計上の考慮事項
ホスティング モデル。 Azure では、各種ホスティング モデル (主にサービスとしてのインフラストラクチャ (IaaS) とサービスとしてのプラットフォーム (PaaS)) を提供しており、それぞれに独自の利点とトレードオフがあります。 アプリケーションの要件を評価し、最適なモデルを選択します。
IaaS は、仮想マシン (VM) を提供し、ネットワークやストレージなど、仮想マシン (VM) を全面的に制御します。 ただし、管理と修正プログラムの適用が必要であり、運用上の負荷が高くなる場合があります。 この例には、Virtual Machine Scale Sets や Azure Kubernetes Service (AKS) クラスターなどがあります。
PaaS を使用すると、基になるインフラストラクチャを管理せずに、アプリケーションをデプロイできます。 これには、自動スケーリングと負荷分散のための組み込みの機能が含まれています。 例として、Azure App Service や Azure Container Apps があります。
PaaS サービスでは、IaaS と比較して制御できる度合いが低くなります。これは、アプリケーションで特定の構成が必要な場合に問題になる可能性があります。 たとえば、アプリケーションが、PaaS サービスがサポートしていないオペレーティング システム上で実行される場合があります。
ワークロードの種類。 プラットフォームには、特定のワークロードに特化したものや、汎用性のあるものがあります。 たとえば、Azure App Service は Web アプリケーション用に設計されているのに対し、AKS はより汎用性があります。 ここでは Web アプリ、AI ワークロード、バッチ コンピューティング タスクをホストできます。
チームの専門知識の開発。 チームに新しいプラットフォームの経験がないと、大幅な変更は難しい可能性があります。 チームのスキルを評価し、チームをプラットフォームの要件に適合させます。 単純なプラットフォームから始めて、徐々にアーキテクチャを進化させる方法を採用し、より高度なオプションに急に飛躍するのは避けます。
たとえば、コンテナー化されたアプリケーションを構築する場合は、簡単に管理できるように Container Apps から始めます。 ニーズがより複雑になっていくときに、時間の経過とともにプラットフォームの理解が深まっていたら、AKS に移行できます。
管理のオーバーヘッド。 コンピューティング プラットフォームは、オーバーヘッドと制御のバランスを取ります。 チームから離れた管理責任が増えるということは、プラットフォームに制御を及ぼしにくくなることを意味します。
たとえば、IaaS では VM を大幅に制御できますが、大きなオーバーヘッドが伴います。 アプリケーションが顧客の環境にデプロイされている場合は、限られた管理操作しか実施できない可能性があります。 これらのトレードオフが、許容できる範囲内であり、実行可能かどうかを評価します。
パフォーマンス要件。 CPU、メモリ、ネットワーク (帯域幅と待機時間、GPU、可用性のニーズを含む) をモデリングして、アプリケーションのパフォーマンス要件を理解します。 また、将来の成長も検討する必要があります。 この情報を使用して、VM のシリーズやサイズなど、適切なコンピューティング リソースを選択します。 また、特殊な要件を満たすために、特定の VM シリーズをサポートする特定のリージョンを選択する必要がある場合もあります。
信頼性の要件。 コンピューティング プラットフォームの信頼性機能を検討し、信頼性の目標を満たしていることを確認します。 信頼性を高めるために、特定のサービス レベルを使用してソリューションの複数のインスタンスを作成し、Availability Zones 間でデプロイする必要がある場合があります。
「RE:04 信頼性目標を定義するための推奨事項」を参照してください。
アプリケーションのセキュリティとコンプライアンス。 各コンピューティング プラットフォームのセキュリティ機能とコンプライアンス認定を評価して、ニーズを満たしていることを確認します。 たとえば、送信トラフィックを監視してフィルター処理する必要がある場合は、特定のコンピューティング サービスまたはレベルを選択する必要があります。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| CPU、メモリ、ネットワーク、GPU スケールの各ディメンションを推定して、コンピューティング パフォーマンス要件を評価します。 ロード テストを実行して、より正確なデータを収集し、モデリングの実践内容を通知します。 |
これらのタスクは、コンピューティング プラットフォームに適したサイズ設定を選択し、システムの負荷が増加したときに適切にスケーリングするのに役立ちます。 |
| チームの能力を評価し、ニーズを満たす最も複雑でないプラットフォームから始めるか、チームが既に熟知しているプラットフォームから始めます。 | 使い慣れたコンピューティング プラットフォームを選択することで、よりスムーズな運用を実現し、チームに負担がかかりすぎないようにできます。 |
| 設計に柔軟性を持たせます。 進化するビジネス要件と技術要件に適応するために、時間の経過に沿って繰り返し実行できるソリューションを目指します。 | 柔軟性を持たせることで、時間の経過に伴う変更や改善に簡単に適応できます。 進化するビジネスと技術のニーズに効果的に対応できます。 |
| ソリューションの運用コストを含め、総保有コスト (TCO) を評価します。 | 価格モデルを計画し、コスト効率の高い運用を確実に行うには、コストを明確に理解している必要があります。 |
| テクノロジ スタックが理由で特定のコンピューティング プラットフォームを使用する必要があるかどうかを評価します。 コンピューティング プラットフォームには、特定のプログラミング言語、ツール、オペレーティング システムにより適したものがあります。 選択したテクノロジをネイティブにサポートするプラットフォームを使用するように努めます。 | アーキテクチャを再設計するコストが生じることを回避します。このような再設計には、新しいプラットフォームへの移行が含まれる場合があります。 |
| プラットフォームの信頼性機能を評価し、クラウド サービス プロバイダーの保証を SLO に組み込みます。 | 信頼性機能を計画し、Availability Zones が使用可能な場合は使用することで、局地的なデータセンターの停止のリスクを軽減します。 |
テナント モデルと分離
SaaS ビジネス モデルによって、顧客のリソースをホストするか、顧客の環境で管理するかが決まります。 ほとんどの SaaS プロバイダーは、顧客に代わってリソースをホストします。これにより、コンピューティング プラットフォーム設計の柔軟性が得られます。 顧客のワークロードを効果的に分離し、カスタマー エクスペリエンスやパフォーマンスを損なうことなく、コスト効率が最適化されるようにします。
設計上の考慮事項
テナント モデルの計画。 テナント モデルによって、顧客間のリソース共有が決定され、このモデルは、ビジネス モデルと価格モデルの影響を受けます。 シングルテナント モデルの場合、完全マルチテナント モデルと比較して、顧客あたりのコストが高くなります。 価格設定に、これらの違いが反映される必要があります。
顧客要件。 顧客によっては、データ所在地、パフォーマンスの保証、またはセキュリティ コンプライアンスに関する特定のニーズを持っている場合があります。 これらの要件に、通常よりも高い分離レベルが必要な場合は、コストの増加をビジネス モデルに反映する方法を検討します。
うるさい隣人の問題。 テナント間でリソースを共有する場合は、「うるさい隣人の問題」に注意する必要があります。 コンピューティング リソースが、最も影響を受けます。 詳細については、「うるさい隣人のアンチパターン」を参照してください。
テナント モデルを選択するときは、リソース共有のコスト削減と、顧客のパフォーマンスを保証する必要性のバランスを取ります。 リソースを過剰に共有する、または過剰な消費を許可すると、カスタマー エクスペリエンスが低下する可能性があります。
トレードオフ: パフォーマンスとコスト。顧客間でリソースを共有するとコスト効率が高くなりますが、一部の顧客が予想よりも多くのリソースを使用した場合、他の顧客のパフォーマンスが低下する可能性があります。 これを回避するには、適切なリソース ガバナンスを実装して、テナントの使用状況が、予想される制限内に収まるようにします。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| コンピューティング プラットフォームの分離機能を評価して、テナント モデルの要件を満たしていることを確認します。 | 重要な構成を最初に確認することで、プラットフォームの再作業を回避できます。 |
| 分離モデルを適用します。 ローカル ディスク キャッシュ、システム メモリ、外部キャッシュなどの共有リソースは、適切に管理されないと、意図せずにテナント間でデータが漏えいする可能性があるため、慎重に扱います。 分離要件が高い場合は、コンピューティング プラットフォーム内とアプリケーション内で分離を適用します。 |
強力に分離することで、重大なセキュリティ インシデントであるテナント間のデータ漏洩のリスクが軽減されます。 |
| 顧客レベルのメトリックを可視化して、リソース ガバナンスと監視を実装します。 各顧客のリソース消費量を予防的に監視して、うるさい隣人の問題を検出して軽減します。 |
リソースの消費量を監視し、問題を早期に軽減することで、問題が他の顧客に波及しないようにします。 |
スケーラビリティとコスト効率を目指して構成する
顧客は、さまざまなパフォーマンス プロファイルでアプリケーションを使用する可能性があります。 顧客は、アプリケーションが速度とパフォーマンスを損なうことなく、増加するユーザーの要求、大規模なデータ、複雑なワークロードに対応することを期待します。 システム アーキテクチャでは、管理するユーザーが数百人か数百万人かにかかわらず、パフォーマンスのニーズとコストのバランスを取りながら、スケーラビリティと最適なパフォーマンスを確保する必要があります。
コスト管理の詳細については、「Azure での SaaS ワークロードの課金とコスト管理」を参照してください。
設計上の考慮事項
水平スケーリングと垂直スケーリングのスケーリング戦略。 水平スケーリングと垂直スケーリングのスケーリング方法は、負荷の増加に対応するために実行できます。 使用する方法は、複数のインスタンス間でスケーリングするアプリケーションの機能によって異なります。
- 水平スケーリングでは、コンピューティング ノードのインスタンスを追加します。 アーキテクチャに、受信トラフィックを複数のサーバーまたはインスタンスに分散させるためにロード バランサーが必要です。
- 垂直スケーリングでは、1 台のサーバーに CPU やメモリなどのリソースを増設します。 キャッシュなどの外部状態ストアを必要としないステートフル アプリケーションには、この方法を使用します。 垂直スケーリングを実施すると、サービスの中断が短く、1 台のサーバーでリソース制限が発生する可能性があります。
PE:05 スケーリングとパーティション分割のための推奨事項に関する記事を参照してください。
自動スケーリング。 システムは、さまざまなレベルの需要を効率的に処理する必要があります。 ユーザー トラフィックが増加するにつれて、パフォーマンスを維持するために、アプリケーション リソースをスケールアップする必要があります。 需要が減少したときは、ユーザー エクスペリエンスに影響を与えずにコストを制御するために、リソースはスケールダウンします。 これらの調整は、CPU 使用率、時刻、受信要求などの要因によって決まります。 自動スケーリングは、パフォーマンスとコストのバランスを取り、他のテナントに与える高い需要の影響を軽減するのに役立ちます。
RE:06 信頼性の高いスケーリングのための推奨事項に関する記事を参照してください。
容量計画とコンピューティング割り当て。 新しい顧客を SaaS ワークロードにオンボードすると、リソース容量が消費されます。 垂直スケーリングまたは水平スケーリングを実施した場合でも、ソリューションのスケーラビリティにおいて、最終的にはネットワークやストレージの制約などの制限に達します。
Note
デプロイ スタンプ パターンでは、ソリューションの複数の独立したインスタンスをデプロイできます。 これにより、別のスケーリング ディメンションが提供されます。 各スタンプの容量を理解して、デプロイするタイミングを決定することが重要です。 この概念は、ビン パッキングとも呼ばれます。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| 垂直スケーリングよりも、水平スケーリングを優先して選びます。 多くの場合、水平スケーリングは、垂直スケーリングよりも複雑でなく、信頼性とコスト効率が高くなります。 | 多くの場合、水平スケーリングは、垂直スケーリングよりも高い度合いにスケーリングできるため、より単純で信頼性が高く、コスト効率が高くなります。 |
| ロード テストを実行します。 | 使用のシミュレーションは、運用環境にデプロイする前に、ボトルネックとスケーリングのしきい値を特定するのに役立ちます。 |
| 水平スケーリングまたは垂直スケーリングでなく、新しいスタンプをデプロイするためのスケーリングしきい値を定義します。 パフォーマンスを低下させずにコスト効率の高いスケーリングを行うためには、テナントをできるだけ少ないリソースに圧縮します。 |
現在のインフラストラクチャを超えた成長に対応する備えがしやすくなります。 |
| 可能な場合は、自動スケーリングを実装します。 自動スケーリング ルールは、アプリケーションの負荷を正確に反映するように設定します。 | 必要に応じてリソースを増減することで、パフォーマンスとコストを最適化できます。 |
| 顧客の使用パターンを監視および評価します。 | パフォーマンスを向上し、コストを最適化するために、インフラストラクチャを調整するタイミングを把握できます。 |
| 可能な場合は、キャッシュ メカニズムを実装します。 | コンピューティング レイヤーの潜在的な処理負荷が軽減されます。 |
| コストのアラートを使用します。 | 警告は、使用量が多い問題を検出し、コストの問題を早期に制御するのに役立ちます。 |
| 長期のコミットメントを持ち、その期間全体のコンピューティング使用が保証されている顧客に対し、Azure の予約を使用します。 | 予約容量のコスト効率が最大化されます。 |
回復性の設計
コンピューティング レイヤーの回復性は、全体的な回復性戦略において大きな役割を果たします。 提供するアプリケーションは、ユーザーに影響を与えることなく、一般的なエラーを自動的かつシームレスに許容して復旧する必要があります。
設計上の考慮事項
信頼性の要件。 明確な信頼性要件を設定します。 これらの要件には、内部ターゲット (SLO) と、多くの場合に 1 か月あたり 99.9% などのアップタイム ターゲットを指定する顧客コミットメント (SLA) が含まれます。
「RE:04 信頼性目標を定義するための推奨事項」を参照してください。
デプロイ戦略。 クラウド リソースは、特定の地理的リージョンにデプロイされます。 Azure では、Availability Zones はリージョン内で分離されたデータセンター セットです。 回復性を確保するために、複数の Availability Zones にアプリケーションをデプロイします。 リージョン間またはクラウド プロバイダー間にまたがってデプロイすると、回復性が向上しますが、コストと運用の複雑さが増します。
RE:05 Availability Zones とリージョンの使用に関する推奨事項の記事を参照してください。
ステートレス ワークロード。 回復性のあるアプリケーションをデプロイするには、通常、異なる場所で冗長コピーを実行する必要があります。 このタスクは、セッション状態を維持する必要があるステートフル ワークロードでは困難な場合があります。 可能であれば、ステートレス ワークロードの構築を目指します。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| 提供するアプリケーション内の一時的な障害を処理します。 | 小さな問題から迅速に復旧することで、可用性が向上します。 |
| ステートレス アプリケーションを選択します。 アプリケーションがステートフルである必要がある場合は、キャッシュなどの外部状態ストレージ メカニズムを使用して状態を格納します。 | 誤った負荷分散中や故障中など、インスタンスが使用できないことが原因で発生する状態の損失が防げます。 |
| 可用性ゾーンを使用する。 | ローカライズされたデータセンターの停止を軽減することで、回復性が高まります。 |
| ビジネス上の正当な理由がある場合は、複数の地域にまたがるアーキテクチャを設計します。 | 高いアップタイムの要件を満たし、さまざまなリージョンのユーザーがサポートされます。 |
| カオス エンジニアリングを実施します。 | 障害点がどこにあるかを把握しやすくなり、停止が発生する前に修正できます。 |
| 複数のスタンプが共有するコンポーネントの使用を制限します。 | 単一障害点を排除し、障害の潜在的な影響領域が低減されます。 |
その他のリソース
マルチテナントは、SaaS ワークロードを設計するための主要なビジネス手法です。 これらの記事では、コンピューティング プラットフォームに関する考慮事項について、より詳しく説明します。
次のステップ
SaaS ワークロードのネットワークに関する考慮事項について説明します。