【要約】FreeRADIUSを触っていたら負荷試験ツールまで作っていた話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
著者はFreeRADIUSの性能を正確に測定しようとしたが、既存のツールでは高負荷時の検証に耐えられない問題に直面した。
- ・Bash版では
radclientを毎回起動するため、プロセス起動コストがノイズとなる。 - ・実装上のsleep処理により、指定RPSと実際のRPSに乖離が生じる。
- ・クライアントの統計とサーバの統計が一致しない現象が発生する。
// Approach
既存ツールの限界を克服するため、低レイヤでの通信制御と統計の突き合わせを行うアプローチを採用した。
- ・Pythonを用いてUDPソケットを直接操作し、RADIUSパケットを自前で生成・解析する。
- ・
Access-Acceptを直接解析し、レイテンシや成功率を詳細に計測する。 - ・FreeRADIUSのログを監視し、サーバ側の処理件数を秒単位で集計するツールを併用する。
// Result
100RPS程度までは、クライアントとサーバの統計が一致し、低レイテンシでの動作を確認できた。
- ・500RPSの負荷では、クライアントとサーバの統計に差異が生じる課題が残った。
- ・負荷試験ツール自体の精度や、プロトコル上の考慮漏れの可能性が浮き彫りになった。
- ・性能限界の特定には至らなかったが、検証における測定誤差の重要性を学んだ。
Senior Engineer Insight
> 負荷試験において、計測器自体の精度が最大の変数になり得ることを示している。
- ・高負荷環境では、ツールのプロセス起動コストやOSのスケジューリングが結果を歪める。
- ・500RPSでの統計乖離は、ツールの実装限界か、ネットワークスタックのボトルネックか、あるいはFreeRADIUSの内部キューイングの問題か。
- ・実戦では、測定対象の性能を疑う前に、計測器の信頼性を担保するプロセスが不可欠である。