[MSA 1편] MSA 기본 개념 정리

목차는 MSA 에 있습니다.

MSA(Microservice Architecture)

• 도메인을 중심으로 서비스를 모델링하고 구현하는 아키텍처 입니다.
• 도메인 별로 서비스, DB 등이 물리적, 논리적으로 분리돼있으며, 이렇게 분리된 도메인 서비스들은 HTTP API 또는 비동기 메시징 방식으로 통신합니다.
• 하나로 묶은 애플리케이션을 여러 어플리케이션 (보통 도메인) 으로 나누어서 각 서버에 배포해서 서로 간에 통신을 통해 서비스를 제공하는 방식입니다.
• 예를 들면, 상품도메인은 상품 로직 + 상품 DB 로 묶어서 특정 서버에 배포. 주문 도메인은 주문 로직 + 주문 DB 로 묶어서 특정 서버에 배포합니다.
  • 이렇게 따로 배포해서 서로의 데이터가 필요할 땐 보통 API 를 통해서 접근합니다.
• 장점은 서버 확장성이 쉽고, 소스 코드 수정, 배포 등 쉽습니다. 소스 간 영향도 등, 결합성 등이 낮습니다.
• 단점은 트랜잭션 묶기, 테스트, 도메인을 나누는 기준 등이 있습니다

모놀리틱

• 하나의 프로젝트 안에서 모든 도메인을 구현하는 방식입니다.
• 비즈니스 로직, DB, UI 등을 하나로 묶어 빌드하고 배포하는 아키텍처입니다.
• 즉, 도메인을 통쨰로 묶어서 서비스를 제공하는 방식입니다.
• 이렇게 함으로써 서비스에서 DB 를 바로 접근해서 처리하기에 여러 도메인 DB 에 접근하기 쉬운 장점이 있습니다.
• 단점으로는 하나로 묶어서 빌드 배포를 하기에 소스가 많아지면 무거워지고 장애가 발생했을 때, 서로 간에 영향도가 큽니다.
• 특정 component 또는 framework 에 종속적입니다.

MSA 를 적용해야하는 시점은?

• 모놀리틱으로 비즈니스 서비스를 제공하기 어려운 시점
  • 신규 기능을 추가하기가 어려울 때
  • 소스 코드를 분석할 때 너무나 많은 시간이 걸릴 때

MSA 장점

• 소스가 작아 관리 편하며, 개발하기 편합니다.
• 지속적으로 배포, 테스트를 할 수가 있어 신뢰성있고 확장성있는 시스템 구축을 하기 좋습니다. (서비스 단위입니다.)

MSA 단점

• 여러 서비스 간 걸쳐있는 기능은 테스트 및 배포가 어렵습니다.
• 어떤 서비스, 어떤 도메인 단위로 나눌지 명확한 기준이 없습니다. 만약 잘못 나눌 경우 결합성이 강한 서비스가 나올 수 있으며, 이는 위의 장점으로 나온 지속적 테스트, 배포가 어려울 수 있습니다.
• 분산 시스템은 고려할게 많습니다. (트랜잭션, 지연시간, 장애, 운영 resource 등)

결론

• 어떤 것이 더 낫다고 할 수 없으며, 업무가 모놀리틱이 맞다면 모놀리틱으로 구성해도 되고, 업무가 MSA 에 맞다면 MSA 로 구성하면 됩니다.
• 예를 들면, 여러 개의 도메인에 대해 명확한 기준을 가지고 도메인을 나눌 수 있다고 가정해보겠습니다.
  • 이럴 경우 명확한 기준으로 도메인을 나눠서 각각 서버를 배정하고, 서로 간의 데이터가 필요하다면 API 통신을 하는 등 MSA 를 사용하면 좋습니다.
• 반대로 도메인이 작고 프로그램이 작다면 모놀리틱 방식을 사용해 빠르게 개발해 개발 기간을 단축하는 등 모놀리틱을 사용할 수 있습니다.