Monolithic Architecture

우선 MSA에 대해 알기 전 Monolithic Architecture를 이해하고 MSA에 대한 내용을 학습 하면 더욱 도움이 될것이다.
모노리틱 아키텍쳐는 이전에 사용하였던 아키텍쳐로, 모든 모듈이 한배에 타있다고 생각하면 된다.

이러한 모노리틱 아키텍쳐는 상호 데이터 참조가 용이하여 빨리 개발하기 위한 초기 아키텍처로 적합하다.

그러나 아래와 같은 단점이 존재한다.
1. 쉬운 상호연동은 상호의존성을 높힘
2. 선별적 확장이 용이하지 않다.
3. 하나의 컴포넌트를 수정하는 일은 많은 다른 컴포넌트의 수정을 동반하게 됨
4.코드량이 방대함
5.하나의 변경이 나머지의 모든 재배포를 유발함

아래는 아마존 회장을 한 제프베조스의 말을 인용했다.

제프 베조스의 의무사항
다음과 같은 그 어떠한 직접적 서비스간의 연동은 허용하지 않겠다: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network

즉, 다른 서비스의 데이터 저장소에 접근할 때는 직접적으로 연결하는 것이 아니라, 반드시 API를 통해서만 접근해야 한다는 것이다. 모노리틱 아키텍처는 이러한 제프 베조스의 의무사항을 충족하지 못하는 구조로, 서비스 간에 직접적인 데이터 접근이 빈번하게 발생할 수 있다.

이러한 단점들은 보기에 별거아닌것 처럼 느껴질 수 있지만, 개발 규모가 커지면 커질 수 록 복잡도가 기하급수적으로 증가할 수 있다.

MSA

이와 달리 MSA는 모든 기능을 각각의 배포 스택으로 분리 했다.

이러한 마이크로 서비스 아키텍쳐의 특징은 다음과 같다.
-서비스 지향 아키텍쳐
-요소들의 느슨한 결합
-통신 방법으로는

• HTTP/REST를 통해서만 상호 작용 (동기적 API 호출)
  
  -클라이언트-서버 REST API 는 내부구현을 숨길 수 있으면서 연동 (약한 결합)
  -빌드타임에서만 약결합을 제공함
  -->런타임에서 api가 바뀔시 오류가 발생함

  so, 비동기 메시징을 통한 약결합!

• 비동기식 스트리밍/메시징 (비동기적 QUE를 통한 통신)
  

  -상대의 수신을 기다리지 않는 비동기식 메시징
  -data stream topic이라는 곳에 하나의 서비스가 write할시 다른 서비스에서 필요할때 가져감 → non blocking 그러므로 런타임에서도 약결합을 제공해줌

MSA의 장점

1. 작은 코드량은 이해하기 쉽고, 오류를 찾기 쉬움
2. 수정된 서비스에 대한 국지적 단위 디플로이와 테스팅이 용이해진다.
   -> 부분을 수정을 할때 전체시스템을 배포할 필요가 없음
3. 장애격리가 좋아진다.
   -> 한서비스에 문제가 생겨도 다른서비스에 영향을 끼치지 않음
4. 여러가지 혼재된 기술 스택을 사용하기 쉽다.
   -> 각서비스 마다 다른 DB와 언어를 사용할 수 있어 유연함.
5. 개발환경을 구축하기 쉽고 빨리 기동된다.

MSA의 단점

1.개발도구들이 아직 최적화 되지않음
2.전체적인 테스트가 복잡해짐
-> 서비스가 늘어날 수록 테스트 케이스도 늘어나고 복잡해짐
3.devops 환경이 필수적(운영과 디플로이가복잡해져서)
-> 서비스를 배포하고 관리하는게 복잡해짐, 자동화 하려면 CI/CD와 같은 devops환경이 필요함
4.서비스간 연동을 통해서만 구현하는 비용의 상승 (네트워크 통신 비용의 상승)
5.분산트랜잭션(+데이터 일관성)을 어떻게 보장할것인가

결국, 소규모 프로젝트와 같이 빠르게 프로토타입을 만들어야 할 때는 모노리틱 아키텍처가 유리할 수 있으나, 서비스가 성장하고 복잡도가 증가함에 따라 MSA로 전환할 필요가 있다는 결론을 내렸다.