Overview
스프링 프레임워크를 주력으로 공부하고 개발을 하며 여러 프로젝트를 해보면서 단순히 백엔드에서 모놀리식 아키텍처로 개발하는 것을 넘어서서 여러 디자인패턴과 아키텍쳐에 많은 관심을 가지게 되었다.
많은 회사에서 기존의 모놀리식 아키텍처 시스템을 마이크로서비스 아키텍처로 전환하고 있다. 왜 많은 회사에서 마이크로서비스 아키텍처로 기존의 모놀리식 아키텍처 시스템을 전환하고 있는지, 많은 신규 프로젝트가 MSA로 이루어지고 있는지,
MSA가 무엇이기에 MSA MSA 하는 것인지, MSA하면 나오는 필수개념인 DDD(도메인 주도 설계)에 대해서도 차근차근 알아보고자 한다.
(요즘 취업시장에서도 우대사항에 MSA가 많이 보인다.)
모놀리식 아키텍쳐와 마이크로서비스 아키텍쳐
모놀리식 아키텍처는 마이크로서비스 아키텍처를 설명할 때 많이 비교 등장하는 아키텍처이다.
모놀리식은 하나의 애플리케이션에 모든 비즈니스 요소를 구현해 전체적인 서비스를 구현하는 방식이라면 MSA는 분리될 수 있는 비즈니스 요소는 마이크로서비스 단위로 DB까지 분리한 후 이들이 모여 전체적인 서비스를 구현하는 방식이다.
왜 MSA인가
우리가 학부생 때 흔히 해오던 프로젝트 개발 방식을 모놀리식이라고 보면 된다.
그림과 같이 모놀리식은 모든 서비스가 하나의 애플리케이션에 구성되며 도메인간 강한 결합도를 가진다는 것을 알 수 있다. 마이크로서비스 아키텍처는 도메인에 따라 물리적으로 분리되며 각각의 마이크로서비스간 약한 결합도를 가진다.
기존의 모놀리식 아키텍처는 비즈니스가 복잡해지면 복잡해질수록 도메인간 강결합에 의해 여러 문제점이 발생하였고, 비즈니스가 복잡해질수록 모놀리식에 비해 훨씬 유연하게 대처 가능한 MSA가 각광받게 되었다.
모놀리식의 단점
1. 개발 유연성의 한계
모놀리식의 경우 모든 서비스가 하나의 애플리케이션에 구성되기 때문에 여러 개발 유연성 부분에서 한계점을 지닌다.
먼저 개발 언어에 종속적이다.
만약 시작을 자바로 했으면 모든 서비스를 자바로 구성해야한다. 특정 기능 구현에 강점인 경우(ex - 소켓통신, 머신러닝) 해당 언어를 사용하기가 힘들다. MSA는 이를 해결해준다.
의존성끼리도 강한 결합도를 가진다.
모놀리식 시스템의 경우 모든 서비스가 하나에 구현되어 아주 강한 결합도를 가지기에 기능 구현이 되어있는 의존성 버전끼리도 강한 결합도를 가진다.
모놀리식의 경우 서비스간에도 강한 결합도를 가지는데 의존성에도 강한 결합도를 가지게 되는 것이다. 그로 인해 옛날 버전의 의존성을 그대로 활용해야하는 문제점이 있고 의존성 버전을 바꾸기가 쉽지 않아 의도대로 기능 구현이 힘들 수 있다.
MSA는 마이크로서비스 별로 따로 개발을 하고 협업이 편하다. 새로운 기술이 나오게 된다면 서비스 별로 구현이 가능하다.
개발자는 배포에 많은 부담을 느낀다.
모든 서비스가 하나의 애플리케이션에 구성되어 있다. 하나의 기능이 추가되거나 버그 수정 등이 이루어질 경우 모놀리식 시스템이기에 전체적인 기능에 대한 테스트와 빌드, 그리고 배포가 이루어져야 한다. 얼마나 부담스러운가, 간단한 수정조차도 전체적인 테스트와 빌드, 배포가 이루어져야 한다.
마이크로서비스 아키텍처는 마이크로서비스 단위로 테스트, 배포가 이루어지므로 모놀리식에 비해 훨씬 부담이 덜하다.
2. 장애 전파
모놀리식은 하나의 거대한 시스템이고 강한 결합도를 가지기 때문에 특정 서비스에서 장애가 발생하면 그 장애는 다른 서비스로 전파된다. 상품 구매 기능에 장애가 발생하면 상품 조회도 안되는 것이다.
MSA는 모든 서비스가 약한 결합도를 가져 특정 마이크로서비스에서 장애가 발생할 경우 장애나는 서비스를 격리시켜 다른 마이크로서비스에는 영향을 덜 주고 빠른 복구가 가능하다.
3. 리소스 낭비
모놀리식 시스템의 경우 모든 요소가 하나의 모놀리식 시스템에 구현되어 있으므로 모놀리식 단위로 스케일링이 이루어져야 한다. 즉 스케일 아웃이 힘들다.
모놀리식 시스템을 구성하는 여러 요소(상품구매, 상품조회 등) 중 특정 요소만이 엄청 인기가 많으면 어떨까, 해당 요소만 어떻게 리소스를 배분할 수 없다. 스케일링을 하고자 하더라도 전체 모놀리식 시스템 단위로 스케일링이 이루어져야 한다.
MSA는 각 요소가 분리되어있어 인기있는 마이크로서비스만 스케일링을 더 하고 리소스를 더 부여하는 등 리소스를 효율적으로 사용할 수 있다.
Only 마이크로서비스 아키텍쳐인가
마이크로서비스 아키텍쳐가 무엇이고 그 장점에 대해 알아보았고 많은 기업에서 MSA를 도입, 전환하고 있음을 알게됐다. 그렇다고 모든 프로젝트에서 MSA가 정답일까, 그것은 아니다!
Don't even consider microservies unless you have a system that's too complex to manage as a monolith. - MARTIN FOWLER
마틴 파울러는 모놀리식 아키텍처의 단점이 들어날 정도로 시스템이 복잡하지 않다면 MSA를 고려하지 말라고 하고 있다.
시스템의 복잡성이 높아야 MSA가 모놀리식에 비해 생산성이 높아지며 무조건 MSA가 정답이 아니다.
마이크로서비스 아키텍처의 단점
모놀로식에 비해서 마이크로서비스 아키텍처의 단점도 있다. 주로 모놀로식의 장점이었던 점이 MSA의 단점이라고 보면 된다.
1. 데이터 관리의 어려움
모놀리식은 단일 트랜잭션으로 처리하면 되지만 MSA는 데이터베이스가 분리되어 있기 때문에 각각의 데이터베이스에서의 트랜잭션을 처리해주어야 한다. 또한 데이터들이 도메인 별로 분리되어 있어 데이터 정합성 관리도 어려워진다.
2. 로그 추적의 어려움
마이크로서비스가 많아지면 많아질수록 로그 추적에서 어려움을 느끼고 마이크로서비스 간 통신이 이루어지기 때문에 이를 추적하는 것에도 점점 어려워진다.
3. 비용 증가
마이크로서비스 간 통신이 이루어지기 때문에 관련 네트워크 비용 및 지연 시간이 증가한다.
마이크로서비스 분리 기준
마이크로서비스 아키텍처가 무엇이고 그 장단점에 대해 알아보았다.
그럼 마이크로서비스는 무엇을 기준으로 분리할까?
비즈니스 능력에 근거한 도출
마이크로서비스를 식별하는 가장 쉬운 방법은 경험적인 원칙을 적용하는 것이다.
크리스 리처드슨은 비즈니스 능력에 따라 서비스를 식별할 수 있다고 말한다.
각 도메인에서는 조직, 부서 체계가 이미 정의되어 있다. 이러한 부서는 업무 처리에서의 응집성을 가지고 있고 타 부서와의 의존도는 낮을 것이다. (주문, 배송, 상품, 결제 부서)
이처럼 비즈니스 부서가 가진 역할, 처리 능력을 체계적으로 분해하는 업무 기능 분해를 통해 마이크로서비스를 도출해낼 수 있다.
마이크로서비스를 도출할 때 서비스가 소유권을 가진 데이터를 독립적으로 식별하는 것이 중요하나 비즈니스 능력에 근거한 도출방법은 서비스가 소유해야할 데이터 식별에 적합하지 않다.
DDD의 바운디드 컨텍스트 기반 도출
DDD의 전략적 설계를 통해 바운디드 컨텍스트를 기반으로 마이크로서비스를 도출해낼 수 있다.
도메인은 여러 서브 도메인으로 구성될 수 있다. 이러한 하위 도메인들은 별도의 도메인 모델로 정의되며 각 도메인 모델은 해당 도메인에서만 용어가 통용되는 유비쿼터스 언어가 정의된다.
바운디드 컨텍스트란 이러한 도메인들 간의 경계를 의미한다. 자세한 내용은 다음 시간에 알아보장
DDD(도메인 주도 설계) 는 MSA 라는 개념이 등장하기 이전부터 존재하던 디자인 패턴으로 각광받지 못하다가 마이크로서비스를 도출하는 과정에서 DDD의 개념이 많은 도움이 된다는 것이 발견되고 최근 각광받고 있다고 한다. DDD에 대해서는 차근차근 알아보고자 한다. (넘모 어려운 개념..)
Polyglot Persistence
마이크로서비스의 특징 중 하나는 마이크로서비스 별로 해당 서비스에 적합한 데이터베이스를 사용한다는 것이다. 이를 지칭하는 용어가 Polyglot Persistence이다.
Polyglot Persistence 란 다양한 데이터 저장 요구 사항에 대해 여러 데이터 저장 기술을 사용하는 것을 나타내는 용어이다.
서비스 별로 적합한 데이터베이스를 선택하여 NoSQL을 사용할 수도, SQL을 사용할 수도 있다.
각 마이크로서비스는 각자의 DB를 가지고 있고 다른 서비스의 DB 에 접근할 수 없다. 제공된 API 를 통해서만 접근이 가능하여 데이터를 캡슐화하고 결합도를 낮출 수 있다.
쿠버네티스 짱짱
마이크로서비스 아키텍처에 대해서 알아보았다. MSA하면 무엇이 떠오르는가, 쿠버네티스가 떠오른다. MSA에서 컨테이너 기술은 거의 필수적이라고 할 수 있지만 꼭 쿠버네티스를 써야만 MSA라고 할 수는 없다.
ECS, docker swarm 등 다양한 MSA를 배포, 관리하는 방법이 존재한다.
그럼에도 왜 쿠버네티스인가, 쿠버네티스는 GOD 구글에서 만든 컨테이너 오케스트레이션 도구로 인프라 환경을 추상화해 인프라 관리를 매우 쉽게 해준다.
수많은 마이크로서비스들을 운영하고 배포하고 모니터링 해주며 관리해야하는데 쿠버네티스는 이를 상대적으로 쉽게 해준다.
또한 많은 기업에서의 활용사례를 찾아볼 수 있으며 많은 MSA를 배포할 때 쿠버네티스를 사용한 성공 사례들이 존재해 MSA 서비스를 배포할 때 쿠버네티스가 각광받게 되었다.
마무리
오늘은 마이크로서비스 아키텍처에 대해서 알아보았다.
MSA는 모놀리식에 비해 설계하고 개발하는데 많은 시간과 비용이 소요된다. MSA의 어려움은 구현이 아니다, 바로 분석, 설계이다.
다음 시간에는 MSA를 분석 설계하는 과정에서 마이크로서비스를 도출해내는데 많이 사용되는 DDD(도메인 주도 개발)에 대해 알아보고자 한다.
참고자료
네이버 클라우드 플랫폼 유튜브 - 누구나 쉽게 이해하는 MSA 시리즈
도메인 주도 설계로 시작하는 마이크로서비스 개발
https://engineering-skcc.github.io/microservice%20modeling/microservice-%EB%8F%84%EC%B6%9C%EA%B8%B0%EB%B2%95/
