소개

npm socket-io-sticky-session (이후 sio-sticky )가 sticky를 활성화한 AWS ALB와 같은 LoadBalancer 뒤에 있고,
LoadBalancer로부터 Keep-Alive 접속되는 경우, X-Forwarded-For 등의 헤더에 의해 올바른 Worker에 할당되지 않는 경우가 있다.

라는 이야기입니다.

설명

증상

sio-sticky 는 X-Forwarded-For 등의 HTTP 헤더를 보고 Node.js의 웹 서버/WebSocket 서버 등에 Sticky에 연결을 나눠줍니다. 이것은 SocketIO의 polling이나 websocket에서 사용되는 sid라는 SessionID를 가진 요청을 같은 프로세스의 Node.js로 나눌 때 매우 유용합니다 (sid는 다른 프로세스의 Node.js에서 공유되지 않기 때문에).

그러나 다음과 같은 구성의 경우,
브라우저가 ALB 쿠키를 제대로 보내고 있어도 Sticky가 잘하지 않고 오류 (BadRequest : Session ID unknown)가 될 수 있습니다.

원인

원인은 ALB와 sio-sticky 사이의 keep-alive 연결이라고 생각됩니다.

sio-sticky 는 새로운 TCP 접속이 있었을 때, 부하의 Worker(Node.js)에 그 접속을 건네주기 때문에, keep-alive 된 뒤의 2회째 이후의 HTTP 리퀘스트의 헤더등을 보지 않습니다.
또한 ALB는 어떤 대상으로 요청을 보낼지 제어하고 있지만, 어떤 keep-alive 된 연결에 어떤 HTTP 요청을 흘리는지는 신경 쓰지 않으므로 기본적으로 운임이됩니다.

아래 그림에서 설명하면,

① Browser1과 Browser2는 서로 다른 Worker (Node.js)로 나뉘어져 있다고 가정한다.

② Browser2로부터의 요청이 잠시 후에도 ALB와 Worker 간의 TCP 연결은 유지된다 (keep-alive).

③ Browser1에서 ALB에 리퀘스트가 있는 경우, 이 다른 Worker와 keep-alive된 접속에 리퀘스트가 흐르는 일이 있다. 다른 worker에게 요청이 가면 Session ID unknown 라고 화나게 된다.

라는 이미지입니다.

검증

sio-sticky의 keep-alive시의 동작에 대한 검증은 아래를 참조하십시오.
htps : // 기주 b. 코 m / 모케 모케 치 c 켄 / 그 c 케 - 오 치 쿠키 - 세시 온 / b ぉ b / 훗 아츠레 / 훗 r_ st_ 케이 p ぃ ゔ /ーええ pー아아ごぇ. md

덧붙여서, ALB에서 sio-sticky에의 접속은 통상의 설정에서는 keep-alive 되고, 이번 현상도 확인할 수 있습니다.

사이고에게

sio-sticky와 같은 구조라면 TCP 접속시에 나누기 때문에 괴로운 것이지요.
keep-alive를 무효로 하는 것도 비효율적이고, sio-sticky등을 사용하지 않고 1개의 Node.js를 직접 ALB에 매달리는 것이 Better일까라고 생각합니다.