概要
Deep Security Agent (DSA) を導入したサーバで、負荷テストを実施しました。
テスト結果から、大幅な遅延や一部のパケットロスが発生しているように見えますが、ファイアウォールや侵入防御イベントには何も記録されていません。
また、DSAのファイアウォール / 侵入防御機能を停止した場合には応答の遅延やパケットのドロップは発生しません。
この原因と対処方法について教えてください。
詳細
本事象の発生は、Apache JMeter等を利用した負荷テストの実施時にのみ確認されておりますが、ロードバランサによって負荷分散されたアクセス頻度が極めて高い環境では同様の事象が発生する可能性が想定されます。
パケットが破棄される原因
DSAでは、各TCPコネクションの状態を一時的に保存するためのセッションテーブルを保持しています。
各TCPセッションは、セッションテーブル上に記録された送信元IPアドレス：ポートおよび宛先IPアドレス：ポートの組み合わせで識別されますが、負荷テストツール等によって短時間内で大量のTCPセッションを発生させ、単一の送信元から同一ポートがリサイクルされた場合、既にクローズされているセッションがテーブルから破棄される前に同一ポートを利用した新規セッションの確立を試みて、DSAがそれをクローズされているセッションに対して不正なSynパケットが送信されたと誤認識し、このパケットを破棄します。
現行のDSAにおいて、このようなパケット破棄はファイアウォール/侵入防御イベントとしては記録されない仕様となっております。
パケットが遅延する原因
DSAでは、ネットワークエンジンの設定に従って定期的にセッションテーブルのリサイクルを行います。
リサイクル間隔が長い上に、一度にクリーンナップするセッションの数が多い場合、セッションテーブルのリサイクルに時間を要する場合があります。
セッションテーブルのリサイクル処理を行っている間はセッションテーブルがロックされるため、リサイクル処理が完了するまで新たなセッションを処理できず、結果としてパケットの遅延が発生しやすくなります。
解決策
下表に列挙されているネットワークエンジンの詳細設定を調整する事によって、事象の発生確率を大幅に低減させる事が可能です。
ネットワークエンジンの詳細設定は、各ポリシーまたは各コンピュータのプロパティを開き、[設定]-[ネットワークエンジン]タブから変更できます。
| パラメータ名 | 初期設定値 | 高トラフィック時の推奨値 | 解説 |
|---|---|---|---|
| 最大TCP接続数 | 1000 | 10000 | TCPセッションテーブルの最大数。同時接続数に応じてこの値を増加する事が望まれる反面、この値を必要以上に引き上げるとDSAが大量のカーネルメモリを使用したり、セッションテーブルのリサイクル処理に時間を要する可能性があります。 |
| LAST_ACK タイムアウト | 30秒 | 0秒 | TCPセッションの状態が[LAST_ACK]になってから、該当セッションテーブルをクリーンナップする必要があると判断するまでの時間 |
| 接続クリーンナップタイムアウト | 10秒 | 2秒 | セッションテーブルのリサイクル間隔。この値が長いほどクローズ済のセッションテーブルが長時間維持されますが、0にすると環境によっては逆に負荷を高めたり予期せぬ問題を引き起こす可能性があるため、1以下の値は推奨できません。 |
| 最大接続数(クリーンナップ単位) | 1000 | 600 | 一度にリサイクルされる最大のセッションテーブル数。この値が大きい程、セッションテーブルのリサイクル処理に時間を要する可能性を高めますが、同時接続数が多い環境で必要以上にこの値を小さく設定した場合、クローズ済のセッションテーブルが適切にリサイクルされず、セッションテーブルが肥大化する可能性があります。 |
上記は全て参考値に過ぎず、推奨値に設定すれば確実に事象の発生を抑止できる事を保証するものではありません。実際の適正値はサーバのスペックやトラフィック量に応じて調整する必要があります。
また、上記の設定箇所に限らず、ネットワークエンジンの詳細設定の値を変更した場合、本件のような事象が発生する可能性があるため、基本的にネットワークエンジンの詳細設定は初期設定でご利用頂き、問題が発生した場合にのみご調整下さい。
