MSA란
- 하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐이다.
- 어플리케이션을 특정 목적을 가진 작은 어플리케이션의 단위로 나누는 것이다.
- 어플리케이션끼리는 약한 결합도와 강한 응집도를 가져야 한다.
MSA 이전의 모습(Monolitic Architecture)
- 독립적이고 단순한 개별 서비스들로 전체의 서비스를 구성한다.
- 모듈별로 개발한 앱 어플리케이션을 하나의 결과물로 패키징하여 배포한다.
- 웹의 경우 모놀리틱 어플리케이션을 WAR파일로 빌드하여 배포하는 형태를 말한다.
Monolitic Architecture의 문제점
빌드/테스트 시간이 길어진다.
- 작은 수정에도 시스템 전체를 빌드해야 하며, 테스트 시간도 길어진다.(선택적 확장 어려움)
- 서비스 변화가 빨라질수록 배포 주기가 짧아지는 것이 부담된다.
- 코드의 크기가 커서 클라우드 환경에 적용하기 어렵다.
하나의 서비스가 모든 서비스에 영향을 준다.
- ex) 상품, 주문, 결제 서비스 중 하나라도 에러가 발생 시 어플리케이션의 다른 모든 서비스를 사용할 수 없다.
- 서버 이용 트래픽이 높아질수록 단일 어플리케이션의 부하가 커진다.
- 서버가 다운되면 모든 서비스가 마비된다.
MSA의 구성방식
각 서비스는 HTTP기반 API 등을 통해서 통신한다.
각 서비스는 독립적으로 동작하기 때문에 서로 다른 언어로 개발할 수 있다.(Polyglot Programming)
- 타 컴포넌트와 의존성이 없기 때문에 독립적인 배포를 한다.
- 컴포넌트의 부분적인 확장이 가능하다.
서비스 간 독립적인 DataBase를 사용한다.
- 검색에 특화된 DB, 트래픽에 강한 DB, 정확도가 높은 DB등 독립된 서비스에 독립된 DB로 데이터를 관리할 수 있다.
API Gateway를 사용한다.
- 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 한다.
MSA의 특징
Decoupled
- 서비스 간의 종속성 배제
Well Defined Interface
- 서비스 간의 통신을 위해 잘 정의된 API 필요
Independent
- 각 서비스 별로 독립적인 개발 및 운영 가능
Conway's Law
- 서비스의 구성 디자인은 그 서비스를 구현하는 조직의 모습에 기반한다.
- 서비스별로 팀을 나누고 기획, 설계, 계발, 운영이 팀별로 이루어져 의존성이 사라진다. 유연하고 지속적인 운영, 개발이 가능해진다.
