[스프링 마이크로서비스] Spring Boot로 마이크로서비스 구축 (아키텍처 편)

본 포스팅에서는 Spring Boot를 이용한 마이크로서비스 구축과정에 대해 알아보겠습니다.

---

기존 빅뱅 오픈을 목표로하는 사이트의 경우 모든 애플리케이션의 요구 사항과 설계를 프로젝트 초반에 정의할 것을 요구 (폭포수-Waterfall 개발 방법론)하여 프로젝트가 진행되는 과정에서 발생하는 새로운 요구 사항을 충족하거나 리팩토링할 여지나 개발 초기 단계에서 저지른 실수를 만회하기가 어렵다는 문제가 있습니다.

사실 프로젝트를 진행해 나가면서 새로운 비즈니스 요구 사항은 당연히 발생가능하며, 이해의 차이, 수정 등 끊임없는 변동이 일어나는 프로젝트 초 중반 단계에서 전통적인 워터풀 개발 방식은 다양한 문제를 발생시켜왔습니다.

강한 결합(Tightly Coupled)으로 인해 애플리케이션 컴포넌트를 조그만 수정해도 그 애플리케이션의 다른 부분을 깨뜨리거나 새로운 버그를 생산할 가능성이 높아집니다.

또한 기존 모놀리식 개발 방법은 애플리케이션 코드를 조그만 변경해도 이를 반영하기위한 많은 시간이 소요되며 비용이 듭니다.

---

● 마이크로서비스 아키텍처 특성

앞서 살펴봤던 내용과 같이 이를 위한 색다른 접근법이 등장하였습니다. 바로 마이크로서비스 기반 아키텍처(이하 MSA)입니다.

① loosely coupled : MSA를 설명할 때 항상 선두로 등장하는 용어입니다. 마이크로서비스 간에 중립적인 인터페이스를 통해 통신하며(HTTP, REST 등) 각 서비스는 독립적으로 수정, 변경, 배포가 가능한 결합이 느슨하다는 장점을 갖고 있습니다.

② abstraction은 마이크로서비스를 설명하는데 가장 적합한 단어라고 볼 수 있습니다. 서비스를 쪼개는 것은 단순히 애플리케이션만을 분산하는 것이 아닙니다. 애플리케이션과 데이터베이스, 미들웨어 때로는 OS까지 구분하여 이를 관리하게 됩니다. (실제 클라우드 환경에서 멀티 컨테이너를 사용할 수 있는 환경을 이용해 MSA는 급격히 성장하고 있습니다.) 이는 가벼워 진다 즉 복잡도를 요구하는 실력가 집단만 가능한 설계가 아니라는 것입니다. 데이터베이스의 모델링이 간단해지고, 애플리케이션의 인터페이스 설계가 쉬워진다는 것은 수많은 장점 중 하나입니다.

③ independent는 이러한 모든 마이크로서비스 집합을 별도로 개발하고, 컨파일하고, 배포하고, 분리하고, 테스트 할 수 있습니다. 바로 이러한 점 때문에 장애를 발생시킨 성능 이슈, 버그 등에 유연하게 대비할 수 있으며, 수많은 사람들이 외치지만 실행할 수 없었던 애자일 방법론을 실무에 손쉽게 적용할 수 있게 되었습니다. 바로 이러한 점 때문에 신규로 개발되는 기능을 손쉽게 반영할 수 있고 다운타임을 최소화 할 수 있으며, 수평확장에 용이한 PaaS 환경의 표준 아키텍처로 자리잡기 시작했습니다.

 

DevOps를 추구하는 MSA이지만 여전히 역할 중심의 구분이 필요합니다.

① 아키텍트 : 솔루션을 제공하기 위해 큰 그림을 바라보고 애플리케이션을 개별 마이크로서비스로 분해하는 방법과 마이크로서비스의 상호 작용 방법을 이해한다.

② 개발자 : 코드를 작성하고 마이크로서비스를 제공하기 위해 프로그래밍 언어와 해당 언어용 개발 프레임워크의 사용 방법을 자세히 이해한다.

③ 데브옵스 엔지니어 : 운영 환경 및 비운영 환경에서 서비스 배포와 관리 방법 정보를 제공한다. 모든 환경에서의 일관성과 반복성을 유지한다.

---

● 마이크로서비스를 구축하기 위한 아키텍처의 역할

마이크로서비스를 구축할 때 아키텍처는 다음과 같은 역할을 수행합니다.

① 비즈니스 문제의 분해

아키텍처는 비즈니스 문제를 각 활동 영역을 대표하는 덩이(chunks)들로 분해하고, 비즈니스 영역의 특정 부분과 연관된 비즈니스 규칙과 데이터 로직을 이 덩이들 안에 캡슐화합니다.

비즈니스 문제를 인식하고 마이크로서비스 후보로 분해하기 위해서는 아래와 같은 기준을 갖습니다.

ⓐ 데이터 모델 단순화

[그림 1] 모놀로식 아키텍처의 애플리케이션 구조

기존 모놀리식 애플리케이션의 전형적인 구조입니다.

위와 같이 구매, 재무, 총무팀의 각 업무 담당자는 하나의 애플리케이션에 접속하여 하나의 데이터베이스에 접근하게됩니다.

이를 잘 분해하기 위해서는 데이터 모델을 단순화 해야합니다.

먼저, (a) 애플리케이션의 사용자를 인터뷰하는 것이 중요합니다. 사용자의 요구사항을 판단하여 (b) 어플리케이션 간의 상호 작용을 판단합니다.

위 그림 1을 단순화한 모델은 다음과 같습니다.

[그림 2] 모놀로식 애플리케이션 모델 단순화

 

② 마이크로서비스 정의

모델이 단순화 되었으면 이를 기반으로 실제 마이크로서비스를 배치합니다.

[그림 3] 데이터 모델을 기반으로한 마이크로서비스 애플리케이션

데이터 모델을 배치하는 일은 단순히 (a) 여러 프로젝트로 재패키징하는 것보다 더 많은 작업이 요구됩니다. (b) 서비스가 접근하는 실제 데이터베이스 테이블을 서비스에 따라 정리하고 (c) 각 서비스가 특정 도메인의 테이블만 액세스하게 구분합니다.

 

다만 유념해야 할 부분은 기존 모놀리식에서 반복했던 실수를 또 하지 말자는 것입니다. 한번에 결정해서 그래로 해야 한다는 그런 관점은 애자일한 방식이 아니며, 또한 마이크로서비스가 추구하는 방식이 아닙니다.

㉠ 큰 마이크로서비스에서 시작해 작게 리팩토링하는 것이 더 낫다.

㉡ 서비스 간 교류하는 방식에 먼저 집중한다.

㉢ 문제 영역에 대한 이해가 깊어짐에 따라 서비스 책임도 계속 변한다.

 

# 참조

마이크로서비스가 적절한 크기로 나뉘었는가를 판단하는 기준

[너무 크게 나뉘었을 경우]

- 책임이 너무 많은 서비스

- 많은 테이블의 데이터를 관리하는 서비스 (외부 데이터베이스와 연결하거나, 5개 이상의 테이블을 소유할 경우)

- 과다한 테스트 케이스 (시간이 지남에 따라 서비스의 크기와 책임이 늘어날 경우 리팩토링이 필요)

[너무 작게 나뉘었을 경우]

- 한 문제 영역 부분에 속한 마이크로서비스가 너무 많은 경우

- 마이크로서비스가 지나치게 상호 의존적인 경우 (서비스 간의 트랜젝션이 너무 많은 경우)

- 마이크로서비스가 단순한 CRUD의 집합이 되는 경우

 

③ 서비스 인터페이스 정의

마지막으로 아키텍트가 제공한 요소는 애플리케이션의 마이크로서비스가 대화하는 방식을 정의하는 것입니다.

즉 서비스 인터페이스는 직관적이고, 개발자가 1~2개의 애플리케이션 서비스를 학습하고 나면 애플리케이션의 모든 서비스에 대한 동작 규칙을 습득할 수 있어야 합니다.

㉠ REST 방식

REST 방식은 서비스의 호출 프로토콜로 HTTP를 수용하고 표준 HTTP 동사(GET, PUT, POST, DELETE)를 사용하는 것이 핵심입니다.

㉡ URI 사용

서비스의 엔드포인트로 사용되는 URI는 자원간의 관계에 대한 기본 메커니즘을 제공해야 합니다.

㉢ Request와 Response에 JSON을 활용

JSON은 초경량 데이터 직렬화 프로토콜이며 XML보다 훨씬 사용하기 쉽습니다.

㉣ HTTP 상태 코드로 결과를 전달

HTTP 프로토콜에는 서비스의 성공과 실패를 명시하는 풍부한 응답 코드가 있습니다. 상태 코드를 익히고 모든 서비스에 일관되게 사용하는 것이 중요합니다.

---

● 마이크로서비스를 사용하지 않아야 할 때

마이크로서비스의 강력함을 살펴보았지만, 그렇다고 무조건 적용해야 하는 것은 아닙니다.

다음과 같은 경우에는 마이크로서비스를 적용할지 고민해 봐야 합니다.

① 분산 시스템 구축의 복잡성

마이크로서비스는 세분화 되어 나뉘고 분산되어 자동화와 운영(모니터링과 확장)에 투자가 필요합니다. 따라서 성공적으로 오픈하기 위한 이와 같은 투자가 없는 사이트의 경우 마이크로서비스를 고려하지 않는 것이 좋습니다.

② 서버 스프롤 (Server Sprawl)

서버 스프롤은 추가하기 쉽다는 이유로 시간이 흐름에 따라 클라우드 환경에서 구동되는 컨테이너의 수가 늘어나는 상황을 의미합니다. 단순히 리소스를 제공하는 서버나 컨테이너를 실행하는데 드는 비용은 저렴할지 몰라도 이와 함께 서버를 관리하고 모니터링하는 운영 작업은 엄청 복잡할 수 있다는 것을 인지해야 합니다.

③ 애플리케이션 유형

부서 수준의 소형 애플리케이션이나 소수 사용자를 위한 애플리케이션을 개발할 때 마이크로서비스와 같은 분산 모델로 구축한다면 구축에 따른 복잡성이 얻게 될 가치보다 더 클 수 있습니다.

④ 데이터 변환과 일관성

애플리케이션이 여러 데이터 소스에서 복잡한 데이터를 취합하고 변환해야 할 경우 마이크로서비스의 분산된 특성 때문에 작업이 어려워집니다.