모놀리식
- 작은 크기에서 용이
- 규모 크면 불리한점이 많다
- 특정 컴포넌트의 오류가 다른 컴포넌트에 영향을 미칠 가능성이 높아짐
- 시스템 구조 커질수록 이해하기가 어려워짐
- 컴포넌트 하나 수정해도 재 배포시 전체 애플리케이션 재 컴파일해야함
- 잦은 배포해야하는 경우 매우 느림
- 차후 IO작업이 많은 컴포넌트를 개발해야할 때 node js를 사용하는 것이 유리할 수 있으나 자바로 개발되어 다른 기술 집어넣기 매우 힘들어짐
MSA
- SOA에 근간을 두고 있음
- 각 컴포넌트를 “서비스”라는 개념으로 정의
- 데이터, 비즈니스 로직까지 독립저그로 상호 컴포넌트 간 의존성 없이 개발된 컴포넌트를 가지고 REST API와 같은 인터페이스로 그 기능을 외부로 제공
- 배포관점에서 변경된 컴포넌트 파트만 재배포를 하면 됨
- 로드밸런서를 활용해 서비스간의 로드를 분산시킴
- 데이터베이스까지 분리함
- 샤딩
- 이렇게 하면 조인을 못하니 다른 방식으로 해야함
- 반정규화 데이터베이스를 가져다 놓던가 아니면 따로따로 가져오던가
API gateway
- MSA 아키텍쳐에서 많이 언급되는 컴포넌트
- 프록시 서버처럼 api 앞에서 모든 api에 대한 end point를 통합하고, 몇가지 추가적인 기능을 제공
- SOA의 ESB 경량화 버전
기능
1. Endpoint 통합, 토폴로지 정리
- MSA는 각 서비스가 다른 서버에 분리 배포되므로 API의 endpoint. 즉, 서버의 URL이 각각 다름
- 사용자 경험 관점에서도 사용하기가 불편해짐
- MSA는 서비스를 잘게 쪼개기때문에 서버의 URL이 다 달라질 것
- 향후 토폴로지가 매우 복잡해지고 거미줄 모양의 서비스 컴포넌트간의 호출 구조는 향후 관리의 문제를 일으킬 수 있다
- API gateway를 사용해 서비스 버스와 같은 역할을 하는 채널을 배치시켜 전체 토폴로지를 p2p가 아닌 hub & spoke 방식으로 변환