backend-interview-guide

마이크로서비스 아키텍처 (Microservices Architecture, MSA)

마이크로서비스 아키텍처란?

마이크로서비스 아키텍처(MSA) 는 애플리케이션을 작고 독립적인 서비스 단위로 분리하여 개발, 배포, 운영할 수 있도록 설계하는 분산 소프트웨어 아키텍처입니다. 각 서비스는 특정 도메인 기능(예: 사용자 관리, 주문 처리)을 담당하며, 다른 서비스와 독립적으로 개발되고 배포됩니다.

주요 개념:

작고 자율적인 서비스: 각 서비스는 특정 기능에 집중하며, 작은 단위로 설계됩니다.
독립적 배포: 서비스 간 의존성을 최소화하여 개별 서비스가 독립적으로 업데이트 및 배포될 수 있습니다.
분산 아키텍처: 서비스 간 통신은 주로 HTTP/REST API, gRPC, 메시징 시스템(Kafka, RabbitMQ) 등을 통해 이루어집니다.
폴리글랏 프로그래밍: 각 서비스는 요구사항에 따라 다른 언어, 프레임워크, 데이터베이스를 선택하여 구현할 수 있습니다.

MSA의 특징

1. 도메인 중심 설계

서비스는 특정 도메인 또는 비즈니스 기능에 맞춰 설계됩니다.
DDD(Domain-Driven Design) 원칙을 따르며, 특정 도메인의 독립성을 보장합니다.

2. 독립적 데이터베이스

각 서비스는 고유한 데이터베이스를 가지며, 다른 서비스와 데이터베이스를 공유하지 않습니다.
장점: 데이터 모델의 독립성을 유지할 수 있고, 스키마 변경 시 다른 서비스에 영향을 주지 않습니다.

3. 자율적 팀 구성

각 서비스는 독립된 개발 및 운영 팀이 담당합니다. 팀은 서비스의 전체 라이프사이클(개발, 배포, 유지보수)을 책임집니다.
이를 통해 빠른 의사결정과 개발 속도를 보장합니다.

4. API 기반 통신

서비스 간 통신은 API(주로 REST, gRPC)를 통해 이루어집니다.
API Gateway를 통해 요청을 라우팅하고, 인증, 로깅, 트래픽 관리 등을 처리합니다.

5. 경량화된 배포

컨테이너(Docker)와 오케스트레이션 도구(Kubernetes)를 활용하여 경량화된 배포를 지원합니다.
개별 서비스는 독립적으로 배포 및 확장될 수 있습니다.

MSA와 모놀리식 아키텍처 비교

특징	모놀리식 아키텍처	마이크로서비스 아키텍처
구조	단일 코드베이스로 모든 기능이 통합된 애플리케이션	독립적으로 개발 및 배포 가능한 작은 서비스들의 집합
배포	전체 애플리케이션을 한꺼번에 배포	개별 서비스 단위로 배포 가능
확장성	수직 확장(더 강력한 서버로 업그레이드)	수평 확장(서비스별로 독립적으로 확장 가능)
개발	모든 팀이 동일한 코드베이스에서 작업	각 팀이 독립된 서비스에서 작업
의존성 관리	의존성이 복잡하게 얽힐 가능성 높음	각 서비스가 독립적이므로 의존성 최소화 가능
장애 전파	하나의 장애가 전체 시스템에 영향을 줄 수 있음	특정 서비스 장애가 전체 시스템에 미치는 영향을 최소화할 수 있음
복잡성	단일 애플리케이션이므로 구조는 단순하지만 확장 시 복잡성 증가	분산 시스템이므로 초기 설계 및 운영 복잡성이 높음

MSA의 장점

1. 독립적 배포 및 개발

특정 서비스에 변경 사항이 있을 때, 전체 애플리케이션을 재배포할 필요 없이 해당 서비스만 업데이트할 수 있습니다.
개발팀이 독립적으로 작업할 수 있어 빠른 개발 주기와 배포 속도를 보장합니다.

2. 확장성

서비스별로 독립적인 수평 확장이 가능하므로, 트래픽이 많은 서비스만 확장하여 리소스를 효율적으로 사용할 수 있습니다.
클라우드 네이티브 환경에서 자동 확장 기능(Auto Scaling)과 결합하면 확장성이 극대화됩니다.

3. 장애 격리

특정 서비스에 장애가 발생해도 다른 서비스에는 영향을 미치지 않으므로, 시스템 가용성이 향상됩니다.
예: 결제 서비스에 장애가 발생해도 사용자 인증이나 상품 검색 기능은 계속 동작.

4. 폴리글랏 아키텍처

각 서비스는 요구사항에 따라 적합한 기술 스택(프로그래밍 언어, 데이터베이스, 프레임워크 등)을 선택할 수 있습니다.
이를 통해 최적의 기술을 적용하여 성능과 생산성을 높일 수 있습니다.

5. 빠른 장애 복구

장애가 발생한 서비스만 재시작하거나 롤백할 수 있어, 시스템 복구 속도가 빠릅니다.

MSA의 단점

1. 복잡성 증가

서비스가 많아질수록 의존성과 통합 테스트의 복잡도가 증가합니다.
서비스 간 통신, 데이터 일관성, 배포 파이프라인 등 분산 시스템의 복잡성을 관리해야 합니다.

2. 서비스 간 통신 비용

서비스 간 API 호출, 네트워크 지연(latency), 데이터 직렬화/역직렬화로 인해 성능 저하가 발생할 수 있습니다.

3. 데이터 일관성 문제

각 서비스가 독립적인 데이터베이스를 사용하므로, 글로벌 트랜잭션을 지원하지 않습니다.
이를 해결하기 위해 이벤트 소싱(Event Sourcing), CQRS(Command Query Responsibility Segregation) 패턴을 적용해야 할 수 있습니다.

4. 모니터링 및 디버깅 어려움

분산된 서비스에서 발생하는 문제를 추적하기 어렵습니다.
이를 해결하기 위해 분산 트레이싱 도구(Jaeger, Zipkin)와 모니터링 도구(Prometheus, Grafana)를 사용해야 합니다.

5. 초기 설정 및 운영 비용

초기 설계와 인프라 설정에 많은 비용과 노력이 필요합니다.
컨테이너 오케스트레이션(Kubernetes), API Gateway, 메시징 시스템 등을 관리해야 합니다.

MSA 구현 시 고려사항

서비스 분리 전략
- 각 서비스를 비즈니스 도메인별로 설계하여 높은 응집도와 낮은 결합도를 유지합니다.
- DDD(Domain-Driven Design)를 기반으로 서비스 경계를 정의합니다.
데이터 분리
- 각 서비스는 고유한 데이터베이스를 사용해야 하며, 다른 서비스와 데이터베이스를 공유하지 않습니다.
- 데이터 동기화를 위해 이벤트 기반 통신(Kafka, RabbitMQ)을 활용할 수 있습니다.
API 게이트웨이 활용
- 모든 요청은 API Gateway를 통해 라우팅됩니다. Gateway는 인증, 로깅, 트래픽 관리, CORS 등을 처리합니다.
서비스 간 통신
- RESTful API 또는 gRPC를 사용하며, 비동기 작업에는 메시지 브로커(Kafka, RabbitMQ)를 활용합니다.
자동화된 배포
- CI/CD 파이프라인을 구축하여, 서비스별로 자동화된 빌드, 테스트, 배포 프로세스를 구현합니다.
모니터링 및 로깅
- 모든 서비스의 상태를 실시간으로 모니터링하기 위해 Prometheus, Grafana를 사용합니다.
- 분산 로그 수집은 ELK(Elasticsearch, Logstash, Kibana) 스택을 활용합니다.

대규모 트래픽 환경에서의 MSA

독립적 확장성
- 대규모 트래픽을 처리하기 위해 트래픽이 집중되는 서비스만 독립적으로 확장합니다.
- 예: 검색 서비스만 트래픽이 몰린다면, 해당 서비스의 인스턴스 수를 늘립니다.
오토스케일링
- Kubernetes와 같은 오케스트레이션 도구를 사용하여 자동 확장을 구현합니다.
- HPA(Horizontal Pod Autoscaler)를 설정해 트래픽 증가에 따라 파드 수를 늘립니다.
로드 밸런싱
- 서비스 간 트래픽을 균등하게 분산하기 위해 로드 밸런서를 사용합니다.
- 클라우드 제공자의 관리형 로드 밸런서(AWS ALB, GCP Load Balancer)와 통합합니다.
서비스 간 메시징
- 메시지 브로커(Kafka, RabbitMQ)를 사용하여 트래픽 급증 시에도 비동기로 요청을 처리합니다.
- 이를 통해 서비스 간 의존성을 줄이고 성능을 최적화합니다.
캐싱
- Redis, Memcached 등을 사용하여 데이터베이스 부하를 줄이고, 읽기 성능을 최적화합니다.
모니터링 및 장애 대응
- 실시간 트래픽 상태를 Prometheus와 Grafana로 모니터링합니다.
- 장애 발생 시 즉각적인 복구를 위해 Canary 배포 또는 롤백을 지원합니다.

결론

마이크로서비스 아키텍처는 대규모 시스템의 확장성, 유연성, 가용성을 극대화할 수 있는 강력한 설계 방식입니다. 그러나 초기 설계와 운영의 복잡성을 해결하기 위한 전략이 필수적입니다. 올바른 도구와 프레임워크를 활용하여 MSA를 구현한다면, 대규모 트래픽과 복잡한 요구사항을 효과적으로 처리할 수 있습니다.

This site is open source. Improve this page.