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