エージェントのリソースを割り当てる
- English
- 日本語
Next-Gen WAF エージェントが適切に機能するにはコンピューティングリソースが必要です。デプロイのセットアップとテストを行う際には、エージェントに十分な CPU、RAM、およびファイルハンドルを割り当てる必要があります。Web アプリケーションと予想されるトラフィックに必要な正確な量は、リクエストのサイズとコンテンツ、アプリケーションとネットワークのレイテンシ、適用されるルールなど、複数の要因によって異なります。一般に、リクエストレイテンシを最小限に抑えるために、エージェントに十分なリソースをバランスよく割り当てるようにしてください。
平均エージェントリソース使用率
エージェントに必要な正確なコンピューティングリソースはデプロイによって異なりますが、他のユーザーの集計されたエージェントリソース使用量の数値を参考にすることで、ご自身のデプロイメントに必要なリソースの目安を把握できます。平均値を確認することは良い出発点となり、上位パーセンタイルの値は高負荷デプロイメントで想定されるリソース要件を示す指標となります。
ヒント : 最初のPOC (概念実証) では、各エージェントが1つのフル CPU コアと少なくとも 500MB の RAM を利用できる環境を推奨します。お客様固有のトラフィックと Web アプリケーションの使用量について負荷テストを実施すれば、お客様固有のニーズに合わせてリソースを適宜増減することができます。
平均 CPU 使用率
デプロイされたエージェントのほとんどは、利用可能な CPU リソースを十分に活用していません。通常、ベースラインのトラフィックレベルよりも多くの CPU リソースを確保することが望ましいです。これにより、トラフィックスパイク時に十分な余裕を持ち、パフォーマンスを維持できます。
以下の表は、デプロイ済みエージェントの CPU 使用率を、エージェントが使用する設定 CPU コア数に応じて正規化した時点のスナップショットを示しています。
| パーセンタイル | CPU 使用率 |
| 平均 | 約3% |
| 95パーセンタイル | 約20% |
| 99パーセンタイル | 約41% |
| 99.9パーセンタイル | 約65% |
平均 RAM 使用率
エージェントのメモリフットプリントは、長期実行中は通常比較的安定しています。ただし、Golang はガベージコレクション言語であるため、トラフィックの急増時には通常のベースラインを超える一時的なメモリ使用量の急増が発生する可能性があります。こうした急増に対応するため、通常観測されるベースラインよりも余裕を持ったメモリを確保し、エージェントがガベージコレクションサイクルを頻繁に実行せずに一時的に高い負荷に耐えられるようにすることを推奨します。顧客の設定、データセット、ルールセットの差異がメモリ使用量に影響を与える可能性があります。
下表は、デプロイされたエージェントの RAM 使用状況の特定時点における状況を示したものです。
| パーセンタイル | RAM 使用率 |
| 平均 | 約76 MB |
| 50パーセンタイル | 約67 MB |
| 95パーセンタイル | 約126 MB |
| 99.9パーセンタイル | 約280MB |
平均使用可能なCPUコア数
システム上の他のプロセスの CPU 不足を防ぐために、エージェントはデフォルトでホスト上の使用可能な CPU コアの半分だけを使用します。max-procs 設定を使ってこの数値を変更できます。
下表は、デプロイされたエージェントに提供される使用可能な CPU コア数のスナップショットを示しています。データについて以下の点に注意してください。
一部のエージェントは、デフォルトの50%より上または下で
max-procsの設定を変更しています。Kubernetesのデプロイを含むすべてのデプロイタイプが示されています。Kubernetes デプロイには低リソースのエージェントが多く、そのため分布の低い端に強く偏ります。
| パーセンタイル | 使用可能なCPUコアの数 |
| 平均 | 6 |
| 50パーセンタイル | 2 |
| 75パーセンタイル | 8 |
| 95パーセンタイル | 18 |
| 99パーセンタイル | 48 |
エージェントのリソースニーズの計算
エージェントが負担するインフラコストを理解するには、以下の手順を実行してください。
Next-Gen WAF をデプロイする前に、特にピーク使用時にWeb アプリケーションが使用する計算リソースを測定してください。Web アプリケーションと OS 一般の両方について、CPU 使用率、メモリ従量課金プラン、およびファイルハンドル数に焦点を当ててください。
トラフィックが検査され、タグ付けされ、必要に応じてブロックされていることを確認してください。
手順1で実行したのと同じテストを実行します。可能であれば、同じホスト、同じリソース、同じ時間、同じ曜日、以前と同じビジネスサイクルでテストを実行してください。
テストの結果を比較してください。
例えば、Next-Gen WAF をインストールする前に、Web アプリケーションの実行に 50 パーセントの CPU 使用率を測定したとします。その後、アプリケーションと並行して Next-Gen WAF をインストール・設定した結果、90パーセントの CPU 使用率を測定し、Web アプリケーションに悪影響を及ぼす遅延は発生しませんでした。トラフィック変動に備えた余剰容量を確保するため、より多くの CPU コアを備えた大規模なホストシステムへのスケールアップを検討する価値があるでしょう。Kubernetes 環境では、レプリカ数、自動スケーリング、またはリソース制限の設定を調整する必要があるかもしれません。
ハイパーバイザー
仮想マシンは、他の仮想マシンとリソースを共有する環境で動作します。ハイパーバイザー上で、こうした仮想マシンのグループが過剰に割り当てられる場合があります。エージェントは、最小限のレイテンシで動作するように設計されたリアルタイムのセキュリティソリューションです。仮想マシンがハイパーバイザー上で CPU サイクルを待機する必要がある場合、キューイングが発生し、パフォーマンスが低下します。極端な例を挙げると、この種のリソース不足は、完全な障害やアプリケーションのクラッシュにつながる可能性があります。このリソーススケジューリングの競合を回避するため、Next-Gen WAF は過剰サブスクライブされていない、またはリソース予約が設定された仮想マシン上で実行することを推奨します。
Kubernetes
Kubernetes ではリソースをリクエストしたり制限したりするのが一般的です。十分なリソースを持つノードに Next-Gen WAF ポッドを配置するには、リソースリクエストを設定することをお勧めします。しかし、一般的にリソースの制限を設定することはお勧めしません。ポッドがその制限に達すると、強制終了され、保護レベルに影響を与え、潜在的に中断を引き起こす可能性があるからです。エージェントが完全に使用できる CPU コアの数を制限するには、max-procs 設定を使用してください。