信頼性の高いスケーリング戦略を設計するための推奨事項
この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:06 | アプリケーション、データ、インフラストラクチャのレベルで、タイムリーで信頼性の高いスケーリング戦略を実装します。 |
|---|
関連ガイド: データのパーティション分割
このガイドでは、信頼性の高いスケーリング戦略を設計するための推奨事項について説明します。
定義
| 相談 | 定義 |
|---|---|
| 垂直方向のスケーリング | 既存のリソースにコンピューティング容量を追加するスケーリング アプローチ。 |
| 水平スケーリング | 特定の種類のリソースのインスタンスを追加するスケーリング アプローチ。 |
| 自動スケール | 一連の条件が満たされたときにリソースを自動的に追加または削除するスケーリング アプローチ。 |
Note
スケーリング操作は、静的 (通常の負荷パターンに対応するために定期的にスケジュールされた毎日のスケーリング)、自動 (条件が満たされた場合に応じて自動で実行されるプロセス)、または手動 (オペレーターが予期しない負荷の変更に対応して 1 回だけスケーリング操作を実行する) にすることができます。 垂直および水平スケーリングは、どちらの方法でも実行できます。 ただし、自動垂直スケーリングには追加のカスタム自動化開発が必要であり、スケーリングするリソースによってはダウンタイムが発生する場合があります。
主要な設計戦略
負荷パターンに応じて設計する
ワークロードの信頼性の高いスケーリング戦略を設計するには、スケーリング操作につながる各ワークロードのユーザーおよびシステム フローの負荷パターンを特定することに重点を置きます。 さまざまな読み込みパターンの例を次に示します。
静的: 毎晩午後 11 時 (東部標準時) までに、アクティブなユーザーの数は 100 を下回り、アプリ サーバーの CPU 使用率はすべてのノードで 90% 低下する。
動的、規則的、予測可能: 毎週月曜日の朝、複数のリージョンで 1,000 人の従業員が ERP システムにサインインする。
動的、不規則、予測可能: 製品の発売が月の初日にあり、このような状況でのトラフィックの増加の様子について、前回のリリース時の履歴データがある。
動的、不規則、予測不能: 大規模なイベントにより、製品の需要にスパイクが発生する。 たとえば、除湿機を製造および販売している企業では、ハリケーンやその他の洪水などの後に、その影響を受けた地域の人々が自宅の部屋を乾燥させる必要がある場合、トラフィックが急激に増加する可能性がある。
これらの種類の読み込みパターンを特定すると、次のことができます。
各パターンに関連付けられている負荷の変化がインフラストラクチャに与える影響を特定する。
スケーリングに確実に対処するための自動化を構築する。
前の例では、スケーリング戦略は次のようになります。
静的: 午後 11 時から午前 6 時 (東部標準時) の間に、コンピューティング ノードを最小数 (2) にスケーリングするようにスケジュールされている。
動的、規則的、予測可能: 最初のリージョンが業務を開始する前に、コンピューティング ノードから通常の 1 日の容量へのスケール アウトがスケジュールされている。
動的、不規則、予測可能: 製品の発売の朝にコンピューティングおよびデータベース インスタンスの 1 回限りのスケジュールされたスケール アップを定義し、1 週間後にスケール ダウンする。
動的、不規則、予測不能: 計画外のトラフィックの急増を考慮するように自動スケーリングのしきい値が定義されている。
スケーリング戦略を自動化する
スケーリングの自動化を設計するときは、次の問題を考慮してください。
ワークロードのすべてのコンポーネントは、スケーリングの実装の候補である必要がある。 ほとんどの場合、Microsoft Entra ID などのグローバル サービスは、ユーザーと顧客に対して自動的かつ透過的にスケーリングされます。 ネットワークのイングレスおよびエグレス コントローラーと負荷分散ソリューションのスケーリング機能を必ず理解してください。
スケールアウトできないコンポーネント。たとえば、シャーディングが有効になっていないため、大きな影響を与えずにリファクタリングできない大規模なリレーショナル データベースが挙げられます。 クラウド プロバイダーによって発行されたリソース制限を文書化し、それらのリソースを注意深く監視します。 これらの特定のリソースを、スケーラブルなサービスに移行する将来の計画に含めます。
インフラストラクチャに余分な負荷がかかる前に、操作を適切にスケジュールできるように、スケーリング操作を実行するためにかかる時間。 たとえば、API Management などのコンポーネントのスケーリングに 45 分かかる場合、スケーリングのしきい値を 90% ではなく 65% に調整すると、より早くスケーリングし、予想される負荷の増加に備えるのに役立つ場合があります。
スケーリング操作の順序から見たフローのコンポーネントの関係。 最初にアップストリーム コンポーネントをスケーリングして、ダウンストリーム コンポーネントを誤ってオーバーロードしないようにします。
スケーリング操作と、実装されているセッション アフィニティ (またはセッションの持続性) によって中断される可能性があるステートフル アプリケーション要素。 持続性によってスケーリング機能が制限され、単一障害点が発生する可能性があります。
潜在的なボトルネック。 スケールアウトしても、すべてのパフォーマンスの問題が解決されるわけではありません。 たとえば、バックエンドのデータベースがボトルネックである場合、Web サーバーを追加しても改善されません。 問題に対して、単により多くのインスタンスを追加する前に、まずシステムでボトルネックを特定して解決します。 システムのステートフルな部分は、最もボトルネックの原因となりやすいものです。
デプロイ スタンプ設計パターンに従うと、インフラストラクチャ全体の管理に役立ちます。 スケーリングの単位としてスタンプをスケーリング設計の基にすることも有益です。 また、複数のワークロードとワークロードのサブセットにわたってスケーリング操作を厳密に制御するのに役立ちます。 多数の異なるリソースのスケーリング スケジュールと自動スケーリングのしきい値を管理するのではなく、限られたスケーリング定義セットをデプロイ スタンプに適用し、必要に応じてスタンプ間でミラーリングすることができます。
トレードオフ: スケールアップはコストと関連するため、できるだけ早くスケールダウンしてコストを管理できるように戦略を最適化します。 スケールアップに使用している自動化にもスケール ダウンのトリガーがあることを確認します。
Azure ファシリテーション
自動スケーリング機能は、多くの Azure サービスで使用できます。 これにより、インスタンスを水平方向に自動的にスケーリングする条件を簡単に構成できます。 一部のサービスには、自動的にスケールインする機能が制限されているか、組み込まれていないため、これらのケースを文書化し、スケールインに対処するプロセスを定義してください。
多くの Azure サービスでは、「Azure IoT Hub を自動スケーリングする」のサンプル コードのように、Azure Automation を使用したカスタム自動スケーリング操作の設計に使用できる API を提供しています。 Azure Kubernetes Service および Azure Container Apps で利用できる、イベント ドリブンの自動スケーリングには KEDA などのツールを使用できます。
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) に準拠するために、Basic サービス パッケージのコンピューティング リソースよりも、Premium サービス パッケージのコンピューティング リソースの方をより積極的にスケールアウトする必要が生じる可能性があります。
UI とバックグラウンド コンピューティング インスタンスが通信に使用するキューの長さを考慮します。 それを自動スケール戦略の基準として使用します。 この問題は、バックグラウンド タスクの現在の負荷と処理能力の間の不均衡または差異を示す可能性がある 1 つの指標です。 スケーリングの決定に基づく、少々複雑ながらより優れた属性は、メッセージが送信されてから処理が完了するまでの時間を使用することです。 この間隔は、クリティカル タイムと呼ばれます。 このクリティカル タイムの値が意味のあるビジネス上のしきい値を下回る場合は、キュー長が長くてもスケーリングする必要はありません。
たとえば、キューには 50,000 個のメッセージが含まれる可能性があります。 ただし、最も古いメッセージのクリティカル タイムは 500 ミリ秒で、エンドポイントはメールを送信するためのサードパーティの Web サービスとの統合を処理しています。 ビジネス利害関係者は、それをスケーリングのために余分なコストを使うことを正当化できない期間であるとみなすでしょう。
一方、キューに 500 個のメッセージがある可能性があり、クリティカル タイムは同じ 500 ミリ秒だが、エンドポイントは、ビジネス利害関係者が応答時間を 100 ミリ秒以下に定義した、あるリアルタイム オンライン ゲームのクリティカル パスの一部です。 その場合は、スケールアウトが有効であると言えます。
自動スケーリングの決定にクリティカル時間を利用するには、メッセージの送信および処理中に、それらのヘッダーに関連情報を自動的に追加するライブラリを用意すると便利です。 この機能を提供するライブラリの 1 つが NServiceBus です。
1 時間当たりに行われた命令数や複雑なトランザクションの平均実行時間など、ビジネス プロセスを測定するカウンターに基づいて自動スケーリング戦略を作成する場合は、そのようなタイプのカウンターから得られる結果と実際のコンピューティング能力の要件の関係を完全に理解してください。 ビジネス プロセス カウンターの変更に応じて、複数のコンポーネントまたはコンピューティング ユニットをスケールする必要が生じる場合があります。
システムによって過度なスケールアウトが試行されたり、多数のインスタンス実行に関連するコストが生じたりしないようにするために、自動的に追加できるインスタンスの最大数を制限することを検討してください。 ほとんどの自動スケーリング メカニズムでは、ルールのインスタンスの最小数と最大数を指定できます。 また、インスタンスの最大数を設定しても、システムが依然としてオーバーロードの状態である場合には、システムによって提供される機能を適度に低下させることを検討してください。
自動スケーリングは、ワークロードの急激な増加を処理する最も適切なメカニズムではない場合もあることに留意してください。 サービスの新しいインスタンスをプロビジョニングして開始したり、リソースをシステムに追加したりする作業は時間を要します。また、追加したそのリソースが使用できるようになる頃には、ピーク需要が過ぎてしまう可能性もあります。 このようなときは、サービスを調整したほうがよい場合があります。 詳細については、「調整パターン」を参照してください。
逆に、ボリュームが急激に変動する場合にすべての要求を処理する容量が必要であり、コストが主な検討要因ではない場合は、追加のインスタンスをより迅速に開始する積極的な自動スケーリング戦略の使用を検討してください。 また、負荷が予見される前に、十分な数のインスタンスを開始して最大負荷に対応するようにスケジュール設定されたポリシーを使用する方法もあります。
自動スケーリング メカニズムでは、自動スケーリング プロセスを監視し、各自動スケーリング イベントの詳細 (イベントがトリガーされた理由、追加または削除されたリソース、それらの日時) を記録する必要があります。 カスタムの自動スケール メカニズムを作成する場合は、この機能が組み込まれていることを確認してください。 情報を分析して、自動スケール戦略の効果を測定し、必要に応じて調整します。 使用パターンがより明確な場合は短期間の調整を行い、ビジネスが拡大したり、アプリケーションの要件が増加したりする場合は長期間の調整を行うことができます。 アプリケーションが自動スケーリングの定義された上限に到達すると、このメカニズムにより、必要に応じてより多くのリソースを手動で開始できるオペレーターにアラートが出される可能性もあります。 このような状況下では、ワークロードが軽減された後、オペレーターがこれらのリソースを手動で削除する責任を負う場合もあります。
例
AKS ベースライン リファレンス アーキテクチャのスケーリング ガイダンスを参照してください。
関連リンク
信頼性チェックリスト
レコメンデーションの完全なセットを参照してください。