스파이크 트래픽을 잡아라
우리 회사는 온라인 예약 서비스를 제공하며, 많은 고객들이 이벤트성 판매를 진행했다.
마치 수강 신청하듯이 순식간에 많은 트래픽이 몰리는 일이 잦았고, 서버 부하로 인해 서버가 터진 적도 많았다.
수강 예약부터, 선착숙 공구, 레드벨벳 예약까지 경험했다.
터질 때마다 약점을 보완하며, 안정성을 지속적으로 강화해왔다.
터질 때마다 강해지는 서버…
지금은 상당한 트래픽 스파이크도 안정적으로 운영하고 있는데,
이 경험을 공유하고자 한다.
1. 일단 클라우드 서비스를 쓰자.
클라우드를 사용해야만 인프라를 빠르게 교체해 나갈 수 있다.
만약 서버실을 직접 운영하는 분이 이 글을 보고 있다면, 이는 시간 낭비일 수 있다.
2. 서서히 증가하는 트래픽은 전혀 문제가 되지 않는다.
로드 밸런서와 오토 스케일링을 적용하면 이러한 문제는 걱정할 필요가 없다.
3. 문제는 트래픽 스파이크
만약 1분 단위로 트래픽이 10배, 20배 증가한다면, 스케일링이 완료되기 전에 서버가 터질 것이다.
미리 서버를 증설할 수는 없는데, 이는 비용 문제 때문이다.
결국 최후에는 클라이언트에게 이벤트 시간을 미리 알려달라고 당부하는 것이 가장 효과적이다.
어떤 조치보다 효율적이고 안정적이다.
4. 전조 증상이 존재한다.
트래픽이 몰릴 것 같으면 전조 증상이 나타나는데,
내 경험상 특정 페이지에 접속하는 IP의 개수가 급격히 증가하는 것이 그 신호였다.
이 IP들은 이벤트 시간이 되면 더 많아지고, 더 무거운 요청을 서버로 보낼 가능성이 크다.
따라서 IP 개수가 점점 많아질 때, 미리 스케일링을 트리거할 수 있도록 준비하는 것이 좋다.
5. 서버 안전 종료, 무사한가?
• 모든 트랜잭션과 I/O가 서버 및 데이터 상태의 불변성을 보장하는가?
• 비동기 처리 과정에서 서버 전원이 갑자기 차단되더라도, 데이터 일관성이 유지되는가?
어플리케이션 단계에서 안전 종료를 보장하기 위해 최선을 다해야 한다.
이 과정은 생각보다 복잡한데, 시스템이 클수록 부하 테스트를 해야 하는 시나리오의 경우의 수가 기하급수적으로 늘어나기 때문이다.
디자인 패턴이 잘 설계된 서버일 수도 있지만,
개발사의 사정에 따라 서버 설계 방식은 제각각이다.
6. 중요한 건, 터진 후의 대처 방법이다.
서버가 터지지 않을 것이라 생각하는 것은 망상이다.
터진 이후를 대비해 1차, 2차, 3차 안전망을 미리 구축하는 것이 중요하다.
이건 기술적인 문제를 떠나서도 마찬가지다.
서버가 터지면 무조건 내가 먼저 알림을 받고, 클라이언트에게 안내할 수 있도록 해야 한다.
혹시 개발 담당자가 알림을 받지 못할 경우를 대비해,
팀원들에게도 알림을 공유하여 함께 모니터링할 수 있도록 설정해야 한다.
7. 로그 기록을 단계별로, 체계적으로 하자.
설령 데이터 손실이 발생하더라도, 복구할 수 있도록 체계적인 로그 관리가 필요하다.
이를 통해 시스템의 약한 부분을 찾아내고 보완할 수 있다.
기술적 해결책은 깊게 설명하지 않는다. 어차피 각 회사, 서비스마다 해결책은 다르다.
다만 6번과 7번은 모두에게 적용되는 것이니, 당연한 소리라고 해도 명심 하는게 좋다.
클라이언트를 넘어 파트너까지 Cubrix
외주개발은 Cubrix