MSA(Microservices Architecture)? MA(Monolithic Architecture)? 개념 및 차이

 

모놀리식(Monolithic Architecture), MA

하나의 통합된 코드 베이스로 여러 비즈니스 기능을 수행하는 전통적인 소프트웨어 개발 모델

단일 애플리케이션 내에 서비스의 모든 로직이 통으로 들어가 있는 구조

(ex : 상품, 정산, 알림, 쿠폰, 배송 등)

이렇게 서비스를 애플리케이션 하나로만 처리할 때의 가장 큰 장점은 간결하다는 점
중앙 집중된 구조이기 때문에 분산된 애플리케이션에 비해 엔드 투 엔드 테스트(End-to-End)를 
더 빠르게 수행할 수 있다. 단일 애플리케이션에 비즈니스 로직부터 UI, 콘텐츠 등 모든 구성요소를 이루는
코드가 들어있기 때문에 디버깅하기도 간편하다. 소규모 애플리케이션이라면 단순하면서도 견고한 구조를 만들기 좋다.

하지만, 서비스 규모가 커짐에 따라 모놀리식 아키텍처의 단점도 제기되기 시작했다.

 

단일 애플리케이션이 커지면 자연히 구동부터 빌드, 배포에 드는 시간이 오래 걸리게 된다.
더욱이 하나로 된 거대한 시스템 구조를 제대로 파악하지 않으면 특정 컴포넌트나 모듈에서 발생하는 성능 문제나 장애가 다른 영역에까지 영향을 주게 된다. 아무리 작은 부분만 수정하더라도 전체 애플리케이션을 통째로 컴파일해서 배포해야 하는 만큼 잦은 환경에서는 번거롭다. 

 

장점

• 단순하고 통일성 있는 구조
• 단일 코드베이스로 인한 간편한 개발
• 빠르고 편한 E2E 테스트
• 손쉬운 모니터링, 디버깅

단점

• 유지보수 및 안정성 문제
• 느린 개발 및 배포 속도
• 위축된 확장성
• 기술 유연성 낮음

적합한 경우

• 기술적 복잡도가 낮은 소규모 프로젝트
• 복잡한 비즈니스 로직이 필요하지 않을 때
• 프로토타입 제작 및 단기 프로젝트

---

MSA(Microservices Architecture)

아주 작은 서비스 단위로 나눠 각 서비스에 독립적으로 서비스를 구성하는 모델
중앙 집중적인 관리 체계 대신 경량화된 API나 메시지로 직접 통신하며 접근하는 방식을 취한다

MSA의 장점은 서비스를 잘게 쪼개면서 개발 구조가 민첩하고 유연해졌다는 점
각 서비스를 독립적으로 개발하고 배포할 수 있어서 작업 시간이 단축되고 확장성도 높다. 배포가 빠르고 잦은 만큼 애자일 작업 방식을 취하기도 편리하다.

 

더욱이 일부분에 문제가 생기면 시스템 전체가 다운될 수 있는 모놀리식 아키텍처와 달리, 한 서비스가 
다운되더라도 다른 서비스는 문제가 없이 작동할 수 있다. 서비스에 적합한 언어나 프레임워크 등 기술을 독립적으로 선택할 수 있고, 자체 DB를 서비스마다 가지고 있어서 데이터 무결성을 유지하는데도 도움이 된다.

단점으로는, 분산된 서비스가 서로 API를 호출하는 과정에서 통신 비용과 지연 시간이 들고, 큰 인프라 비용이
발생할 수 있다. 장애 추적이나 디버깅, E2E테스트 역시 쉽지 않다. DB가 분리되면서 데이터를 조회하기 어렵고 DB 간 데이터 중복이 발생할 수도 있다. 무엇보다 서비스가 커지는 만큼 복잡해지기 때문에 적절하게 관리하지 않으면 오히려 개발 속도나 운영 성능이 나빠질 수 있다. 

 

장점

• 유연한 확장성
• 더 민첩한 배포 주기
• 유지관리 안정성
• 기술 유연성 높음(서비스별 독립적인 스택 선정 가능)

단점

• 복잡한 구조, 높은 구현 난이도
• 모니터링, 디버깅, 통합테스트 어려움
• 인프라 및 자원, 인력에 드는 막대한 비용
• 까다로운 DB 트랜잭션 관리

적합한 경우

• 기술적 복잡도가 높은 대규모 프로젝트
• 다양한 기술 스택을 사용하고, 여러 비즈니스별 요구사항이 명확한 경우
• 장애를 줄이고 시스템 전체의 가용성과 탄력성을 높여야 할 때

---

 

Inner Architecture

실제 비즈니스가 실행되는 각 MSA 내 구조를 정의한 아키텍처, 내부 서비스 구축에 관한 설계

 

고려해야 할 사항

서비스를 어떻게 정의할 것인가?

→ 쇼핑몰에서 주문하는 부분과 카트 담기를 같은 서비스로 넣을 것인지, 다른 서비스로 분리할 것인지는 그 비즈니스나 시스템의 특성에 따라 정의되어야 한다.

DB Access 구조를 어떻게 설계한 것인가?

→ 사용하는 데이터는 일반적으로 일관된 API를 통해서 접근한다. 또한 각 마이크로 서비스에는 자체의 

데이터베이스를 가질 수 있는데, 일부의 비즈니스 트랜잭션은 여러 마이크로서비스를 걸쳐 있기 때문에,

각 서비스에 연결된 데이터베이스의 정합성을 보장해 줄 수 있는 방안이 필요하다.

서비스 내 API를 어떻게 설계할 것인가?

 

+ 추가적인 사항

---

Outer Architecture

MSA가 운영되는 환경 정의, 인프라 기반의 아키텍처, 서비스 개발, 배포, 실행할 환경관리 기능에 대한 설계

구성요소

1. External Gateway

전체 서비스 외부로부터 들어오는 접근을 내부 구조를 드러내지 않고 처리하기 위한 요소
API 서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고 API에 대한 인증과 인가 기능에서부터 메시지에 따라 여러 서버로 라우팅 하는 고급기능 담당 (사용자 인증, 권한 정책관리 수행 등)

2. Service Mesh

마이크로서비스 구성 요소 간 네트워크를 제어하는 역할
서비스 간에 통신을 하기 위해서는 Service Discovery, Service Routing, 트래픽 관리, 보안 등을 담당하는 요소가 있어야 한다. 이러한 기능을 모두 수행하는 역할.

3. Container Management

컨테이너 기반 어플리케이션 운영(Kubernetes)
컨테이너 기반 어플리케이션 운영은 유연성과 자율성을 가지며, 개발자가 손쉽게 접근 및 운영할 수 있는
인프라 관리 기술이기 때문에 MSA에 적합하다고 평가받고 있다.

대표적인 컨테이너 관리 환경인 Kubernetes가 많이 사용되고 있다.
특히 AWS의 EKS, Google cloud platform의 GKE는 Kubernetes를 지원하는 클라우드 서비스로, 
앞으로의 어플리케이션 운영 환경을 많이 변화시킬 것으로 예상된다.

4. Backing Service

어플리케이션이 실행되는 가운데 네트워크를 통해서 사용할 수 있는 모든 서비스
데이터베이스, 캐쉬 시스템, SMTP 서비스

MSA에서의 특징적인 Backing Service들 중 하나는 'Message Queue'이다. MSA에서는 메시지의

송신자와 수신자가 직접 통신하지 않고 Message Queue를 활용하여 비동기적으로 통신하는 것을 지향한다.

 

예를 들어, MSA를 적용한 프로젝트에서 장애 발생이 일어났다고 가정해 보자. 이 경우, 마이크로서비스 오케스트레이션이 진행되면서, 새로운 마이크로 서비스를 신규 생성하거나 재생성 등의 작업을 진하게 된다.

만약 Message Queue를 사용하지 않는 강한 결합 구조의 경우, 여러 서비스를 걸치는 실시간 트랜잭션을 처리할 때, 하나의 서비스가 죽어버린다면 트랜잭션이 끊어지기 때문에 해당 서비스 요청을 보존할 수 없고 큰 에러가 
발생하게 된다. 또한 REST 통신으로 트랜잭션 실패에 대한 처리를 구현하는 방법은 굉장히 복잡하다.

MSA에서 데이터 변경이나, 보상 트랜잭션과 관련된 처리는 Message Queue를 활용한 비동기 처리가 효율적이다.

 

마이크로서비스 오케스트레이션( Microservice Orchestration)

분산된 마이크로 서비스들을 중앙에서 관리하고 조율하는 방식
분산된 서비스들이 협력하여 전체 시스템을 구성하는 MSA 환경에서 장애를 관리하는 방법 중 하나

각 서비스가 독립적으로 동작하지만, 전체 시스템이 유기적으로 작동하기 위해서는 서비스 간의 흐름과 작업을
조율하는 방식이 필요한데, 이 부분에서 핵심적인 역할을 한다.

서비스가 중단되거나 문제가 발생할 경우, 새로운 인스턴스를 생성하거나 기존 인스턴스를 재생성하여
서비스 가용성을 유지하려는 작업을 자동화한다.

 

5. Telemetry

실시간으로 먼 거리에서 원격으로 측정할 수 있는 기능, 서비스 상태 모니터링

MSA에서는 상당수의 마이크로서비스가 분산환경에서 운영되기 때문에 서비스들의 상태를 일일이 모니터링하고, 이슈에 대응하는 것은 굉장히 힘들고 오랜 시간이 걸린다. Telemetry는 서비스들을 모니터링하고

서비스별로 발생하는 이슈들에 대응할 수 있도록 환경을 구성하는 역할

6. CI/CD Automation

어플리케이션 개발 단계를 자동화하여, 어플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법

지속적인 통합(Continuous Intergration), 지속적인 전달( (Continuous Delivery),
지속적인 배포(Continuous Deployment)가 CI/CD의 기본 개념으로, 이를 자동화하는 것은 배포가 잦은

MSA 시스템에서 꼭 필요한 요소 중 하나이다.