この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:06 | アプリケーション、データ、インフラストラクチャ のレベルで、タイムリーで信頼性の高いスケーリング戦略を実装します。 実際の使用パターンまたは予測される使用パターンに基づいてスケーリング戦略を立て、手動による介入を最小限に抑えます。 |
|---|
このガイドでは、信頼性の高いスケーリング戦略を設計するための推奨事項について説明します。
定義
| 任期 | 定義 |
|---|---|
| 垂直スケーリング | 既存のリソースにコンピューティング容量を追加するスケーリング アプローチ。 |
| 水平スケーリング | 特定の種類のリソースのインスタンスを追加するスケーリングアプローチ。 |
| 自動スケーリング | 一連の条件が満たされたときにリソースを自動的に追加または削除するスケーリングアプローチ。 |
注
スケーリング操作は、静的 (通常の負荷パターンに対応するために定期的にスケジュールされた毎日のスケーリング)、自動 (満たされている条件に応じて自動化されたプロセス)、または手動 (オペレーターが予期しない負荷の変更に対応して 1 回限りスケーリング操作を実行する) にすることができます。 垂直スケーリングと水平スケーリングは、どちらの方法でも実行できます。 ただし、自動垂直スケーリングには追加のカスタム自動化開発が必要であり、スケーリングするリソースによってはダウンタイムが発生する可能性があります。
システムは水平方向にスケーラブルに設計されている必要があります。 インスタンス アフィニティに関する想定は避けてください。 コードがプロセスの特定のインスタンスで常に実行されていることを必要とするソリューションを設計しないでください。 クラウド サービスまたは Web サイトを水平方向にスケーリングする場合、同じソースからの一連の要求が常に同じインスタンスにルーティングされると想定しないでください。 同じ理由から、アプリケーションからの一連の要求を常にサービスの同じインスタンスにルーティングする必要がないように、サービスをステートレスに設計します。 キューからメッセージを読み取って処理するサービスを設計するときは、サービスのどのインスタンスが特定のメッセージを処理するかを想定しないでください。 自動スケールでは、キューの長さが長くなるにつれて、サービスのインスタンスが増える可能性があります。 競合コンシューマー パターンでは、このシナリオを処理する方法について説明します。
自動スケールの決定に重要な時間を使用するには、送信および処理中に、ライブラリに関連する情報をメッセージのヘッダーに自動的に追加してもらうと便利です。 この機能を提供する 1 つのライブラリは NServiceBus です。
主要な設計戦略
負荷パターンに応じた設計
ワークロードの信頼性の高いスケーリング戦略を設計するには、スケーリング操作につながる各ワークロードのユーザーフローとシステム フローの負荷パターンを特定することに重点を置きます。 さまざまな負荷パターンとそれに対応するスケーリング戦略の例を次に示します。
静的： 毎晩午後 11 時 EST までに、アプリケーションのアクティブなユーザーの数が 100 を下回り、アプリ サーバーの CPU 使用率がすべてのノードで 90% 低下します。 これを処理するには、コンピューティング ノードのスケール ダウンを、午後 11 時から午前 6 時 (EST) までの最小数 (2) にスケジュールできます。
動的、標準、予測可能: 毎週月曜日の朝、複数のリージョンにまたがる 1,000 人の従業員が ERP システムにサインインします。 これを管理するには、最初のリージョンが作業を開始する前に、コンピューティング ノードのスケールアウトを通常の 1 日の容量にスケジュールできます。
動的、不規則、予測可能: 製品の発売は月の最初の日に行われ、このような状況でのトラフィックの増加に関する前回のリリースの履歴データがあります。 これに対処するために、製品発売の朝にコンピューティング インスタンスとデータベース インスタンスの 1 回限りのスケジュールされたスケールアップを定義し、1 週間後にスケールダウンできます。
動的、不規則、予測不可能: 大規模なイベントにより、製品の需要が急増します。 たとえば、除湿機を製造および販売している企業では、影響を受ける地域の人々が自宅の部屋を乾燥させる必要があるときに、ハリケーンやその他の洪水イベントの後にトラフィックが急激に急増する可能性があります。 これを処理するために、計画外のトラフィックの急増を考慮して自動スケールのしきい値を設定できます。
個々のコンポーネントまたはフローに合わせてスケーリング戦略を調整する
万能スケーリング戦略はありません。 クラウド サービスによって、スケーリングのサポートの程度が異なり、スケーリングのアプローチも異なります。 そのため、全体的なスケーリング戦略を設計するために、すべてのワークロード コンポーネントでスケーリングがどのようにサポートおよび実装されているかを理解することが重要です。 アーキテクチャ設計に応じて、個々のコンポーネント レベルまたはフロー レベルでスケーリング戦略を適用できます。 ワークロード全体にスケーリングを実装する方法を決定する場合は、次の要因を考慮してください。
スケールアウトできないコンポーネント。たとえば、シャーディングを有効にせず、大きな影響を与えずにリファクタリングできない、大規模なリレーショナル データベースがあります。 クラウド プロバイダーによって発行されたリソース制限を文書化し、それらのリソースを注意深く監視します。 これらの特定のリソースを将来の計画に含めて、スケーラブルなサービスに移行します。
スケール操作の順序に関するフローのコンポーネントの関係。 最初にアップストリーム コンポーネントをスケーリングして、ダウンストリーム コンポーネントを誤ってオーバーロードしないようにします。
スケーリング操作と、実装されているセッション アフィニティ (またはセッションの持続性) によって中断される可能性のあるステートフル アプリケーション要素。 持続性によってスケーリング機能が制限され、単一障害点が発生する可能性があります。 実用的な範囲でステートレスなワークロードを設計します。
潜在的なボトルネック。 スケールアウトしても、すべてのパフォーマンスの問題が解決されるわけではありません。 たとえば、バックエンドのデータベースがボトルネックである場合、Web サーバーを追加しても改善されません。 インスタンスを追加する前に、まずシステムのボトルネックを特定して解決します。 システムのステートフルな部分は、最もボトルネックの原因となりやすいものです。
実行時間の長いタスクの処理。 スケールアウトとスケールインの両方をサポートするように、実行時間の長いタスクを設計します。 このようなタスクは、システムのスケールイン時にプロセスのインスタンスが正常にシャットダウンされるのを防ぐことができます。 または、プロセスが強制的に終了すると、データが失われる可能性があります。 理想的には、実行時間の長いタスクをリファクタリングし、実行される処理をより小さな個別のチャンクに分割します。 パイプとフィルター パターンは、このソリューションを実現する方法の例を提供します。
適切なテクノロジの選択
スケーリングを念頭に置いて十分な情報を得たテクノロジの選択を行うと、ワークロードの進化に合わせてワークロードが信頼性の目標を満たすことができます。 同様の機能を提供するさまざまなリソースに提供されるスケーリング機能を調査し、将来の成長計画に最適な組み合わせを選択します。 たとえば、使用する特定の種類のデータベースをホストできるデータ ストアには、いくつかのオプションがあります。 ただし、1 つの選択肢では、他の選択肢よりもすぐに使用できる機能のスケーリングが優れている可能性があるため、ワークロードに適した選択肢になる可能性があります。
自動的にスケーリングされるサービスを利用します。 実用的な場合は、構成や入力なしで自動的にスケーリングする SaaS サービスを使用します。 Microsoft Entra ID などのグローバル サービスでは、この機能が提供されます。 サーバーレス ソリューション は自動スケーリングも提供し、多くのユース ケースに適した選択肢となります。
すぐに使用できるスケーリングを提供するサービスを利用します。 多くの PaaS サービスには、信頼性の要件を満たすように構成できる、使いやすい統合されたスケーリング機能が用意されています。 たとえば、特定の要件を満たすように Cosmos DB のスループット スケーリング を構成できます。
スケーリングの自動化
ワークロード コンポーネントのスケーリング操作を、実用的な範囲で自動化します。 構成可能な自動スケール機能を持つリソースを使用する場合は、構成ロジックをコードとしてのインフラストラクチャ (IaC) デプロイ コードに組み込みます。 すぐに使用できる自動スケーリングが提供されていないリソースを使用する場合は、ネイティブ自動化ツールを使用してスケーリング操作を実行する自動化を構築し、自動化コードを IaC コードに含めます。
1 時間あたりの注文数や複雑なトランザクションの平均実行時間など、ビジネス プロセスを測定するカウンターに基づいて自動スケール戦略を行う場合は、これらの種類のカウンターからの結果と実際のコンピューティング容量の要件との関係を十分に理解してください。 ビジネス プロセス カウンターの変更に応じて、複数のコンポーネントまたはコンピューティング ユニットをスケーリングすることが必要になる場合があります。
自動スケールは、ワークロードの突然のバーストを処理するための最も適切なメカニズムではない可能性があることに注意してください。 サービスの新しいインスタンスのプロビジョニングと開始、またはシステムへのリソースの追加には時間がかかります。需要のピークは、これらの余分なリソースが利用可能になるまでに経過する可能性があります。 このシナリオでは、サービスを制限した方が良いかもしれません。 詳細については、「 調整パターン」を参照してください。
逆に、ボリュームが急速に変動したときにすべての要求を処理する容量が必要で、コストが大きな要因ではない場合は、より迅速にインスタンスを開始する積極的な自動スケーリング戦略の使用を検討してください。 また、その負荷が予想される前に最大負荷を満たすのに十分な数のインスタンスを開始するスケジュールされたポリシーを使用することもできます。
適切なスケール ユニットを選択する
スケール ユニットに基づくスケーリング戦略。これは、一緒にスケーリングするコンポーネントの論理的なグループであり、使用するスケールの増分 (VM SKU 間の移動など) です。 考慮すべきオプションは次のとおりです。
リソースを個別にスケーリングする: 必要に応じて、個々の VM またはデータベースのみをスケーリングします。
完全なコンポーネントを同時にスケーリングする: たとえば、同時にスケーリングする必要がある App Service、データベース、キューで構成されるマイクロサービス API があるとします。
ソリューション全体のスケーリング: 複雑なワークロードやミッション クリティカルなワークロードの場合は、ソリューション全体を デプロイ スタンプ としてスケーリングすることで、スケーリング戦略を簡素化できます。 多数の異なるリソースのスケーリング スケジュールと自動スケールのしきい値を管理するのではなく、限られたスケール定義セットをデプロイ スタンプに適用し、必要に応じてスタンプ間でミラーリングすることができます。
Von Bedeutung
超過コストを回避するために、自動的に割り当てることができるスケール ユニットの数に上限を設定します。
スケール ユニットの初期化時間を最適化する
スケーリング戦略を設計する際は、異なるサービスが異なるタイムスケールでスケーリングされることを念頭に置いておください。 ほぼ瞬時にスケーリングするサービスもあれば、スケールが大幅に遅いサービスもあります。 たとえば、API Management インスタンスのスケーリング操作が完了するまでに最大 45 分かかることがあります。 スケーリング操作のタイムスケールを考慮するには、予想される負荷の増加がワークロードにヒットする前に、スケーリング操作の実行を適切に計画します。 考慮すべきその他の推奨事項は次のとおりです。
初期化に必要な時間を短縮するためにデプロイされるノードを事前初期化します。
さらに変更を加えたり、システムを一般的でない方法で使用したりする前に、構成の変更に関するバッファー時間を許容します。 たとえば、ルールの変更によって App Gateway バックエンド インスタンスの割り当てを解除できます。 接続がそのインスタンスからドレインされるまで待ってから、安全に削除する必要があります。
スケーリングが行われている間、負荷の増加に対処するためにリソースを過剰にプロビジョニングします。 VM は通常、75% の使用率容量で実行され、水平方向のスケーリングが行われている間に負荷の増加を確実に処理できます。
監視を使用してスケーリングのしきい値を微調整します。 容量の監視を使用して、スケーリングのしきい値を確認してスケーリング操作をトリガーします。
シャーディングとパーティション分割を使用してデータ ストアをスケーリングする
スケーリング戦略にデータ資産を含めることで、データ資産の信頼性を最適化します。 データをパーティション分割すると、論理ストレージ リソースまたは物理ストレージ リソースにデータベースが分散され、単一障害点が削除されます。 ユース ケースに最適なパーティション分割戦略を選択します。
水平パーティション分割 (シャーディング): パーティション (シャード) は別々のデータ ストアに配置されますが、すべてのパーティションのスキーマは同じです。 各シャードは、データベースのサブセットを保持します。 これは、負荷分散を容易にし、問題に対処するときの操作の負担を最小限に抑えるため、信頼性を最適化するための優れたアプローチです。 シャードをレプリケートして信頼性を高めることができます。
垂直パーティション分割: 各パーティションには、データ ストア内の項目のフィールドのサブセットが保持されます。 フィールドは、使用パターンに従って分割されます。
機能パーティション分割: データは、システム内の各境界コンテキストでデータがどのように使用されるかに従って集計されます。
パーティション分割スキームを設計するときは、これらの戦略を組み合わせることを検討してください。 たとえば、データをシャードに分割し、垂直パーティション分割を使用して、各シャード内のデータをさらに分割することができます。
スケーラビリティのためにパーティション戦略を最適化します。 データ アクセス パターンを分析して、最も処理の多いリソースを必要とする操作を特定し、パーティションのバランスを取って、スケーラビリティ要件を処理するのに十分なリソースが各操作に確実に含まれるようにします。
パーティション分割とシャーディングに関する詳細なガイダンスについては、設計ガイドを参照してください
スケーリング操作を監視する
自動スケール メカニズムでは、自動スケール プロセスを監視し、各自動スケール イベントの詳細 (トリガーされた内容、追加または削除されたリソース、およびタイミング) をログに記録する必要があります。 カスタム自動スケーリングメカニズムを作成する場合は、この機能を組み込むことを確認してください。 情報を事前に分析して自動スケール戦略の有効性を測定し、必要に応じて調整します。
Azure ファシリテーション
自動スケール機能は、 多くの Azure サービスで使用できます。 これにより、インスタンスを水平方向に自動的にスケーリングする条件を簡単に構成できます。 一部のサービスには、自動的にスケールインする機能が制限されているか、組み込まれている機能がないため、これらのケースを文書化し、スケールインに対処するプロセスを定義してください。
多くの Azure サービスには、Azure IoT Hub の自動スケーリングのコード サンプルなど、Azure Automation を使用してカスタム自動スケーリング操作を設計するために使用できる API が用意されています。 KEDA などのツールは、 Azure Kubernetes Service と Azure Container Apps で利用できるイベントドリブン自動スケーリングに使用できます。
Azure Monitor 自動スケール は、Azure Virtual Machine Scale Sets、Azure App Service、Azure Spring Apps などの一般的な自動スケール機能セットを提供します。 スケーリングは、スケジュールに基づいて実行することも、CPU やメモリ使用量などのランタイム メトリックに基づいて実行することもできます。 ベスト プラクティスについては、 Azure Monitor ガイド を参照してください。
トレードオフ
トレードオフ: スケールアップにはコストの影響があるため、できるだけ早くスケールダウンしてコストを管理できるように戦略を最適化します。 スケールアップに使用している自動化にもスケール ダウンのトリガーがあることを確認します。
例
AKS ベースライン リファレンス アーキテクチャ のスケーリングガイダンスを参照してください。
関連リンク
信頼性チェックリスト
完全なレコメンデーションのセットを参照してください。