📌 정의
작고 독립적이며 자율적으로 배포 가능한 서비스로 구성된 애플리케이션 아키텍처
MSA란 MicroService Architecture의 줄인 말로 소프트웨어 아키텍처 디자인 패턴 중 하나입니다. 애플리케이션을 작은 독립적인 서비스 단위로 분할하고, 이러한 서비스 단위들을 조합하여 전체 애플리케이션을 구성하는 방식
각각의 서비스는 특정 비즈니스 기능을 수행하며 서로 다른 서비스와 API를 통해 통신합니다.
예를 들어 쇼핑몰 홈페이지를 MSA로 구현했다고 가정해보도록 합시다. 로그인 및 권한을 담당하는 서비스, 상품 주문을 담당하는 서비스, 상품 판매를 위해 상품을 업로드 하는 서비스 등 비즈니스 로직을 처리하는 각각의 서비스가 존재하고 A 서비스에서 B 서비스를 호출해야 하는 경우, API를 통해 통신합니다.
📌 탄생배경
이미지 출처 - https://www.lgcns.com/blog/cns-tech/36171/
MSA는 기업이나 조직의 비즈니스 요구사항이 급격히 변화하고 서비스의 빠른 개발과 배포, 확장성과 가용성을 보장하는 것이 중요해진 현대의 IT 환경에서 발전해왔습니다.
이전의 Monolithic Architecture에서는 애플리케이션 전체를 한 번에 빌드하고 배포하는 것이 일반적이었지만, 이러한 방식은 대규모 애플리케이션에서 많은 문제점을 유발했습니다.
MSA는 이러한 문제점을 극복하고자, 각각의 서비스 단위를 개별적으로 개발, 배포 및 관리함으로써 애플리케이션의 유연성, 확장성, 가용성을 높이는 것을 목표로 합니다.
이러한 아키텍처의 탄생 배경은 클라우드 컴퓨팅, 분산 시스템, DevOps 등의 기술의 발전과 함께 나타난 것으로 볼 수 있습니다.
그럼 Monolithic Architecture와 MicroService Architecture를 비교해보도록 하겠습니다.
📌 Monolithic VS MSA
이미지 출처 - https://kr.tmaxsoft.com/info/storyTView.do?seq=345
| 구분 | Monolithic | MSA |
|---|---|---|
| 구조 | 애플리케이션의 모든 구성 요소가 하나의 단일 프로세스에 포함 | 애플리케이션을 작고 독립적이며 자율적으로 배포 가능한 서비스로 분리 |
| 확장성 | 전체 애플리케이션을 수평적으로 확장해야 하며 개별 구성 요소의 확장이 어려움 | 각 서비스를 독립적으로 확장할 수 있어 필요한 부분만 유연하게 확장할 수 있음 |
| 유연성 | 모든 구성 요소가 긴밀하게 결합되어 있어 하나의 구성 요소를 변경하려면 전체 애플리케이션을 재배포해야함 | 각 서비스가 독립적이므로 필요한 서비스만 변경하고 재배포할 수 있음 |
| 개발속도 | 전체 애플리케이션의 복잡성으로 인해 개발 및 테스트 속도가 느려질 수 있음 | 각 서비스를 독립적으로 개발 및 테스트할 수 있어 개발 속도와 생산성이 향상됨 |
| 장애격리 | 하나의 구성 요소에서 발생한 장애가 전체 애플리케이션에 영향을 줄 수 있음 | 각 서비스가 독립적이므로 장애가 발생한 서비스의 영향이 제한적임 |
| 기술스택 | 일반적으로 하나의 기술 스택을 사용하며, 새로운 기술 도입이 어려움 | 각 서비스마다 다른 기술 스택을 선택할 수 있어 기술적 유연성 높음 |
비록 MSA가 Monolithic Architecture를 개선하기 위해 탄생했고 기술적인 유연성이 뛰어나고 생산성이 향상되었으나 규모가 작은 프로젝트에도 MSA를 도입하게 되면 오히려 복잡도만 높이는 결과를 낳을 수 있습니다.
아래에서는 MSA의 장점과 단점을 알아보도록 하겠습니다.
📌 MSA 장점 및 단점
| 구분 | 👍 장점 | 👎 단점 |
|---|---|---|
| 확장성 | 각 서비스를 독립적으로 확장할 수 있어, 유연한 확장성 제공 | 분산 시스템의 복잡성으로 인해 전반적인 시스템 관리 및 통합에 어려움이 있을 수 있음 |
| 개발 및 배포 속도 | 독립적인 서비스 개발 및 배포로 인해 빠른 개발 및 배포 속도 제공 | 서비스 간의 통신 오버헤드가 증가할 수 있음 |
| 기술 스택 | 각 서비스마다 다른 기술 스택을 선택할 수 있어, 기술적 유연성이 높음 | 데이터 일관성 유지가 어려울 수 있음 |
| 장애 격리 | 각 서비스가 독립적이므로, 장애가 발생한 서비스의 영향이 제한적임 | MSA를 구현하고 관리하는 데 필요한 DevOps 기술과 도구에 대한 요구가 증가 |
📌 MSA 구현시 고려사항
MSA를 도입하기 전에 현재의 프로젝트 규모, 개발 팀의 기술 역량, 인프라 및 운영 부서와의 협업 등을 고려해야 합니다.
초기 단계의 스타트업이나 작은 프로젝트에서는 모놀리식 아키텍처가 더 적합할 수 있으며, 시스템이 점점 커지면서 복잡도가 높아지는 경우에 MSA를 고려하는 것이 좋습니다.
실제로 Netflix, Amazon, eBay, Uber 등의 유수의 글로벌 기업에서는 MSA를 구현함으로써 빠르게 확장하고 변화하는 시장 요구에 대응할 수 있는 높은 유연성을 얻었습니다.
📌 결론
프로젝트의 규모나 복잡도 등을 고려하여 MSA의 도입 여부를 결정해야 하며, 간단한 프로젝트에서는 모놀리식 아키텍처를 적용하는 것이 더 적절할 것입니다.
상황에 맞게 잘 판단하여 아키텍처 도입 여부를 결정하는 편이 좋겠습니다.
