대용량 업로드 중 VPN 끊김: 먼저 대기열을 읽어라

터널은 하루 종일 안정적이다가 큰 업로드가 시작될 때마다 끊긴다. 대화형 요청이 먼저 멈추고, 클라이언트가 시간 초과를 보고하며, 전송이 끝나면 연결이 돌아온다. 이 패턴은 서버가 제때 응답할 기회를 한 번도 받지 못했기 때문에 원격 서버가 죽은 것이 아니라 대기열과 처리에 문제가 있음을 가리킨다. 할 일은 통제된 부하에서 이를 재현하고 올바른 카운터를 읽는 것이다.

실행마다 변수 하나만 바꾸고 엔드포인트는 고정해 둔다.

반복 가능한 부하 비교를 만든다

링크가 유휴일 때 왕복 시간, 몇 개의 애플리케이션 요청, 터널 자체의 이벤트 로그를 기준선으로 기록한다. 그다음 알려진 크기의 업로드를 시작하고 실행되는 동안 똑같은 측정을 반복한다. 엔드포인트, 클라이언트, 테스트 대상을 바꾸지 않는 이유는 둘을 동시에 바꾸면 아무것도 알 수 없기 때문이다.

어떤 이벤트가 먼저 나타나는지 살펴본다. 오류보다 먼저 왕복 시간이 올라가면 대기열이고, 지연이 안정적인 채로 단호한 시간 초과가 나오면 다른 원인, 예컨대 키 갱신이나 계정 조치다. 두 패턴은 서로 다른 다음 단계로 이어진다. 무엇이든 바꾸기 전에 관찰을 적어 둔다.

출력을 타임스탬프와 함께 저장해 부하 실행과 유휴 실행을 줄 단위로 비교한다.

속도가 아니라 대기열을 읽는다

소비자 회선은 제공자 장비에서 패킷을 버퍼링하며, 업스트림 대기열이 가득 차면 터널을 살려 두는 작은 제어 패킷까지 모두 지연된다. 높은 수치를 보고하는 속도 테스트는 그 지연에 대해 거의 말해 주지 않으므로, 유휴 상태의 테스트는 통과하지만 포화된 회선은 실패한다.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

부하 상태의 지연 수치를 유휴 상태와 비교한다. 패킷 손실 없이 수십 밀리초에서 수백 밀리초로 뛰면 대기열이고, 지연이 안정적인데 손실이 있으면 다른 결함을 가리킨다.

장치와 제어 경로를 확인한다

암호화와 전달은 프로세서 시간을 쓰며, 작은 라우터나 열에 제한된 노트북은 바쁜 동안 패킷을 떨어뜨릴 수 있다. 커널 전달과 인터럽트 처리는 사람들이 흔히 보는 곳에 나타나지 않으므로 프로세스 하나의 비율이 아니라 전체 부하를 본다.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

클라이언트 시간 초과는 예약된 키 갱신이나 세션 정책 이벤트와 겹칠 수도 있다. 이벤트 순서는 애플리케이션의 오류 메시지만이 아니라 클라이언트 자체 로그에서 읽는다.

한 가지만 바꾸고 반복한다

플랫폼이 지원하는 곳에서는 업로드 속도를 제한하거나 대량 트래픽을 대화형 트래픽보다 낮게 분류해 대기열이 차지 않게 한다. 그다음 같은 작업 부하를 반복하고 이전과 같은 세 수치를 비교한다. 속도 테스트를 개선하면서 시간 초과를 남겨 두는 변경은 아무것도 고치지 않았다.

시간 제한을 전면적으로 올리는 것과 암호화를 약화하는 것은 어느 경계가 무너졌는지 밝히지 않고 증상을 사라지게 하는 두 가지 변경이다. 둘 다 수리가 아니다. 둘 다 실패를 더 나중으로, 원인을 밝히기 어려운 곳으로 옮긴다.

새 요청과 사용자가 실제로 의존하는 재연결 동작을 테스트하며 마무리한다. 불만을 일으킨 부하 아래에서의 안정성이 기록할 가치가 있는 유일한 결과다.