MSA(Microservices Architecture)

---

0. 문제

MSA에 관하여 설명하시오.

---

1. 서론

▣ 개념 정의

**MSA(Microservices Architecture, 마이크로서비스 아키텍처)**란, 애플리케이션을 작고 독립적인 서비스 단위로 분해하여 개발, 배포, 운영하는 소프트웨어 아키텍처 패턴이다.

▣ 역사적 배경

• 기존의 모놀리식(Monolithic) 아키텍처는 단일 코드베이스로 인해 변경, 배포, 확장이 어려웠음.
• DevOps, 클라우드 컴퓨팅, 컨테이너 기술의 발전과 함께 애자일/지속적 배포가 가능하도록 등장.

▣ 출현 목적

• 빠른 서비스 개발 및 배포
• 각 기능을 독립적으로 운영하여 민첩성과 확장성 확보
• 장애 격리 및 복원력 향상

---

2. 본론

▣ MSA 구조 및 원리

구성 요소	설명
Service	독립적인 비즈니스 기능을 수행하는 마이크로 단위 서비스
API Gateway	클라이언트 요청을 서비스에 라우팅하고 인증/로깅 처리
Service Discovery	동적으로 서비스 위치를 탐색 (ex. Netflix Eureka)
Configuration Server	공통 설정 관리, 서비스 재시작 없이 설정 변경 가능
Message Broker	비동기 통신 지원 (ex. Kafka, RabbitMQ)
Container/Orchestration	서비스 배포 및 확장 자동화 (ex. Docker, Kubernetes)

▣ 특징 및 구성 방식

항목	설명
작은 단위	각 서비스는 단일 책임 원칙(SRP)에 기반한 최소 단위
독립 배포	특정 서비스만 수정/배포 가능
기술 다양성	서비스별 언어/프레임워크 선택 가능
DB 분리	서비스별 데이터베이스 소유권 분리 (데이터베이스 분산 관리)

▣ 장단점

구분	장점	단점
개발	독립적 개발로 생산성 향상	서비스간 인터페이스 관리 필요
운영	장애 격리, 롤백 용이	분산 트랜잭션 처리 복잡
확장	필요 기능만 스케일링 가능	인프라/모니터링 복잡도 증가
보안	최소 권한 설계 용이	서비스 간 인증/인가 설계 필요

▣ 타 아키텍처와 비교

항목	모놀리식	MSA
구조	단일 애플리케이션	독립적인 서비스 모듈
배포	전체 재배포 필요	부분 배포 가능
장애 영향	전체 영향	국지적 영향
확장성	수직 확장 중심	수평 확장 중심
기술 스택	통일된 스택	서비스별 다양성 허용

▣ 실무 적용 방안

• 적용 대상 판단: 복잡도 높은 비즈니스, 빠른 배포 요구 환경

• 전환 전략:

  • Big Bang 방식은 위험 → 점진적 리팩토링 권장
  • 예: 도메인 단위의 모듈부터 서비스 분리

• 조직 구성: 서비스 중심의 DevOps 및 팀 구조 정비

• 보안/인증: OAuth 2.0, JWT(JSON Web Token) 등 API 인증 체계 도입

• 관측성 확보: 모니터링, 로깅, 트레이싱 필수 (예: Prometheus, ELK, Jaeger)

▣ 최신 기술 트렌드

트렌드	설명
Service Mesh	Istio, Linkerd를 통한 서비스 간 보안/정책/모니터링 자동화
Serverless MSA	AWS Lambda 등과 결합하여 운영 부담 최소화
AI Ops 적용	마이크로서비스 장애 예측 및 자가 복구
Domain-driven Design(DDD)	마이크로서비스 도메인 모델 설계 가이드로 채택

---

3. 결론

▣ 어린이 버전 요약

MSA는 큰 프로그램을 작은 부품처럼 나눠서 만들고, 각각을 혼자서 움직이게 하여 더 빠르게 만들고 고치고 돌릴 수 있는 방법이에요.

---

▣ 한 눈에 보는 요약표

항목	내용
정의	독립 서비스 단위로 구성된 아키텍처
핵심 구성	API Gateway, Discovery, 메시징, 개별 DB
장점	민첩성, 장애 격리, 확장성
단점	복잡도, 통신 오버헤드, 테스트 어려움
실무 적용	점진적 전환, DevOps 정비, 보안 체계 구축
최신 트렌드	서비스 메시, 서버리스, AIOps, DDD 기반 설계

---