마이크로서비스는 최근 많은 조직에서 고도의 애자일성, 전달 신속성, 확장성을 확보할 수 있는 중요한 수단으로 사용 중인 아키텍처 스타일입니다.
기존의 특정한 물리적인 서버에 서비스를 올리던 on-promise 서버기반의 monolithic architecture에서 이제는 클라우드 환경을 이용하여 서버를 구성하는 MicroService Architecture로 많은 서비스들이 전환되고 있고, 새로 출시되는 서비스들은 이렇게 진행되고 있습니다. 오늘은 기존의 Monolithic Architecture와 MSA(MicroService Architecture)의 변화와 차이에 대해서 알아보도록 하겠습니다.
Monolithic Architecture
모놀리식 아키텍처란 서비스의 아키텍처를 구성할 때 모든 서비스를 구성하는 비즈니스 로직, DB, UI 등은 논리적으로 모듈화 될 수 있지만 하나의 패키지에 담아 빌드하고 배포하는 방법입니다. 이러한 방식은 application의 언어나 프레임워크에 제한을 가지게 됩니다. Java라고 하면 일반적으로 Tomcat이나 Jetty의 웹서버에 War 파일로 배포되게 되듯 말입니다. 이러한 방식은 사실 일반적입니다.
형상은 아래와 같습니다.
이러한 형상은 우리가 일반적으로 개발하고 있던 방법이며, 당연하게 여기고 있던 방법입니다. 이러한 방법으로 설계한다면 빠르고 쉽게 서비스를 구성할 수 있어 적은 비용으로 서비스를 출시할 수 있으며 고객의 피드백을 빠르게 받아 볼 수 있는 장점이 있습니다.
모놀로식(Monolitnic) Architecture의 한계점
이러하 단순한 접근방법은 서비스의 규모가 커짐에 따라 한계점이 존재합니다. 지속적으로 개발하고 요구사항이 많아짐에 있어서 많은 코드들이 수정될 것이고 코드의 량도 많아질 것입니다. 이렇게 코드가 많아지고 복잡해짐에 따라 아래와 같은 문제점이 모놀리식 아키텍처에서는 일어납니다.
- 부분장애가 전체 서비스의 장애로 확되될 수 있습니다.
- 개발자의 잘못된 코드 배포 또는 갑작스런 트래픽 증가로 인해 성능에 문제가 있을 때, 서비스 전체의 장애로 확대될 수 있습니다. 만약 서비스 하나에서 메모리 누수 등이 일어난다면 전체적인 성능 저하로 이어집니다.
- 부분적인 Scale-out이 어렵습니다.
- 만약 주문이 너무 많이 발생해서 트래픽적으로 문제가 발생하여 Scale-out으로 문제를 해결해야할 때, 모놀로식 아키텍처에서는 과하게 사용되지 않는 다른 모든 서비스가 Scale-out되어야 하기때문에 Scale-out이 어렵습니다.
- 서비스의 변경이 어렵고, 수정시 장애의 영향도 파악이 힘들다.
- 여러 컴포넌트가 하나의 서비스에 강하게 경합되어 있기 때문에 수정에 대해서 영향도 파악이 힘듭니다. 이는 결국 새로운 기능의 개발, 수정에 대해서 개발기간의 지연을 야기합니다. 만약 공통으로 사용하는 컴포넌트가 있다면 상황은 더욱 악화됩니다.
- 배포 시간이 많이 걸립니다.
- 최근의 어플리케이션 개발 방법은 CI/CD를 통한 개발부터 배포까지 빠르게 반영하는것에 있습니다. 하지만 규모가 커짐에 따라 작은 변경에도 높은 수준의 테스트 비용이 발생하게 되기도 하며, 많은 사람이 하나의 시스템을 개발하며 배포하기 때문에 배포에 영향을 줄 수 밖에 없습니다.
- 한 Framework와 언어에 종속적입니다.
- 만약 우리가 Spring framework를 이용하여 프로젝트를 진행합니다. 그러던 중 blockchain 연동 모듈이 추가된다고 하겠습니다. blockchain 쪽은 web3를 이용한 node.js가 일반적이며 강세입니다. 하지만 우리에게는 java를 이용하여 해당 모듈을 작성할 수 밖에 없습니다. 왜냐하면 선정했던 framework가 spring이기 때문입니다.
MSA의 등장
마이크로서비스 아키텍처의 정의는 표준화된 유일한 정의는 없지만 마이크로서비스를 마틴파울러는 아래와 같이 정의했습니다.
마이크러서비스 아키텍처 스타일은 각자 별도의 프로세스에서 실행되며, HTTP 자원 API 같은 가벼운 매커니즘으로 통신하는 작은 서비스를 모아 하나의 어플리케이션을 만든다. 이런 작은 서비스들은 각자의 비즈니스 기능을 담당하고 완전 자동화된 절차에 따라 독립적으로 배포 가능하다. 작은 서비스를 관리하는 중앙 집중형 관리 방식은 최소한으로 사용되며, 각 서비스는 서로 다른 프로그래밍 언어나 서로 다른 데이터 저장 기술을 사용할 수도 있다.
많은 조직에서 모놀리식 아키텍처의 문제를 마이크로서비스 아키텍를 도입하여 해결해왔습니다. 단일 서비스로 구축하는게 아닌 작게 쪼개서 개발하는 방식으로 말입니다. 마이크로소프트 아키텍처를 적용하면 위의 아키텍처는 아래와 같이 변화합니다.
MSA의 원칙
마이크로서비스를 구현할때 지켜야할 원칙이 있습니다. 서비스 하나에 책임도 하나, 마이크로서비스는 자율적 이렇게 2가지 입니다.
서비스 하나에 책임도 하나
서비스 하나에 책임도 하나? 문구를 보자마자 SOLID 패턴의 S, Single Responsibility Principle(단일 책임 원칙)을 떠올리시는 분들도 있으실 것 같습니다. 이 원칙은 클래스든 함수간에 하나의 단위 요소는 반드시 하나의 책임만을 가져야 한다는 말입니다. 하나의 단위 요소가 여러 개의 책임을 가지면 결국 다른 요소들과 높은 결합도를 형성하게 됩니다. 이러한 단일 책임 원칙이 서비스 차원에도 적용해야 한다는 것입니다.
마이크로서비스는 자율적
마이크로서비스는 자기 완비적으로 독립적으로 배포할 수 있으며, 자율적인 서비스로서 비즈니스의 범위와 실행에 대해 전적인 책임을 져야합니다. 마이크로서비스는 라이브러리 의존성을 포함한 모든 의존 관곅와 엡서버나 컨테이너 또는 물리적인 차원을 추상화하는 가상머신을 모두 함께 갖고 있어야합니다. 대표적인 예로 Spring Boot의 flatJar 방식, 내장형 서버가 있습니다.
마무리
오늘은 이렇게 모놀리식 아키텍처란 무엇인지, 그리고 MSA란 무엇인지, 그리고 MSA의 원칙에 대해서 알아보았습니다. 다음시간에는 MSA의 특징과 장단점에 대해서 알아보도록 하겠습니다.
감사합니다.
참조
스프링 5.0 마이크로서비스 2/e
What are microservices?
Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous
microservices.io
행복을 찾기 위한 우리의 여정,
쿠팡의 MSA — Part 1
medium.com
Introduction to Microservices | NGINX
Microservices are currently getting a lot of attention. This blog post is the first in a 7-part series about designing, building, & deploying microservices.
www.nginx.com
'기타 > MSA' 카테고리의 다른 글
| Event Sourcing 맛보기 - 이론편 (0) | 2022.08.22 |
|---|---|
| CQRS(Command and Query Responsibility Segregation) 맛보기 - 실습편 (0) | 2022.06.25 |
| CQRS(Command and Query Responsibility Segregation) 맛보기 - 이론편 (1) | 2022.06.16 |
| [MSA] MSA의 특징과 장단점 (0) | 2020.01.02 |
| [MSA] 12요소 어플리케이션; 클라우드 네이티브 어플리케이션 (0) | 2019.12.15 |
댓글