티켓팅 시스템요구사항유명인의 내한으로 이벤트를 열게 되었다. 선착순 1,000명에게만 주어지는 기회다.티켓팅 신청을 웹 애플리케이션으로 받으려고 계획 중이며, 요구사항은 아래와 같다. 티켓 수량: 선착순 1,000장제한: 1인 1티켓. 중복 불가.예상 트래픽: 5만 명 동시 접속인프라 제약: 애플리케이션 서버는 필요한 만큼 scale-out 가능목표 응답시간: 1초 이내 동시성 처리? 락?분산 락을 통해 락을 걸었다고 해보자. 혹시 완벽하게 동시성을 제어했다고 안심하고 있는가?티켓 오픈 시간, 수만 명이 몰려올 때 서버에서는 어떤 일이 벌어지게 될까? 대규모 트래픽이 하나의 자원을 획득하기 위해 경쟁하는 상황이 벌어지면, 이는 치명적 병목이 될 수 있다. 아래는 실제로 5만 명이 동시 요청을 보냈을 때의..

이전 글인 "좋아요 기능으로 알아보는 비관적 락"에서 이어지는 글이다. "Lettuce는 SpinLock만 지원한다"는 잘못된 정보를 바로잡고, Spring RedisLockRegistry의 PubSub Lock 설정으로 Redisson 없이도 효율적인 분산 락을 구현하는 방법을 소개한다. Lettuce에 대한 오해, 당신도 믿고 있는가?구글에 "Redis 분산 락"를 검색하면 수십 개의 블로그가 같은 내용을 반복한다:"Lettuce는 SpinLock 방식이라 Redis에 부하를 준다""그래서 Redisson을 써야 한다""Lettuce로는 PubSub 방식을 구현할 수 없다"이런 주장들이 마치 정설처럼 반복되고 있다. 그리고 이러한 논리를 바탕으로 Redisson 구현체를 추천한다. 하지만, 이는 ..

너무 느린 외부 API우리 팀은 외부 시스템과의 연동 프로젝트를 진행하게 되었다. 요구사항은 간단해 보였다. "해당 일자에 주문이 가능한지 외부 API를 통해 확인할 수 있어야 한다." 하지만 실제로 구현해보니, 고객에게 정확한 정보를 전달하기 위해선 한 화면에서 40~60건의 날짜별 배송 계획을 한 번에 조회해야 했다. 병렬 처리를 적용했음에도 불구하고 API 응답 시간은 500ms에서 1초, 심지어 요청이 여러 번 겹치면 그 이상 소요되었다. 연동사에서 제공해준 bulk API를 사용했는데 오히려 더 느려졌다.사용자가 주문 가능 일자를 확인할 때마다 1초 이상을 기다려야 한다니, 이건 명백히 사용성에 심각한 문제였다. 우리는 데이터가 일자 단위로 예측 가능하고 실시간이 덜 중요하다는 점을 주목했다.캐..