레코드 랜덤 조회를 통한 낙관적 락 성능 개선기 (with 사이드 프로젝트)

서론

Tiketeer

현재 저는 지인 3분과 함께 간단한 팀 프로젝트를 진행 중인데, 그 곳에서 진행 중인 ‘티케팅 서비스’ 프로젝트에서 한순간 부하가 몰리는 티케팅 환경에서도 구매의 정합성을 보장하기 위해 노력하고 있습니다. 뿐만 아니라 성능적인 개선도 이루어내기 위해 다양한 논의들을 진행하고 있습니다. 해당 글에서는 성능 개선을 위해 데이터베이스 내에서 티켓 레코드를 읽어오는 방식을 개선하고 기존 방식과 성능적으로 비교한 내용을 다루고, 최종적으로는 이를 통해 저희 서비스에 미친 영향에 대해 이야기해보도록 하겠습니다.

 

들어가기 앞서

본격적인 성능 비교에 앞서 현재 프로젝트에서 티케팅이 이루어지는 방식에 대해 간단히 설명하겠습니다.

서비스 내 티케팅 관련 로직에 참여하는 테이블 간 간략화한 ERD는 위와 같습니다.

아래는 티켓 구매와 관련된 대략적인 흐름입니다.

• 판매자가 티케팅을 생성할 때 판매할 티켓의 개수만큼 DB 내 레코드가 생성됩니다.
• 구매자는 구매할 티켓의 수와 함께 구매 요청을 보내게 됩니다.
• 티켓에 대한 동시성을 고려하기 위해 티켓을 DB에서 읽어올 때 락을 통해 구매할 티켓 개수만큼 읽어옵니다.
• 구매 레코드를 생성하고 그와 함께 티켓에 해당 구매를 배정합니다.

이 과정에서 제가 확인하고자 하는 성능 개선 포인트는 락을 걸고 티켓을 가져오는 과정입니다.

 

 

본론

기존 방식

기존에 구현했던 티켓을 가져오는 레포지토리 메서드는 아래와 같습니다.

(서비스 내 해당 로직은 비관적 락과 낙관적 락, 그리고 분산락으로 모두 구현되어 있지만 락의 특성 상 해당 개선은 낙관적 락의 경우에 가장 큰 차이가 존재할 것이라 생각했습니다.)

위 메서드를 호출하면 아래 쿼리가 나가게 됩니다.

SELECT * 
FROM tickets 
WHERE 
    ticketing_id = :ticketingId 
  AND 
    purchase_id IS NULL 
ORDER BY ticket_id
LIMIT :limit;

이 쿼리는 목표 레코드를 조회하는데 결국 티켓 ID 순으로 조회하기 때문에 동시다발적인 구매가 발생했을 때 모든 유저들이 같은 티켓을 바라보게됩니다. 따라서 모든 유저들의 요청이 같은 티켓에 낙관적 락을 거는 것이기 때문에 동시성이 많이 저하될 것으로 예상했습니다.

ORDER BY절은 뺀다면?
그렇다면 ORDER BY를 빼면되는 것 아니냐고 할 수 있지만, MySQL의 특성 상 클러스터링 인덱스를 순회하게 되고 암묵적으로 ORDER BY ticket_id가 존재하는 것으로 볼 수 있습니다. 따라서 ORDER BY 절을 빼더라도 동일하게 동작합니다.

 

개선 방안

매 요청마다 같은 티켓에 락을 거는 문제를 해결하기 위해서는 티켓 테이블 내에서 레코드를 랜덤하게 추출할 필요가 있다고 생각했습니다.

MySQL에서 이를 위해서는 아래처럼 쿼리를 작성하면 됩니다.

SELECT * 
FROM tickets 
WHERE 
    ticketing_id = :ticketingId 
  AND 
    purchase_id IS NULL 
ORDER BY RAND()
LIMIT :limit;

그리고 해당 쿼리를 실행시키기 위해서는 아래처럼 JPQL을 작성하면 됩니다.

 

테스트 방안

도출한 개선 방안과 기존 방안의 성능을 비교하기 위해 테스트 설계가 필요했습니다.

이를 위해 Executor와 CountDownLatch를 활용한 테스트를 아래처럼 작성해주었습니다.

그 후 테스트 시 변인을 상정해야 했는데, 저는 이를 특정 티케팅 이하의 티켓 수로 잡았습니다.

그 이유는 티켓을 가져오는 쿼리의 성능에 가장 큰 영향을 미치는 요소가 바로 그것이기 때문입니다. 이에 따라 실제 티케팅 상황을 상정하여 각각 300(영화관 규모), 3000(올림픽 홀 규모), 30000(야구장 규모)의 티켓 수를 가지고 각각 테스트를 진행하였습니다.

티켓 수 외 요인들에 대해서는 특정 값으로 고정한 뒤 테스트를 진행했습니다.

• 동시 티케팅 유저 수: 20 (프로젝트 대기열 정책에 기반한 가능한 값 내 선택)
• 각 유저 당 티켓 구매 수: 3 (임의의 값)

또한 낙관적 락 방식이기 때문에 동시성 예외가 발생했을 경우 이에 대한 예외처리가 필요합니다. 저는 @Retryable 어노테이션으로 실패 시 구매 로직을 다시 실행시키는 방식을 사용했습니다. 또한 방식 별 비교를 위해 최종 재시도 횟수를 반환해주었습니다.

이 때 @Retryable 관련 설정은 아래와 같습니다.

• backoff(실패 시 재시도까지 딜레이): 50ms
• maxAttempts(최대 재시도 횟수): 100회

 

테스트 결과

모든 유저의 티케팅이 완료되기까지 걸린 시간과 재시도 횟수를 각 케이스 별로 확인하면 아래와 같습니다.

티켓 수	기존 방식		랜덤 추출 방식
	소요 시간	경합 발생 횟수	소요 시간	경합 발생 횟수
300개	761ms	59회	98ms	2회
3000개	666ms	55회	106ms	1회
30000개	979ms	75회	120ms	0회

 

테스트 해석

기존 방식의 테스트 결과를 해석해보자면, 결국 티켓의 수만 증가하고 있는 셋업에서 작업 소요 시간이 모두 비슷합니다.

SELECT * 
FROM tickets 
WHERE 
    ticketing_id = :ticketingId 
  AND 
    purchase_id IS NULL 
ORDER BY ticket_id
LIMIT :limit;

이를 해석하기 위해서는 기존 방식의 쿼리가 동작하는 방식을 이해해야 하는데, PK 기준으로 정렬된 값 중 3개의 레코드를 가져오는 것이 목적이기 때문에 결국엔 클러스터링 인덱스를 풀스캔하면서 조건을 만족하는 레코드를 3개 찾는 순간 곧바로 실행이 종료되는 쿼리입니다.

따라서 레코드가 많아지더라도 티케팅이 하나 있는 상황에서는 모두 비슷한 성능을 보입니다. 이러한 상황은 티케팅이 둘 이상 있는 상황에서는 깨지게 되는데 이 또한 tickets 테이블 내 ticketing_id에 인덱스를 걸어주는 방식으로 최적화가 가능합니다.

즉, 티켓을 조회하는 것 자체는 어느정도 최적화가 이루어져있다고 볼 수 있습니다. 하지만 문제는 바로 본론 서두에서 언급한 모든 트랜잭션이 동일한 티켓 레코드를 바라보는 것입니다. 이로 인해 불필요한 경합이 발생하게 되고, 이를 통한 반복적인 재시도를 통해 결론적으로는 성능이 좋지 않은 모습을 보이고 있습니다.

 

반면, 수정된 쿼리는 큰 차이는 아니나 티켓의 수가 증가함에 따라 일정하게 실행 시간이 늘어나고 있습니다.

SELECT * 
FROM tickets 
WHERE 
    ticketing_id = :ticketingId 
  AND 
    purchase_id IS NULL 
ORDER BY RAND()
LIMIT :limit;

이는 위 쿼리가 PK를 기준으로 정렬된 3개의 레코드를 가져오는 것이 아니라, 조건을 만족하는 모든 레코드에 랜덤 값을 부여하고 이를 기준으로 정렬을 수행하기 때문에 이 과정에서 데이터의 수만큼 연산량이 늘어나기 때문입니다. 따라서 이 부분은 이후 테이블 내 데이터가 많아짐에 따라 추가적인 성능 개선의 포인트로 잡을 수 있어보입니다.

다만 그럼에도 불구하고, 기존 방식과 비교했을 때 재시도 횟수(경합 횟수)가 엄청나게 줄어들어 결론적으로 성능 개선은 굉장히 많이 된 것을 볼 수 있습니다. (약 8배 개선)

 

 

결론

낙관적 락은 경합이 많이 발생할수록 성능이 드라마틱하게 나빠지는 특성을 갖기 때문에, 같은 조건에서 경합을 줄일 수 있다면 낙관적 락 로직의 성능 개선을 이루어낼 수 있다고 생각했습니다.

저는 이를 바탕으로 저희가 초기 구현한 방식의 경우 불필요한 경합이 과도하게 많이 발생할 것으로 예상하여 기존과는 다른 방식으로 티켓 추출을 진행해야 한다고 생각하여 해당 테스트를 진행하였고, 결론적으로 위 테스트 결과들을 통해 레코드를 랜덤하게 추출하는 방식이 경합을 줄이는데 큰 도움을 준다는 것을 확인할 수 있었을 뿐 아니라 이를 통해 경합 시 티켓 구매 성능을 약 8배 개선할 수 있었고, 최종적으로는 저희 서비스가 낙관적, 비관적, 분산 락 중 어떤 락을 선택할지 고려하는 단계에서 낙관적 락을 선택하는데 큰 기여를 하였습니다.

(프로젝트 내 락 선택 관련 문서: https://tiketeer.notion.site/cd390c746077406eb352947875df9457)