MSA

Micro Service Architecture

정의

• 단일 프로그램을 컴포넌트별로 나누어서 작은 서비스의 조합으로 구축하는 방법
• 복잡한 웹 시스템에 맞춰 개발된 API 기반의 서비스 지향적 아키텍처 스타일

적용

• MSA 적용 전
  

• MSA 적용 후
  

특징

1. 데이터 분리 (Database Per Service)
   • 각 컴포넌트는 서비스 형태로 구현된다.
   • 서비스별로 별도의 DB를 사용하거나 하나의 DB를 나누어서 사용한다.
     • 각각은 자체 프로세스에서 실행된다.
   • 다른 서비스 컴포넌트에 대한 의존성이 사라져서 독립적으로 개발, 배포, 운영할 수 있다.
     • 느슨한 연결(Loosely-coupled) 구조
   • 타 서비스와 API로 통신한다.
2. API Gateway
   • 각 서버의 URL이 다르다.
   • 게이트웨이는 API 서버 앞단에서 모든 API 서버들의 End-Point를 단일화해서 묶어준다.
   • 복잡한 서비스간 API 호출 구조를 단순화시켜준다.
   • 라우팅, 로드밸런싱, 인증 등 다양한 역할 수행
3. 팀의 변화
   • 기존에는 역할별로 팀을 구분했다.
     - 팀 간의 협업과 커뮤니케이션이 오래 걸릴 수 있다.
     
   • 서비스별로 팀을 나눈다.
4. 팀의 구조뿐만 아니라 시스템 설계, 프로젝트 관리 방법까지 달라진다.
5. 클라우드 기반 환경에 적합하다.
   • Docket, Kubernetes 같은 컨테이너 기반의 플랫폼과 조합이 잘 어우러진다.

장점

• 서비스의 재사용성
• 유연한 아키텍처 구조
• 대용량 웹 서비스에 적합한 구조
• 부분적인 확장이 가능하다.
  • 한 서비스에 트래픽이 몰려도 해당 서버만 확장하면 된다.
• 서비스 기획, 설계, 개발, 운영이 팀 내에서 이루어지기 때문에 다른 팀에 대한 의존성이 사라진다.
  • 요청과 피드백이 빨라지고 유연하고 지속적인 운영이 가능하다.

단점

• 다른 컴포넌트의 데이터를 가져오기 위해 API 통신을 이용하기 때문에 속도가 느리다.
  • 통신에 사용하기 위한 값을 데이터 모델로 변환시켜주는 오버헤드가 발생한다.
• 하나의 트랜잭션으로 묶을 수 없다.
  • 반정규화된 데이터의 동기 처리도 신경써야 한다.
• 통합 테스트의 어려움
  • 테스트 시작 전에 의존성이 있는 서비스를 미리 확인해야 한다.
• 인력 리소스 관리의 어려움
  • 각 팀의 담당자들은 기본적인 업무 숙련도를 가져야 한다.
• 개발 복잡도와 배포 복잡도
  • 분산 시스템 개발은 일반 개발보다 복잡하다.
  • 배포할 때 각 서비스간의 조정이 필요할 수도 있다.

---

출처

• 자동등록방지를 위해 보안절차를 거치고 있습니다.
• 당신의 MSA는 안녕하신가요? MSA를 보완하는 아키텍처 EDM[Event Driven MicroService]