카테고리 없음
동시성 제어에 대한 비관락/낙관락 성능 테스트
멋쟁휘개발자
2024. 10. 29. 20:24
동시성 제어에 대한 비관락/낙관락 성능 테스트
`콘서트 예약 서비스`를 만들고, 서비스의 기능 중 동시성 이슈가 발생할 것으로 예상되는 기능에 대해 락 종류와 환경에 따른 `동시성 제어 성능 테스트`를 해보고자 합니다.
| 동시성 제어 방식에 따른 비교
| 항목 | 낙관적 락 | 비관적 락 | Redis | Kafka |
| 장점 | - 충돌이 적을 때 성능이 뛰어남 - 락을 걸지 않아 자원 효율성 높음 |
- 데이터 일관성 보장 강력 - 충돌 시 안전한 트랜잭션 처리 |
- 빠른 응답 시간과 높은 처리 속도 - 실시간 메시지 전송 기능 제공 |
- 높은 내구성 - 대용량 데이터의 안정적 전송 - 확장성 우수 |
| 단점 | - 충돌 발생 시 성능 저하 - 높은 재시도 비용 |
- 락 경합 시 성능 저하 - 트랜잭션 대기 시간 증가 |
- 락 분산 관리가 복잡 - 다중 노드 환경에서 일관성 유지 어려움 |
- 지연 시간이 발생할 수 있음 - 메시지 순서 보장 복잡도 높음 |
| 구현 복잡도 | - 쉬움 - 버전 필드 추가만으로 구현 가능 |
- 쉬움 - 락 어노테이션 선언 |
- Redis 구성 및 분산 환경 설정 필요 - 락 만료 시간 설정 필수 |
- 상대적으로 복잡 - Topic, 파티션 관리 필요 |
| 성능 | - 락 경합이 적으면 성능 좋음 - 트랜잭션 경합 시 재시도 필요 |
- 낮은 성능 - 락 획득과 해제 과정으로 처리 시간 증가 |
- 높은 성능 - 메모리 기반으로 빠른 메시지 처리 |
- 높은 처리량 - 다량의 메시지 동시 처리 가능 |
| 효율성 | - 충돌이 적은 환경에서 효율적 - 낮은 자원 소모 |
- 충돌이 많은 환경에서 안전함 - 자원 사용량 증가 |
- 실시간 성능과 효율성 높음 - 트래픽 많은 서비스에 적합 |
- 대규모 분산 처리에 효율적 - 데이터 파이프라인에 적합 |
| 주요 API 및 동시성 제어 포인트
- 유저 토큰 발급
- 예약 가능 날짜 / 좌석 조회
- 좌석 예약: 빈 좌석을 조회 할 때
- 잔액 충전: 중복 충전 이슈(`따닥` 문제)
- 좌석 결제: 중복 결제 이슈
| 시나리오
| 구분 | 비관락 | 낙관락 |
| 시나리오 | - 요청자는 전부 성공 - 정책에 따른 예외자는 실패해야 함 |
- 요청자는 최초 1명 - 이외 동시 예약자는 실패해야 함 - 성능상으로 비관락 보다 낙관락이 더 빠를 것으로 예상 |
| 실행결과
| 구분 | 좌석예약 | 잔액 충전 | 결제 |
| 비관락 | 1 sec 526 ms | 1 sec 859 ms | 1 sec 046 ms |
| 낙관락 | 1 sec 2 ms | 965 ms | 1 sec 372 ms |
(3회 평균 속도)
| 실행 후 시나리오 비교
| 구분 | 비관락 | 낙관락 |
| 시나리오 | - 요청자는 전부 성공 - 정책에 따른 예외자는 실패해야 함 |
- 이외 동시 예약자는 실패해야 함 - 성능상으로 비관락 보다 낙관락이 더 빠를 것으로 예상 |
| 실제 | - 시나리오와 동일 | - 비교적 적은 스레드에서는 시나리오와 일치하였음 - 스레드 수를 100개 이상 늘리면, 30여개정도가 추가 성공 |
| 알게된 점
낙관락에서의 발생한 예상 밖의 결과는,
아무리 동시에 스레드가 버전을 조회한다고 하더라도, 조회의 시점 차이가 발생할 수밖에 없다.
따라서, 앞쪽에 들어온 스레드가 버전을 증가시키고, 나중에 들어온 스레드는 증가된 버전을 조회하고-매칭하기 때문에 정상으로 처리된다.