[Project] MSA란?

 Monolithic Architecture란?

전통적인 아키텍처, 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태

모든 프로세스가 강하게 결합되어있고, 단일 서비스에 실행된다.

하나의 DB로 관련 도메인의 테이블을 가지고 데이터를 저장한다.

 

그렇다 보니 단점이 강하게 드러나게 된다

1. 도메인 하나의 장애가 서비스 전체에 영향을 미친다
2. 각 도메인의 유지보수가 어렵다
3. 빌드. 배포시간이 길어서 생산성이 낮다

 

이러한 단점들을 극복하기 위해 MAS아키텍처가 등장한다

 

MSA(Micro Service Architecture)란?

하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍

MSA는 여러 도메인 각각의 독립적으로 구성되어 있는 구조이다.

 

각각의 서비스가 분리되어 있고 결합도가 낮기 때문에  Monolithic Architecture의 단점을 보완할 수 있다

1. 도메인 하나의 장애가 서비스 전체에 전파되지 않는다.
2. 상대적으로 각 도메인의 유지보수가 쉽다.
3. 빌드 및 배포 시간을 줄여서 생산성을 높일 수 있다.

 

현재 프로젝트 작업 중인 E-Commerce 프로젝트를 모놀리식 아키텍처에서 MSA아키텍처로 변경해 보려 한다

 

MSA전환 시 고려할 점

• 외부의 요청을 알맞은 서비스 Application에 어떻게 전달할 것인가?
  • 각각의 서비스(도메인별)로 쪼개진 Application의 외부 요청에 대해 도메인 분기 처리가 필요해지게 되었다. 이러한 처리를 위해 API Gateway를 도입할 예정이다
• 서비스(도메인) 간 통신은 어떤 방식으로 할 것인가?
  • 기존의 모놀리식에서는 필요한 정보를 가지고 있는 도메인을 직접 참조하면 됐지만  서비스별로 분리된 도메인 간의 통신을 위해 추가적인 통신 방법이 필요하다
  • 다양한 방법 중 프로젝트에 적합한 방법을 선택해 작업을 진행할 예정이다 
    • RestTemplate
    • WebClient 
    • OpenFeign -> 해당 방법 사용
    • 메시지 중개인(Kafka, RabbitMQ, ActiveMQ 등)
• 서비스들의 정보를 어떻게 관리할 것인가?
  • 클라이언트(외부)에서 보내주는 요청은  API Gateway를 통해 전달되고, 서비스 간의 통신도 이루어진다
  • 이때  API Gateway는 어떻게 서비스의 정보를 알고 전달하고, 각 서비스들도 어떻게 다른 서비스의 정보를 알 수 있을까?
  • MSA에서는 이러한 과정을 각 서비스들의 정보를 등록/관리하는 서비스 디스커버리 패턴을 통해 처리한다
  • 넷플릭스 유레카를 통해 구현할 예정이다
    • 요청이 왔을 때 어디에 누가 저장되어 있으며, 요청정보에 따라 필요한 서비스 위치를 알려준다.