Azure Firewall の事前スケーリング

Azure Firewall では、CPU 使用率、スループット、接続ボリュームに基づいて容量を動的に調整するための組み込みの自動スケーリングがサポートされています。 ミッション クリティカルなワークロードや予測可能なトラフィックの急増 (ブラック フライデーや移行など) の場合は、一貫したパフォーマンスを確保するために、より優れた制御を構成できます。

事前スケーリング を使用すると、最小容量ユニットと最大容量ユニットを事前に設定できます。 この構成では、定義された範囲内で自動スケールが行われる間、予測可能なパフォーマンスが提供されます。

主な利点

プリスケーリングを使用することで、次のことができます。

• 高トラフィックのイベントや既知のトラフィックスパイクに備えて容量を事前に準備する
• ベースライン容量を設定して一貫したパフォーマンスを維持する
• 観測容量メトリクスを用いてリアルタイムで容量を観察する

事前スケーリングのしくみ

autoscaleConfiguration 設定では、次の 2 つのプロパティを構成できます。

minCapacity と maxCapacity が同じ値に設定されている場合、ファイアウォールは自動スケールなしで固定容量で実行されます。

構成オプション

事前スケーリングは、Azure portal、Azure PowerShell、ARM テンプレート、または Bicep を使用して構成できます。

ポータルの例

Azure ポータルでプレスケーリングを構成するには:

1. Azure Firewall リソースに移動します。
2. [ 設定] で、[ スケーリング オプション] を選択します。
3. [事前スケーリング] を選択します。
4. 目的の最小容量と最大容量の値を設定します。

PowerShell の例

New-AzFirewall `
  -Name "MyFirewall" `
  -ResourceGroupName "MyResourceGroup" `
  -Location "centralus" `
  -VirtualNetwork (Get-AzVirtualNetwork -Name "MyVNet" -ResourceGroupName "MyResourceGroup") `
  -PublicIpAddress (Get-AzPublicIpAddress -Name "MyFW-PublicIP" -ResourceGroupName "MyResourceGroup") `
  -MinCapacity 4 `
  -MaxCapacity 10

Bicep の例

参考までに、新しい autoscaleConfiguration プロパティを確認できる Bicep テンプレートを使用した構成例を次に示します。 Azure Firewall Bicep テンプレート

容量値の選択

最適な minCapacity 値と maxCapacity 値を決定するには:

• 不要なスケーリングを回避するために適切な最小値を設定します。通常のピーク トラフィックを快適に処理する最小容量から開始します。そのため、スケーリング イベントは通常の条件下ではまれです。
• ヘッドルームの最大値を大きくしたままにする: 予期しないサージを処理するために、maxCapacity を予想されるピークよりも高く設定します。 Azure Firewall の自動スケールにより、maxCapacity 値まで容量が増加します。
• 監視容量メトリックを監視 してスケーリングの頻度を確認し、必要に応じて最小値と最大値を調整します。 スケーリングが頻繁に行われる場合は、minCapacity を上げることを検討してください。
• 調整が必要かどうかを評価できるように、監視容量メトリックでアラートを構成して、スケーリング イベントが発生したときに通知を受け取るようにします。

モニタリング

** プレスケーリングは新しい可観測性を導入します。

パフォーマンスの問題の処理

パケットのドロップまたは接続の問題が発生した場合:

• 容量の傾向を評価するには、観察された容量を確認します。
• より多くの容量サポートを提供するために、または頻繁に上向きのスケールが発生する場合は、最小容量を増やすことを検討してください。
• 待機時間プローブ、スループット、監視容量などの主要なテレメトリ メトリックを使用して、スケーリング戦略を最適化します。

課金情報

事前スケーリングでは、通常の Azure Firewall 料金に加えて課金される容量ユニット時間課金メーターが導入されています。 料金は、プロビジョニングされた容量ユニットごとに 1 時間あたりに計算されます。

この計算に使用されるインスタンス数は、既定で実行されている 2 つのインスタンスを除外します。 たとえば、10 個のインスタンスがプロビジョニングされている場合、課金対象の数は 8 になります。

制限事項

事前スケーリングを使用する場合は、次の点に注意してください。

• リージョン レベルの容量の保証なし: リージョンに容量がない場合、スケーリングが失敗したり、遅延したりする可能性があります。
• 固定容量では自動スケールが無効になります。minCapacity が maxCapacity と等しい場合、自動スケールは無効になります。
• 以前の設定の保持: ファイアウォールに autoscaleConfiguration 値が既に設定されていて、autoscaleConfiguration プロパティ (Bicep、ARM テンプレート、その他のテンプレートなど) を指定せずにリソースをデプロイまたは更新した場合、ファイアウォールは既存の autoscaleConfiguration 値を使用し続けます。 この動作は、スケーリング設定が誤って上書きされたり失われたりするのを防ぐのに役立ちます。
• リソースの変更に対する構成のリセット: ファイアウォールを削除、再作成、または移行すると、容量の値が既定値にリセットされる場合があります。
• アクティブなスケーリングまたはメンテナンス イベント: ファイアウォールがミッドスケールの場合、またはアップグレード中に、事前スケーリングの変更が失敗する可能性があります。 完了後に再試行してください。

既知の問題

事前スケーリングを使用する場合、次の既知の問題が存在します。

次のステップ

• Azure Firewall の監視について説明します
• Azure Firewall のベスト プラクティスを確認する