自動スケールのベスト プラクティス
Azure Monitor の自動スケーリングは、Azure Virtual Machine Scale Sets、Azure Cloud Services、Azure App Service の Web Apps 機能、および Azure API Management にのみ適用されます。
自動スケールの概念
- 1 つのリソースで使用できる自動スケーリング設定は "1 つ" に限られます。
- 自動スケーリング設定では、1 つ以上のプロファイルを使用でき、プロファイルごとに 1 つ以上の自動スケーリング ルールを設定できます。
- 自動スケール設定では、インスタンスが水平方向にスケールされます。つまり、インスタンス数を増やしてスケール "アウト" し、インスタンス数を減らしてスケール "イン" します。
- 自動スケール設定には、インタンスの最大値、最小値、既定値があります。
- 自動スケール ジョブでは、スケールに使用する関連付けられたメトリックを常に読み取り、スケールアウトまたはスケールインの構成済みのしきい値を超えているかどうかをチェックします。 自動スケールで使用できるメトリックの一覧については、「Azure Monitor の自動スケールの一般的なメトリック」をご覧ください。
- しきい値はすべてインスタンス レベルで計算されます。 たとえば、"インスタンス数が 2 で、平均 CPU 使用率が 80% を超えたときに、インスタンスを 1 つ増やしてスケールアウト" します。これは、全インスタンスの平均 CPU 使用率が 80% を超えたときにスケールアウトすることを意味します。
- 自動スケーリングのエラーはすべてアクティビティ ログに記録されます。 次に、自動スケーリング エラーが発生したときに必ず、電子メール、SMS、または Webhook で通知されるように、アクティビティ ログ アラートを構成できます。
- 同様に、正常なスケール アクションすべてが、アクティビティ ログに記録されます。 次に、自動スケーリング アクションが成功したときに必ず、電子メール、SMS、または Webhook で通知されるように、アクティビティ ログ アラートを構成できます。 また、正常なスケール操作が行われたときに通知されるように、自動スケール設定の通知タブで、電子メールまたは webhook の通知を構成することもできます。
自動スケールのベスト プラクティス
自動スケールを使用するときは、次のベスト プラクティスを使用します。
最大値と最小値が異なっており、これらの値に十分な差があることを確認する
最小値が 2 で最大値が 2 の設定があり、現在のインスタンス数が 2 の場合、スケール操作は実行できせん。 インスタンスの最大数と最小数に十分な差を付けておきます。 自動スケールでは、常にこれらの制限の範囲でスケールします。
手動スケーリングは、自動スケーリングの最小値と最大値によってリセットされる
インスタンス数を最大値を上回る値または下回る値に手動で更新した場合、自動スケール エンジンにより、自動的に最小値 (下回る場合) または最大値 (上回る場合) にスケールされます。 たとえば、3 ～ 6 の範囲を設定します。 実行中のインスタンスが 1 つの場合は、自動スケーリング エンジンにより、次回の実行時にインスタンスが 3 つにスケーリングされます。 同様に、スケーリングを 8 インスタンスに手動で設定すると、自動スケーリングが次回実行されたときに 6 インスタンスに戻ります。 自動スケーリング ルールもリセットしない限り、手動スケーリングの効果は一時的です。
増減を実行するスケールアウトとスケールインのルールの組み合わせを常に使用する
組み合わせの一方のみを使用すると、自動スケーリングは、プロファイルで定義されている最大または最小のインスタンス数に達するまで、単一方向 (スケールアウトかスケールイン) のみの動作を行います。 この状況は最適ではありません。 理想的には、可用性を確保するために、使用率が高い時間帯にリソースをスケールアウトする必要があります。 同様に、使用率が低いときは、コストを節約するため、リソースをスケールインする必要があります。
スケールインとスケールアウト ルールを使用するときは、同じメトリックを使用して両方を制御するのが理想です。 そうしないと、スケールインとスケールアウトの条件が同時に満たされ、ある程度のフラッピングが発生する可能性があります。 たとえば、次のルールの組み合わせは、メモリ使用量のスケールイン ルールがないため推奨されません。
- CPU 使用率が 90% を超えた場合は 1 つスケールアウトする
- メモリ使用率が 90% を超えた場合は 1 つスケールアウトする
- CPU 使用率が 45% 未満の場合は 1 つスケールインする
この例では、メモリ使用量が 90% を超えているにもかかわらず、CPU 使用率は 45% を下回るという状況が考えられます。 このシナリオでは、両方の条件が満たされている間、フラッピングにつながる可能性があります。
診断メトリックに適切な統計を選択する
診断メトリックの場合、スケールに使用するメトリックとして、平均、最小、最大、合計 の中から選択できます。 最も一般的な統計は 平均です。
特殊なメトリックのスケーリングしきい値に関する考慮事項
Azure Storage や Azure Service Bus のキューの長さメトリックなどの特殊なメトリックでは、しきい値は現在のインスタンス数あたりの使用可能な平均メッセージ数です。 このメトリックのしきい値は慎重に選択します。
動作を理解しやすいように、例を挙げて説明します。
- Storage のキューのメッセージ数が 50 以上のときにインスタンスを 1 つ増やす
- Storage のキューのメッセージ数が 10 以下のときにインスタンスを 1 つ減らす
次の例について考えてみます。
- 2 つの Storage キュー インスタンスがあります。
- メッセージが次々にキューに入り、Storage キューを確認したところ、メッセージの総数が 50 になっていました。 この場合、自動スケールによってスケールアウト操作が開始されると思われるかもしれませんが、 ただし、インスタンスあたりのメッセージ数はまだ 50/2 = 25 です。 そのため、スケールアウトは行われません。 最初のスケールアウトが発生するには、Storage キューのメッセージの総数が 100 になる必要があります。
- 次に、メッセージの総数が 100 に達したとします。
- スケールアウト操作により、3 つ目の Storage キュー インスタンスが追加されます。 150/3 = 50 であるため、キューのメッセージの総数が 150 に達するまで、次のスケールアウト操作は実行されません。
- これで、キューあたりのメッセージの数が減少します。 インスタンスが 3 つの場合、すべてのキューのメッセージの総数が 30 に達すると、インスタンスあたりのメッセージ数がスケールインのしきい値である 30/3 = 10 になるため、最初のスケールイン操作が実行されます。
プロファイルに複数のルールが構成されている場合のスケーリングに関する考慮事項
プロファイルに複数のルールを設定することが必要な場合があります。 複数のルールが設定されている場合、自動スケーリング エンジンでは次の自動スケーリング ルールが使用されます。
- "スケールアウト" の場合、いずれかのルールが満たされていれば、自動スケールが実行されます。
- "スケールイン" では、自動スケーリングのすべてのルールが満たされている必要があります。
わかりやすく説明するために、4 つの自動スケーリング ルールがあると仮定します。
- CPU 使用率が 30% 未満の場合は 1 つスケールインする
- メモリ使用率が 50% 未満の場合は 1 つスケールインする
- CPU 使用率が 75% を超えた場合は 1 つスケールアウトする
- メモリ使用率が 75% を超えた場合は 1 つスケールアウトする
その後、次のアクションが発生します。
- CPU が 76% でメモリが 50% の場合、スケールアウトします。
- CPU が 50% でメモリが 76% の場合、スケールアウトします。
一方、CPU が 25% でメモリが 51% の場合、スケールインは "実行されません"。 スケールインのためには、CPU が 29%、メモリが 49% である必要があります。
常に、安全な既定のインスタンス数を選択する
既定のインスタンス数は重要です。自動スケーリングで、メトリックを使用できないときにサービスがその数にスケーリングされるからです。 そのため、ワークロードに対して安全な既定のインスタンス数を選択してください。
自動スケールの通知を構成する
自動スケーリングでは、次のいずれかの状況が発生した場合に、アクティビティ ログに記録されます。
- 自動スケールでスケール操作が発行された。
- 自動スケール サービスでスケール操作が正常に完了した。
- 自動スケール サービスがスケール操作を実行できない場合。
- 自動スケーリング サービスでスケールを決定する際にメトリックを使用できない場合
- スケールを決定する際にメトリックを再び使用できるようになった (回復した) 場合。
- 自動スケーリングによってフラッピングが検出され、スケーリングの試行が中止されます。 この状況では、
Flappingのログの種類が表示されます。 この種類のログが表示された場合は、しきい値が狭すぎるかどうかを検討してください。 - 自動スケーリングによってフラッピングが検出されますが、スケーリングは正常に実行できます。 この状況では、
FlappingOccurredのログの種類が表示されます。 このログの種類が表示された場合は、自動スケーリング エンジンによって (たとえば、4 インスタンスから 2 への) スケーリングが試行されたものの、この変更によりフラッピングが発生する可能性があると判断されました。 代わりに、自動スケーリング エンジンによって、異なる数のインスタンス (たとえば、2 つではなく 3 つのインスタンスを使用する) にスケーリングされています。フラッピングが発生しなくなるので、この数のインスタンスにスケーリングされています。
また、アクティビティ ログ アラートを使用して、自動スケーリング エンジンの正常性を監視することもできます。 一例として、アクティビティ ログ アラートを作成して、サブスクリプションで自動スケーリング エンジン操作をすべて監視する方法を示します。 もう 1 つの例では、アクティビティ ログ アラートを作成して、サブスクリプションで失敗した自動スケーリングのスケールイン/スケールアウト操作をすべて監視する方法について示します。
アクティビティ ログ アラートを使用する以外に、スケール操作が行われたときに通知されるように、自動スケール設定の通知タブで、電子メールまたは webhook の通知を構成することもできます。
TLS 1.2 を使用してデータを安全に送信する
Azure Monitor に転送中のデータのセキュリティを確保するには、エージェントを、少なくともトランスポート層セキュリティ (TLS) 1.2 を使用するように構成することを強くお勧めします。 これより前のバージョンの TLS/Secure Sockets Layer (SSL) は脆弱であることが判明しています。 現在も下位互換性を確保するために動作しますが、推奨 "されません"。 業界は、これらの古いプロトコルのサポートを中止する方向へ急速に動いています。
PCI Security Standards Council は、2018 年 6 月 30 日を期限として、TLS/SSL の以前のバージョンを無効にし、より安全なプロトコルにアップグレードすることを求めています。 Azure がレガシー サポートを廃止した後は、エージェントが TLS 1.2 以上で通信できないと、Azure Monitor ログにデータを送信できなくなります。
お使いのエージェントで TLS 1.2 のみを使用するように明示的に設定することは、必要でない限りお勧め "しません"。 エージェントによる今後のセキュリティ標準の自動検出、ネゴシエートを許可し、利用できるようにしておくことをお勧めします。 そうしないと、新しい標準によるセキュリティ強化が使用できなくなり、TLS 1.2 が廃止され、新しい標準が採用されたときに、問題が発生する可能性があります。