MSA (Micro Service Architecture)

Monolithic Architecture : 전체의 서비스를 하나의 구조로 구성한 아키텍처, 애플리케이션의 모든 구성 요소가 한 프로젝트에 통합되어 있는 형태.

Monolithic  Architecture

장점

• 개발 초기에 단순한 아키텍처 구조로 인해 개발에 용이하다.
• 어떤 서비스든지 개발되어 있는 환경이 같아서 복잡하지 않다.
• 배포가 간단하다.
• 확장성이 쉽다. 로드밸런스를 이용하여 로드 부하를 나눠 가지는 방식으로 진행한다.
• 쉽게 고가용성 서버 환경을 만들 수 있다.
• End-to-End 테스트가 용이하다.

단점

• 프로젝트의 규모가 커짐에 따라 애플리케이션 구동 시간이 늘어나고 빌드 및 배포 시간이 길어진다.
• 서비스, 프로젝트가 커질수록 많은 양의 코드가 몰려 있어서 개발자가 모든 코드를 이해하기 힘들며, 유지 보수가 어렵다.
• 일부분의 오류가 전체에 영향을 미친다. 즉, 부분의 장애가 전체 서비스의 장애로 이어지는 경우가 발생하게된다.
• 전체 애플리케이션 확장은 쉽지만, 부하 분산을 위해 각 컴포넌트를 독립적으로 확장하기 어렵다.
• 서비스를 부분적으로 scale-out하기가 어렵다.

 

Micro Service Architecture : 소프트웨어 개발 기법의 하나. MSA는 단일 애플리케이션을 작은 서비스 모음으로 개발하는 접근 방식. 각각은 자체 프로세스에서 실행이 되고 느슨한 연결(Loosely-coupled) 구조로 만들어 HTTP 리소스인 REST와 같은 경량 메커니즘과 통신. 한마디로 "하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처". 서비스나 프로젝트가 크고, 복잡하고, 장기적으로 운영될 수록, MSA의 장점이 더욱 드러난다.

Micro Service Architecture

장점

• 배포 관점
  • 서비스 별 개별 배포가 가능. 
  • 독립 배포가 가능하므로 개발자의 자율성이 증가. 
• 확장 관점
  • 특정 서비스에 대한 확장성이 용이.
  • 클라우드 사용에 적합.
• 장애 관점
  • 장애가 전체 서비스로 확장될 가능성이 적다.
  • 부분적 장애에 대한 격리가 수월.
• 코드 / 유지 보수 관점
  • 팀 별로 프로젝트가 분리되어 있으므로 코드의 이해도가 증가하고, 그에 따라 유지 보수하기 쉽다.

단점

• 성능 관점
  • 서비스 간 호출 시 API를 사용하기 때문에 통신 비용 및 지연 시간이 증가.
• 데이터 관리 관점
  • 데이터가 여러 서비스에 걸쳐서 분산되므로 한 번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어렵다.
• 테스트 / 트랜잭션 관점
  • 단위 테스트는 쉽지만, 통합 테스트 및 End-to-End 테스트 단위로 들어가면 여러 서비스의 API를 검증해야 하므로 시간과 비용이 많이 든다.
  • 각 서비스 별로 데이터베이스가 있으므로 트랜잭션을 구현하기 까다롭다.
• 아키텍처가 다소 복잡하므로 개발 및 관리가 어렵고, 비용이 많이 든다.

 

 

 

참조

https://www.samsungsds.com/kr/insights/msa_architecture_edm.html

https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-1-MSA%EC%9D%98-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90-3sk28yrv0e

https://steady-coding.tistory.com/595