jmeter3 [고성능 선착순 쿠폰 발급 시스템] #5. Redis 분산 락의 한계를 넘어 Kafka 도입하기 implementation 'org.springframework.kafka:spring-kafka'1. 왜 락(Lock)을 버리고 Kafka인가?지난 포스팅에서는 Redis 분산 락(Redisson)을 도입하여 동시성 이슈를 해결했습니다. 데이터 정합성은 지켰지만, 성능 테스트 결과는 아쉬웠습니다. TPS(초당 처리량): 약 200대 수준원인: DB 락은 피했지만, Redis 락 역시 "한 명씩 줄을 서서(Lock) 처리하는 동기(Synchronous) 방식"이기 때문입니다.결국 사용자가 많아지면 대기 시간이 길어지고 처리량은 제자리걸음일 수밖에 없습니다. 그래서 오늘은 아키텍처를 완전히 뒤집기로 했습니다. 2. 환경 구축: Docker로 Kafka 띄우기 로컬 환경에 Kafka를 직접 설치하는 것은 .. 2026. 1. 20. [고성능 선착순 쿠폰 발급 시스템] #4. Redis 분산 락과 Facade 패턴 도입기 1. 지난 이야기 지난 포스팅에서 비관적 락(Pessimistic Lock)을 통해 데이터 정합성은 지켰지만, 1,000명의 유저가 몰리자 대기열이 폭발하며 타임아웃 에러(14.8%)가 발생하는 한계를 확인했습니다.DB는 데이터 저장소이지, 줄을 세우는 역할로는 적합하지 않다는 결론을 내렸습니다. 그래서 오늘은 '줄 세우기(Lock)' 역할을 DB보다 훨씬 빠르고 가벼운 인메모리 저장소인 Redis에게 위임하기로 했습니다. 2. Redis 설정 및 연결 테스트 저는 윈도우 환경에서 개발을 하고있기 때문에 아래 링크에서 Redis를 다운받았습니다.Releases · tporadowski/redis Releases · tporadowski/redisNative port of Redis for Windows... 2026. 1. 17. [고성능 선착순 쿠폰 발급 시스템] #3. synchronized의 배신과 비관적 락(Pessimistic Lock) 적용 1. JMeter을 활용한 부하 테스트지난 포스팅에서 기본적인 쿠폰 발급 로직을 구현했고 curl을 이용해 단일 요청(Single Thread) 환경에서 테스트했을 때는 정상 작동을 확인했지만, 접속자가 늘어났을 때는 어떻게 작동하는지 확인할 필요가 있다고 느꼈습니다. 우선 제 서버가 얼마나 연약한지 확인해보기 위해 JMeter을 활용해서 테스트를 진행해보려 합니다.시나리오: 쿠폰은 딱 100장.공격: 100명의 유저가 동시에 발급 요청을 보낸다.기대 결과: 재고는 0이 되고, 발급 내역은 정확히 100개여야 한다.부하 테스트를 위해 Apache Jmeter 공식 사이트에 접속해서 Binaries 항목에 apache-jmeter-5.6.3.zip(윈도우 기준)을 다운로드 했습니다.편한 위치에 압축 해제 .. 2026. 1. 9. 이전 1 다음
