MSA 설계하기: 성공적인 마이크로서비스 아키텍처 구축을 위한 가이드

마이크로서비스 아키텍처(MSA)는 하나의 애플리케이션을 작고 독립적인 서비스들의 집합으로 분해하여 개발하고 배포하는 방식입니다. 이는 복잡한 시스템을 관리하고 확장하기 쉽게 만들어 주지만, 성공적인 MSA를 설계하기 위해서는 신중한 고려가 필요하다.

도메인 분석 및 서비스 식별

• 비즈니스 도메인 이해: 시스템의 핵심 기능과 비즈니스 로직을 명확하게 파악
• 바운디드 컨텍스트: 각 도메인을 독립적으로 관리할 수 있는 바운디드 컨텍스트로 나눈다.
• 서비스 분해: 각 바운디드 컨텍스트를 하나의 마이크로서비스로 매핑한다.

 1. 비즈니스 문제를 기술하고 그 문제를 기술하는 데 사용된 명사에 주목할 것

문제를 기술하는 데 동일한 명사가 반복해서 사용된다면 핵심 비즈니스 영역과 마이크로서비스로 쪼갤 것을 고려하여야 한다.

2. 동사에 주목할 것

예를 들어 "데스크톱 서비스 부서의 "마이크"는 새로운 PC를 설치할 때 소프트웨어 X의 라이선스 개수를 조회하고 여분이 있다면 설치한다. 그런 다음 장부에 라이선스 개수를 업데이트한다"에서 핵심 동사는 조회하다(looks)와 업데이트하다(updates)이다.

3. 데이터 응집성을 찾아라

비즈니스 문제를 각 부분으로 분해할 때 서로 연관성이 높은 데이터 부분들을 찾는다. 마이크로서비스는 자기 데이터를 완전히 소유해야 한다. 따라서 만일 설계 도중 지금껏 설계한 내용과 근본적으로 다른 데이터를 CRUD 한다면 새로운 서비스를 하나 더 생성할 것을 고려해야 한다.

서비스 세분화의 확정

비즈니스 문제에 따라 분해한 예시 데이터 모델을 자산(Assests), 계약(Contract), 라이선스(License), 조직(Organization) 으로 쪼갤 경우, 4개의 마이크로서비스를 고려할 수 있는데 중요한 것은 이러한 주요 기능을 가져와 서로 독립적으로 빌드하고 배포할 수 있는 자체 완비형 유닛 (Self-Contained unit)을 추출하는 것이다.

 

MSA는 처음부터 올바르게 설계하기 어렵기에 잘게 나뉜 서비스보다 굵게 나뉜 서비스에서 시작하는 것이 더 좋다. 너무 잘계 나뉘면 분리된 두 서비스 사이에 지나친 호출이 발생하기 때문에 데이터를 합치는 집합 (aggregation) 서비스를 별도로 만들거나 서비스 영역의 명확한 경계선이 없는 서비스에서 물리적 제약이 발생할 수 있다.

지나치게 굵게 쪼개진 마이크로서비스의 특징

• 책임이 너무 많은 서비스 :  이 서비스에서 비즈니스 로직의 일반 흐름은 복잡하며 지나치게 다양한 종류의 비즈니스 규칙을 시행하게 된다
• 많은 테이블의 데이터를 관리하는 서비스 :  마이크로서비스는 3~5개 이내의 테이블을 소유하는 것이 적절하다
• 과다한 테스트 케이스: 테스트 케이스가 많다는 것은 변경에 대한 위험성이 크다는 것을 의미한다.

지나치게 잘게 쪼개진 마이크로서비스의 특징

• 한 문제 영역 부분에 속한 마이크로서비스가 토끼처럼 번식함 :  작업 수행에 필요한 서비스 개수가 증가해서 비즈니스 로직을 만드는 것이 복잡하고 어려워짐, 애플리케이션에 수십 개의 마이크로서비스가 있고 각 서비스가 하나의 데이터베이스 테이블과 통신할 때 관리하기 어려워짐
• 지나치게 상호 의존적인 마이크로서비스 : 문제 영역의 한 부분에 있는 마이크로서비스는 하나의 사용자 요청을 완료하기 위해 각 서비스가 서로 계속 호출함

마이크로서비스가 단순 CRUD (Create, Read, Update, Delete) 집합이 됨 :  마이크로서비스는 비즈니스 로직의 표현이지 데이터 소스 (data sources)의 추상화 계층이 아님

서비스 인터페이스 설계

• RESTful API  : 대부분의 경우 RESTful API를 사용하여 서비스 간 통신을 구현한다. 
• 명확한 계약: 각 서비스의 API는 명확하고 일관된 계약을 가져야 한다.
• 버전 관리: API 변경 시 호환성 문제를 최소화하기 위해 버전 관리를 적용한다.

1. REST 철학을 수용할 것

서비스에 대한 REST 방식은 서비스의 호출 프로토콜로 HTTP를 수용하고 표준 HTTP 동사 (GET, PUT, POST, DELETE)를 사용하는 것이 핵심이다. HTTP 동사를 기반으로 기본 행동 양식을 모델링한다.

2. URI를 사용해도 의도(intent)를 전달할 것

서비스의 엔드포인트로 사용되는 URI는 문제 영역에 존재하는 다양한 자원을 기술하고 자원 관계에 대한 기본 메커니즘을 제공해야 한다

3. 요청(request)과 응답(response)에 JSON을 사용할 것

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

4. HTTP 상태 코드로 결과를 전달하라

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

데이터 관리

• 분산 데이터 : 각 서비스는 독립적인 데이터 저장소를 가질 수 있다.
• 데이터 일관성 : 분산 데이터 환경에서 데이터 일관성을 유지하기 위한 전략을 수립한다.
• 이벤트 소싱 : 필요한 경우 이벤트 소싱을 통해 데이터를 관리하고 추적할 수 있다.

서비스 간 통신

• API 게이트웨이 : 다양한 서비스에 대한 단일 진입점을 제공하고, API 관리 기능을 수행한다.
• 서비스 디스커버리 : 서비스의 위치를 동적으로 찾을 수 있도록 지원한다.
• 비동기 통신 : 메시지 큐를 이용하여 비동기 통신을 구현한다.

배포 및 관리

• 컨테이너 : Docker와 같은 컨테이너 기술을 활용하여 서비스를 패키징하고 관리한다.
• 오케스트레이션 : Kubernetes와 같은 오케스트레이션 도구를 사용하여 서비스를 배포하고 관리한다.
• CI/CD : 지속적인 통합 및 배포(CI/CD) 파이프라인을 구축하여 빠른 개발과 배포를 지원한다.

모니터링 및 관찰성

• 로그 : 각 서비스의 로그를 수집하고 분석하여 문제를 진단한다.
• 메트릭 : 서비스의 성능을 측정하기 위한 메트릭을 수집하고 모니터링한다.
• 트레이싱 : 분산 시스템에서 요청의 흐름을 추적하여 문제를 파악한이크로서비스 아키텍처(MSA)는 하나의 애플리케이션을 작고 독립적인 서비스들의 집합으로 분해하여 개발하고 배포하는 방식입니다. 이는 복잡한 시스템을 관리하고 확장하기 쉽게 만들어 주지만, 성공적인 MSA를 설계하기 위해서는 신중한 고려가 필요하다.