created at 2023-03-27
먼저 제 채팅 프로젝트는 아래의 형태를 추구하고 있어요.
- Event-Driven Architecture 를 통한 loose-coupling
- API-Gateway 를 통한 통합 엔트리 포인트 제공
- 올바른 트랜젝션 처리
- 비동기 멀티 스레드를 통한 동시성 성능 향상
- 자동화
- 장애대응
그렇지만 구현에 있어 Event-Driven Architecture 과 장애대응을 함께 사용하는 것이 큰 벽처럼 느껴졌어요. 시간 또한 너무나도 많이 사용되는 것을 느꼈습니다. 생각해야 할 것들이 한두가지가 아니거든요ㅜㅜ.
일단 애초에 저는 이벤트 방식을 왜 사용했을까요?
- loose-coupling 이기 때문에 서비스 별 쉬운 수정
- 다른 서비스를 추가할 때, 해당 토픽을 구독해서 처리하기만 하면 됨
- 잠깐 서비스가 다운되도 재실행되면 요청했던 데이터의 마지막 읽은 위치부터 다시 읽을 수 있음. 메세지 큐는 소비자 별 offset 이 있어서, 소비자가 다운되고 다시 실행되도 마지막 읽은 오프셋부터 다시 읽으면 됨.
즉, 이벤트 방식은 확장성과 장애대응에 있어 확실히 이점을 가질 수 있기 때문에 제가 사용하고자 했었던 거에요.
그런데 이게 생각보다 까다로운 점이 많았습니다.
- 메세지 큐에서 컨슈머가 원할 때 꺼내쓰는 특성(Kafka 특성)상 언제 읽을 지 모릅니다.
- 메세지로 전파되는 트랜젝션의 순서가 보장되어야 합니다. 이를 위해 메세지 스키마 별 KEY 설정(특정 파티션으로만 들어가도록 하기 위함)
- 트랜젝션과 데이터를 이벤트 소싱(or UPDATE tx row) 및 CQRS 방식으로 따로 관리함에 있어, 추가적인 테이블 구성 및 스키마 세팅이 필요합니다. (ex) txId, user_id, status, … 의 attribute 를 가지고 있는 트랜젝션 테이블) 그리고 만약 이걸 RDB 로 구성한다고 한다면, 느린 성능 문제의 해결방안은?
- 보상 트랜젝션을 직접 작성(기존에는 단순 rollback 으로 쉽게 가능했지만, 이벤트 듣고 순서를 고려해서 직접 보상 tx SQL 을 작성해주어야함).
위의 고려점들 외에도 생각할 것들이 꽤 많았습니다. 즉, 시간이 매우매우 오래 걸린다는 이야기이죠.
결론 : 그래서 MSA 개발 기간을 단축시키기 위해 어떤 플랫폼을 사용할 지 찾아본 결과, Spring Cloud 를 사용하기로 마음먹었습니다.
이유 : 이유는 Spring Cloud 를 통한 간단한 saga-choreography 형태의 주문/고객/상품 어플리케이션을 Git 에서 보고 구동해보았는데, 너무나도 짧은 코드로 최적의 결과를 도출하더라구요. 당연히 장애대응또한 되어있구요. 그래서 결론은 Spring Cloud 를 사용해서 현재의 모든 부분을 따로 떼기로 마음먹었습니다.
자 그럼 Spring Cloud 가 무엇이고 어디까지 지원해주는지 알아아겠죠?
이를 위해서 지금부터 잘 구성된 강의와 함께 문서와 책들을 보면서 제 프로젝트를 Spring Cloud 기반 MSA 로 변환하려 합니다. 인프런 강의