모놀리틱 아키텍처 (Monolithic Architecture)
모놀리틱 아키텍처는 비즈니스 로직, DB, UI 등을 하나의 패키지에 담아 빌드하고 배포하는 아키텍처다.
빠르고 쉽게 서비스를 구성할 수 있어 적은 비용으로 서비스 출시가 가능하다는 장점이 있다.
모놀리틱 아키텍처의 한계
코드가 많아지고 복잡해짐에 따라 모놀리틱의 아키텍처의 한계점이 드러난다.
- 부분장애가 전체 서비스의 장애로 확대될 수 있다.
- 소스 코드의 수정이 어렵다.
여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있기 때문에 서비스 수정에 대한 영향도 파악이 어렵다. - 한 프레임워크와 언어에 종속적이다.
- 부분적인 Scale-out이 어렵다.
과하게 사용되지 않는 다른 모든 서비스가 Scale-out되어야 하기때문에 Scale-out이 어렵다.
새로운 아키텍처의 필요성
- 코드 주소의 독립성
- 기능별 분산된 구조
- 기능별 최적화도니 기술 적용 가능
마이크로 서비스 아키텍처 (Microservices Architecture)
마이크로 서비스 아키텍처는 하나의 큰 애플리케이션을
여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처다.
애플리케이션을 핵심기능 별로 세분화하고 각 기능을 서비스라고 부르며,
독립적으로 구축하고 배포할 수 있다.
서비스는 각 별도의 프로세스에서 실행되며, HTTP 자원 API 같은 가벼운 매커니즘으로 통신한다.
💡 독립적인 배포, 다른 프로그래밍 언어나 다른 DB 사용 가능
MSA는 언제 적용할까?
MSA는 어느정도 트래픽이 나오고 큰 규모의 서비스에 사용해야 한다.
어느 정도 규모가 있어야 유지보수 비용이 줄어들기 때문에 모든 프로젝트에 MSA가 적합하다고 할 수 없다.
장점
- 부하가 집중되는 특정 서비스를 자원을 할당해 스케일 아웃할 수 있어 효율적인 자원 사용이 가능하다.
- 서비스의 변경이 다른 서비스에 영향을 미칠 가능성이 적다.
- 서비스 단위로 독립적인 배포가 가능하다.
- 시스템의 아키텍처가 개발 조직과 나아가 회사 조직 문화에 큰 영향을 미치는데,
- 특정 서비스의 개선과 수정 작업이 다른 서비스의 이해 당사자들과 독립적으로 진행될 수 있다.
- 의사결정이 빠르고, 독립적인 테스트의 구축이 용이해 품질이 증가한다.
단점
- 서비스 간의 통신에 대한 처리가 추가적으로 필요하다.
- 공유 자원 접근이 어렵다.
- 배포와 실행이 복잡하다.
MSA의 원칙
-
서비스 하나에 책임도 하나
하나의 단위 요소가 여러 개의 책임을 가지면 결국 다른 요소들과 높은 결합도를 형성하게 됩니다.
이러한 단일 책임 원칙이 서비스 차원에도 적용해야 한다는 것입니다.
-
마이크로서비스는 자율적
마이크로서비스는 자기 완비적으로 독립적으로 배포할 수 있으며,
자율적인 서비스로서 비즈니스의 범위와 실행에 대해 전적인 책임을 져야합니다.
마이크로서비스는 라이브러리 의존성을 포함한 모든 의존 관계와
웹서버나 컨테이너 또는 물리적인 차원을 추상화하는 가상머신을 모두 함께 갖고 있어야합니다.
대표적인 예로 Spring Boot의 flatJar 방식, 내장형 서버가 있습니다.
MSA에 필요한 기술
- REST
각 서비스들은 대체로 REST API와 같이 가벼운 프로토콜을 이용하여 통신한다.
- API Gateway
각 서비스들이 서로를 직접 호출하는 것이 아니라, API Gateway를 거쳐 통신하도록 한다.
API Gateway는 부하를 분산시키는 로드 밸런싱, 캐싱, API 미터링, 모니터링 등 다양한 기능을 수행한다.
- VM/Docker(K8s)
각 서비스들은 편리한 배포 및 확장을 위하여 가상 머신이나 Docker 컨테이너 상에서 동작한다.
위 기술은 다른 포스트에서 자세하게 알아보자.