대량 이벤트 트래픽의 모니터링과 차단·복구 대응

관심이 큰 상품의 이벤트가 열리면 짧은 시간에 사용자가 몰렸습니다. 당시에는 요청을 계속 받으며 버틸 수 있을지, 유입을 제한하고 복구해야 할지 판단하는 상황이 반복됐습니다.

아래는 당시 남긴 운영 대시보드 화면입니다. TPS와 응답 시간, CPU·힙 메모리, 사용자 수 등의 표시를 함께 볼 수 있습니다.

응답 시간과 처리량의 변화

화면에서는 요청 처리량이 증가하는 시점에 응답 시간과 CPU 사용률도 함께 올라갑니다. 다만 이 한 장으로 특정 쿼리나 락이 원인이라고 판단할 수는 없습니다. 해당 시점의 로그와 DB 상태, 실행 중인 요청을 이어서 확인해야 합니다.

처리량이 높다는 사실만으로 서비스가 정상인 것도 아닙니다. 요청이 많이 처리되는 동안 일부 요청은 오래 기다리거나 실패할 수 있습니다. 성공·실패와 대기 상태를 함께 봐야 어느 기능의 영향이 큰지 알 수 있었습니다.

DB 경합과 밀리는 요청

주문과 재고에 요청이 집중되면서 DB 경합이 심해진 경험이 있었습니다. 갭 락처럼 DB 내부의 잠금과 관련된 문제도 확인해야 했습니다. 이런 상황에서는 웹 서버를 더 늘리는 것만으로 해결되지 않고 DB로 들어가는 요청이 더 많아질 수도 있습니다.

응답 지연이 길어지면 애플리케이션 안에서 처리 중인 요청과 연결도 쌓입니다. CPU가 높은지 외에 DB 연결을 기다리는지, 외부 호출에서 대기하는지, 특정 주문·재고 처리에 몰리는지를 나눠 봐야 했습니다.

유입 제한과 서비스 복구

당시에는 Akamai 쪽에서 요청을 더 받으며 버틸지, 유입을 막고 복구할지를 판단해야 했습니다. 계속 운영하기 어려운 순간에는 트래픽을 차단하고 웹 서버를 내린 뒤 안정화해 다시 올리는 조치도 했습니다.

재기동이 원인을 해결하는 것은 아니었습니다. 유입이 그대로인 상태에서 서버만 다시 올리면 같은 상황이 반복될 수 있었습니다. 현재 쌓인 작업과 DB 상태를 살펴보고, 어느 시점에 다시 요청을 받을 수 있을지 함께 봐야 했습니다.

더 많은 요청을 받아내고 싶었지만, 당시 구조로 감당하지 못하는 순간이 있었다는 점은 아쉬움으로 남습니다. 그때는 우선 서비스를 회복시키고 이후에 원인과 개선할 부분을 정리해야 했습니다.

인프라와 외부 인증 서비스

애플리케이션 외의 한계도 있었습니다. AWS에서 바로 늘릴 수 있는 한도에 걸려 별도로 연락해 증설을 요청했던 경험이 있었습니다.

본인인증이 필요한 흐름에서는 우리 서비스의 트래픽이 외부 인증 서비스에도 영향을 줬습니다. 해당 서비스 쪽에 요청이 몰리며 장애로 이어진 적도 있어, 이벤트 전에 예상 부하를 공유하고 증설이나 대응 가능 범위를 확인해야 했습니다.

우리 서버의 자원만 늘려서 끝나는 일이 아니었습니다. 사용자가 거치는 인증과 주문·결제 경로에서 어느 곳이 먼저 한계에 닿는지 함께 봐야 했습니다.