인프런 커뮤니티 질문&답변
작성한 질문수
[데이터 버저닝을 활용한 멱등성 처리] 멱등성 보장을 위한 version 비교 질문
해결된 질문
작성
·
66
1
안녕하세요 준형님!
우선, 강의 정말 잘 들었습니다. 정말 정말 많이 배웠습니다 🙇🏻🙇🏻🙇🏻
다름이 아니라,
데이터 버저닝 파트에서 컨슈머의 멱등성을 보장하기 위해
주문 서비스가 재고 차감 이벤트에 version을 담고,
상품 서비스에서는 JPA가 관리하는 상품 version과 이를 동등성 비교하여
중복 소비를 방지하는 방식에 대해 질문드리고 싶습니다.
이 접근 방식에서 많은 인사이트를 얻었지만,
상품의 version을 주문 서비스가 반드시 알아야 한다는 점은 조금 와닿지 않았습니다.
테스트에서는 version = 0부터 시작하니 문제가 없어 보였으나,
여러 이유로 두 version 값이 어긋나면 오히려 소비해야 할 이벤트까지 멱등 처리되어 버릴 수 있다고 생각했습니다.
그렇다고 이를 해결하기 위해 주문 서비스가 상품 서비스로부터 version 이벤트를 직접 받아 관리하는 것도 과한 방식처럼 느껴지는데요,
이 부분에 대해 준형님의 의견을 들을 수 있다면 좋을 것 같습니다.
시간 편하실 때 부담없이 답변 주시면 감사하겠습니다 🙂
답변 2
1
100and님 안녕하세요!
제가 최근 인프런 질문글을 확인 못해서 답변이 늦었습니다. ㅠ 죄송합니다.
질문 주신 내용은 바로 직전에 다른분께서 질문주신 내용이랑 동일한 내용 같은데 한번 아래 질문-답변 읽어보시고 추가적으로 궁금한 내용 있으면 질문 남겨주세요!!
다시한번 너무 늦게 답변 드려 죄송합니다. (_ _)
아하 그 포인트를 질문주셨던 거군요. ㅎㅎ
말씀하신 대로, 이 방식은 상품 서비스의 내부 상태(version)가 외부(주문 서비스)로 노출되는 강한 결합을 만듭니다. 이는 분명한 단점이고 다음과 같은 생각이 들게 합니다.
"version은 상품 서비스의 내부 구현인데, 이걸 다른 서비스가 알아도 괜찮은가?"
저는 이 문제가 설계의 트레이드오프 문제라고 생각합니다. 이 경우 version은 단순히 '내부 구현'이라기보다는, 해당 데이터를 변경하기 위한 사전 조건(Precondition)이자 서비스 간의 명시적인 계약(Explicit Contract)으로 해석할 수 있습니다. 즉, "이 버전일 때만 이 요청이 유효하다"는 의도를 API 스펙에 포함시키는 것입니다.
특히 재고 관리처럼 데이터 정합성이 매우 중요한 도메인에서는 약간의 결합도를 감수하더라도 데이터 불일치 위험을 원천적으로 차단하는 것이 더 중요할 수 있다고 생각합니다.
다만 이러한 버저닝은 일반적으로 멱등성에 대한 처리보다는 '낙관적 락을 활용한 동시성 제어'에 더 많이 활용됩니다. 멱등성은 제가 해당 링크에 남겨둔 답변처럼, 그리고 100and님이 이야기 해주신 것처럼 'eventId나 orderId 같은 고유 ID로 멱등성을 보장하는 것이 더 자연스러운 방식'이 맞습니다.
'데이터 버저닝을 활용한 멱등성 처리' 영상에서 제가 소개한 방식은 '낙관적 락을 활용한 동시성 제어'에 주로 활용되는 버저닝을 활용해서도 가능하다는것을 이야기 드리고 싶었던거고, 일반적으로 활용되는 'eventId나 orderId 같은 고유 ID로 멱등성을 보장하는 방식'은 섹션 4의 '컨슈머에서 발생할 수 있는 메시지 중복 처리' 후반부에서 이미 다룬 내용이라서 여기서는 데이터 버저닝을 기준으로 내용을 전개하였습니다.
혹시 이 구성이 강의 이해에 영향을 준다면 강의 내용을 일부 수정하겠습니다. 🙂
답변이 됐을까요?!
추가적으로 질문 있으시면 질문 주세요.
감사합니다. (_ _)
0
안녕하세요, 인프런 AI 인턴입니다. 100and님.
데이터 버저닝을 통한 멱등성 보장에서 질문해 주신 내용은 현실적인 문제 상황에서 중요하고 실제로 많이 다뤄지는 주제입니다. 관련하여 비슷한 질문과 답변을 찾아 몇 가지 참고 사항을 안내드리겠습니다.
데이터 버저닝과 멱등성 보장
데이터 버저닝을 활용한 시스템은 중복 처리를 방지하고 데이터의 일관성을 유지하기 위한 중요한 기술입니다. 말씀하신 것처럼, 주문 서비스가 상품 서비스의 버전을 알아야 하는 상황은 복잡성을 증가시킬 수 있습니다. 주로 다음과 같은 방법들이 사용됩니다:
이벤트 소싱(Event Sourcing): 시스템의 모든 상태 변화를 이벤트로 기록하고 여기에 버전을 부여합니다. 각 서비스는 공통된 이벤트 스트림을 사용하여 일관성을 유지할 수 있습니다.
버전 관리 시스템: 각 서비스가 독립적으로 버전을 관리하며, 이를 중앙 이벤트 저장소에서 조율합니다. 이러한 방식은 복잡도를 줄이고 멱등성을 보다 쉽게 관리할 수 있습니다.
분산 트랜잭션: 트랜잭션 관리 시스템을 사용하여 복수의 서비스에 걸친 트랜잭션을 조율하되, 성능 상의 이점은 제한적일 수 있습니다.
상태 기반의 일관성: 상태 변화를 하나의 원자적 작업으로 취급하여, 각 이벤트가 독립적으로 발생하더라도 일관성을 유지합니다.
참고할 만한 유사 질문 및 답변
관심 있으신 내용을 더 깊이 이해하실 수 있도록 관련된 유사한 질문의 링크를 드립니다:
- Redis를 활용한 캐시와 트랜잭션 관리: 버저닝 및 트랜잭션 관리에 대한 구체적인 사례와 논의가 이루어집니다.
- 비동기 분리에 관한 논의: 비동기 처리와 멱등성 등에 대한 내용이 포함되어 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
안녕하세요 답변 감사드립니다!
다만, 제 질문 의도와 약간 다른 부분이 있어 추가로 말씀드리고 싶습니다.
제 질문은 주문 서비스가 상품 서비스의 version 을 알아야 하는 설계 자체에 대한 의문이었습니다. 주문 서비스 입장에서는 상품의 version 이 현재 몇인지 정확히 알기 어렵고, 네트워크 지연이나 이벤트 처리 순서 등 여러 이유로 주문 서비스가 가진 version 정보와 상품 서비스의 실제 version 이 어긋날 수 있습니다. 이런 불일치가 발생하면, 실제로는 처리해야 할 정상적인 이벤트까지도 version 불일치로 인해 멱등 처리되어 버릴 수 있지 않을까 우려됩니다.
즉, version 은 '상품' 서비스의 내부 구현 사항인데, 이를 상품 서비스가 아닌 다른 서비스에서 이벤트에 담아 통신하는 것이 적절한 설계인지, 만약 주문 서비스가 상품 version 을 계속 추적해야 한다면(상기 언급한 바와 같이 네트워크 지연 문제 등으로 공유 중인 version 이 어긋나는 경우를 방지) 이는 상품 서비스의 내부 상태를 외부에 노출시키는 강결합이 아닌지 궁금합니다.
말씀하신 것처럼 eventId나 orderId 같은 고유 ID로 멱등성을 보장하는 것이 더 자연스러운 방식이 아닐까 싶어서 질문드렸던 것입니다. 혹시 제가 놓치고 있던 부분이나 강의에서 사용하신 방식이 실제로 유효한 경우가 있다면 설명 부탁드려도 될까요?
항상 감사합니다 :)