MSA(Microservices Architecture)에 대한 오래된 글

MSA에 대한 많은 글들이 있고, 저마다 해석의 기준이 다양한 것도 사실이다.

가장 간단 명료한 글들 중에 하나로 참조 할만한 싸이트...

"간단히 말해서, 마이크로서비스 아키텍처 스타일은 각각 자체 프로세스에서 실행되고 경량 메커니즘(종종 HTTP 리소스 API)과 통신하는 소규모 서비스 모음으로 단일 애플리케이션을 개발하는 접근 방식입니다. 이러한 서비스는 비즈니스 기능을 중심으로 구축되며 완전히 자동화된 배포 기계를 통해 독립적으로 배포할 수 있습니다. 다른 프로그래밍 언어로 작성되고 다른 데이터 저장 기술을 사용할 수 있는 이러한 서비스에 대한 최소한의 중앙 집중식 관리가 있습니다." - 아래 싸이트 참조 - 

출처: https://martinfowler.com/articles/microservices.html

"In short, 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. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies."

 

https://martinfowler.com/articles/microservices.html

Microservices

 

 

 

 

- 출처 : https://velog.io - 

 

ㅇ MSA의 장점

우선 MSA의 장점에 대해 알아보도록 하겠습니다. MSA는 서비스가 커지면서 생겼던 Monolithic Architecture의 문제점들을 어느정도 보완해 줄 수 있습니다.

• 배포(deployment) 관점
  * 서비스 별 개별 배포 가능 ( 배포 시 전체 서비스의 중단이 없음)
• 확장(scaling) 관점
  * 특정 서비스에 대한 확장성이 용이함.
• 장애(failure) 관점
  * 장애가 전체 서비스로 확장될 가능성이 적음

 

이외에도, 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발/운영 할 수 있다는 장점이 있습니다.

 

ㅇ MSA의 단점

Monolithic Architecture은 단순한 아키텍쳐인데 비해 MSA는 보다 복잡한 아키텍쳐로, 전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어날 수 있습니다.

• 성능 - 서비스 간 호출 시 API를 사용하기 때문에, 통신 비용이나, Latency가 그만큼 늘어나게 됩니다.
• 테스트 / 트랜잭션 - 서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원을 필요로 합니다.
• 데이터 관리 - 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어렵습니다.

 

https://velog.io/@tedigom/MSA-제대로-이해하기-1-MSA의-기본-개념-3sk28yrv0e

MSA 제대로 이해하기 -(1) MSA의 기본 개념