[SW 아키텍처] MSA(MicroServices Architecture)

https://claremont.tistory.com/entry/SW-Architecture-Monolithic-Architecture%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9D-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98

[SW Architecture] 모놀리식 아키텍처(Monolithic Architecture)

 
소프트웨어 개발이 점점 복잡해짐에 따라 기존의 모놀리식 아키텍처(Monolithic Architecture)는 확장성과 유지보수성에서 한계를 드러내고 있다. 이를 해결하기 위해 등장한 개념이 MSA(Microservices Architecture, 마이크로서비스 아키텍처)이다. MSA는 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발, 배포 및 운영을 최적화하는 방법론이다.

 

 
ㅁMSA(Microservices Architecture): 하나의 애플리케이션을 여러 개의 작은 서비스로 구성하여 각각 독립적으로 개발, 배포, 운영할 수 있도록 하는 소프트웨어 설계 방식

문어발식

 
각 서비스는 특정 기능을 수행하며, API를 통해 서로 통신한다
 
[MSA 주요 특징]

• 독립적인 배포 및 확장: 각 서비스가 개별적으로 배포 및 확장 가능
• 분산 아키텍처: 각 서비스가 분리되어 독립적으로 운영됨 (특정 기능 or 도메인에 대한 책임을 맡는다)
• 개발 유연성: 다양한 프로그래밍 언어와 기술 스택을 사용할 수 있음
• 고가용성: 특정 서비스 장애 발생 시 전체 시스템에 영향을 최소화

 

[모놀리식 아키텍처 vs 마이크로서비스 아키텍처(MSA)]

모놀리식 아키텍처는 단순한 애플리케이션에는 적합하지만, 규모가 커질수록 유지보수와 확장이 어려워진다 반면, MSA(마이크로서비스 아키텍처)는 유연성이 뛰어나지만 운영 복잡성이 증가한다

 

---

MSA의 주요 구성 요소

1) API Gateway

• 클라이언트와 마이크로서비스 간의 요청을 관리하는 중간 계층
• 인증, 로드 밸런싱, 요청 라우팅 등의 역할 수행

2) 서비스 디스커버리(Service Discovery)

• 서비스가 동적으로 변경될 수 있도록 위치를 자동으로 찾아 연결
• Consul, Eureka 등 사용

3) 분산 데이터 관리

• 각 서비스가 독립적으로 데이터베이스를 가질 수 있음
• 데이터 동기화 및 일관성 유지가 중요

4) 통신 방식

• 동기식 통신: REST API, gRPC
• 비동기식 통신: Kafka, RabbitMQ 같은 메시지 큐를 사용

5) 모니터링 및 로깅

• 각 서비스의 상태를 지속적으로 모니터링하고, 장애 발생 시 대응
• Prometheus(모니터링 데이터 수집), Grafana(모니터링 데이터 시각화), ELK Stack(Elasticsearch, Logstash, Kibana) 활용

---

 

[MSA 장점]
✅ 확장성 → 특정 서비스만 확장 가능하여 리소스 효율적 운영 가능
✅ 유지보수성 향상 → 개별 서비스 수정 및 배포가 가능하여 빠른 개발 가능
✅ 다양한 기술 스택 활용 가능 → 서비스별로 최적의 언어 및 프레임워크 사용 가능
✅ 장애 격리 → 특정 서비스가 다운되더라도 전체 시스템에는 영향을 최소화
✅ 빠른 배포 및 개발 속도 → CI/CD 파이프라인을 활용한 자동화 가능
 
 
[MSA 단점]
❌ 복잡성 증가 → 서비스 간 통신, 데이터 일관성 유지가 어려움
❌ 운영 및 모니터링 부담 → 여러 개의 서비스 상태를 지속적으로 관리해야 함
❌ 네트워크 오버헤드 → 서비스 간 API 호출이 많아지면 성능 저하 가능
❌ 분산 데이터 관리의 어려움 → 데이터 정합성을 유지하는 것이 어려움(트랜잭션 처리 문제)

 

 

(MSA의 성공적인 도입 사례)

✅ Netflix - MSA계의 아버지 수준

• 수백 개의 마이크로서비스로 구성된 시스템 운영
• API Gateway를 사용하여 사용자 요청을 최적화

✅ Amazon - MSA계의 어머니 수준

• 마이크로서비스를 기반으로 개별 팀이 독립적으로 기능을 개발 및 배포
• EC2, Lambda, DynamoDB 등 다양한 기술 스택 활용

✅ Uber

• 주문, 결제, 드라이버 관리 등 개별 서비스를 독립적으로 운영하여 글로벌 확장
• Kafka, gRPC 등을 활용한 마이크로서비스 간 통신

 
 
<모놀리식에서 마이크로서비스로 전환할 때 고려할 사항>
모놀리식에서 MSA로의 전환이 항상 정답은 아니다!

1) 서비스 경계를 명확히 정의
어떤 기능을 분리하여 마이크로서비스로 전환할 것인지 명확하게 정의해야 함

+ 각 마이크로서비스는 특정 기능 or 도메인에 대한 책임을 맡는다

2) 기존 시스템의 의존성 고려
기존 모놀리식 아키텍처에 깊이 뿌리박힌 의존성을 반드시 고려해야 한다

마이크로서비스는 서로 최소한의 의존성을 가지도록 설계되어야 한다

3) 데이터 관리 전략 수립
마이크로서비스 전환 시 각 서비스별 DB를 어떻게 분리할 것인지 + 트랜잭션 처리를 어떤 방식으로 할 것인지 결정해야 함

4) 운영 및 배포 자동화
CI/CD(Continuous Integration & Continuous Deployment) 환경을 구축하여 자동화된 배포가 가능해야 함
Kubernetes, Docker 등 컨테이너 기술을 활용한 배포 자동화 필요

5) 서비스 간 통신 방식 결정
REST API, gRPC, 메시지 큐(Kafka, RabbitMQ) 등의 통신 방식을 결정해야 함
 
6) 모니터링 및 장애 대응 시스템 구축
전체 시스템을 실시간으로 모니터링하고, 장애 발생 시 빠르게 대응할 수 있는 체계 필요

7) 팀의 역량 및 조직 구조 고려
MSA는 운영과 유지보수가 어렵기 때문에 팀의 역량과 조직 구조를 고려해야 함

 

 
MSA는 확장성과 유연성을 극대화할 수 있는 강력한 아키텍처이지만, 설계와 운영이 복잡하다는 단점도 존재한다. 따라서 팀의 역량, 프로젝트의 복잡성, 요구사항을 고려하여 MSA 도입을 결정하는 것이 중요하다.
적절한 도구와 모범 사례를 활용하면, MSA는 대규모 트래픽을 처리하는 시스템, 글로벌 서비스, 빠른 배포가 필요한 애플리케이션에 강력한 해결책이 될 수 있다!