MSA(1) - MSA란? (MSA Overview)

1. MSA 란?

"The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery."

small services(작은 서비스)
each running in its own process(스스로 실행 가능)
independently deployable(독립적 배포 가능)

-> 작고, 독립적으로 배포가능한 기능을 마이크로 서비스로 나누어, 독립적인 배포/ 다른 기술 스택을 사용 가능

 

2. 기존 Legacy(Monolithic)의 문제점

 

1. 조금만 수정해도 전체 배포 => (경험담) 배포&재시작만 10분
2. 서비스를 유연하게 가져가기 힘들다 (scale-out : 서버의 대수를 늘려 처리 능력 향상, scale-up은 서버 자체 용량등을 늘림)
3. 부분의 장애 -> 전체 장애
4. 서비스가 커질수록 영향도 파악, 시스템 구조 파악이 어려움

 

3. MSA의 장점 (독립+별도 배포)

1. 서비스별 배포 가능 (전체 서비스 중단 X )
2. 특정 서비스 확장 가능 (특히 클라우드 사용에 적합)
3. 장애 - 부분적 장애에 대한 격리가 수월
4. 신기술 적용에 유연
5. 서비스를 polyglot 하게 개발/운영 (=여러 언어를 사용)

사실상, 독립적으로 배포 할 수 있는게 가장 중요

• 독립 배포 가능 -> 전체 서비스 중단X없이 서비스별 배포 or 확장 가능
• 독립된 서비스라 장애가 격리되고, 신기술 적용하기 좋음

 

4. MSA의 단점

1. 성능 하락 - 서비스간 호출시 API를 사용해서 통신 비용 & Latency(지연)이 늘어남
2. 테스트 / 트랜잭션의 어려움 - 분리된 서비스이기 때문에 트랜잭션의 복잡도가 증가 & 많은 자원이 필요
3. 데이터 관리 - 데이터가 쪼개져서 여러 서비스에 분산되기 때문에, 한번에 조회하기 어렵고, 정합성 관리가 어려움

 

 

5. Monolithic -> MSA 이유

1. MS를 조합해서 다양한 플랫폼 서비스 가능(이전에는 주석 처리 or 새 프로젝트 생성)
2. Scale-out 이 힘들고, lon-transaction은 서비스 구조를 전체 개선해야함
3. 부분의 장애가 전체의 장애
4. 여러 컴포넌트가 하나의 서비스에 강하게 결합
5. 배포 오래걸림