Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
Tags
- buffer
- JSON
- Algorithm
- Serialization
- C 언어 코딩 도장
- 메모리구조
- 알기쉬운 알고리즘
- Stack
- Selection Sorting
- 윤성우 열혈자료구조
- Graph
- stream
- datastructure
- 윤성우의 열혈 자료구조
- coding test
- ㅅ
- list 컬렉션
- R
- 이스케이프 문자
- insertion sort
- 혼자 공부하는 C언어
- C programming
- s
- 이것이 자바다
Archives
- Today
- Total
Engineering Note
[SW Engineering] 선착순 이벤트 시스템의 동시성 및 트래픽 처리 개선 본문
SW Engineering/선착순 이벤트
[SW Engineering] 선착순 이벤트 시스템의 동시성 및 트래픽 처리 개선
Software Engineer Kim 2026. 1. 17. 21:031. 문제 상황
- 선착순 이벤트 주문 기능 구현 필요
- 동시 다발적인 주문 요청으로 인한 재고 유실 문제 발생
- Race Condition으로 인한 Lost Update 문제
2. 1차 해결: 비관적 락 적용
- 문제 원인 분석: 조회 시점의 데이터 경합
- 해결 방법: 비관적 락으로 트랜잭션 종료 전까지 락 유지
- 선택 이유: 어노테이션 기반으로 간단하게 구현 가능
- 결과: 재고 정합성 100% 보장
3. 병목 지점 발견
- 부하 테스트 실행
- 모니터링을 통한 문제 발견: DB 커넥션 사용량 과다
- 원인 분석: 선착순 이벤트 트래픽이 DB로 직접 몰림
- 추가 문제 인식: Scale-out이 어려운 구조
4. 시스템 개선
아키텍처 변경:
- Docker를 통한 애플리케이션 컨테이너화
- WAS 확장 (Scale-out 구조 확보)
- Redis 분산락 도입으로 DB 앞단에서 트래픽 제어
Redis 분산락 선택 이유:
- DB 병목 해소
- 분산 환경에서 동시성 제어
- 시스템 확장성 확보
5. 개선 결과 검증
- DB 커넥션 사용량 90% 감소
- 상품 조회 API 처리량 1.3배 증가
- 재고 데이터 정합성 100% 유지
- 확보된 DB 자원으로 전체 시스템 처리 능력 향상
6. 결론
- 데이터 기반 모니터링을 통한 병목 지점 발견
- 아키텍처 개선을 통한 확장 가능한 시스템 구축
- 동시성 제어와 성능 개선을 동시에 달성
'SW Engineering > 선착순 이벤트' 카테고리의 다른 글
| [SW Engineering]동시성 제어를 위한 Lock 비교 (0) | 2026.02.04 |
|---|---|
| [DevOps] Docker 활용 컨테이너화 (1) | 2026.01.04 |
| 선착순 이벤트 시스템의 동시성 및 트래픽 처리 개선 (0) | 2026.01.03 |
| [선착순이벤트] 선착순 이벤트 Redis vs 비관적락 성능 비교와 고가용성 측면 비교 (0) | 2026.01.03 |
| Redis 도입 여부 결정하기 (0) | 2026.01.01 |
Comments