티스토리 뷰

마이크로서비스 패턴 / Chris Richardson (2020). Microservices Patterns (이일웅, 역). 길벗. (원본 출판 2018년)의 내용 중 일부를 정리해봤습니다.

모놀리식과 MSA

모놀리식 아키텍처 패턴은 애플리케이션을 하나의 배포단위로 구성하지만 마이크로서비스 아키텍처 패턴은 독립적으로 배포 가능하면서 자체 DB를 보유한 서비스로 시스템을 분해합니다.

서비스 디스커버리

서비스 인스턴스의 네트워크 위치나 상태가 여러 가지 사유로 달라질 수 있기 때문에 서비스 디스커버리를 사용합니다.

애플리케이션 수준의 서비스 디스커버리 패턴

서비스 클라이언트와 서비스 인스턴스 사이에 이들을 매개하는 서비스 레지스트리가 있습니다. 서비스 인스턴스는 자기 자신을 서비스 레지스트리에 등록하며, 클라이언트는 서비스 레지스트리에 인스턴스 목록을 요청해서 넘겨받습니다. 다양한 플랫폼에 적용할 수 있지만 사용하는 언어에 맞는 서비스 디스커버리 라이브러리가 필요합니다. 스프링 클라우드 기반의 클라이언트는 유레카를 기본 서비스 디스커버리로 사용합니다.

플랫폼에 내장된 서비스 디스커버리 패턴 적용

도커나 쿠버네티스 등 최신 배포 플랫폼에는 대부분 서비스 레지스트리, 디스커버리 메커니즘이 탑재되어 있습니다. 플랫폼의 일부인 등록기(Registrar)라는 서드파티가 서비스 레지스트리에 서비스 인스턴스를 등록하며, 클라이언트가 DNS명을 요청하면 플랫폼 라우터를 거쳐 인스턴스로부터 서비스를 제공받습니다. 각 서비스 인스턴스는 가상 IP와, 가상 IP를 해석한 DNS명을 가집니다. 이 방식은 디스커버리 방식이 해당 플랫폼에 종속되는 단점이 있지만 개발 언어, 라이브러리와 상관 없이 동일하게 적용할 수 있습니다.

동기 RPI 패턴

동기 RPI는 클라이언트가 서비스에 요청을 보내면 서비스가 처리 후 보내는 응답을 클라이언트가 대기하는 방식이 블로킹입니다. 책에서는 프록시 패턴으로 이 구조를 설명하는데 클라이언트의 비즈니스 로직은 프록시 인터페이스를 호출하고, 인터페이스를 구현한 RPI 프록시 어댑터 클래스에 서비스에 요청을 보내는 통신이 들어갑니다. 요청을 전달받은 RPI 서버 어댑터가 다시 서비스 인터페이스를 통해 서비스의 비즈니스 로직을 호출합니다. 로직 처리를 마친 서비스는 다시 RPI 프록시로 응답을 돌려주고 최종 결과는 클라이언트 비즈니스 로직에 반환됩니다.

회로 차단기 패턴

성공/실패 요청 개수를 지켜보다가 에러율이 주어진 임계치를 초과하면 그 이후 시도는 바로 실패 처리합니다. 타임아웃 시간 이후 클라이언트가 재시도해서 성공하면 회로 차단기는 닫힙니다.

도메인 이벤트

애그리거트에 발생한 사건으로 대부분 어떤 상태 변경을 나타냅니다. 도메인 이벤트는 과거 분사형 동사로 명명한 클래스로 표현합니다. 원시 값(Primitive Type) 또는 밸류 객체(Value Object)로 표현된 프로퍼티로 이루어져 있으며 그 중에는 이벤트 ID, 타임스탬프와 같은 메타데이터도 있습니다. 메타데이터는 상위 클래스에 정의된 이벤트 객체의 일부이거나, 특정 이벤트 프로퍼티가 아닌 이벤트 객체를 감싼 인벨로브 객체에 들어있을 수도 있습니다.

이벤트 소싱

이벤트 소싱은 애그리거트를 여러 이벤트로 저장하며, 이 이벤트를 가져와 현재 애그리거트의 상태를 다시 구성합니다.

API 조합 패턴

서비스 클라이언트가 데이터를 가진 여러 서비스를 직접 호출하여 그 결과를 조합하는 패턴입니다. 쿼리를 구현하는 간단한 방법이지만 오버헤드 증가, 가용성 저하 우려, 데이터 일관성 결여 등의 단점이 있습니다.

CQRS 패턴

CQRS(Command Query Responsibility Separation)는 영속적 데이터 모델과 그것을 사용하는 모듈을 커맨드와 쿼리, 두 편으로 가릅니다. 조회 쪽 기능은 쿼리 쪽 모듈 및 데이터 모델에, 생성/수정/삭제 기능은 커맨드 쪽 모듈 및 데이터 모델에 구현하는 것입니다. 양쪽 데이터 모델 사이의 동기화는 커맨드 쪽에서 발행한 이벤트를 쿼리 쪽에서 구독하는 식으로 이루어집니다.

API 게이트웨이

API 게이트웨이는 방화벽 외부의 클라이언트가 애플리케이션에 API 요청을 하는 단일 창구 역할을 하는 서비스입니다. 퍼사드처럼 내부 애플리케이션 아키텍처를 캡슐화하고 자신의 클라이언트에는 API를 제공합니다. 인증, 모니터링, 사용량 제한 등 부수적인 일도 담당합니다. REST API 보다 GraphQL 같은 그래프 기반의 API를 이용하는 것이 효율적입니다.

BFF 패턴

BFF(Backends For Frontends) 패턴은 각 클라이언트마다 API 게이트웨이를 따로 두는 패턴입니다. 공통 게이트웨이를 이용할 때의 책임 소재가 불분명해지는 문제를 해결하고 API 모듈이 서로 격리되어 신뢰성이 향상됩니다.

컨슈머 주도 계약 테스트

컨슈머 주도 계약 테스트는 프로바이더 API의 형상(shape)이 클라이언트의 기대에 부합하는지 확인합니다.

배포 파이프라인

배포 파이프라인은 개발자가 데스크톱에서 작성한 코드를 프로덕션에 반영하는 자동화 프로세스입니다. 배포 파이프라인은 다음과 같은 단계를 가집니다.

  • 사전-커밋(pre-commit): 단위 테스트를 실행합니다.
  • 커밋 테스트(commit test) 단계: 서비스 컴파일 후 단위 테스트를 실행하고 정적 코드 분석을 수행합니다.
  • 통합 테스트(integration test) 단계: 통합 테스트를 실행합니다.
  • 컴포넌트 테스트(component test) 단계: 서비스 컴포넌트 테스트를 실행합니다.
  • 배포(deploy) 단계: 프로덕션에 서비스를 배포합니다.

참조

마이크로서비스 패턴

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글