WebSocket Scale Out - 이론편

개요

webSocket을 흔히 전이중통신이라 말합니다.

웹소켓의 경우에는 끊어지지 전까지 TCP Connection이 계속이 지속되어야 하는데, 그러면 Port를 붙잡고 있는 건지 궁금해졌습니다.

 

글의 주제가 Scale Out인데 TCP Connection과 Port이야기를 하는 이유는 만약 서버의 포트가 모두 TCP Connection에 의해 연결되면 신규 클라이언트는 연결할 수 없으니 자연스럽게 Scale Out이 필요하게 됩니다.

 

따라서 먼저 이에대한 궁금증을 해결하고 Scale Out 하는 방법에 대해 알아봅니다.

 

Websocket은 어떤방식으로 Connection 연결을 유지할까?

80번 포트 혹은 443포트로 핸드셰이크과정을 거칩니다. (클라이언트의 무작위의 포트, 서버는 80 혹은 443 포트)

그러면 클라이언트 측에서 엄청나게 많은 요청을 보내면 80 또는 443 포트에 연결이 어떻게 유지되는 걸까요?

Port는 대게 16bit로 구성되며 0~65535으로 구성됩니다.

 

그러면 65535대가 넘어가는 Client는 연결할 수 있을까요?

이 질문에 대답하기 위해서는 멀티플렉싱이란 개념을 이해하면 해결됩니다

 

Multiplexing이란?

클라이언트의 임의 포트와 Server의 80 포트 간의 TCP 연결이 설정되면 Server는 포트 멀티플렉싱을 사용하여 여러 클라이언트 연결을 동시에 처리할 수 있습니다.

포트 멀티플렉싱은 클라이언트의 IP 주소와 포트의 조합을 기반으로 각 연결을 추적하여 이를 달성합니다.

 

 

TIME_WAIT의 누적과 포트 고갈

일반적인 케이스에서는 잘 발생하지 않지만 TCP Connection을 끊고 나면 커넥션의 IP주소와 포트번호를 기록해 둡니다.

포트번호를 사용하는 새로운 TCP Connection은 일정시간 동안 사용하지 않기 위해서입니다.

단일 클라이언트에서 사용가능한 포트번호가 60,000개라 가정했을 때 120초 동안 유지된다면 초당 500개로 커넥션이 제한됩니다.

만약 서버가 초당 500개 이상의 트랜잭션을 처리할 만큼 빠르지 않다면 TIME_WAIT 포트고갈은 일어나지 않습니다.

해당 케이스는 서버 측이 아닌 클라이언트 측에서 발생할 수 있습니다.

 

Scale Out과 Load Balancer

scale out은 기존 인스턴스에 더 많은 리소스를 추가하는 대신 인스턴스를 만드는 것이며 이를 수평적 확장이라 합니다.

수평 확장이 필요한 이유는 사용자가 증가함에 따라 서버의 부하가 증가하고 필요할 때마다 서버 수를 늘리거나 줄일 수 있는 기능을 제공하는 것이 필요합니다.

https://betterprogramming.pub/design-considerations-for-scaling-websocket-server-horizontally-with-a-publish-subscribe-pattern-fe6de9988400

 

Load Balancer를 통한 응답은 다음과 같이 이루어집니다.

Client와 LB, Sever의 IP 요청,응답

1. (Client) 84.15.184.60 -> (VIP) 192.168.90.10
2. (VIP) 192.168.90.10 -> (Real server) 192.168.90.6
3. (Real server) 192.168.90.6 -> (VIP) 192.168.90.10
4. (VIP) 192.168.90.10 -> (Client) 84.15.184.60

 

우리의 Load Balancer가 만약 1개로 구성되어 있으며, 서버도 1개라고 가정해 보겠습니다.

그러면 출발지 IP는 동일할 것이며 포트는 임의로 구성, 목적지 IP와 PORT는 80 또는 443으로 고정된다고 생각할 수 있습니다.

그러면 LB의 임의포트 중 사용가능한 30000개 정도만 처리가능 할 것으로 예상됩니다.

(위의 TIME_WAIT가 클라이언트 측인 LB에 발생합니다)

(TIME_WAIT과는 별개와 웹소켓은 Connection을 지속하기 때문에 최대 30000개의 연결만 가능할것 같습니다)

 

해결방법

1. 로컬포트범위 증가시키기

2. Local Port 재사용 (net.ipv4.tcp_tw_reuse를 사용하여 time_wait 소켓을 재사용하도록 합니다)

3. 서버단의 port를 고정해서 사용하지 않고, 여러 포트를 listen 하게 하기

4. 여러개의 LB를 두기

 

이론적으로는 이렇게 고민해 보았지만 실제로 연동하는 GateWay라던가, Load Balancer를 구축해 둔 뒤 실제로 서버에 얼마큼의 동시요청이 가능한지 테스트해고자 합니다.

 

이외의 주의사항

만약 In-Memory Message Broker를 사용하고 있는 경우에는 여러 대의 Server가 존재하면 사용자가 Socket Subscription과정에서 진행했던 서버와 메시지를 실제로 받아서 처리하는 서버가 다를 수 있습니다.

이럴 때는 External Message Broker로 관리되어야 합니다.

 

 

참고자료

https://www.soneticscorp.com/how-it-works-full-duplex-communication/

https://www.sysnet.pe.kr/2/0/964

https://www.popit.kr/%EB%A1%9C%EC%BB%AC-%ED%8F%AC%ED%8A%B8-%EB%B6%80%EC%A1%B1%EA%B3%BC-time-wait/

https://stackoverflow.com/questions/651665/how-many-socket-connections-possible

https://kenial.tistory.com/917

https://linuxer.name/2020/11/linux-port-range/

https://jojoldu.tistory.com/319

https://tech.kakao.com/2016/04/21/closewait-timewait/