아키텍쳐
현재까지 완성된 부분이다. 조회 서비스는 이제 작업을 진행할 텐데, 몽고 DB를 사용하여 CQRS 패턴을 도입할 것이다.
구현 계획
단계별 점진으로 만들어가는게 CQRS 패턴을 도입하는 방법인 것 같다.
1단계)DB를 공통 사용하되, CUD와 R을 분리한다.
2단계)DB도 분리한다.
3단계)이벤트 소싱 패턴을 도입한다.
이벤트 소싱 패턴은 조사해보니 구현 난이도가 어렵고, 카프카와 같은 메시징 서비스를 깊이 있게 공부하고 나서 실험해봐야 할 것 같다.
현재까지 진행중인 상황에서는 2단계가 적합해서 위 그림처럼 CUD는 SQL을, R은 몽고 DB를 사용한다.
그리고 카프카를 활용해서 CUD 서비스 <-> R 서비스 간 메시징을 적용한다. 여기서 전달되는 인자는 DTO로 변환된 엔티티이거나 엔티티 ID이다.
단, 현재 구현 수준에서는 카프카 비동기 메시징이 메시지 순서를 일관되게 보장한다고 가정한다.
추후에 카프카를 더 공부하고 나서 메시지 순서를 보장하는 로직도 넣을 필요가 있다.
참고 링크
https://www.popit.kr/cqrs-eventsourcing/
아쉬운 점
게이트웨이를 경유하면 구글 OAuth 로그인 진행이 안 된다.
이 부분의 경우 Spring cloud gateway나 Spring web flux를 따로 더 공부해야 개선할 수 있을 것 같다.
개선 사항
- development 패키지에서 개발이 완료되면, staging 또는 production 패키지의 DB들은 도커에서 빼야 한다.
- SPOF (단일 장애 지점) 핸들링을 추가한다. DB 단에서 단일 리더 복제라던지, 마이크로 서비스 노드를 여러개 띄운다던 지 등.
- 카프카 공부 후 전반적 코드 개선 (현재 코드에는 deprecated된 코드들이 있다.)
- 쿠버네티스 도입.
참고 링크 (DB를 도커에서 빼내는 이유)
https://this-programmer.tistory.com/119
완성 아키텍쳐
SW 마에스트로 14기 (스타트업 재직중)