딜 상품과 재고 통합형 저장 구조(A구조) vs 딜 상품과 재고 분리형 저장 구조(B구조)

[daadaadaah]

Conclusion(ing)

• 현재 B구조로 구현했지만, A구조로 변경 가능성 있음

Why

• 현재 단순함을 생각해서 A구조로 갈 것이냐? 추후에 확장성을 고려해서 B구조로 갈것이냐? 고민이었는데,
• 일단, B구조의 상황을 가정하고, 구현했기 때문에, 일단 B로 정했는데, 시간 나면 테스트해보고 싶습니다.
• 딜 상품과 재고 통합형 저장 구조(A구조)을 선택하지 않는 이유가 U 상황(예 : 주문 API)에서 애플리케이션 로직의 복잡도가 올라가고, Lock으로 인해 딜 상품과 재고 분리형 저장 구조(A구조)보다 처리량이 적을 수 있기 때문이었습니다.
• 그런데,딜 상품과 재고 분리형 저장 구조(A구조)보다 처리량이 적을 수 있지만, 1) 우리가 목표하는 TPS는 처리 가능할 수도 있다는 점과 2) redisson을 사용하면 재시도 로직 필요 없으므로, Redis의 쓰기 부하가 높지 않을 수 있다는 점 때문입니다.

B 구조 선택한 이유

이유 1. 추후에 확장성을 고려해서 재고 도메인이 분리되어야 하는 상황이 발생했을 때, A 구조가 B 구조보다 작업량이 줄어든다.
이유 2. 쓰기 부하보다 읽기 부하를 대응하는게 좀더 간단하다고 생각했기 때문에

• 현재 CRUD 상황에서 U 상황(예 : 주문 API) 에서 B구조가 불리하고,CRD 상황(예 : 상품 등록, 상품 조회, 상품 삭제 API)에서는 A구조가 불리하다.
• 이때, CD 상황(예 : 상품 등록 API, 상품 삭제 API)은 기획상 자주 발생하지 않는 API이고, 서버가 한가할 때 처리해도 되는 API이므로, 절대적인 부하가 낮다고 생각해서 제외하고 생각했습니다.
• 그래서, U 상황(예 : 주문 API)에서 상대적으로 Redis에 쓰기 부하가 높은 딜 상품과 재고 통합형 저장 구조을 선택할 것인가? 아니면, R 상황(예 : 상품 목록/상세 조회 API)에서 상대적으로 Redis에 읽기 부하 높은 B구조를 선택할 것인가? 고민이었는데, R 상황(예 : 상품 목록/상세 조회 API)이 U 상황(예 : 주문 API)보다 8:2 또는 9:1 로 더 많은 부하를 발생시킬 수 있지만, 쓰기 부하보다 읽기 부하를 대응하는게 좀더 간단하다고 생각했습니다. 왜냐하면, 만약, 부하로 인해 TPS 낮게 나오면, 읽기는 Slave를 늘려주는 방법으로 해결하고 있지만, 쓰기는 Master를 늘리는 방법으로 해결해야 되고, 그때 개발 작업 복잡도가 올라갈 것이라고 생각했습니다.

Reference

• 구글 Docs에 API 특징, 딜 상품과 재고 통합형 저장 구조와 딜 상품과 재고 분리형 저장 구조의 장단점, CRUD 상황별 로직을 정리했습니다.