개요

• MSA 아키텍처에 대해서 알아봄
• MSA는 무조건 좋을까?
• 실제 MSA 적용 방식

MSA란

✅ MSA(Microservices Architecture)는 애플리케이션을 여러 개의 독립적인 서비스로 나누어 개발하는 아키텍처
✅ 각 서비스는 도메인 기반의 마이크로서비스로 설계되어 독립적으로 배포, 운영 및 확장 가능
✅ 일반적으로 REST API, gRPC, 메시지 큐(Kafka 등)를 사용하여 서비스 간 통신
✅ 맡은 파트별 독립적인 서비스를 개발가능

MSA 이전의 아키텍처

모놀리식(Monolithic)

• 하나의 애플리케이션이 모든 기능을 포함
• 모든 기능이 단일 코드베이스로 통합되어 있어 유지보수와 확장이 어려움
• 데이터베이스도 하나로 통합
• 개발, 배포, 관리리가 단순

SOA(Service-Oriented Architecture)

• 각 기능을 서비스 단위로 나누어 운영, ESB(Enterprise Service Bus)를 통해 통합 관리
• MSA의 전신
• 서비스 간 강한 결합도와 중앙 집중화된 통신 방식(ESB)
• 서비스 간 결합도가 강하다는 건 비즈니스 로직이 서비스의 중심에 있다는 것
  • 재사용에 유리하나 분리, 확장과 같은 유연성이 낮음

MSA는 무조건 좋은가

✅ 대규모 서비스의 경우 고가용성을 위해서라도 서비스의 분리가 필요
✅ 개별 서비스 단위 배포로 신규 배포건이 기존에 영향을 주지 않음
✅ 서비스 개발이 특정 언어나 기술에 종속되지 않게 개발 가능
❌ 배포/모니터링/트랜잭션 관리가 구현되지 않았을 경우 오히려 리스크가 있음
❌ 개별 서비스가 DB를 가지기 때문에 트랜잭션 관리와 데이터 일관성의 리스크
❌ 화면이 들어가는 MVP/MVC 구조인 경우

데이터를 쪼갰는데 다시 합쳐야한다?

• 계정(account), 장바구니(inventory), shipping(상품) 기준 서비스 분리
• 데이터 기반 개인화 상품 추천 을 구성
  • 개인(=account)화 상품(=shipping)을 추천
  • 구매했던 내역이나 장바구니 목록(=inventory)의 데이터가 필요

문제점

• 3개의 DB에서 JOIN을 해서 유저별 구매/관심 상품 테이블을 만들어줘야하는데 물리적으로 분리된 DB에서 JOIN연산은 사실상 불가능
• 전체 유저/상품/장바구니 데이터를 뽑아서..는 말할 가치도 없음
• 결국 분리된 데이터를 다시 합쳐야하는 경우가 발생
  • 이를 위해 CQRS(Command Query Responsibility Segregation) 패턴을 활용

외부에서의 MSA

• 그러면 이런 문제점을 해결하고 커머스들은 어떻게 적용했을까?

쿠팡의 경우

DB 레플리카 방식
✅ 데이터 일관성을 보장하기 위해 DB 복제를 구성
✅ 각 마이크로서비스가 개별 DB를 가지되, 일부 데이터는 복제하여 일관성 유지

• 이 구성이라고 한다면 쿠팡은 계정과 장바구니 메뉴에서 보이는 상품 정보를 각 서비스에 복제하여 참조

11번가의 경우

event-driven 방식
✅ 서비스 간 결합도를 낮추기 위해 이벤트 기반 적용
✅ Kafka 등 메시지 큐를 활용하여 비동기 통신으로 데이터 처리

참조

데보션