1. 개요
일전에 대용량 트래픽 처리 관련해서 네이버 블로그에 좋은 개념 정리 글이 있어 읽어보았는데, 다른 방안을 찾다가 동일하게 좋은 내용이 있어서 추가 기록하게 되었다.
이전의 방법은 아키텍칭, 하드웨어적인 제어가 많았지만 본 글의 경우 SW적인 제어이므로 향후 업무확장에 좋은 관점이 될 수 있을 것으로 생각하였다.
2. 유의사항
네이버에서 대기열 시스템을 설계할때는 기회비용을 고려하였다. 내가 만약 대용량 트래픽 제어를 위한 설계를 진행한다고 했다면 대기사용자에 대한 번호 부여 뿐 만 아니라, 대기열 시스템 자체의 관리(대기 번호 부여 후 동작, 시퀀스처럼 누락 번호에 대한 고려 등)를 생각하였을 것이다.
대부분의 부하가 주문서의 최초 화면을 불러올 때 발생하므로, 주문서 화면 진입 이후 구매자의 퇴장까지 관리하는 것은 효율적이지 않습니다.
이처럼 네이버는 트래픽이 몰리는 그 부분만 관리하도록 하였고, 나머지는 관리 대상에 포함하지 않았다. 오히려 비효율적이라 생각하였다.
대용량 트래픽 부터 대기, 조회, 주문처리까지 상세한 과정을 알아야하겠지만, 일단 네이버는 최초 주문 시스템 접속을 할 시점에서 트래픽을 제어한다면 그 이후의 유일값 등은 자연스럽게 해결될 문제라 생각한 것 같다.
각설하고 여기서 중요한 점은 문제상황에 집중한다는 것이고, 그 이외의 상황에 대한 접근은 비효율적이라 생각하였다는 점이다.
3-1. ASIS
기존 대용량 트래픽이 있을 경우 네이버는 하기와 같이 처리하였다.
- 비정상적인 요청이 있을 경우 거부
- 특정 조건 발생 시 주문 못하도록 validate 처리
- 대기열에서 대기하는 사용자들이(client) 주기적인 요청을 보내고(polling), 이 요청에 따라 개별의 대기열 서버가 응답을 진행한다.
별도의 대기열 서버는 사용자 수가 많아진다면 그만큼 부하가 늘어날 것이고, 대기열 서버 운용 자체도 비효율적이다.
3-2. TOBE
사용자와 대기열 서버 사이에 Socket.IO 서버를 둔다.
- 사용자는 대기열 서버로부터 응답을 직접 받지 않고, Socket.IO를 통해 응답을 전달 받는다.
- 통신 자원이 부족하다면 별도의 서버 작업없이, Socket.IO의 클러스터만 확장하여 관리하면 된다.
4. 대기표 관리 방식
대기표 관리 방식, 나아가 대기 사용자에 대한 순번 등 대기 정보 관리 방식은 관리하지 않고 저장만 한다는 점이 핵심이다.
- 기본적으로 한꺼번에 많은 트래픽이 온다면, 해당 트래픽 전체에 대한 그룹화를 하여 전체 대기표를 생성하고 만든다.
- 다만 대기표를 생성 후 정렬까지 한다면 정렬에 대한 비용이 증가하고, 이에 따라 처리속도가 저하되므로 성능과 확장성 면에서 비효율적이다.
- 따라서 대기표는 단일한 값 그 자체로만 저장하고, 대기번호를 부여하는 기능만 작동할 수 있도록 한다.
판매자 대기 방식을 보면, 대기열 순번은 갱신되고 이에 따라 대기열 처리 작업에 순차적으로 지원한다는 부분이 있는데 한 순간의 트래픽이 아닌 트래픽의 유동성에 따라 유연하게 대응할 수 있어야 하는 것도 고려사항인 것 처럼 보였다.
5. 참고자료
HTTP Polling - https://innu3368.tistory.com/212
대용량 트래픽 제어 - https://d2.naver.com/helloworld/6480558
