Redisson을 이용한 동시성 제어와 JMeter를 통한 테스트 - Workaway

chaean·2025년 5월 31일

Workaway

목록 보기
6/11

1. 개요

결제 시스템은 특히 정합성이 중요한 영역입니다.

동시에 여러 사용자가 같은 객실에 대한 예약 및 예약 건에 대해 결제를 시도할 경우, 데이터 충돌이 발생할 수 있습니다.

이를 해결하기 위해 동시성 제어를 진행했습니다.

동시성 문제 해결 과정을 정리하려고 합니다.
테스트 툴로는 JMeter를 사용하였습니다.

테스트 환경

JMeter를 통해 CSV파일을 읽어 40명의 사용자가 동시에 예약 요청을 시도하는 환경을 구성하였으며,
각 사용자는 로그인 후 서로 다른 인증 토큰을 이용해 API에 접근하도록 설정하였습니다.

2. 결제 검증 API 동시성 테스트

해결

동시성 제어를 위해 4가지 방법을 생각해보았습니다

1. synchronized Lock - X

  • 단일 인스턴스에서만 유효하기 때문에 추후에 서버가 늘어날 경우를 대비

2. MySQL DB 자체에 Lock - X

  • DB 부하 및 Lock 유실/해제 누락 시 문제가 발생할 수 가능성 존재

3. Redis를 통한 직접 구현 - X

  • 재시도/타임아웃 로직 직접 구현 필요
  • set ex, set nx를 이용해 구현 시 스핀락 사용. -> 부하 발생

4. Redisson 라이브러리 사용 - O

  • 분산 락 지원
  • 재시도/타임아웃 로직 기능 내장
  • Pub/Sub 기반 구현

위와 같은 이유로 Redisson을 이용해 구현하는 것이 좋은 방법이라 판단하였고,
추후 다른 기능에서도 사용할 수 있도록 하며, 서비스 로직과 분리하기 위해 커스텀 어노테이션 기반으로 구현하였습니다.

PortOne V2 기반 결제 시스템 설계 및 검증 로직 개선기 - Workaway

테스트 결과

Before

분산락을 적용하지 않은 상태에서는 100명이 동시에 요청할 때 중복 결제 발생 가능성이 존재했습니다.
부하가 많은 환경에서는 데이터 무결성이 깨질 수 있는 구조였습니다.

After

분산락을 적용한 후, 40명이 동시에 예약 및 결제 검증을 요청했을 때, 단 1건의 요청만 성공하고 나머지 99건은 락 획득 실패로 안전하게 차단되었습니다.

마무리

이번 테스트를 통해 성능 최적화와 동시성 문제 해결이 서비스 품질에 미치는 영향을 체감할 수 있었습니다.
단순히 "빠른 응답"을 넘어서, 안정성과 신뢰성까지 잡을 수 있는 구조를 설계하는 것이 중요하다는 점을 다시금 느끼게 되었고, 앞으로도 계속해서 더 나은 아키텍처와 성능 개선을 고민하려 합니다.

profile
백엔드 개발자

0개의 댓글