Microservice Architecture
Maven module 개발 방식을 시스템 아키텩처에 대한 시선으로 설명하면 microservice architecture 이며 이에 대한 이해도를 높여보자.
Monolithic Architecture
Microservice Architecture를 알아보기 전에 현재 우리가 웹 어플리케이션을 만들 때 사용하는 아키텍쳐는 모놀리틱 아키텍처에 대해서 먼저 살펴 보자.
우리가 만드는 어플리케이션은 비즈니스 로직을 담당하는 Service를 가지고 있고 Database 또는 외부 시스템과 특정 프로토콜로 통신을 하게 된다.
또한 User Interface를 제공하기 위해 HTML을 렌더링하는 부분과 RESTful API를 제공하는 Controller를 가지고 있다.
이렇게 구성된 어플리케이션의 소스코드는 하나의 프로젝트로 구성되며 단일 패키지로 배포된다.
실제로 많은 서비스들이 이와 같은 구성으로 이루어지며 개발하기에도 편리하고 통합 테스트를 수행하기에도 쉽고 좋다.
또한 모든 코드가 하나의 묶음으로 있기 때문에 배포도 매우 간편하다.
Monolithic Architecture 의 단점
프로젝트에 투입되는 개발자가 많아질수록 서비스의 복잡도가 증가되면서 간단한 기능 하나를 추가하기 위해 많은 소스코드를 수정해야 하는 상황이 발생되고 그에 따른 통합테스트가 진행되어야 한다.
서비스 구조 자체가 너무 복잡하다는 문제를 가지게 되며 여러 어플리케이션들이 동일한 작업을 수행하는 소스코드를 가지게 되는 문제도 발생한다.
전체 시스템의 구조를 알지 못하여 재활용 가능한 모듈을 사용하지 못하고 중복 코드를 생산하게 되는 문제도 발생하게 된다.
기능/버그 수정에 대한 사이드이펙트가 커지는 경우도 있다.
개인적으로 가장 큰 단점은 아래 두가지라고 생각한다.
- 부분적 스케일 아웃의 어려움
- 프로그래밍 언어, Framework 변경이 거의 불가능에 가까울 정도로 어려움
만약 인증을 담당하는 auth service가 별도로 있다면 필요에 따라 성능과 안정성을 증가시킬 수 있는 새로운 framework로 변경하는 것을 고려해볼 수 있다.
하지만 하나로 묶여 있다면 그동안 개발된 방대한 양의 코드를 새로운 언어나 Framework로 전환하는 것은 시도조차 어렵다.
Microservice Architecture
Microservice Architecture는 하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만드는 것을 말한다.
어플리케이션을 각 기능별로 나누게 되면 자연스럽게 추상화가 가능해진다.
인증을 담당하는 auth service는 다른 서비스에서 구체적인 구현 내용을 모르더라도 약속된 인터페이스를 이용해 인증 과정을 수행할 수 있다.
사용자 정보를 담당하는 user service 또한 다른 서비스에서 약속된 인터페이스를 이용해 사용자 정보에 대한 추가/수정/삭제/조회 등을 수행할 수 있게 된다.
언제 필요할까?
모든 어플리케이션이 마이크로서비스 아키텍처로 구성될 필요는 없다.
앞으로 어떤 서비스와 컴포넌트가 필요하게 될 지 예측할 수 없는 상황에서 과도하게 시스템을 여러개의 서비스로 쪼갤 필요는 없다.
아래와 같은 상황에서 마이크로서비스 아키텍처가 필요하다고 본다.
배포에 한 시간 이상 소요된다.
단순한 기능 하나를 수정해도 전체 기능에 대한 QA가 필요하다.
단순한 버그 수정이 더 중대한 버그를 만들어내는 일이 생긴다.
현재의 어플리케이션을 기능별로 나눈다고 가정했을 때 많은 마이크로서비스가 가능하다.
많은 어플리케이션들이 중복된 기능을 가지고 있다. (ex. infos***, dec**, webre*** 등에서 사용자 2차 인증을 각각 관리한다 ==> 인증을 담당하는 서비스를 분리하여 한곳에하 하도록 한다. ex. sa****as)
장점
서비스가 개별/독립적으로 구성되기 때문에 변경이 용이하고 그 변경이 다른 서비스에 미치는 영향이 적다.
개별 배포가 가능하기 때문에 필요에 따라 여러번 배포가 가능하며 중복로직/코드를 줄일 수 있기 때문에 자원 낭비가 적다.
필요에 따라 특정 서비스에 대해서만 스케일아웃이 가능하다.
단점
서비스 간 통신에 대한 처리가 추가적으로 필요하다.
이는 응답속도에도 영향이 있다.
서로 분산되어 있는 서비스들에 대한 관리 포인트가 증가한다.
이는 배포 자동화를 필요로 하며 Pass(Platform as a service), Docker와 같은 컨테이너 기술을 이용하면 많은 부분 해소 될 수 있다.
API Gateway
Monolithic Architecture 는 아래와 같은 방식이며 특정 서비스 변경이 있을 경우 이 서비스를 포함하고 있는 모든 코드를 찾아서 수정해 줘야 한다.
user interface (ex. browser) -------------- Application ---------------- Database
Microservice 의 경우는 아래와 같은 구조를 갖게 된다.
user interface (ex. browser) -------------- user
-------------- auth
-------------- decide
------------- etc
그런데 이런 구조를 갖게 되면 front-end에서는 각각의 서비스별 호출을 해야 하고 모든 microservice 의 호스트정보와 end point (url) 정보를 알고 있어야 한다.
microservice 가 수십개 수백개가 된다면 이는 큰 문제가 된다.
(microservice 호스트정보가 변경되면 client가 가지고 있는 정보역시 수정되어야 하며 네트워크 지연속도가 선형적으로 증가하며 이에 따른 응답속도가 낮아지는 점 등)
또한 모든 microservice 가 웹 통신에 적합한 프로토콜로 통신하지 않는 경우도 있기 때문에 위와 같은 구조가 힘들 수 있다.
이런 문제를 해결하기 위해 API Gateway 를 사용할 수 있다
.
시스템 아키텍쳐를 내부로 숨기고 외부의 요청에 대한 응답만을 적합한 형태로 응답하는 것이다.
user interface (ex. browser) -------------- API Gateway -------------- user
-------------- auth
-------------- decide
-------------- etc
API Gateway는 필요시 여러 마이크로서비스의 응답을 취합하여 하나의 응답으로 client에 전달할 수 있다.
또한 API Gateway는 전체 시스템의 부하를 분산시키는 로드밸런서의 역할, 동일한 요청에 대한 불필요한 반복잡업을 줄일 수 있는 캐싱, 시스템상에 오고가는 요청과 응답에 대한 모니터링 역할도 수행할 수 있으며 위에서 언급한 문제들을
해결해 준다.
API Gateway의 단점은?
구현하고 관리해야 하는 요소가 하나 더 증가한다는 점
성능상의 병목지점이 될수 있다는점 (Gateway에서 병목현상 발생 시 전체 서비스 품질에 영향이 생김)
그래서 API Gateway를 구현할 때는 비동기적이고 Non-blocking I/O 처리가 가능하도록 구현하는 것이 필요하다.
비동기적이고 Non-blocking I/O. 라... 맞다. 바로 Reactive Programming 이다.
이전 포스팅 (Spring WebFlux) 이 MSA 를 준비하기 위한 것이었다는....