Micro Service란?

MSA(Micro Service Architecture)는 거대한 구조(Monolithic)로 되어있는 Service를 여러 소규모의 Service로 나누는 구조 및 방법이라고 생각한다.

먼저, 대조되는 아키텍처인 Monolithic의 특징을 보자.

가장 접근하기 쉬운 아키텍처로 소스 전체를 하나의 WAR파일로 구성하여 배포하는 전통적인 개발 방식이다.

• 모두 동일한 개발 환경 및 툴을 사용
• 개발환경 구성 간단
• 성능의 제약이 덜하다(각 기능을 함수로 호출)
• 트랜잭션 처리 간단
• 작은 규모의 어플리케이션에 적합

여러 장점을 가지고 있지만 유지보수를 하면서 혹은 새로운 기능의 추가로 어플리케이션은 점점 거대하지기 시작한다.

이벤트와 포인트 기능이 추가되었다.
하나의 서비스에서 너무 많은 기능을 가지게 되었다. 이렇게 됨으로써 나타나는 현상으로

• 빌드/배포가 오래 걸린다.
• 주문과 관련된 기능을 유지보수하는데 전체를 내리고 올려야한다.
• 이벤트 때문에 접속량이 폭주해 scale-out, sacle-up 등 확장을 해야하는데 이벤트 부분만 선택적으로 확장할 수 없다.
• 부분적인 장애가 전체의 장애로 이어진다.(포인트에서 장애가 났는데 전체 서비스가 다운되는 현상)

이러한 불편한 사항을 가만히 둘 수 없던 개발자들은 다른 MSA로 어플리케이션을 구성하기 시작한다…!
없던 개념은 아니고 SOA라는 개념이 전에 있었지만 완전한 독립이 아니었기에 MSA가 나오게 되었다고 한다.

위 그림과 같이 프레젠테이션 계층, 비즈니스 계층, DB를 하나의 서비스로 묶었다. 이렇게 묶음으로써 회원, 상품, 주문의 서비스가 생긴다. 이렇게 됨으로써 위의 단점들을 해결할 수 있다.

• 빌드/배포 독립적으로 가능하여 빠르다.
• 부분적인 장애는 각 서비스에서 해결하고 배포
• 트래픽에 대비해서 선택적 확장 가능
• 포인트 서비스의 장애는 다른 서비스에 영향을 끼치지 않는다.(포인트 서비스만 사용못하고 다른 서비스는 사용 가능)
• 서비스별 독립적으로 개발 가능(DB, Framework, 언어 등을 다르게 하여 구성할 수 있다, 폴리그랏)

아키텍처를 바꿈으로써 이렇게 많은 장점들이 생긴다.
그러나, 서비스를 나눔으로써 단점 또한 생긴다.

• 설계가 복잡하다.(서비스를 어떻게 나누고 어떤 식으로 통신, 트랜잭션 처리할 것인지 등)
• 서비스 간 통신을 해야하고(API, Message Stream 등) 그로 인해 latency가 발생함
• 트랜잭션 처리가 쉽지않다.(분산 트랜잭션으로 진행하고 Event Driven 및 Saga Pattern 등 적용해야하는 것이 많음)
• 러닝커브가 있다.(Event Driven, Feign, Eureka, API Gateway 등)
• 서비스가 나눠짐으로써 빌드 배포 횟수가 늘어나고 CI/CD가 필수적이게 된다.

참고로,
서비스를 나누는 기준은

1. 도메인 기준(비즈니스적으로 잘 알아야한다)
2. DB 기준
3. 나눠보고 진행하면서 경계를 깨닫고 고쳐나가기
   등이 있는 것 같다.

끝으로

MSA가 많은 장점이 있지만 그렇다고 무작정 MSA를 쓰는 것은 아니다. 작은 규모면 오히려 모놀리틱이 개발하기 쉽고 운영하기 쉬울 것이다. 또 비즈니스적으로 MSA가 맞지 않을 수도 있다. 러닝 커브 또한 높다. 도메인에 대한 이해가 바탕이 되고 목적이나 상황에 맞게 아키텍처를 선택해야 한다는게 모두의 공통 의견이다.

---

http://clipsoft.co.kr/wp/blog/마이크로서비스-아키텍처msa-개념/
https://www.popit.kr/마이크로-서비스msa를-어떻게-나눌까-ii/
https://velog.io/@tedigom/MSA-제대로-이해하기-1-MSA의-기본-개념-3sk28yrv0e
https://medium.com/dtevangelist/event-driven-microservice-란-54b4eaf7cc4a
https://www.redhat.com/ko/topics/microservices/what-are-microservices