한 서비스의 스트리밍 연결이 주기적으로 끊긴다는 문제가 있었다. 연결이 안 되는 것이 아니라 되다가 몇 분 뒤에 끊기는 형태였다.
Table of contents
Open Table of contents
잘 되는 설정과의 비교
같은 프록시에 여러 서브도메인이 물려 있는데 다른 것들은 안 끊겼다. 같은 서버와 같은 프록시와 같은 앞단 배포망을 쓰므로 설정만 다른 상태였다.
두 설정을 나란히 놓으니 네 항목이 갈렸다. 읽기 타임아웃과 버퍼링과 캐시와 연결 헤더였다.
다른 프로토콜용 설정
문제가 있는 쪽은 연결 헤더에 업그레이드 값을 넣고 있었는데 그것은 WebSocket 핸드셰이크용이다. 이 서비스는 일반 HTTP 연결을 열어 두고 서버가 계속 보내는 방식이라 프로토콜이 달랐다.
스트리밍이니까 WebSocket 설정을 쓰면 되겠거니 하고 복사한 것으로 보인다. 프로토콜이 다르면 필요한 설정도 다르므로 복사가 성립하지 않는다.
네 항목이 각각 필요한 이유
읽기 타임아웃은 기본값이 몇 분이라 이벤트가 뜸하면 유휴로 판단해 끊기므로 길게 잡아야 한다. 버퍼링은 프록시가 응답을 모았다가 보내는 것이라 한 줄씩 즉시 나가야 하는 스트리밍에서는 꺼야 한다.
캐시는 스트림을 캐싱하면 안 되므로 끄고 연결 헤더는 유지 연결을 위해 빈 값으로 둔다. 넷이 각각 다른 이유로 필요했다.
앞단과 얽힌 버퍼링
버퍼링이 왜 결정적이었는지가 이 조사의 핵심이었다. 앞단 배포망에도 타임아웃이 있고 스트리밍 서버는 주기적으로 유지 신호를 보내 그것을 리셋한다.
프록시가 버퍼링하면 그 신호가 앞단까지 안 나가고 앞단은 아무것도 못 받은 채 타임아웃에 도달한다. 주기적으로 끊긴 이유가 유지 신호가 버퍼에 묶여 있었기 때문이었다.
계층별 타임아웃
이 문제가 어려웠던 이유는 타임아웃이 세 계층에 있다는 점이었다. 배포망과 프록시와 서버가 각각 값을 갖고 있다.
어느 계층이 끊는지를 알아야 하고 끊기는 주기가 힌트가 되므로 주기를 재는 것이 진단의 시작이다. 이 문제를 푼 방법은 같은 프록시에서 잘 되는 설정과 비교한 것이었는데 누군가 전에 같은 문제를 겪고 고쳐 둔 것으로 보이며 잘 되는 예가 있으면 그것이 문서보다 빠른 답이다.
정리
- 서버 전송 이벤트와 WebSocket은 프록시 설정이 다르다
- 프로토콜이 다르면 설정을 복사하면 안 된다
- 필요한 설정 넷이 각각 다른 이유로 있다
- 버퍼링이 켜져 있으면 유지 신호가 안 나간다
- 그러면 앞단 타임아웃에 끊긴다
- 타임아웃이 여러 계층에 있다
- 끊기는 주기로 어느 계층인지 좁힌다
- 같은 서버에서 잘 되는 설정과 비교하는 것이 문서보다 빠르다