HTTP 요청 순차 처리 솔루션 개발 프로젝트 - 3

안녕하세요.

이번 편에서는 프로그램 테스트 결과에 대해서 소개하도록 하겠습니다.

 

테스트 예제로는 1편에서 소개한 '아이템 주문' 서비스를 사용했습니다. '아이템 주문' 서비스의 흐름은 아래와 같았습니다.

아이템 주문

 

 

아이템 주문 서비스를 아래와 같이 2가지 방법으로 구현하였습니다.

• 방법 1. 비관적 락을 활용한 구현
  • 재고와 포인트에 Race Condition이 발생할 수 있으므로 이를 방지하기 위해 비관적 락을 사용함
• 방법 2. 순차 처리 솔루션을 활용한 구현
  • 아이템 주문 요청을 하나의 이벤트 메세지로 간주하고, 이를 Kafka Partition에 발행하여 순차적으로 처리될 수 있도록 구현함

 

500명의 서로 다른 사용자가 동일한 상품을 1초에 3회 구매하며, 이를 10번 반복하는 것을 테스트한 결과는 아래와 같습니다.

	표본 수	평균(ms)	최소값	최대값	표준편차	오류 %	처리량	수신 KB/s	전송 KB/s
방법 1	15000	8244	121	12842	1393.50	0.00%	171.1/sec	35.76	38.73
방법 2	15000	5864	2826	8441	552.65	0.00%	236.6/sec	37.51	54.93

 

 아이템 주문 서비스만 놓고 보았을 때는 방법 2보다는 방법 1이 더 나은 선택으로 보였습니다. 처리량과 평균 응답 속도에 따르면, 방법 2가 더 나은 선택지로 보이나 이는 이벤트 기반 비동기 처리이므로 응답성만이 방법 1에 비해 높은 것일 뿐, 실제 처리가 완료되기 까지는 약 1분 30초의 시간이 더 필요했습니다. 그러므로, 아이템 주문 서비스 자체만 놓고 보았을 때는 방법 1이 더 나은 선택지로 판단되었습니다.

 

 물론, 방법 1도 테스트가 반복될수록 비관적 락이 해제되는 것을 기다리는 요청들이 더 많아지기 때문에 평균 응답 속도가 증가하는 단점도 있었습니다. 방법 2가 방법 1에 비해 단점만 있는 것도 아니였습니다. 이 예제에서는 모든 이벤트가 하나의 파티션으로 발행되도록 했지만, 트랜잭션을 조정하여 여러 파티션으로 이벤트가 분산되어 처리되도록 개선하는 방법도 있고, 또한 비관적 락을 사용하지 않음으로써 잠재적인 교착 상태(Dead Lock) 위험성도 없앨 수 있습니다.

 

그러므로, 방법 1과 2의 장단점을 비교해보면 아래와 같습니다.

 

• 방법 1 : 비관적 락 활용
  • 성능이 방법 2에 비해 좋음
  • 잠재적인 교착 상태의 위험과 동시 요청이 많아질수록 Lock Waiting이 많아짐에 따라 평균 응답 속도가 낮아짐 
• 방법 2 : 순차 처리 솔루션 활용
  • 성능이 방법 1에 비해 낮음
  • 잠재적인 교착상태 위험성을 제거할 수 있음
  • 트랜잭션 조정 및 파티셔닝 정책 변경을 통해 성능 개선의 여지가 존재함