#1. 오늘의 학습 키워드

개발 아키텍처 패턴 중 MSA에 대해

저번 시간은 모놀리식 아키텍처에 대해 알아봤다
- 다시 정리하면 모놀리식 아키텍처는 초기에는 개발 편의성이 높고, 빠른 구축이 가능하지만,
- 어플리케이션의 복잡도가 높아질 수록 모놀리식 아키텍처는 부적합하다.
- 그러면 이런 문제 점을 해결해주는 패턴은 무엇일까
  - MSA

#2. 공부한 내용

- 어플리케이션을 다수의 서비스로 분리하여 개발하는 구조

높은 개발 생산성
- 각 서비스 단위로 개발 / 유지보수 되기 때문에, 고객의 요청사항에 대해 해당 기능을 담는 서비스만 고쳐서 배포하면 된다
- 또한 빌드도 기존 모놀리식 아키텍처처럼 전체 코드 빌드가 아닌, 해당 서비스만 빌드하기 때문에, 개발 과정에서의 빌드로 인하여 소모되는 시간이 짧아진다
- 즉 개발 → 빌드 → 수정 → 배포의 주기가 짧아진다
높은 확장성
- 만약 특정 서비스에만 트래픽이 몰린다면, 해당 서비스만 확장 (scale out) 해도 된다.
- 해당 서비스는 당연히 전체 서비스보다 코드베이스가 작기 때문에, 모놀리식 아키텍처에 비해 확장 비용이 저렴하다
Polyglot 구조 지원
- 기존에는 전체 구조가 단일 환경, 언어, 기술이 강제 되었지만,
- MSA 에서는 기능 별로 가장 적합한 언어, 기술들을 선택하여 적용할 수 있다.
  - 언어, 프레임워크, 라이브러리, 방법론 포함
- 따라서 새로운 기술들도 쉽게 적용해볼 수 있다
  - 이는 빠르게 변하는 개발 트랜드에서 기술 부채 탕감 및 기술 혁신을 할 수 있는 좋은 조건이다.
리팩토링 비용
- 각 서비스를 다른 언어 혹은 프레임워크로 바꾸고 싶을 때, 모놀리식 구조보다 소요되는 시간은 훨씬 짧다.
- polyglot 구조가 지원되는 장점과 연관이 있다.

성능 측면
- 우선 컴퓨팅 자원의 사용이 모놀리식의 비해 비효율적이고
- 네트워크로 서비스간 데이터를 주고 받기에 이를 위한 추가적인 오버헤드가 발생한다.
- 또한 메모리에서 JVM, 톰캣 등 중복적인 자원 사용이 발생한다.
- 따라서 성능 자체가 같은 조건의 모놀리식 구조보다 낮을 수 있다.
유지 보수 측면
- 모니터링의 대상이 서비스의 수만큼 늘어난다.
- 테스트의 난이도가 증가한다.
- 서비스 별 데이터 소스가 다를 경우 디비 트랜잭션 처리가 어렵다.
  - 특히 분산 데이터베이스 환경 자체에서 트랜잭션 처리가 어렵다.

MSA 는 기존 모놀리식 아키텍처가 갖는 많은 단점을 극복하는 우수한 아키텍처다
- 특히 빌드/배포 시간, 확장(scale out), 버그 파악 등 이슈에서 MSA 는 모놀리식 아키텍처보다 유연하게 대처할 수 있다.
개인적으론 애자일 방법론을 적용하여 개발할 때 적합한 개발 구조로 느껴졌다.
- 현재 IT 업계에서 비즈니스 환경이 급변하고, 경쟁이 심하기에,
- 이를 빠르고 유연한 대응을 하지 않은 경우 성장이 어려울 수 있다.
그럼에도 불구하고 MSA 구조를 채택할 때는 서비스간 통신과 데이터 일관성(트랜잭션) 에 각별한 주의를 하지 않으면, 오히려 안정적이지 못한 서비스를 제공하게 될 수 있다.
- 그렇기에 API 게이트웨이나 이벤트 기반 통신, 그리고 멀티 트랜잭션 등 이를 대응하기 위한 기술을 도입해야 한다.

728x90