1447 단어
7 분
MSA
2025-07-03

1. MSA 개요#

1.1 MSA란?#

  • *MSA(Microservices Architecture)**는 하나의 애플리케이션을 여러 개의 독립적인 서비스로 나누어 개발하고 운영하는 소프트웨어 아키텍처 방식임
  • 각 서비스는 독립적으로 배포되고 실행되며, 특정 비즈니스 기능을 담당함
  • 즉, 대규모 서비스/애플리케이션을 여러 개의 작은 규모의 서비스/애플리케이션으로 나누는 접근 방식을 말함

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

모놀리식 (Monolithic)

  • 하나의 단위로 개발되는 일체식 애플리케이션
  • 단일 프로세스에서 실행됨
  • 스케일 아웃(Scale-out) 시 모놀리스 전체가 확장됨 (로드 밸런서를 두고 전체 덩어리를 복제)
  • 수정 시 시스템 전체를 재빌드/재배포해야 함
  • 데이터베이스가 통합되어 있어 탄력적 대응이 어려움

마이크로서비스 (Microservices)

  • 서버 측이 여러 개의 조각으로 구성되어 각 서비스가 별개의 인스턴스로 로딩됨
  • 각기 다른 저장소를 사용하여 업무 단위로 모듈 경계가 명확함
  • API를 통해서만 느슨하게 연계됨 (Loose Coupling)
  • 폴리글랏(Polyglot): 각 서비스를 구축하는 언어/DB를 자율적으로 선택 가능
  • 자동화된 환경에서 독립적으로 배포됨

🆚 비교표#

항목모놀리식 아키텍처 (Monolithic)마이크로서비스 아키텍처 (MSA)
개발 및 배포전체 시스템을 한 번에 빌드 및 배포개별 서비스 단위로 독립적 배포 가능
확장성전체 시스템을 확장해야 함필요한 서비스만 개별적으로 확장 (리소스 최적화)
유지보수코드가 복잡해질수록 어려움서비스 단위로 유지보수 가능
장애 영향전체 시스템에 영향 (SPOF 위험)특정 서비스만 장애 발생 가능 (격리)

2. MSA의 장점과 단점#

2.1 장점#

  • 유연한 확장성: 트래픽이 몰리는 특정 서비스만 확장하여 리소스 최적화 가능
  • 독립적인 배포: 전체 중단 없이 특정 기능만 업데이트하거나 롤백 가능
  • 개발 속도 향상: 서비스별로 팀을 나누어 독립적인 개발 가능
  • 기술 스택 자유도: 각 서비스의 목적에 맞는 최적의 언어와 DB 선택 가능

2.2 단점#

  • 복잡한 관리: 서비스가 많아질수록 운영 포인트와 모니터링 대상이 급증함
  • 데이터 일관성 문제: DB가 분산되어 있어 트랜잭션 관리가 어렵고 정합성 맞추기가 까다로움
  • 네트워크 비용 증가: 내부 호출(In-memory call)이 아닌 네트워크 통신(RPC, REST)이 많아져 지연 시간(Latency) 발생 가능
  • 분산 트랜잭션 어려움: 하나의 작업이 여러 서비스에 걸칠 경우 롤백 등의 처리가 복잡함 (SAGA 패턴 등 필요)

3. MSA의 핵심 구성 요소#

3.1 API Gateway#

클라이언트와 마이크로서비스 간의 ‘문지기’ 역할을 하는 중간 계층

  • 요청 라우팅: 클라이언트의 요청을 적절한 서비스로 전달
  • 인증 및 인가: JWT, OAuth 등을 이용해 입구에서 보안 처리
  • 로드 밸런싱: 트래픽을 여러 인스턴스로 분산
  • 캐싱: 자주 요청되는 데이터를 저장해 응답 속도 향상
  • 모니터링: 요청/응답 로그를 기록하여 추적

3.2 서비스 디스커버리 (Service Discovery)#

동적으로 생성/삭제되는 서비스들의 위치(IP, Port)를 등록하고 찾는 시스템

  • 주요 기능:
    • 서비스 등록: 서비스 시작 시 중앙 저장소에 자신의 위치 등록
    • 서비스 검색: 다른 서비스를 호출할 때 위치를 조회
    • Health Check: 장애가 난 서비스는 목록에서 자동 제외
  • 예시: Eureka (Spring Cloud), Consul, Zookeeper

3.3 분산 데이터 관리#

각 마이크로서비스는 Database per Service 원칙에 따라 독립적인 DB를 가짐

  • Eventual Consistency: 실시간 일관성(ACID) 대신, 시간 차를 두고 최종적으로 데이터가 일치하도록 설계
  • CQRS: 명령(Write)과 조회(Read) 모델을 분리하여 성능 개선
  • 이벤트 기반 아키텍처: Kafka, RabbitMQ 등을 통해 데이터 변경 사실을 이벤트로 전파
  • SAGA 패턴: 분산 환경에서 트랜잭션을 안전하게 처리하기 위한 보상 트랜잭션 패턴

3.4 로깅 및 모니터링#

서비스가 분산되어 있어 장애 추적이 어렵기 때문에 중앙 집중화된 관리가 필수임

  • 분산 로깅: 여러 서비스의 로그를 한곳에 모아서 분석 (Trace ID 활용)
  • 메트릭 수집: CPU, 메모리, 응답 시간, 에러율 등 수집
  • 트레이싱: 서비스 간 호출 흐름을 시각화하여 병목 구간 파악
  • 예시:
    • Logging: ELK Stack (Elasticsearch, Logstash, Kibana)
    • Monitoring: Prometheus, Grafana
    • Tracing: Jaeger, Zipkin, OpenTelemetry

4. MSA 구축 시 고려 사항#

  1. 서비스 경계 정의: 도메인 주도 설계(DDD) 등을 기반으로 비즈니스 경계를 명확히 나누어야 함
  2. 데이터베이스 설계: 단일 DB 공유를 피하고 서비스별 DB 설계를 원칙으로 함
  3. 보안 강화: 서비스 간 내부 통신 암호화(mTLS), 인증/권한 관리 철저
  4. 테스트 전략: 단위 테스트(Unit)뿐만 아니라 복잡한 통합 테스트(E2E) 시나리오 수립 필요
MSA
https://devlog.jpstudy.org/posts/2025/cs/msa/
저자
SY
게시일
2025-07-03
라이선스
CC BY-NC-ND 4.0