[MSA] MSA (Microservices Architecture)란?

MSA (Microservice Architecture)

msa 는 한마디로 "하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합ㅇ이 가능하도록 만든 아키텍처" 라고 표현 할 수 있겠다.

 

msa 의 이유를 설명하기 위해 기존의 일반적인 프로젝트 아키텍처(Monolithic Architecture)의 특징을 먼저 알아보겠다.

기존 우리의 개발 방식을 보면 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 Monolithic Architecture 이다.

 

Monolithic Architecture 의 장단점을 살펴보자면

우선, 아키텍처 자체가 간단하여 소규모 프로젝트일수록 적합하며 유지보수에 용이하다.

하지만 일정 규모 이상의 서비스에서는 단점이 명확해진다.

• 전체적인 시스템 파악이 어렵다.
• 시스템 영향도의 파악이 어렵다.
• 빌드 및 테스트시간, 배포시간이 규모에 따라 기하급수적으로 늘어난다.
• 서비스를 부분적으로 scale-out 하기 힘들다. (scale-out은 서버의 대수를 늘려 처리 능력을 향상시키는 것. 수평 스케일이라고도 부름)
• 부분의 장애가 전체 서비스의 장애로 이어질 수 있다.

MSA는 이러한 단점을 극복하기 위해 나왔으며 비즈니스 민첩성(Business agility)과 관련이 큽니다.

서비스가 복잡하고, 프로젝트 규모가 크고 장기적으로 운영될 수록 MSA의 장점은 더욱 드러나게 됩니다.

 

Monolithic Architecture vs Microservices Architecture

Micro service의 특징

• 분리된 서비스 (서비스 자체는 하나의 모놀리틱 아키텍처와 유사한 구조를 가짐)
• 각 서비스들의 독립적 배포 가능
• 각각의 서비스에 대한 의존성 최소화
• 각 서비스는 개별 프로세스로 구동되며, REST 호출과 같이 가벼운 방식으로 통신됨

MSA

MSA 의 장단점

- 장점 

• 배포 관점
  * 서비스별 개별 배포 가능, 배포 시 전체 서비스의 중단이 없음.
• 확장 관점
  * 특정 서비스에 대한 확장성이 용이함. (클라우드 사용에  적합한 아키텍처)
• 장애 관점
  * 장애가 전체 서비스로 확장될 가능성이 적음

- 단점

• 보다 복잡한 아키텍처
• 서비스 간 호출 시 REST API 사용으로 인한 통신비용, Latency(지연시간) 증가

 

 

 

 

 

참조 : velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-1-MSA%EC%9D%98-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90-3sk28yrv0e