Share via

信頼性の高いスケーリング戦略を設計するための推奨事項

  • [アーティクル]

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

RE:06 アプリケーション、データ、インフラストラクチャ の各レベルで、タイムリーで信頼性の高いスケーリング戦略を実装します。

関連ガイド:データのパーティション分割

このガイドでは、信頼性の高いスケーリング戦略を設計するための推奨事項について説明します。

定義

期間 定義
垂直方向のスケーリング 既存のリソースにコンピューティング容量を追加するスケーリング アプローチ。
水平スケーリング 特定の種類のリソースのインスタンスを追加するスケーリングアプローチ。
自動スケール 一連の条件が満たされたときにリソースを自動的に追加または削除するスケーリング アプローチ。

注意

スケーリング操作は、静的 (通常の負荷パターンに対応するために定期的にスケジュールされた毎日のスケーリング)、自動 (満たされている条件に応じて自動化されたプロセス)、手動 (予期しない負荷の変更に応じて 1 回限りのスケーリング操作を実行する) のいずれかです。 垂直方向と水平方向の両方のスケーリングは、これらの方法のいずれかを使用して実行できます。 ただし、垂直方向の自動スケーリングでは、追加のカスタム自動化開発が必要であり、スケーリングされるリソースによってはダウンタイムが発生する可能性があります。

主要な設計戦略

ワークロードの信頼性の高いスケーリング戦略を設計するには、スケーリング操作につながる各ワークロードのユーザーとシステム フローの負荷パターンを特定することに重点を置きます。 さまざまな読み込みパターンの例を次に示します。

  • 静的: 毎晩午後 11 時までにアクティブなユーザーの数が 100 を下回り、アプリ サーバーの CPU 使用率がすべてのノードで 90% 低下します。

  • 動的、定期的、予測可能: 毎週月曜日の朝、複数のリージョンにまたがる 1,000 人の従業員が ERP システムにサインインします。

  • 動的、不規則、予測可能: 製品の発売は月の最初の日に行われ、このような状況でのトラフィックの増加に関する以前の発表の履歴データがあります。

  • 動的、不規則、予測不可能: 大規模なイベントにより、製品の需要が急増します。 たとえば、除湿機を製造および販売している企業では、影響を受ける地域の人々が自宅の部屋を乾燥させる必要がある場合、ハリケーンやその他の洪水イベントの後にトラフィックが急激に急増する可能性があります。

これらの種類の読み込みパターンを特定したら、次のことができます。

  • 各パターンに関連付けられている負荷の変化がインフラストラクチャに与える影響を特定します。

  • スケーリングに確実に対処するための自動化を構築します。

前の例では、スケーリング戦略は次のようになります。

  • 静的: コンピューティング ノードのスケジュールされたスケールを、午後 11 時から午前 6 時 EST の間の最小数 (2) に設定します。

  • 動的、通常、予測可能: 最初のリージョンが動作を開始する前に、コンピューティング ノードから通常の 1 日の容量へのスケールアウトがスケジュールされています。

  • 動的、不規則、予測可能: 製品発売の朝にコンピューティングとデータベース インスタンスの 1 回限りのスケジュールされたスケールアップを定義し、1 週間後にスケールダウンします。

  • 動的、不規則、予測不可能: 計画外のトラフィックの急増を考慮するために、自動スケーリングのしきい値が定義されています。

スケーリングの自動化を設計するときは、次の問題を考慮してください。

  • ワークロードのすべてのコンポーネントは、スケーリング実装の候補である必要があります。 ほとんどの場合、Microsoft Entra ID などのグローバル サービスは、ユーザーと顧客に対して自動的かつ透過的にスケーリングされます。 ネットワーク イングレスコントローラーとエグレス コントローラーのスケーリング機能と負荷分散ソリューションを理解してください。

  • スケールアウトできないコンポーネント。たとえば、シャーディングが有効になっていない大規模なリレーショナル データベースがあり、大きな影響を与えずにリファクタリングすることはできません。 クラウド プロバイダーによって公開されているリソース制限を文書化し、それらのリソースを注意深く監視します。 これらの特定のリソースを、スケーラブルなサービスに移行するための将来の計画に含めます。

  • 追加の負荷がインフラストラクチャにヒットする前に操作を適切にスケジュールできるように、スケーリング操作の実行にかかる時間。 たとえば、API Management のようなコンポーネントのスケーリングに 45 分かかる場合、スケーリングしきい値を 90% ではなく 65% に調整すると、より早くスケーリングし、予想される負荷の増加に備えるのに役立つ場合があります。

  • スケール操作の順序に関するフローのコンポーネントの関係。 最初にアップストリーム コンポーネントをスケーリングして、ダウンストリーム コンポーネントを誤ってオーバーロードしないようにします。

  • スケーリング操作と、実装されているセッション アフィニティ (またはセッションの持続性) によって中断される可能性のあるステートフル なアプリケーション要素。 べたつきによってスケーリング機能が制限され、単一障害点が発生する可能性があります。

  • 潜在的なボトルネック。 スケールアウトしても、すべてのパフォーマンスの問題が解決されるわけではありません。 たとえば、バックエンド データベースがボトルネックである場合、Web サーバーを追加しても役に立ちません。 インスタンスを追加する前に、まずシステムのボトルネックを特定して解決します。 システムのステートフルな部分は、最もボトルネックの原因となりやすいものです。

デプロイ スタンプの設計パターンに従うと、インフラストラクチャ全体の管理に役立ちます。 また、スケールの単位としてスタンプにスケーリング設計を基にすることも有益です。 また、複数のワークロードとワークロードのサブセットにわたってスケーリング操作を厳密に制御するのに役立ちます。 多数の異なるリソースのスケーリング スケジュールと自動スケーリングしきい値を管理するのではなく、限定された一連のスケーリング定義をデプロイ スタンプに適用し、必要に応じてスタンプ間でミラーできます。

トレードオフ: スケールアップにはコストの影響があるため、できるだけ早くスケールダウンしてコストを管理できるように戦略を最適化します。 スケールアップに使用する自動化に、スケール ダウンのトリガーも含まれるようにします。

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 ガイド を参照してください。

トレードオフ

自動スケーリングに関する考慮事項

自動スケールは単純なソリューションではありません。 単にリソースをシステムに追加したり、実行するプロセスのインスタンスを増やしたりするだけで、システムのパフォーマンスが確実に向上するわけではありません。 自動スケール戦略を作成するときには、次の点を考慮してください。

システムは、水平方向にスケールできるように設計されている必要があります。 インスタンス アフィニティに関する仮定は避けてください。 コードが常にプロセスの特定のインスタンスで実行されている必要があるソリューションを設計しないでください。 クラウド サービスまたは Web サイトを水平方向にスケーリングする場合、同じソースからの一連の要求が常に同じインスタンスにルーティングされるとは想定しないでください。 同様の理由で、アプリケーションからの一連の要求が常にサービスの同じインスタンスにルーティングされなくても済むように、サービスはステートレスになるように設計します。 キューからメッセージを読み取り、それらを処理するサービスを設計する場合、サービスのどのインスタンスが特定のメッセージを処理するかを事前に想定しないでください。 自動スケーリングでは、キューの長さが長くなるにつれて、サービスのインスタンスが増える可能性があります。 「競合コンシューマー パターン」には、この状況に対処する方法が記載されています。

ソリューションで長期タスクを実装する場合、このタスクを作成して、スケールアウトとスケールインの両方がサポートされるようにします。 このようなタスクは、システムのスケールイン時にプロセスのインスタンスが正常にシャットダウンされるのを防ぐ可能性があります。 または、プロセスが強制的に終了すると、データが失われる可能性があります。 可能であれば、長期タスクをリファクタリングし、プロセスを分割して、より小さい、個別のまとまりで実行されるようにします。 パイプとフィルター パターンでは、このソリューションを実現する方法の例を示します。

または、タスクに関する状態情報を定期的に記録するチェックポイント メカニズムを実装することもできます。 その後、タスクを実行しているプロセスの任意のインスタンスからアクセスできる永続ストレージにこの状態を保存できます。 このようにして、プロセスがシャットダウンされた場合、実行していた作業は、別のインスタンスによって最後のチェックポイントから再開できます。 NServiceBus や MassTransit など、この機能を備えたライブラリがあります。 これらは透過的に状態を保持します。間隔は、Azure Service Bus内のキューからのメッセージの処理に合わせて調整されます。

クラウド サービスでホストされるアプリケーションの worker ロールなど、バックグラウンド タスクを別々のコンピューティング インスタンスで実行する場合は、異なるスケーリング ポリシーを使用してアプリケーションのさまざまな部分をスケーリングする必要がある場合があります。 たとえば、バックグラウンド コンピューティング インスタンスの数を増やすことなく、追加のユーザー インターフェイス (UI) コンピューティング インスタンスをデプロイする必要がある場合や、その逆を行う必要がある場合があります。 Basic サービス パッケージや Premium サービス パッケージなど、さまざまなレベルのサービスを提供する場合は、サービス レベル アグリーメント (SLA) を満たすために、基本的なサービス パッケージよりも積極的に Premium サービス パッケージのコンピューティング リソースをスケールアウトする必要がある場合があります。

UI とバックグラウンド コンピューティング インスタンスが通信に使用するキューの長さを考慮します。 それを自動スケール戦略の基準として使用します。 この問題は、現在の負荷とバックグラウンド タスクの処理能力の不均衡または差を示すインジケーターの 1 つです。 スケーリングの決定の基礎となるもう少し複雑ですが、より優れた属性は、メッセージが送信されてから処理が完了するまでの時間を使用することです。 この間隔はクリティカルタイムと呼ばれます。 この重要な時間値が意味のあるビジネスしきい値を下回っている場合は、キューの長さが長い場合でもスケーリングする必要があります。

たとえば、キューに 50,000 件のメッセージが含まれる場合があります。 しかし、最も古いメッセージの重要な時間は 500 ミリ秒であり、エンドポイントはメールを送信するためのサードパーティの Web サービスとの統合を処理しています。 ビジネス利害関係者は、スケーリングに余分なお金を費やすことを正当化しない期間であると考える可能性があります。

一方、キューには 500 個のメッセージがあり、クリティカル時間は 500 ミリ秒と同じですが、ビジネス関係者が応答時間を 100 ミリ秒以下で定義したリアルタイム オンライン ゲームでは、エンドポイントはクリティカル パスの一部です。 その場合は、スケールアウトが有効であると言えます。

自動スケーリングの決定に重要な時間を使用するには、ライブラリでメッセージの送信と処理中に関連する情報をメッセージのヘッダーに自動的に追加すると便利です。 この機能を提供する 1 つのライブラリは NServiceBus です。

1 時間あたりの注文数や複雑なトランザクションの平均実行時間など、ビジネス プロセスを測定するカウンターに基づいて自動スケーリング戦略を行う場合は、これらの種類のカウンターからの結果と実際のコンピューティング容量要件の関係を十分に理解してください。 ビジネス プロセス カウンターの変更に応じて、複数のコンポーネントまたはコンピューティング ユニットをスケーリングすることが必要な場合があります。

システムが過剰にスケールアウトを試みないようにし、何千ものインスタンスの実行に関連するコストを回避するには、自動的に追加されるインスタンスの最大数を制限することを検討してください。 ほとんどの自動スケーリング メカニズムでは、ルールのインスタンスの最小数と最大数を指定できます。 さらに、インスタンスの最大数がデプロイされていて、システムがまだオーバーロードされている場合は、システムが提供する機能を適切に低下することを検討してください。

自動スケーリングは、ワークロードの突然のバーストを処理するための最も適切なメカニズムではない可能性があることに注意してください。 サービスの新しいインスタンスのプロビジョニングと開始、またはシステムへのリソースの追加に時間がかかり、これらの追加リソースが使用可能になるまでにピーク需要が過ぎる可能性があります。 このシナリオでは、サービスを調整することをお勧めします。 詳細については、「調整パターン」を参照してください。

逆に、ボリュームが急速に変動したときにすべての要求を処理する容量が必要で、コストが大きな要因ではない場合は、より多くのインスタンスをより迅速に開始する積極的な自動スケーリング戦略の使用を検討してください。 また、負荷が予見される前に、十分な数のインスタンスを開始して最大負荷に対応するようにスケジュール設定されたポリシーを使用する方法もあります。

自動スケーリング メカニズムでは、自動スケーリング プロセスを監視し、各自動スケーリング イベントの詳細 (トリガーされた内容、追加または削除されたリソース、およびいつ) をログに記録する必要があります。 カスタムの自動スケール メカニズムを作成する場合は、この機能が組み込まれていることを確認してください。 情報を分析して、自動スケール戦略の効果を測定し、必要に応じて調整します。 使用パターンがより明確な場合は短期間の調整を行い、ビジネスが拡大したり、アプリケーションの要件が増加したりする場合は長期間の調整を行うことができます。 アプリケーションが自動スケーリング用に定義された上限に達した場合、必要に応じてより多くのリソースを手動で開始できるオペレーターに、メカニズムによって警告される場合もあります。 このような状況では、ワークロードの緩和後にオペレーターがこれらのリソースを手動で削除する責任も負う場合があります。

例

AKS ベースライン リファレンス アーキテクチャ のスケーリングに関するガイダンスを参照してください。

信頼性チェックリスト

推奨事項の完全なセットを参照してください。

信頼性チェックリスト