MSA를 고려하지 않았을 때의 기존 Monolithic 아키텍처는 모든 도메인이 하나의 데이터베이스 내에서 설계되었습니다. 이로 인해 도메인 간의 관계가 복잡하고, 변경 사항이 발생할 때마다 전체 시스템에 영향을 미칠 가능성이 있었습니다.
MSA로의 전환을 위해 우리는 이벤트 스토밍 기법을 활용하여 각 도메인 간의 기능과 이벤트 흐름을 명확히 정의하였습니다. 이를 통해 각 서비스의 경계를 구체화하고, 독립적으로 개발 및 배포할 수 있는 구조로 전환했습니다. 최종 ERD는 다음과 같습니다.
데이터베이스 설계와 선택 기준
도메인 간의 기능을 고려하여, 저는 Monolithic 아키텍처에서 참조하던 외래 키(Foreign Key)를 끊고, 각 키 값을 그대로 데이터 값으로 가져가는 방식으로 데이터베이스를 설계했습니다. 이로 인해 데이터베이스 간의 관계가 분리되어 NoSQL 데이터베이스를 사용해도 문제가 없다고 판단했습니다. 그러나 각 서비스 내에서 발생하는 로컬 트랜잭션 관리가 중요하다고 생각하여 결국 MySQL을 선택하게 되었습니다. 예를 들어, 주문하기와 같은 기능에서는 데이터 일관성이 매우 중요하기 때문에 주문, 결제, 배송 관련 정보는 MySQL 데이터베이스를 사용하는 것이 적합하다고 판단했습니다. 그러나 비교적 데이터 일관성이 덜 중요한 도메인에서는 NoSQL 데이터베이스도 고려하고 있습니다.
데이터 중복 저장을 통한 서버 간 통신 최소화
MSA 전환 과정에서 우리는 여러 서비스 간의 통신을 최소화하고 시스템의 효율성을 높이기 위해 각 서비스에서 필요한 외부 엔티티의 주요 데이터를 자체적으로 저장하는 설계를 적용했습니다. 예를 들어, MSA 환경에서는 각 서비스가 독립적으로 배포 및 운영되기 때문에, OrderLine 서비스에서 주문 데이터를 조회할 때마다 Product 서비스와의 통신을 통해 제품 정보를 가져오는 것은 네트워크 비용을 증가시키고, 시스템의 복잡성과 지연을 초래할 수 있습니다. 따라서 OrderLine 엔티티에 필요한 제품 정보를 저장함으로써, 주문 내역 조회 시 Product 서비스와의 통신을 피할 수 있습니다. 특히, 제품의 가격이 수정되는 경우 데이터 일관성 문제를 고려할 필요가 있습니다. 각 주문의 OrderLine에서 제품의 가격을 저장하는 이유는, 주문 시점의 가격을 명확히 기록하고 유지하기 위함입니다. 이를 통해 사용자가 주문을 완료한 시점의 정확한 가격 정보를 저장하며, 이후 제품 가격이 변경되더라도 과거 주문 내역의 정확성을 보장할 수 있습니다.