더 진한 동시성 제어 - 1를 보고 오시면 더
풍부한 이해를 얻을 수 있습니다.

0. Previously

앞선 포스트에서는 낙관락, 비관락을 이용하여 3가지 시나리오에서 어떤 결과를 갖는지 결과를 확인했습니다.

• 시나리오 1: 한 유저가 한 좌석에 짧은 시간안에 500+번 요청
• 시나리오 2: 한 유저가 여러 좌석에 짧은 시간안에 500+번 요청
• 시나리오 3: 한 유저가 여러 좌석에 짧은 시간(3분)안에 ~=300,000번 요청

다만, DB의 뛰어난 성능대비 떨어지는 VM 성능 등 다양한 이유로 모든 테스트 결과가 비슷했습니다.

기존 환경 구성으로 이번에는 redis를 이용한 분산락을 이용한 결과입니다.

	동시성 제어	평균 요청 대기시간
낙관락 - 시나리오 1	O	3.32s
낙관락 - 시나리오 2	O	3.1s
비관락 - 시나리오 1	O	3.36s
비관락 - 시나리오 2	O	3.14s
분산락 - 시나리오 1	O	3.13s
분산락 - 시나리오 2	O	3.5s

시나리오 1, 2는 너무 적은 요청에, 모두 비슷한 결과치로 실험으로부터 어떠한 인사이트를 도출하긴 어려웠습니다.

시나리오 3 또한 비슷한 결과를 보여줬습니다.

	동시성 제어	평균 요청 대기시간
낙관락 - 시나리오 3	O	7.59s
낙관락 - 시나리오 3	O	8.15s
비관락 - 시나리오 3	O	7.6s

VM 성능 낮기 때문에 유효한 결과가 나오지 않았습니다.
아래 스펙의 VM * 5 개와 RR방식의 Public LB를 붙여서 테스트 했습니다.

또한 요청을 보내는 k6 에이전트 목표 TPS도 조금 낮추어 실험을 진행했습니다. (기존 30,000 -> 5,000)

Shape: VM.Standard.A1.Flex
OS: Canonical Ubuntu 24.04
Network bandwidth (Gbps): 1
vCPU: 4
Mem: 6GB

• LB Health Ok 모습. 실제로 콘솔 5개를 열고 요청해보면 하나씩 요청이 들어온다.
  

1. 시나리오 3 리-테스트

1.낙관락

• VM
  
  

• DB
  
  

2.비관락

• VM
  
  

• DB
  
  

분산락+낙관락

• VM
  
  

• DB
  
  

	동시성 제어	평균 요청 대기시간
낙관락 - 시나리오 3	O	1.06s
비관락 - 시나리오 3	O	6.54s
분산락 - 시나리오 3	O	1.17s

결론

• 비관락 사용시 많은 대기(blocking)가 생긴다.
• 아직 분산락과 낙관락의 차이로 인한 결과는 없다.

---

더 진한 동시성 제어 - 1