VPNサーバーの負荷を読み解く：ユーザー数か、CPUか、上り回線か

負荷0.4のゲートウェイでも、その背後のすべてのユーザーにとっては這うように遅いことがあります。平均負荷が数えるのは、実行可能なタスクと、割り込み不可能なスリープで止まっているタスクです。四コアのホストでは、一つのプロセスが飽和するだけで1.0に近づき、残り三コアは遊んでいます。この数値を余裕と読むのが、エンドポイント選びで最も多い誤りです。トンネルを実際に制約するのは、たいてい次の四つのどれかです。一つのコアが忙しい、上り回線が細い、その手前のキューが詰まっている、あるいは誰も文書化していないセッション単位のポリシーです。

平均負荷が数えるのはタスクであり、スループットではない

カーネルは実行キューと入出力待ちのタスク数を標本化し、双方を一分、五分、十五分で平滑化します。その定義には、バイトもパケットもトンネルも登場しません。ストレージが詰まったホストは、ほぼ通信がないのに高い負荷を報告することがあり、カーネルのデータ経路でギガビットを流すホストは余裕のある負荷を報告することがあります。

したがって、負荷とトンネル性能を関連づけるにはコアごとの視点が必要です。一つのコアが張り付いていても、ダッシュボードの全体パーセントはまだ良く見えます：

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

三番目のコマンドこそ、VPNホストで最も重要なものです。OpenVPN 2.xのユーザー空間でのパケット処理はプロセス単位でほぼ直列化されるため、一つのスレッドが忙しいだけで天井になり、その間ダッシュボードは余剰容量を報告し続けます。遅い時間帯に一つのスレッドがコアの大半を占めているなら、ホストは全体として性能不足なのではなく、たまたま重要な次元で制約されているのです。

タイミングにも注目してください。十五分平均は通話を台無しにしたバーストを隠すので、苦情の後に撮ったスクリーンショットは弱い証拠です。問題が起きている間に採取し、出力と一緒に時刻を残しましょう。

上り回線とその手前のキュー

インターフェースのカウンターは、CPUの数字では答えられない帯域の問いに答え、容量と損失も切り分けられます。これは別々の障害であり、対処も別です：

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

テスト中に割り当て速度に近い回線なら、それが説明であり、余ったCPUをいくら足しても変わりません。qdiscの行は、対話的な通信で重要な詳細を加えます。滞留とドロップを見れば、パケットが送出前にキューで待っているかが分かります。大容量アップロードの下でキューが満杯になると、人々が遠隔サーバーのせいにする症状、つまりベンチマークではまだ良好に見える接続での通話の不調が、まさに発生します。

再送のカウンターは、パケットが出たのにきれいに届かない場合を捉えます。遅い時間帯に再送が増え、インターフェースが容量から遠いなら、問題はホストではなく経路にあり、同じ都市の別エンドポイントへ移っても解決しません。

セッション数が示すのは需要であり、余裕ではない

公開ディレクトリはどれも接続ユーザー数を示しますが、そのユーザーが何をしているかはほとんど分かりません。対話的な作業をする二十セッションと、大きなファイルを引く四セッションでは、同じハードウェアでも負荷はまったく違います。後者のパターンはユーザー数には現れず、まさにそれが夜を台無しにします。つまりセッション数は需要の手がかりとして読むのが最善で、余剰容量の証拠にはなりません。

自分で管理するホストなら、ステータスファイルが欠けた次元を与えてくれます。OpenVPN はクライアント別のバイトカウンターを含む定期的なスナップショットを書き出すので、一つのセッションが上り回線全体を占めているかが分かります：

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

十秒離れた二つのサンプルがあれば、その累積カウンターはクライアントごとの速度になります。ユーザー数が代わりに立っているのはこの測定であり、一つの設定ミスのあるクライアントが毎晩同じ時刻に回線を飽和させていることも、こうして分かります。

セッション単位の制限はポリシーの中に隠れている

サーバーは遊んでいても、帯域を渡すのを拒むことがあります。速度制限、クライアントごとの帯域上限、トラフィック整形は、共通名やプール単位で適用されることが多く、同じゲートウェイ上の二人のユーザーがまったく違う結果を得ることもあります。仕組みは繊細ではありませんが、どちらの場合もトンネルは正常に張られるため、外からは見えません。

整形は物理インターフェースではなくトンネル側で探しましょう。制限がユーザー、証明書、アドレスプールのどれに従うかを確認します。テスト用アカウントが上限なしのプールに入ると、サーバーは正常で苦情を言うユーザーが間違っている、と結論してしまいます。その結論は結論なしより悪いのです。チケットを閉じてしまうからです。

一つの固定した作業で二つのエンドポイントを比べる

クライアント側の実験は今でも試す価値がありますが、変数を固定した場合に限ります。同じ端末、同じアクセス網、同じプロトコル、同じ宛先ファイルを使い、似た距離にある二つ目のエンドポイントに対して繰り返します。実行の間に変わるもの、たとえば時間帯は、結果を汚します。

失敗も成功と同じくらい丁寧に記録します。三つのエンドポイントが動き一つがタイムアウトする系列は、四つの速度の数字より情報量が多く、容量ではなく経路やポリシーの問題を示します。各ケースは最低二回実行してください。共有ネットワークでは一回の遅い標本は何も証明しません。

最後に、集めた数字は、それが支える主張と一緒に保管してください。「このエンドポイントは、もう一方が止まったのと同じ時間帯に転送をこなした」は擁護できますが、「このエンドポイントのほうが速い」は、トップページのスコアでは勝てない議論を招きます。ホスト側の正確な指示が必要なら、OpenVPN 2.6のマニュアル にステータスファイルと整形オプションの記述があります。