인프런 커뮤니티 질문&답변

안녕하세요~!

아래 질문에 대해 한번 살펴 보겠습니다.

"상품서비스에서 재고 변경 이벤트를 구독해서, 상품 재고 변경이 처리되기 전에, 다른 요청이 똑같은 상품을 조회하는 경우, 상품의 재고가 없지만 상품의 재고가 마치 있는 것처럼 조회가 될 수 있는 동시성 문제가 발생할 수 있다고 생각합니다."

일단, 제가 만약 동시성이슈를 해결하기 위한 아키텍처를 구상한다면, 저는 redis, rdb를 2개를 사용할것입니다. 이때에 조회의 경우 rdb의 값을 참고해도 되고, 조회또한 redis를 사용해도 될것입니다. 만약 조회또한 redis의 값을 참고한다고 하면 일단 조회문제 있어서도 어떠한 문제가 발생하지 않을것입니다. 그런데, 전체코드의 조회 편의목적상 조회는 rdb를 참고하고 값의 수정은 redis를 쓴다고 하더라도, 동시성문제는 발생하지 않을것으로 보입니다. 사용자가 봤을때는 "어?재고가 있네"라고 주문을 넣겠지만, 실질적인 주문은 redis의 값을 참고할것이기 때문입니다.

제가 redis의 streams 또는 kafka를 사용하여 이벤트기반 비동기처리를 한다고 말한것은, redis의 값을 rdb로 동기화하기 위함이고, 결국은 동시성관련해결은 redis를 통해 처리하기 때문에, 어떤식으로든 동시성문제는 발생하지 않을것으로 보입니다.

글로 쓰려다 보니 다소 말이 어려워지고 길어지는데 이해가 되셨을지 모르겠습니다.

안녕하세요, 인프런 AI 인턴입니다. 종혁님.

Redis의 Streams 기능을 사용하여 주문 서비스가 상품 서비스에 “상품 재고를 변경” 요청을 보낼 때의 비동기 처리에서 발생할 수 있는 동시성 문제에 대한 우려를 잘 이해했습니다. 이런 문제는 특히 화장품처럼 인기가 많은 상품을 실시간으로 관리해야 하는 서비스에서 정말 중요합니다.

동시성 문제 해결 방법

1. 락(lock) 구현:

   • Redis에서 SETNX (Set if Not Exists) 명령어를 사용하여 락을 걸어 동시성 문제를 줄일 수 있습니다. 이 방법은 다른 프로세스가 같은 필드에 동시에 접근하지 못하게 합니다.
     
   • 혹은 Redisson과 같은 Redis 기반의 분산 락 라이브러리를 활용하여 보다 복잡한 락을 구현할 수 있습니다.
     

2. Optimistic Locking:

   • 데이터베이스의 버전 관리를 통해 충돌 발생 시 재시도하는 전략입니다. JPA에서도 제공되며, 데이터베이스 레벨에서의 충돌을 방지합니다.
     

3. Outbox 패턴:

   • 새로운 요청이 오기 전까지 이벤트를 미리 저장해두고, 비동기 메시지를 통해 요청 처리와 이벤트 발행을 따로 관리하는 방식입니다.
     

4. 데이터베이스 트랜잭션 관리:

   • 재고 업데이트와 같은 중요한 작업은 단일 트랜잭션 내에서 완료하여 데이터 일관성을 유지합니다.
     

관련 논의 및 자료

자세한 구현과 논의는 아래의 유사 질문 및 답변을 통해 확인해보실 수 있습니다:
- Redis 통신과 동시성 문제 해결 - 비동기 통신에서의 동시성 문제 해결 방법 소개

이러한 기술들은 서로 조합해서 사용할 수 있으며, 각 상황에 맞는 최적의 방법을 선택하는 것이 중요합니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.