트래픽 폭주 : 캐시(Cache) vs Queue(메시지 큐)

들어가며

트래픽이 폭주하여 서버가 느려졌다. 이 때, 캐시(Cache)와 메시지 큐(Queue) 중 어느 것을 도입해야하는가?

진짜 문제를 해결하기 위해서는 '원인(병목)'을 먼저 찾아 그에 알맞게 선택해야한다.

1. 캐시(Cache)

느려진 원인이 반복적인 데이터 조회(Read) 때문일 때.

데이터베이스(DB)까지 가지 않고 메모리에서 데이터를 즉시 반환(조회 속도 O(1))하여 서버와 DB의 연산 부담을 줄임.

2. 메시지 큐(Queue)

느려진 원인이 무거운 작업이나 쓰기/생성(Write) 요청 때문일 때.

서버가 요청을 받자마자 메시지 큐에 던져두고 사용자에게는 "접수 완료" 응답을 바로 보냄.

실제 무거운 처리는 백엔드에서 비동기(Asynchronous)로 차례차례로 처리한다.

 

3. 병목을 찾는 모니터링 도구

"조회가 문제인지, 쓰기가 문제인지"를 감으로 찍어 맞출 수는 없다.

인프라의 상태와 서비스 내부 상황을 정밀하게 관측(Observability)하기 위해 아래와 같은 도구들을 고려해볼 수 있다.

 

1) 프로메테우스 (Prometheus) : 인프라의 '바이탈 사인' 측정

서버, 데이터베이스, 네트워크 장비의 하드웨어 및 시스템 자원 현황(Metrics)을 수집하는데 

보통 CPU 사용량, 메모리 잔량, 디스크 I/O, 네트워크 대역폭)를 실시간으로 기록한다.

 

2) 그라파나 (Grafana) : 데이터를 한눈에 보는 '대시보드'

프로메테우스나 APM이 수집한 수많은 가공되지 않은 데이터를 시각적 대시보드로 그려준다.

 

뛰어난 시각화 기능과 자유로운 커스텀이 장점이며, 임계치(예: CPU 사용량 80% 이상)에 도달하면

슬랙이나 디스코드로 경보(Alerting)를 보낼 수 있다.

 

3) APM (Application Performance Monitoring) : 소스 코드와 DB의 'MRI 촬영'

애플리케이션 내부로 들어가 어떤 소스 코드 라인, 어떤 데이터베이스 쿼리문(Traces)이 지연을 유발하는지 정밀 추적한다.

 

   ▶ 오픈소스 도구: Pinpoint(핀포인트), Scouter(스카우터), SigNoz(시그노즈) 등이 존재

 

 

프로메테우스로 "DB 서버 부하가 높다"는 것을 알았다면, APM을 열어 구체적으로

"어떤 API 호출과 어떤 SQL 쿼리가 DB를 죽이고 있는지" 범인을 잡아낼 수 있다.