등장배경
1990~2000년 초 닷컴 버블 빔을 한번 처맞긴 했지만 끊임없이 성장 IT 업계와 시스템은 성장하고 있었습니다.
그런데 기존 시스템이 대규모로 성장하다 보니 유지 관리 및 확장이 어려워져 개발 주기가 길어지고 다운타임이 증가하는 등의 문제가 생깁니다. 그래서 개발자들은 기존 애플리케이션을 더 작고 독립적인 서비스들로 분해하는 아키텍쳐를 연구합니다.
제임스 루위스 (James Lewis)
마이크로 서비스를 정의
“How big should an application be?”
Most useful, is no bigger than my head.
애플리케이션은 얼마나 작아야 하는가?
내 머리보다 작아야 한다
→ 개발자가 애플리케이션에서 이해하지 못하는 부분이 없어야 한다
마틴 파울러 (Martin Fowler, 코딩왕)
개발자 필수 도서 리팩토링 저자 (나는 안읽어봄)
'마이크로'라는 논문에서 처음으로 MSA 개념을 정의
개념
Monolithic Architecture
하나의 애플리케이션에 모든 로직과 기능이 들어간 구조
하나의 기능을 업데이트시에도
전체를 빌드하고 배포해야함
특정 기능 라이브러리 업데이트 시
다른 기능에서 버전 오류 발생
서버 다운 시 모든 기능 마비
MSA: Micro Service Architecture
단일 애플리케이션을 여러 개의 작은 서비스로 분리하여 개발과 운영을 독립적으로 할 수 있게 만든 구조
API Gateway: 모든 API의 엔드포인트를 단일화 해주는 서버
인증 및 인가, 라우팅, 로드밸런싱, 서비스 오케스트레이션(공통 로직)
모놀리식 구조 또한 MSA가 아닌 것들을 일컫기 위해 만들어진 신조어
MSA의 장점
개발 용이성
수평 확장 용이성
수직 확장 (Scale-Up) : 서버의 성능 증가
수평 확장 (Scale-Out) : 동일한 서버의 개수 증가
수평 확장 용이성 - 클라우드 환경
사용량만큼 요금이 계산되는 클라우드 환경의 특성상 MSA가 매우 유리
MSA의 단점
개발 관점의 단점
1. 설계난이도가 높다.
- 고려해야 할 상호작용 요소가 많음
2. 데이터 지연 혹은 유실
- 왼쪽에 그려진 화살표 뿐만 아니라 사용자와 API 게이트웨이, 서비스와 서비스 내에서도 데이터를 주고받아야 하기 때문
3. 버그 발생 시 디버깅이 힘듦
- 예시) 결제쪽에서 문제가 터졌는데 사실은 회원관리쪽에서 준 데이터가 문제였다
운영 관점의 단점
MSA 도입 시점
마틴 파울러의 두가지 의견 번역
