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

이 글에서는 Spring AOP를 활용해 분산 락 처리 코드를 비즈니스 로직에서 완전히 분리하는 방법을 소개한다. 동시성을 제어를 위해 Lock 인터페이스를 사용할 때, try-finally 블록과 락 관리 코드가 비즈니스 로직을 압도하는 문제를 겪게 된다. Spring의 @Transactional이 트랜잭션 관리를 단순화한 것처럼, DistributedLock Aspect를 만들어 이 문제를 해결할 것이다. 또한, Spring Cache의 검증된 패턴을 참고하여 SpEL 평가기를 만들어 @DistributedLock의 사용성을 확장해볼 것이다. Lock 인터페이스Java/Spring에서 Lock 인터페이스를 직접 사용하면 필연적으로 try-finally 블록을 작성해야 한다.에러가 발생했을 때 락을 해..

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

이 글에서는 좋아요 기능을 구현하면서 발생하는 동시성 문제를 DB 락으로 해결하는 과정을 다룬다. 비관적 락의 동작 원리와 함께, 넥스트 키 락(Next-Key Lock)으로 인한 성능 저하 문제까지 살펴본다. 좋아요 기능 요구사항 정리다중 서버 환경에서 서버 간 동시성 제어 필요기능 명세1) 좋아요 추가사용자는 리뷰에 좋아요를 누를 수 있다한 사용자는 하나의 리뷰에 한 번만 좋아요 가능 (중복 방지)동시다발적인 요청도 안전하게 처리해야 한다2) 좋아요 취소물리적 삭제가 아닌 논리적 삭제(Soft Delete) 방식 사용취소 후 다시 좋아요를 누를 수 있다3) 좋아요 조회좋아요를 누르지 않은 상태: 비활성화 표시좋아요를 누른 상태: 활성화 표시좋아요를 취소한 상태: 비활성화 표시 엔티티 설계리뷰에 좋아요..

이 글에서는 synchronized 키워드의 JVM 모니터 락이 실제로 어떻게 동작하는지 살펴보고, ReentrantLock이 제공하는 동시성 처리 기능을 알아본 뒤, 동시성 프로그래밍을 할 때 발생할 수 있는 생산자-소비자 문제를 해결해본다. 그리고 사용자별 키 값을 활용한 락 분리 전략으로 성능을 개선하는 방법을 다룰 예정이다. synchronized만으로 충분할까'synchronized를 쓰면 동시성 문제가 해결된다'라고만 이해하고 있을 수도 있다. 실제로 동시성 문제를 해결하기 위해 단순히 코드 블록에 synchronized만 붙이면 문제는 해결되지만 성능이 급격히 떨어지는 경우를 자주 볼 수 있다. 예를 들어, 모든 사용자의 포인트 처리가 하나의 공유된 락으로 처리하면, 사용자 A의 포인트 적립..

이 글은 Network I/O로 인한 스레드 블로킹 문제를 진단하고, JDK 21의 가상 스레드(Virtual Thread)를 활용해 근본적인 해결책을 찾아가는 과정을 담고 있다. 단순히 문제를 해결하는 것을 넘어, 가상 스레드 도입 과정에서 마주친 Thread Pinning과 Overwhelming 같은 예상치 못한 도전들과 그 해결책까지 상세히 다룬다. 스레드 풀이 왜 고갈되었을까?월요일 오전 10시, 커피를 마시며 한 주를 시작하려는 순간 슬랙에서 지연시간 알림이 오기 시작한다.급하게 모니터링 대시보드를 확인해본다.잔여 스레드 수: 0왜 스레드 풀이 고갈되었을까?마케팅 팀과 협업해 만든 서버 사이드 이벤트 추적(Meta Conversion API 연동)의 영향이었다.데이터를 수집하기 위해 사용자의..