견고한 결제 시스템 구축 (Lecture)

강의 주소는 여기
시스템 구조 이미지 저작권은 여기
깃허브 소스는 여기

개요

이전회사의 포인트 도메인은 해당 특성에서 요구하는 신뢰성과 일관성을 해결하기 위해 SQS에 모든 요청을 넣었다. 그러나 이는 동시성을 제한하므로 동시성에 대한 문제는 발생하지 않으나 성능문제를 낳았다. 1분당 10개의 리소스를 처리하지도 못하는 처참한 성능 문제였다. 이후로 계속해서 좋은 시스템은 무얼까 고민했다. 그러다가 다음 강의를 보았고 커리큘럼이 좋아서 선택했다.

강의를 시청한 이유

1. 견고한 결제 시스템에 '장부' 도메인에 대한 궁금증
   (실 프로젝트에서도 필요하겠다 생각한 부분인데 어떻게 적용할지 잡히지 않아서 고민했던 기억이 있음)

2. 헥사고날아키텍쳐의 기준 (홀로 공부하고 적용하니 "이게 맞나" 하는 부분이 많았음)

3. Kotlin에 대한 관심 (자바도 모르는데 코틀린이 과하다고 생각할 수 있지만 알아두고 배워두는건 좋다고 생각)

4. kafka 기술 적용 (이론적인 부분만 알고 있다가 실제 사용하며 이슈를 체크하고 싶었음)

시스템 구조도

알게 된 것

1. 헥사고날 아키텍쳐의 적용 기준
   • 처음에 보면 코드가 복잡하다. 그러나 알고 보면 캡슐화와 기능분할이 잘 되어있다는 생각을 하게 된다. 그래서 팀원 간의 협업시에는 이해도가 100인 상태에서 같이 적용해야 적용이 가능한 부분이다. 대충 이해해서 적용해서는 안된다. 그러면 죽도 밥도 안된다.
   • 간단한 프로젝트에는 적용하지 말자. 헥사고날은 많은 클래스를 만들게 된다. MVC 패키지로 적용해도 왠만한 프로젝트는 유지보수 할 수 있다. 그게 더 비용적으로도 효율적이다.
   • 테스트가 간단했다. 레이어 별로 종합 테스트 하기도 편했다. 이는 헥사고날 아키텍쳐의 장점인 의존성 관리를 잘했기 때문이다.
   • 영속화 계층 부분에서 의존관계를 어떻게 해야할지 많이 했갈렸는데 강의를 듣고 보니 명확해지는 부분이 분명히 있었다. (도메인 레이어에서 필요한 기능 별이 아닌 영속화 계층에서 구현가능한 기능별로)
   • 보아하니 핵사고날 아키텍쳐를 사용한 경우 JPA가 편한 부분보다는 불편한 부분이 더 많더라. 차라리 로우쿼리를 사용하는 JDBC를 사용하는 것도 좋은 선택지다.
2. Transactional Outbox Pattern을 구축해보았다.
   • 결제 승인 정보를 DB에 저장할때, 동일한 트랜젝션에서 메시지 큐에 전달할 이벤트들도 함께 데이터베이스에 저장하는 방법을 사용하였다. 이후 저장된 이벤트 메시지들을 가져와 메시지 큐로 전달하는 방식을 사용하면 이벤트 전달과 데이터베이스 반영 모두 성공가능한 시나리오가 된다.
3. 카프카의 원자적 처리에 대한 실습을 해보았다.
   • 카프카는 내부적으로 트랜젝션 기능을 이용할 수 있다는 것을 알았다. 이를 통해 메세지가 전달되고 처리되는 것을 보장 할 수 있다.
4. Optimistic Locking을 사용해보았다.
   • 정산 금액이 동시에 업데이트 되는 경우를 방지하기 위해 사용하였다.
5. Database Trigger 이용해보았다.
   • 장부 도메인에서 차변 대변 방식으로 기록할때 정확히 기록되었는지 확인하는 트리거
   • 모든 결제 비즈니스 로직이 끝난 후 상태를 업데이트하는 트리거를 만들어 해결하였다.
   • 모든 비즈니스로직을 코드로 해결할 필요가 없다. 쉽고 비용 효율적이면 그것을 선택하는 것도 개발자의 능력이다.

6. Webflux를 사용하였다
   • 어렵다. 그러나 코드가 깔끔하고 성능을 기대해볼만 하다.

더 해보고 싶은 것

1. 카프카의 원자적 처리를 Spring Modulith 라이브러리로 해결할 수 있을까?
2. 성능 체크
3. ...