이 글은 Microservice 및 최근에 여러 기업에서 사용되는 패턴들에 대해 정리하였습니다.

목차

• Service Aggregator Pattern
• Circuit Breaker Pattern
• Database Per Service Pattern
• The Saga Pattern
• API Gateway Pattern
• CQRS(Command Query Responsibility Segregation) Pattern
• Service Registry
• Externalized Configuration

Service Aggregator Pattern

참고: Service Aggregator Pattern

• 서비스간 통신을 최소화하기 위해 Service Aggregator Pattern을 사용
• 클라이언트에서 요청한 데이터를 내부적으로 요청 및 결합해 응답하는 방식

Circuit Breaker Pattern

참고: CircuitBreaker

• 서비스 또는 네트워크 오류가 발생했을 때 해당 시스템에 대한 원격 호출 부하 방지 패턴

주요 상태

• Closed: 정상
• Half Open: 오류 상태에서 정상 상태인지 주기적으로 확인하는 상태
• Open: 오류

Database Per Service Pattern

• Microservice에서 서비스별로 데이터베이스를 구성하는 패턴
• 느슨한 결합이 주 목표

The Saga Pattern

• 참고: Saga 분산 트랜잭션 패턴

• 참고: Pattern: Saga

• Saga 디자인 패턴은 분산 트랜잭션 시나리오에서 마이크로 서비스 간의 데이터 일관성을 관리하는 방법

• Saga란 각 서비스를 업데이트하고 메시지 또는 이벤트를 게시하여 다음 트랜잭션 단계를 트리거하는 일련의 트랜잭션

• 단계가 실패할 경우, Saga는 이전 트랜잭션을 상쇄하는 보상 트랜잭션을 실행

Saga 종류

• Choreography: 각 로컬 트랜잭션은 다른 서비스에서 로컬 트랜잭션을 트리거하는 도메인 이벤트를 게시
• Orchestration: 오케스트레이터(객체)는 참가자에게 실행할 로컬 트랜잭션을 알려줌

Choreography

• 참가자가 거의 없고 조정 논리가 필요하지 않은 간단한 워크플로에 적합

장점

• 책임은 Saga 참가자에게 분산되므로 단일 실패 지점을 도입하지 않음
• 도입에 있어 추가적인 구현이 불필요함

단점

• 참가자를 추가할 경우, 워크플로를 고려해 추가 필요
• 트랜잭션을 시뮬레이션하기 위해 모든 서비스를 실행해야 하므로 통합 테스트가 어려움
• 서로의 명령을 소비해야 하기 때문에 Saga 참가자 간에 순환 종속성이 발생할 위험 존재
• Saga 참가자들끼리 어떤 명령을 수신 대기중이고 처리중인지 추적하기 어려움

Orchestration

• 시간이 지남에 따라 많은 참가자가 관여하거나 새 참가자가 추가되는 포함된 복잡한 워크플로에 적합

장점

• 프로세스의 모든 참가자를 제어하고 활동 흐름을 제어할 수 있음
• 참가자를 추가하기 용이함
• 순환 종속성이 발생하지 않음
• Saga 참가자는 다른 참가자의 명령에 대해 알 필요가 없어 비즈니스 논리를 간소화할 수 있음

단점

• 보상 트랜잭선의 추가 구현 필요
• 오케스트레이터가 전체 워크플로우를 관리하기 때문에 추가 실패 지점(오케스트레이터 자체)이 존재

API Gateway Pattern

참고: 효과적인-api-제공을-위한-api-gateway-패턴-선택

• 클라이언트와 애플리케이션 사이에 게이트웨이라는 개념을 추가

주요 구현 기능

• Rate Limit(속도 제한)
• Authentication(인증)
• Caching(캐싱)
• Logging(로깅)

API Gateway 종류

1. 중앙 집중식, Edge Gateway

• 하나의 중앙형 API 게이트웨이를 사용해 모든 요청을 받는 구조

2. Two-Tier(2계층) Gateway

• 두 가지 게이트웨이로 분류됨
  • 보안 게이트웨이(클라이언트 게이트웨이): 클라이언트에서 요청한 내용을 백엔드 게이트웨이로 라우팅
    • SSL/TLS termination
    • 인증 (Authentication)
    • 연결 및 요청의 중앙 집중식 로깅 (Centralized logging of connections and requests)
    • 추적 주입 (Tracing injection)
  • 라우팅 게이트웨이:
    • 권한 부여 (Authorization)
    • 서비스 발견 (Service discovery)
    • 부하 분산 (Load balancing)

3. Microgateway (마이크로게이트웨이)

• 각 microservice에서 별도의 API gateway를 가지고 있는 구조

4. 파드별(Per-Pod) Gateway

• Pod 별로 API gateway를 가진 구조

5. 사이드카 게이트웨이 및 서비스 메시 (Sidecar Gateways and Service Mesh)

• Service Mesh는 쉽게말해 마이크로 서비스 간의 통신(네트워크)을 담당하는 요소
  • 통신 및 네트워크 기능을 비즈니스 로직과 분리한 네트워크 통신 인프라
    서비스의 인프라 레이어로서 서비스들 간의 통신을 처리
• Sidecar pattern은 모든 응용 프로그램 컨테이너에 추가로 sidecar 컨테이너가 배포됨
  • 서비스에 들어오거나 나가는 모든 네트워크 트래픽을 처리
• 비즈니스 로직이 포함된 실제 서비스와 sidecar이 병렬로 구성되어있기 때문에, 서비스 호출에서 서비스가 직접 서비스를 호출하는 것이 아니라 proxy 를 통해서 호출

CQRS(Command Query Responsibility Segregation) Pattern

• 참고: CQRS Pattern

• 참고: 나만 모르고 있던 CQRS & EventSourcing

• 시스템의 명령(Command)부분과 조회(Query) 부분을 분리하는 패턴

• 두 가지로 분리화 관리함으로써 읽기 및 쓰기 처리량을 최적화할 수 있음

CQRS 종류

1. 동일한 DB를 사용하지만 명령과 쿼리 모델 분류

• Database(RDBMS) 는 분리하지 않고 기존 구조 그대로 유지 시키고 Model Layer 부분만 Command와 Query Model로 분리하는 수준
• Domain Layer에 대해서 만 모델링하고 코딩하기 때문에 훨씬 단순하게 구현/적용
• 동일 Database 사용에 따른 성능상 문제점은 개선하지 못함

2. 명령과 쿼리 DB 분리(DB간 Syncronization)

• 명령과 쿼리에서 사용하는 DB를 분리함
• DB가 분리됨으로써 명령과 쿼리 사용간 성능 최적화가 진행됨
• 명령 DB와 쿼리 DB를 동기화하는 동기화 로직이 추가적으로 구현 필요

3. Event Sourcing을 통한 CQRS

• Queue를 사용한 이벤트 발행 및 처리
• 이벤트를 통해 쿼리 DB 동기화 처리
• 어떻게 두 DB 사이의 일관성을 유지할 것인가는 추가 과제

Service Registry Pattern

• 쿠버네티스 환경에서는 서비스의 IP 및 포트 번호가 동적으로 변경됨
• 클라이언트 측에서는 어떤 IP 및 포트를 사용해야 되는지 알기 어려움
• Service Registry Pattern 클러스터에서 마이크로서비스를 등록 하고 검색하는 기능을 제공

• 클라이언트 서비스가 내부 서비스에 액세스해야 하는 경우 Service Registry 에서 쿼리하여 액세스

• Netflix Eureka는 Service Registry Pattern을 구현한 대표적인 오픈 소스 라이브러리

Reference

Service Aggregator Pattern

• CircuitBreaker
• 마이크로서비스 구축을 위한 API Gateway 패턴 사용하기
• Saga 분산 트랜잭션 패턴
• Pattern: Saga
• 나만 모르고 있던 CQRS & EventSourcing
• Pattern: Event sourcing