이번 주의 주제
주문 API의 플로우는 과제가 진행됨에 따라 아래 처럼 여러 처리를 담당하게 되었다 :
- 재고 차감
- 포인트 차감
- 쿠폰 사용
- 결제 요청
- 주문 저장
한 트랜잭션에서 이 모든것을 처리하려다 보니, 하나의 기능이 문제가 생겼을때 다른 기능에 전파가 되는 문제가 발생했다. 현업에서도 이러한 '무거운 트랜잭션'을 만나게 될 수 있는데 해결할 수 있는 방법은 무엇일까?
느슨한 결합 (Loosely Couple)
플로우를 보면 여러 도메인 서비스로 구성됨을 알 수 있는데, 각 서비스를 나눌 수 있을까? 고민해볼 수 있는 시간이었다. 또한 나눌 수 있는 방법이 무엇이 있을까? 를 배우는 중요한 시간이었다.
- 7주차 테크니컬 라이팅 과제 : https://gukin-han.tistory.com/27
- 7주차 PR : https://github.com/gukin-han/commercial-service/pull/7
시도와 시행착오
세 분의 멘토링을 모두 참석했는데 각각 다른 의견을 제시하여 구현을 하는데 어려움이 있었다.
주문 요청의 플로우 안에 결제 요청이 들어있는것 자체가 어색하다는 의견이 있었고, 결제 요청이 포함된 상태를 기반으로 과제를 설계한 멘토님의 의견도 있었다. 학습 관점에서 후자를 따르는게 좋다는 생각했지만 도메인의 세부사항을 배우는것도 중요하다고 생각했다.
많은 시간을 과제와 관련 없는 부분에서 할애하고 싶지는 않아서 적당히 타협하여 주문 요청과 결제는 완전히 분리된 상태로 구현을 하였고, 어떻게 트랜잭션을 구분하고 이벤트 처리 혹은 비동기 처리할 수 있을지 고민을 했다.
이번 주차에 집중했던 부분은 좋아요 집계처리 방식에 따른 성능 테스트였다. 결과를 블로그에 정리를 해두었으니 나중에 설계를 할때 참고 자료로 사용하려고 한다. 이 집약교육을 수강하면서 내가 무슨일을 좋아하는지 알 수 있게 해주었다. 코드 레벨에서의 구현이 아닌 아키텍처 레벨에서 구현과 테스트를 통한 의사결정을 더 재밌어 한다. 앞으로 구현은 AI가 맡아서 할 가능성도 높아질 정도로 코드나 설계 능력이 좋아지는 것을 최근 느끼고 있으니, 도메인과 각 비즈니스 상황에 맞는 아키텍처 설계 능력이 중요하지 않을까?
배운 개념/기술
커맨드와 이벤트의 차이점에 대해 고민해봤다. 커맨드는 커맨드 패턴을 생각나게 했다. 커맨드는 분명한 목적과 대상이 정해져있고, 이벤트는 이벤트를 듣는 사람에게 처리 권한이 있는 방식이다. 이 둘을 구현하는 방법은 별개라고 생각해야 한다.
이벤트 및 트랜잭션을 기반으로 분리하는 방식 중 하나로 Spring EventListener를 사용해봤다. 하나의 JVM 내에서 발행되며 메모리 상에서 진행되기 때문에 처리 속도는 빠르고 유실율이 낮다(네트워크를 타지 않기 때문)
이러한 기술들을 이용해서 핵심 로직이 무엇인지, 후속 로직이 무엇인지를 구분할 수 있는 사고훈련을 하는게 목적이었다.
아쉬움과 다음 목표
이번 테크니컬 라이팅을 다른 방식으로 시도했는데, 역시나 RT를 다시 받기는 어려웠다.
스프링 이벤트 리스너보다는 좋아요의 3가지 처리 방식을 비교하는 분석을 했지만, 다른 사람들은 스프링 이벤트 리스너가 무엇인지에 집중을 했다. 물론 사용하는 입장에서 구체적인것이 중요하지만, 장기적으로 봤을때는 무엇이 더 중요한지에 대한 판단으로 아키텍처적인 관점으로 접근했다.
그래도 이 교육이 끝나면 하나씩 돌아보면서 진행해보지 못한 테스트나 학습을 복습하는 시간을 가져야겠다. 7주차에서 하지 못한것은 스프링 이벤트 리스너의 내부 구현 방식을 하나씩 뜯어보는것이다. 또 트랜잭셔널 기반의 이벤트 체이닝이 왜 불가능한지 테스트를 해봐야 한다.
애플리케이션 이벤트를 통한 느슨한 결합을 구현하는 것이 이번 주차의 핵심이었다면, 다음 주차는 카프카와 같은 외부 시스템을 이용한 느슨한 결합을 구현하는 것이 목표이다. 회사에서도 사용중이기 때문에 어떤 상황에서 사용할 수 있을지, 어떻게 설정할지 등을 고민해봐야겠다.
- 메세지 큐의 여러 구현체(Redis, RabbitMQ, Kafka)가 있지만 왜 카프카를 선택해야하는가?
- 카프카의 주요 특징과 컴포넌트에 대한 이해
- 카프카의 핵심은 메시지를 잃지 않고, 단 한 번만 처리되게 보장할 수 있는가?
- 리트라이, 백오프, 데드 레터 큐, 지연 모니터링, 파티션의 순서 보장 등의 실무 기능을 사용해봤는가?
- 멱등성 구현 전략을 활용해봤는가?
- 카프카는 어디까지 활용 가능한가?
다른 사람을 위한 팁
이 집약교육은 말그대로 다음 스텝은 무엇인가를 고민해보는 과정이기 때문에 각 과정에서 너무 많은 시간을 구현하는데 사용하지 말고, 고민과 사고 확장을 위한 시간을 많이 갖도록 하면 좋을것 같다.
멘토링 세션을 반복적으로 들어보고, 여러 멘토님의 의견도 들어보고 자신만의 결론을 내려서 실무에서 적용하는 단계까지 나아가야 한다.
