Microservice Architecture / Monolithic Architecture

<-> Monolithic Architecture

- 모든 서비스가 하나의 인스턴스에 탑재

- 하나의 컴퍼넌트에 문제 살생시 모든 서비스가 문제가 됨

- 공통 모듈의 경우, 수정시 영향도 파악 어려움

- 특정 서비스 부하 발생시 부분적인 확장이 어려워 전체 서비스에 대한 scale-up/scale-out 해야하는 단점

- 작은 변경에도 높은 수준의 테스트 비용 발생, 조직 성장에 따른 배포 대기시간 증가 또는 빅뱅형태의 배포가 필요

Microservice Architecture

+ 소프트웨어 개발 기법

+ 어플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(Service Oriented Architecture) 스타일의 일종

+ 각 컴퍼넌트는 서비스 형태로 구현, API를 통해 타 서비스와 통신

+ 각 서비스 독립적으로 배포. 인스턴스별 scale-up

+ API부터 DB까지 분리, 독립된 데이터베이스로 구성(물리적 독립 또는 스키마 분리)

- 다른 서비스의 데이터를 API를 통해서만 가져올 수 있어서 성능문제 발생 가능성이 더 큼

- 이기종간 DB 트랜잭션이 보장되지 않을 수 있음

- marshalling overhead

- 시나리오 테스트의 복잡도

- 서비스 수만큼 중복된 양의 메모리가 필요

- 하나의 트랜잭션으로 묶는것은 불가능

> 금융 / 제조와 같이 트랜잭션 보장이 중요한 산업군에는 부적합  --> B2C형 서비스에 적합

API Gateway

+ 마치 프록시처럼 api 앞에 모든 api에 대한 end point를 통합하고, 추가적인 기능도 제공하는 미들웨어

+ Orchestration : 여러개의 서비스를 묶어 새로운 서비스 생성가능

+ Cross cutting function handling : API에 대한 인증/로깅 과 같이 공통 기능을 서비스별 중복 개발할 필요가 없음