마이크로 서비스란 (MSA) - 모놀리식 아키텍처, API Gateway vs ESB

요즘 출퇴근하면서 요런 책을 읽고 있다.

모놀리식 아키텍처

기존의 웹 기반 애플리케이션
서비스 간 호출 = Call by Reference
• UI, 비즈니스로직, DB액세스로직, ... 모두가 하나의 애플리케이션 산출물로 패키징, 배포됨
• 각 팀의 변경이 있을 때마다 애플리케이션 전체를 빌드, 테스트, 배포해야함
• 애플리케이션 규모가 커질 수록 각 팀의 의사소통, 조정비용이 증가함

마이크로서비스

서비스 간 호출 = API
• 애플리케이션을 제한된 책임을 담당하는 컴포넌트로 분해 (전통적 복잡성 문제 해결)
• 느슨히 결합된 작은 분산 서비스
• 각 팀이 코드/ 인프라스트럭쳐 (앱서버, DB)를 독립적으로 가짐
• 팀 단위로 빌드, 테스트, 배포 가능 (상호독립적)
• 확장성, 회복성 향상
• http, json 같은 경량 프로토콜 사용 = 기술 중립적 = 다양한 언어, 기술 사용 가능

MSA : 마이크로 서비스 아키텍처

- SOA 사상에 근간을 둠
- 컴포넌트를 서비스로 정의 (구현)
- REST API 같은 표준인터페이스로 기능을 외부에 제공
- 서비스경계 = 도메인경계
- 서비스 : 독립적인 war파일로 개발, 독립된 톰캣 인스턴스에 배치
- 톰캣 인스턴스 : 횡적으로 스케일가능 (인스턴스 더함), 서비스 간 로드 분산시킴 (앞단에 로드밸런서 배치)
UX(Front-end) - 로드밸런서 - 톰캣(war)

• SOA(서비스 지향 아키텍처) : 엔터프라이즈 시스템 중심으로 고안됨
프로젝트 실패 원인 > ESB (Enterprise Service Bus)
: 메시지를 내부적으로 xml로 변환해서 처리함(EAI 통합기능 처리를 위해...) > 파싱에 대한 오버헤드 발생
> 대안= API Gateway = EAI기능 제거, API처리 기능에만 집중

•  API Gateway
- MSA의 주요 컴포넌트 (미들웨어) = SOA의 ESB 경량화 버전
1) 모든 API의 엔드포인트 통합 (like Proxy) 기능
Hub & Spoke 방식으로 서비스 간 호출 단순화 가능
(MSA는 API 엔드포인트=서버 URL이 각기 다름=사용자관점 불편해짐 >>> 통합필요)
2) 오케스트레이션 (like Mashup) 기능
여러 서비스를 묶어 하나의 서비스로 만듬 (넷플릭스)
3) 공통 기능 처리 기능
API 인증/로깅 같은 공통 기능 담당 > API는 비즈니스 로직에만 집중하도록 함
4) 중재 기능
xml, 네이티브 메시지포맷 -> json 상호변환
프로토콜 변환
서비스 간 메시지 라우팅

• MSA의 단점
서비스 호출(API통신)시 json/xml -> 프로그래밍 데이터 모델 (ex: java객체) 변환하는 오버헤드 발생
메모리 사용량 증가 (독립 서비스 독립 서버 분할 배치)
운영관점 대상 시스템, 필요 기술 증가
서비스간 트랜잭션처리 (모노리틱은 롤백) 구현필요 (복잡)



Reference
스프링 마이크로서비스 코딩 공작소 (존 카넬)

조대협의 서버 사이드 : 대용량 아키텍처와 성능 튜닝 (조대협)