MSA 이전의 기술들
Monolithic Architecture
대부분의 엔터프라이즈급 응용프로그램은 다음과 유사한 계층구조를 가지게 된다.
Presentation: UI 같이 유저에게 보여지는 부분을 담당하는 계층Business Logic: 응용프로그램 내부 로직을 담당하는 계층Database Access: 데이터베이스에 접근하여 영속성 데이터를 관리하기위한 계층Application Integration: 다른 응용프로그램과의 통신을 위한 계층
이때 이러한 모든 계층을 하나의 서비스 또는 어플리케이션만을 사용하여 모든 기능을 하는 경우를 의미한다. (즉 Application Integration 계층이 없거나 작다. (Naver API 같은 타 API 와의 통신은 필요하므로))
이러한 모놀리식 구조는 개발초기에 한하여 개발, 테스트, 배포가 쉽고 서비스 구조가 비교적 단순하다는 장점이 있지만 아래와 같은 한계가 드러나게 된다.
- 유연하지 않은 구조
모놀리식 아키텍처는 기술스택으로부터 자유롭지 못하다. 예를들어서 서비스에 SpringBoot 프레임워크를 사용할 경우, 이후 추가되는 기능들 또한 SpringBoot 기반 어플리케이션에서 구현되야하므로, NodeJS, Ruby on Rails 같은 다른 기술스택을 사용할 수 없다.
- 신뢰성이 떨어지는 구조
모놀리식 아키텍처는 단일 서비스/어플리케이션이 모든 기능을 담당한다. 그러므로 한 기능에서 버그가 생길경우 어플리케이션 전체에 영향을 끼치게 된다.
예를들어서, 커머스 서비스의 쿠폰 기능에서 FatalError 가 나서 서버가 다운될 경우, 회원가입 뿐 아니라 회원가입/로그인, 상품구매 같은 다른기능 또한 이용할 수 없다
O(2^N) 뺨치는개발속도와 확장성 저하
서비스가 점점 커질수록 하나의 어플리케이션에서 담당하는 부하(지원하는 기능의 수)가 증가하고, 각 기능들이 비교적 밀접한 연관관계를 가지게 된다. 이로인해 확장성이 저하되고, 복잡한 내부구조로 인해 개발속도 또한 저하된다.
- 지속적 배포의 어려움
아주 약간의 수정사항을 적용하려 하여도 전체 서비스를 다시 배포하여야한다. 예를들어서 메인페이지의 로그인을 수행할 경우, CAPTCHA 를 도입하는 수정사항을 적용하려면 로그인 이외의 다른 모든 기능들 또한 다시배포하여야 한다.
Service Oriented Architecture
이러한 모놀리식의 단점을 해결하기위해 SOA (서비스 지향 아키텍처) 가 고안되었다.
SOA 는 기존 모놀리식 어플리케이션내의 기능들을 비즈니스적인 의미를 가지는 기능 단위 로 묶어서, 표준화된 호출 인터페이스 를 통해 서비스로 구현하고, 이 서비스들을 통해 어플리케이션을 구성하는 아키텍처이다.
이러한 SOA 는 모놀리식에 존재하던 기술적 복합도를 낮출 수 있을 뿐더러, 점점 확장되어가는 기능들을 독립적으로 다룰 수 있다는 장점이 있었다.
- 서비스
플랫폼에 종속되지 않는 표준 인터페이스를 통해 기능들을 모아놓은 SW컴포넌트
상품 주문 서비스, 회원가입 서비스 등이 이에 해당한다. - ESB
엔터프라이즈 서비스 버스 의 약자로, 서비스들 논리적 집합으로 묶는 미들웨어이다.
서비스에 대한 요청과 처리를 중계하여 느슨하게 연결되어있는 각 서비스들을 조립하여 로직을 실행한다. Application Intergration 에 대한 프록시 같은 역할
MSA 는 이러한 SOA에서의 서비스간 연결을 더욱 느슨하게 만들고, ESB 의 비대화를 해소시키기 위해 나온 아키텍처이다. 그렇다면 MSA 란 과연 무엇일까?
MSA 란
MSA 의 선두주자 Netflix 는 MSA 를 다음과 같이 정의하였다.
📌 loosely coupled service oriented architecture with bounded contexts→ Bounded Contexts 간의 느슨한 결합으로 이루어진 SOA
- SOA 는 전술한 서비스 지향 아키텍처 일것이다. 그런데 Boundded Contexts 는 무엇일까?
- Bounded Context : 각 도메인간의 경계 또는 한 도메인의 범위이다. 자세한 내용은 링크 참조
- 느슨한 결합 : 말그대로 결합이 느슨해야한다는 의미이다.
각 BoundedContext 에 따라 분류된 도메인들을, 서비스단위로 분할하는것을 말한다.
즉 MSA 는 도메인(관심사) 간의 느슨한 결합으로 이루어진 SOA 의 파생형 아키텍처 라는 의미이다.
이러한 MSA 방식의 아키텍처는 다음과 같은 장점을 가진다
- 배포의 용이함
아까 모놀리식에서 든 예시를 다시 사용해보자. 로그인시 CAPTCHA 를 도입할 경우, 로그인 또는 회원관리 서비스 만 재배포하면 된다. 그 이외의 쿠폰이나 상품주문 같은 서비스는 재배포를 하지 않아도 정상적으로 작동한다.
즉, 달리는 자동차를 바꾸지 않고, 자동차의 바퀴나 핸들만 교체하면 된다!
- 개별 Scale-out
MSA 는 각 기능별로 서비스를 분리한다. 따라서 부하가 많이 일어나는 기능을 담당하는 서비스에만 개별적으로 Scale-out을 통한 확장을 진행할 수 있다.
하지만 MSA 또한 장점만 있는것은 아니다. 서비스가 분산되어, 전체 서비스의 복잡성이 증가했을 뿐더러, 한 서버의 부하나 장애로 인한 트렌젝션이슈, 통합테스트의 어려움 등 여러가지 단점이 존재한다.
그러므로 MSA 는 언제나 좋은 아키텍처가아니다. 상황에 따라서는 모놀리식 아키텍처가 오히려 좋을 수도 있다. 그러니 무엇보다 중요한건 현재 상황에 맞는 아키텍처를 도입하는 것 이다.
