MSA

MSA : Micro Service Archiecture

작고 독립적으로 배포 가능한 각 기능 구행하는 서비스들로 구성된 프레임워크.
완전 독립적 배포 가능.
다른 기술 스택 사용 가능.

Monolithic Architecture

Monolithic Architecture : 모든 구성요소가 한 프로젝트에 통합된 형태.
모듈별로 개발 후 완료된 앱 어플리케이션 하나의 결과물로 패키징, 배포.
웹의 경우 WAR 파일 빌드 후 WAS에 배포.

모노리틱 구조의 한계

• 부분 장애가 전체 서비스 장애로 확대

• 부분적 scale-out이 어려움.
  모노리틱 구조에서는 다른 모든 서비스가 스케일 아웃 되어야 함.

• 여러 컴포넌트가 하나의 서비스에 강하게 결합 -> 변경, 수정 어려움

• 배포 시간 오래 걸림

• 한 프레임워크와 언어에 종속적.

이러한 Monolithic Architecture 문제 보완 위해 MSA.
기존의 특정 물리적 서버에 서비스 올리는 on-premise 서버 기반에서, 클라우드 이용해 서버 구성하는 MSA로의 전환.

온 프레미스 : 기업의 서버를 클라우드 같은 원격 환경에서 운영하는 방식이 아닌, 자체 보유한 전산실 서버에 직접 설치해 운영하는 방식.

MSA의 특징

MSA는 API 통해서만 상호작용 가능.
MSA의 end point를 API 형태로 외부에 노출, 실질적 세부사항은 모두 추상화.
-> SOA(Service Oriented Architecture) 특징 가진다.

하나의 마이크로 서비스는 하나의 비지니스 범의 -> 하나의 기능만 수행, 여러 어플리케이션에서 재사용 가능해야 함.

MSA는 SOA에서 사용하는 집중화된 관리 체계 사용 x.
ESB(Enterprose Service Bus)와 같은 무거운 제품 x, REST 등 만 수행, 여러 어플리케이션에서 가벼운 통신 아키텍쳐, Kafka등의 메시지 스트림 주로 사용.

MSA의 장점

• 모듈화, 빠른 개발 및 유지보수
• 다양한 기술 스택
• 서비스 별 독립적 배포
• 각 서비스 부하에 따른 개별적 scale-out -> 메모리, cpu적 이득

MSA의 단점

• 모노리틱에 비해 복잡함. 서비스 모두 분산되어 있기 때문에 내부 통신 어떻게 할 지, 통신 장애, 서버 부하, transaction에 대한 고민.

• 모로리틱은 단일 트랜잭션 유지하면 되지만, MSA에서는 비지니스 별 DB 갖고있는 서비스 다르고, 서비스 연결 위해 통신이 포함되기 때문에 트랜잭션 유지가 어려움.

• 통합 테스트 어렵다. -> 개발 환경과 실제 운영 환경 동일하게 만들기 어려움.

• 실제 운영 환경 배포 까다로움. 서비스 하나 재배포 -> 다른 서비스들과의 연계 모두 확인해야 함.

---

모노리틱 서비스 : 기존에는 하나의 어플리케이션. 단일 서비스

Micro - 얼마나 작게?

why?

쪼갠 시스템 끼리 통신, 호출할 수 있음.
-> 복잡도 올라감. 비용도 상승 가능성.

장점?
모듈화 하면 부분 이상 있어도 전체 장애 방지.

효율적 인프라 관리
결제, 정산, 조회 api 있을 때 서비스 성장 ->

1. 조회 콜이 90%. 조회 기능 탑재한 인프라만 늘리는 것이 효율적.

2. 조회 기능만 빈번한 업데이트, 배포 이뤄지는 모듈.
   전체 코드 빌드, 업데이트말고 조회만 따로 -> 다른 기능은 정상적으로 사용할 수 있음.
   -> DevOps. 조회팀 -> 이 기능에 대해서만.

왜 선풍적인 인기일까?

<참고>
https://wooaoe.tistory.com/m/57
https://www.youtube.com/watch?v=dSGnJWHuxtQ