기존로직은 채팅을 단순히 Polling을 통해서 조회해오고 있었는데, 클라이언트가 늘어남에 따라 부하가 많이 늘어나고 있는 상황이다.
때문에 이 로직을 개선하려한다.
요구사항
- 모바일 환경을 고려하여 네트워크 안정성이 좋지 않을 수 있음을 고려해야 한다.
- 클라이언트 레벨에서 메시지가 너무 과도하게 들어와서 핸들링할 수 없는 상황을 방지해야한다.
솔루션
직접적인 채팅 생성이나 조회는 API-Server만을 통하고, WebSocket-Server는 새로운 채팅이 발생했다는 이벤트만 전달하는 방법으로 로직 개선
서버가 새로운 채팅이 생겼다라는 이벤트만 부여하고, 해당 이벤트에 대한 핸들러는 클라이언트에서 처리하겠다라는 의미로, SSE와도 쓰임이 유사하다.
그럼에도 SSE를 사용하지 않고 WebSocket을 사용한 이유는 SSE는 간단하게 사용할 수 있지만 그만큼 추후에 확정성 측면에서 시도해볼 수 있는 것들이 많이 사라질 것이라고 생각해서 WebSocket을 사용해서 이벤트를 전달했다.
솔루션 세부사항
- 사용자는 RealTime-Server로 부터 WebSocket을 연결한다.
- RealTime-Server는 자신의 서버 정보와, 사용자의 WebSocket-Session 아이디를 저장한다.
- 새로운 채팅이 생기면 API 서버는 kafka에 레코드를 produce한 후, Notification Server에서 consume한다.
- Notification Server에서 해당 채팅에 대한 채팅방 사용자가 접속된 websocket-session을 조회한다.
- 조회된 websocket-session과 realtime-server 정보를 기반으로 각각의 realtime-server에 채팅방에 접속된 websocket-session들에게 이벤트를 보내도록 한다.
- 이벤트를 받은 websocket 클라이언트 들은 각자 채팅을 조회하도록 API 서버에 채팅 조회 요청을 날린다.
적용결과
동시 접속 1,000명 기준 5초에 한 번 10%의 사용자가 채팅하는 상황이라고 했을 때,
기존의 폴링을 하던 구조에선 10분동안 600,000번의 요청을 처리했어야 한다.
하지만 현재 솔루션에서는 124,000건의 요청만 처리하면 된다.
부하를 79.3% 낮춘것이다.
또 모바일 네트워크의 특성을 고려했을 때 네트워크 환경이 좋지 않을 수 있기 때문에 재접속에 대한 로직이 탄탄해야 하는데, 개선된 구조에서는 직접적으로 WebSocket은 API 서버가 하는 역할을 보조만 하는 구조이기 때문에 이벤트를 무시하더라도 전혀 비즈니스 로직에 문제되지 않는다.
WebSocket으로 직접적으로 데이터를 다루지 않기 때문에 한 번에 너무 많은 데이터가 몰려와서 클라이언트가 처리하지 못 하고 죽을 수 있는 문제 또한 발생하지 않는다.
