Traffic 글 모음
총 7개의 글이 있습니다.
대규모 트래픽 경험기 - 대기열
이전 글에서 Pessimistic Lock으로 동시성 문제를 해결했다. 이번에는 한 단계 앞으로 가서, "애초에 서버에 동시에 들어오는 요청 수를 제어하면 어떨까?" 라는 질문에서 출발한다. 콘서트 티켓 오픈 시간에 2000명이 동시에 좌석 조회를 요청한다고 가정하자.
대규모 트래픽 경험기 - 동시성 제어
현재 코드는 성능적인 문제를 어느정도 해결했지만 동시성 문제를 해결하지 못한다. 예를들어, 10명의 사람이 한 좌석에 대해 동시에 예약을 한다면 아래와 같이 10명 모두 같은 좌석을 예매할 수 있게 된다.
대규모 트래픽 경험기 - SSE
3편에서 API를 seat-map(정적 메타)과 seat-status(동적 상태)로 분리하고, DTO 프로젝션으로 조회 비용을 줄였다. 2000명 동시 접속 기준 TPS 51 → 136, p95 36초 → 13초. 처리량 2.7배, Tail Latency 2.6배 개선이었다.
대규모 트래픽 경험기 - api 분리
Redis 캐시를 적용했지만 결과는 기대 이하였다. TPS 48 → 57, 평균 응답 19.2초 → 18.2초. DB 접근은 2초에 1회까지 줄였는데도 체감 성능은 거의 그대로였다. 분석 결과 병목은 이미 DB가 아니었다.
대규모 트래픽 경험기 - 레디스 캐싱 적용
1편에서 확인한 문제는 명확했다. 2000명이 동시에 좌석을 조회하면 TPS 51, 평균 19.2초, p95 36.2초. 서버가 처리할 수 있는 것보다 더 많은 요청이 몰리면서, 대부분의 시간이 쿼리 실행이 아니라 자기 차례를 기다리는 대기 시간으로 소비되고 있었다.
트래픽 경험기 – 문제 상황 관찰
백엔드 개발을 공부하면서 항상 마음에 걸리던 질문이 있었다. "나는 실제 대규모 트래픽을 겪어본 적이 있는가?" CRUD를 만들 수 있고, 트랜잭션을 이해하고, API를 설계할 수 있다. 하지만 현실의 수강신청, 콘서트 티케팅, 한정 수량 이벤트는 다르다.
대규모 트래픽 경험기 – 문제 상황 관찰
백엔드 개발을 공부하면서 항상 마음에 걸리던 질문이 있었다. "나는 실제 대규모 트래픽을 겪어본 적이 있는가?" CRUD를 만들 수 있고, 트랜잭션을 이해하고, API를 설계할 수 있다. 하지만 현실의 수강신청, 콘서트 티케팅, 한정 수량 이벤트는 다르다.