대량 트래픽 발생 당시 캡처로 다시 보는 운영 포인트
대량 트래픽 시점에는 문서보다 캡처가 더 많은 걸 알려주기도 합니다. 당시 직접 남긴 운영 캡처와 모니터링 경험을 보면, 운영자가 무엇을 보고 있었는지 자체가 중요한 단서가 됩니다.
이 글에서는 캡처를 그대로 나열하기보다, 운영 판단 기준이 보이도록 화면과 흐름을 추상화해 정리했습니다.
위 화면은 대량 이벤트 트래픽이 올라오는 시점에 어떤 지표를 함께 보고 있었는지 보여주는 예시입니다. 응답 시간, TPS, 사용자 수, CPU와 메모리처럼 서로 다른 신호를 한 화면에서 같이 봐야 했다는 점이 중요했습니다.
대량 이벤트 트래픽에서는 어느 한 지표만으로는 상태를 설명할 수 없습니다. 응답 시간이 조금 올라간다고 바로 장애라고 단정할 수 없고, TPS가 높다고 무조건 위험하다고 말할 수도 없습니다. 결국 운영자는 여러 신호를 같이 놓고 “지금 어디가 먼저 흔들리고 있는가”를 읽어야 했습니다.
캡처가 보여주는 것
캡처 파일은 단순한 스크린샷 아카이브가 아닙니다. 어떤 시점에 무엇을 열어두고 있었는지, 어느 화면을 반복해서 봤는지, 어떤 문제가 긴박하게 관찰되고 있었는지를 보여줍니다.
여기에 당시 모니터링 경험을 같이 놓고 보면, 대량 트래픽 상황에서 운영 관찰이 어느 축으로 이뤄졌는지도 더 선명하게 보입니다.
문서만으로는 “무엇을 중요하게 봤는지”가 잘 드러나지 않을 때가 많습니다. 반면 캡처는 운영자가 실제 상황에서 어느 화면을 보고 있었는지를 보여줍니다. 이건 그 자체로 당시의 판단 기준을 복원할 수 있는 단서입니다.
캡처를 다시 보면 중요한 건 “무슨 툴을 썼는가”보다 “무엇을 동시에 보고 있었는가”입니다. 응답 시간, 처리량, 동시 사용자, CPU, 메모리처럼 성격이 다른 지표를 한 번에 보고 있었다는 사실 자체가, 운영 판단이 단일 지표 기반이 아니었다는 걸 보여줍니다.
운영자가 실제로 봤던 것
지금 기준으로 다시 정리하면 당시 운영자가 주로 보고 있었던 것은 이런 축이었을 가능성이 큽니다.
- 응답 지연과 처리량 변화
- 재고/주문 관련 경쟁 징후
- 캐시/메모리/스토리지 상태
- 장애가 실시간 기능과 배치 흐름에 미치는 영향
즉 대량 트래픽 운영은 단일 대시보드 하나를 보는 일이 아니라, 여러 신호를 조합해 판단하는 일이었습니다.
이걸 실제 판단 흐름으로 풀어보면 대략 이런 식이었습니다.
- 응답 시간과 처리량이 평소와 다르게 튀는지 먼저 본다.
- 동시에 주문/재고 쪽 경쟁이 시작됐는지 추정한다.
- 캐시나 메모리 상태가 그 징후를 더 악화시키고 있지는 않은지 본다.
- 이 문제가 실시간 요청만의 문제인지, 배치나 후속 처리까지 번지고 있는지 확인한다.
즉 운영자는 지표를 감상하는 게 아니라, 여러 신호를 연결해 현재 어떤 종류의 문제가 벌어지고 있는지 분류해야 했습니다.
여기서 중요한 건 “장애 여부”보다 “어디부터 흔들리는가”였습니다. CPU가 먼저 오르는지, 응답 시간이 먼저 흔들리는지, 주문/재고 관련 징후가 먼저 보이는지에 따라 대응 우선순위가 달라졌기 때문입니다. 같은 트래픽 급증이라도 원인이 DB 경쟁인지, 애플리케이션 처리량 한계인지, 캐시 불일치인지에 따라 보는 포인트가 달라질 수밖에 없습니다.
이 점은 중요합니다. 대량 트래픽 상황에서는 어느 한 지표가 “정답”을 주지 않습니다. 응답 시간, 처리량, 재고 경쟁, 캐시 상태, 운영 배치 상태를 함께 놓고 봐야 상황을 더 정확히 읽을 수 있습니다. 이 글에서 다시 꺼내는 캡처와 기억도 바로 그런 다중 관찰의 경험을 보여줍니다.
대응은 결국 운영 판단이었다
대량 이벤트 상황에서는 모든 문제를 즉시 구조적으로 해결할 수는 없습니다. 그래서 그 순간 운영자가 해야 하는 일은 “완벽한 해법”보다 “지금 가장 위험한 축이 무엇인지 빨리 식별하고, 어디까지 버틸 수 있는지 판단하는 일”에 가까웠습니다.
이런 이유로 운영 캡처는 단순 기록이 아니라 판단의 흔적이 됩니다. 어떤 지표를 먼저 보고, 어떤 화면을 같이 열어두고 있었는지 보면 당시 팀이 어떤 방식으로 상황을 읽고 있었는지까지 복원할 수 있기 때문입니다.
때로는 그 판단이 꽤 거칠 수밖에 없었습니다. 갭 락 같은 DB 경합이 강하게 걸리고, 뉴스에 나올 만큼 이슈가 큰 상품에 사용자가 한꺼번에 몰리면 시스템이 짧은 시간 안에 급격하게 흔들렸습니다. 특히 Akamai에서 더 버텨볼지, 아예 차단하고 재기동으로 넘어갈지를 두고 계속 판단해야 했습니다. 구조적으로 예쁜 대응보다, 우선 트래픽을 강제로 끊고 웹 서버를 내려서 안정화한 뒤 다시 올리는 식의 조치가 먼저 필요했던 순간도 있었습니다.
이 지점이 지금도 아쉬움으로 남습니다. 더 많은 트래픽을 자연스럽게 받아내고 싶었지만, 당시에는 그만큼의 여유를 시스템이 버텨주지 못하는 순간이 반복됐습니다. 그래서 운영 판단은 늘 “조금만 더 버텨볼 것인가”와 “지금 끊고 회복할 것인가” 사이에서 이뤄졌고, 그 선택 하나가 사용자 경험과 운영 리스크를 동시에 바꾸곤 했습니다.
거기에 인프라와 외부 연동 서비스의 수용력도 같이 봐야 했습니다. AWS 쪽에서 즉시 올릴 수 있는 한도에는 제한이 있어서 필요할 때는 별도 연락을 통해 증설을 요청해야 했고, Draw 특성상 본인인증이 필요한 흐름에서는 우리 쪽 트래픽 때문에 외부 본인인증 서비스 전체가 흔들리거나 장애가 번진 적도 있었습니다. 그래서 사전에 연락해 증설을 요청하는 일도 중요했습니다. 실제 운영 판단은 우리 애플리케이션만 버티는지를 보는 일이 아니라, 지금 이 이벤트를 둘러싼 전체 경로가 함께 버틸 수 있는지를 보는 일이었습니다.
이런 기억이 남는 이유는, 대량 이벤트 운영이 결국 “기술적으로 더 세련된 해법이 무엇인가”만의 문제가 아니었기 때문입니다. 실제 현장에서는 지금 이 시스템을 살릴 것인지, 어디까지 차단할 것인지, 언제 다시 열 수 있는지를 판단해야 했고, 그 판단의 근거가 바로 앞에서 말한 다중 관찰 지표들이었습니다.
시리즈 4를 마치며
The Draw 시리즈를 다시 정리해보면 결국 남는 질문은 하나입니다. “대량 이벤트 트래픽에서 시스템은 무엇을 자동화하고, 운영자는 무엇을 직접 판단해야 하는가?”
이 질문이 Broadleaf/Breeze 구조, 주문/재고/정산, 운영 도구화 시리즈와 모두 다시 연결됩니다.