一般的な自動スケーリング パターン
このユニットでは、自動スケーリングのパターンについて説明します。
自動スケールは単純なソリューションではありません。 システムに単にリソースを追加したり、プロセスのインスタンスをより多く実行したりするだけで、システムのパフォーマンスが向上するとは保証されません。 自動スケール戦略を作成するときには、次の点を考慮してください。
Recommendations
ボトルネックを特定する: スケールアウトは、すべてのパフォーマンスの問題が修正されるマジックではありません。 たとえば、バックエンドのデータベースがボトルネックである場合、Web サーバーを追加しても改善されません。 問題に対してより多くのインスタンスを投入する前に、システムでボトルネックを特定して解決します。 システムのステートフルな部分は、最もボトルネックの原因となりやすいものです。
スケーラビリティの要件ごとにワークロードを分解する: アプリケーションは多くの場合、異なるスケーリング要件がある、複数のワークロードで構成されます。 たとえば、公開サイトと、それとは別に管理サイトがあるアプリケーションがあります。 公開サイトでは突然のトラフィック増加が発生する可能性がある一方、管理サイトの負荷はより小さな、より予測がしやすいものです。
多くのリソースを消費するタスクのオフロード。CPU または I/O リソースを多く必要とするタスクは、可能であれば、バックグラウンド ジョブに移動する必要があります。 タスクをオフロードすると、ユーザー要求を処理するフロントエンドの負荷が最小限に抑えられます。
組み込みの自動スケーリング機能を使用する: アプリケーションに予測可能な通常のワークロードがある場合は、スケジュールに基づいてスケールアウトします。 たとえば、営業時間内にスケールアウトします。 そうではなくて、ワークロードが予測可能でない場合は、CPU や要求キューの長さなどのパフォーマンス メトリックを使用して自動スケーリングをトリガーします。
重要なワークロードに対して積極的な自動スケーリングを検討する: 重要なワークロードの場合は、需要を先読みする必要があります。 負荷が高い状態で新しいインスタンスをすばやく追加して他のトラフィックを処理し、徐々にスケールバックすることをお勧めします。
スケールインに向けた設計。柔軟なスケールでは、インスタンスが削除されると、アプリケーションにスケールインの期間が生じることに注意してください。 アプリケーションでは、削除中のインスタンスを適切に処理する必要があります。 次に、スケールインを処理する方法をいくつか示します。
- シャットダウン イベントが使用可能な場合はこれらをリッスンし、正常にシャットダウンします。
- 一時的な障害処理と再試行をサポートします。
- 実行時間の長いタスクについては、作業を分割することを検討してください。
- 作業項目をキューに配置して、インスタンスが処理の最中に削除された場合は別のインスタンスが作業を取得できるようにします。
通知
- すべての自動スケール エラーがアクティビティ ログに記録されます。 その後、自動スケールエラーが発生するたびに、電子メール、ショート メッセージ サービス (SMS)、または Webhook を介して通知するアクティビティ ログ アラートを構成できます。
- 同様に、正常なスケール アクションすべてが、アクティビティ ログに記録されます。 次に、自動スケーリング アクションが成功したときに必ず、電子メール、SMS、または Webhook で通知されるように、アクティビティ ログ アラートを構成できます。 また、正常なスケール操作が行われたときに通知されるように、自動スケーリング設定の [通知] タブで、電子メールまたは webhook の通知を構成することもできます。
Azure でリソースをスケーリングするための一般的なパターン
需要に応じてスケーリングする
顧客の需要が増加する始業時にサービス インスタンスの数を自動的にスケールアウトできます。 終業時に、アプリケーション インスタンスの数を自動的にスケーリングして、アプリケーションの使用が少ない夜間のリソース コストを最小限に抑えます。
平日と週末に異なる方法でスケールする
夜間や週末には、アプリケーションの需要は低くなる可能性があります。 この負荷が一定期間にわたって一貫している場合、スケール セット内のサービス インスタンスの数を減らすように自動スケーリング ルールを構成できます。 このスケールイン アクションを実行することで、現在の需要を満たすのに必要な数のインスタンスのみが実行されるようになるため、スケール セットの実行コストが削減されます。
休暇中は異なる方法でスケールする
月や会計サイクルの特定の時期にサービスの利用が集中する場合は、その追加需要に合わせてサービス インスタンスの数を自動的に拡張できます。 マーケティング イベント、プロモーション、またはホリデー セールがある場合は、予想される顧客の需要に先立ってサービス インスタンスの数を自動的に拡張できます。
カスタム メトリックに基づいてスケールする
最後に、自動スケーリング ルールを慎重に定義することをお勧めします。 たとえば、サービス拒否 (DoS) 攻撃によって大量の受信トラフィックが流入する可能性があります。 DoS 攻撃による要求の急増を処理しようとするのは無駄なことで、大きな損害を被ります。 このような本物ではない要求は、処理するのではなく破棄しなければなりません。 より良いソリューションは、そのような攻撃中に発生する要求の検出とフィルタリングを実装し、要求がサービスに届かないようにすることです。
自動スケーリングのルールを構成したら、アプリケーションのパフォーマンスを一定期間モニターします。 この監視の結果を使用して、必要に応じてシステムをスケーリングするパターンを調整します。