MSA와 MA(Monolithic Architecture) , MSA 꼭 필요한가?

MSA가 무엇인지는 Spring Cloud를 다루면서 간단하게 설명한 적이 있다.
➡ MSA를 위한 Spring Cloud 개념 및 기능
애플리케이션의 각각의 서비스들을 마이크로 서비스 단위로 쪼개어서 구성한다.

MSA가 MA의 단점을 보완하면서 화두가 되었기 때문에, 등장 배경을 설명하기 위해서 모놀리식 아키텍쳐(Monolithic Architecture, MA)를 알아볼 필요가 있다.

모놀리식 아키텍쳐
UI와 비즈니스 레이어, 데이터 레이어가 하나의 덩어리로 구성되어 있는 것을 말한다. MSA와는 달리, 하나의 데이터베이스를 여러 서비스에서 공유한다.

MSA와 MA의 차이

1. MA는 새로운 기능추가나 업데이트가 어렵다. 이유는 다양한 서비스들이 서로 엮여 있어 한 서비스를 업데이트할 때 다른 서비스에 영향을 줄 수 있음을 고려해야 한다. MSA는 각 서비스 간 결합이 느슨하게 이루어져 있어, 한 서비스를 변경해도 다른 서비스에 미치는 영향이 최소화된다.

2. MA는 하나의 서비스의 장애가 다른 서비스로 전이되어 전체 시스템 장애로 이어질 수 있는 구조이다. 그에 반해, 마이크로 서비스 아키텍처는 각 서비스가 독립적으로 분리되어 있어 한 서비스의 문제가 다른 서비스로의 장애 전파가 줄어든다.

3. 스케일 아웃이 필요한 경우 MA는 전체 애플리케이션의 스케일 아웃을 고려해야 하는 경우가 있지만, MSA는 특정 서비스만 스케일 아웃이 가능하다.

4. 배포시 모놀리식 구조는 전체를 다시 배포해야 하는 번거로움이 있다. 반면에 msa는 특정 서비스의 업데이트나 배포 시, 해당 서비스만을 대상으로 할 수 있다.

MSA를 구성하는 주요 Component

• Config Management (환경 설정 관리) : 환경 변수를 별도의 객체로 관리하여 각 서비스의 설정을 중앙에서 관리한다. 이를 통해 변수의 변경이 있을 때 이미지를 재빌드하지 않고도 설정을 동적으로 업데이트할 수 있어 번거로움을 감소시킨다.
• Service Discovery (서비스 디스커버리) : 각 서비스가 서로를 호출할 때 필요한 아이피나 포트 정보를 효율적으로 관리하여 서비스 간의 통신을 원활하게 한다.
• API Management : 외부에서 내부로의 접근을 API 게이트웨이를 통해 관리하며, 요청의 유효성을 확인하거나 트래픽을 제한하는 등의 API를 관리한다. 앞단에 API 게이트웨이를 두어서 외부에서는 내부를 바로 바라보지는 않게끔 구성한다.
• Centralized Logging : 분산된 서비스들의 로그를 단일 위치에서 통합(중앙화)하여 통합적으로 관리한다. 이는 문제 해결 및 모니터링을 용이하게 한다.
• Distributed Tracing : 서비스 간의 상호 작용을 추적하고 시스템 전체에서의 흐름을 시각화하는 기술이다. 이를 통해 분산된 환경에서 발생하는 요청의 상태를 이해하고 모니터링할 수 있다.
• Centralized Monitoring : 서비스들이 분산되어 있어도 중앙 대시보드 형태로 통합된 모니터링을 제공하여 전반적인 시스템 상태를 파악하고 관리한다.
• Resilience & Fault Tolerance : 서비스 간의 통신에서 발생할 수 있는 장애에 대비하여 서킷 브레이커 등의 메커니즘을 도입하여 전체 시스템의 안정성을 확보한다. 예를 들어, 서비스를 호출했는데 응답하지 않을 때, 스레드가 대기상태가 되고 전체적인 장애로 이어질 수 있는 구조이기 때문에 두 서비스 사이에 서킷 브레이커를 두어서 응답이 오지 않을 때 다른 메시지를 리턴하는등 전체적인 장애를 막는다.
• Auto-Scaling & Self-Healing : 서비스의 부하에 따라 자동으로 스케일 아웃을 수행하고, 장애 발생 시 자동으로 시스템을 회복시키는 기능을 자동화한다. 이를 통해 리소스의 효율적인 활용을 보장하며, 순차적인 스케일 아웃 작업을 자동화함으로써 일일이 리소스를 관리하는 수고를 덜어준다.

MSA 꼭 필요한가 ?

<이미지 출처>

마틴 파울러의 주장에 따르면, 모놀리식 아키텍처는 굳이 복잡한 시스템이 아니라면 충분히 효과적으로 활용될 수 있다고 한다.
즉, 서비스의 복잡도가 낮은 경우에는 모놀리식 아키텍처가 높은 생산성을 제공할 수 있다.
그러나, 마이크로서비스 아키텍처는 서비스의 복잡도가 높을 때 빛을 발한다. 복잡한 비즈니스 도메인에서는 각각의 마이크로서비스가 독립적으로 관리되고 확장될 수 있어 효율적인 개발 및 유지보수가 가능하기 때문이다.

다만, 마이크로서비스가 증가하면 통신 관리가 복잡해지며, 각각의 서비스 옆에 프록시 형태로 붙어있는 서비스 메쉬 등으로 인해 컨테이너 수가 증가하는 단점이 있다. 이러한 구조로 인해 리소스 사용량이 늘어나고, 운영 및 모니터링이 어려워질 수 있다. 따라서, 마이크로서비스 아키텍처를 도입할 때는 이러한 측면을 고려하여 적절한 아키텍처를 선택하는 것이 중요하다.

MSA사용시 고려해야 할 점

1. 가장 먼저 기존의 단일 모놀리식 아키텍처와 비교하여 개발, 배포, 유지보수 등의 프로세스가 어떻게 개선되는지를 검토할 필요가 있다.

2. 또한 인프라 레벨에서의 고려가 필수이다. MSA는 컨테이너와 같은 가상화 기술을 활용하여 서비스를 분리하므로, 이에 따른 infrastructure의 지원이 필요하기 때문이다.

3. 시스템 규모에 따른 적합성도 고려되어야 한다. 규모가 크고 복잡한 기업 시스템에서는 마이크로서비스 아키텍처가 도움이 될 수 있다. 그러나 규모가 작은 경우에는 모놀리식 아키텍처로도 충분히 생산성을 유지할 수 있을 것으로 보인다.