스프링 클라우드 스트림을 사용한

이벤트 기반 아키텍처

Spring Microservices in Action

Chapter 8

2019.07.04

박영준

핵심 내용

  • 이벤트 기반 아키텍처 및 이와 연관된 마이크로서비스 이해

  • 스프링 클라우드 스트림을 사용한 마이크로서비스 이벤트 처리 단순화

  • 스프링 클라우드 스트림과 카프카를 사용한 메시지 발행 / 소비

  • 스프링 클라우드 스트림과 카프카, 레디스로 분산 캐싱 구현

이벤트 기반 아키텍처(EDA)

  • 비동기 메시지를 이용한 통신 

  • 메시지 기반 아키텍처(MDA)

  • 높은 수준으로 분리된 시스템을 구축할 수 있다

  • 스프링 클라우드 스트림을 사용하여 손쉽게(?) 구축할 수 있다

EDA와 마이크로서비스 사례 : 캐싱 솔루션

  • 캐싱된 데이터는 모든 인스턴스에 대해 일관성이 있어야 한다.

  • 라이선싱 서비스 컨테이너 메모리에 조직 데이터를 캐시하면 안된다.

  • 조직 데이터가 변경될 때 라이선싱 서비스는 조직 데이터의 상태 변화를 인식해야 한다.

요구사항

라이선싱 서비스에서 읽는 조직 데이터를 캐싱하여 DB 엑세스 비용을 줄인다.

동기식 요청-응답 방식으로 캐싱 솔루션 구현

동기식 요청-응답 방식의 문제점

  • 조직 서비스와 라이선싱 서비스가 강하게 결합된다.

    • 조직 서비스에서 라이선싱 서비스로 향하는 결합 발생
    • 조직 서비스가 레디스에 직접 접근하는 것은 그 자체로 문제
  • 강한 결합으로 인해 두 서비스 사이에 깨지기 쉬운 성질(brittleness)이 생긴다.

    • 라이선싱 서비스의 장애가 조직 서비스에도 영향을 미친다.
  • 조직 서비스 변경에 관심이 있는 새로운 소비자를 추가하기 어렵다(경직성)

    • 다른 서비스를 추가할 때 마다 조직 서비스의 코드도 변경하고 재배포 해야 한다.
    • 거미줄 모양의 의존성  패턴이 생긴다.

메시징 방식으로 캐싱 솔루션 구현

메시징 방식의 장점

  • 느슨한 결합

    • 메시지 전달 과정에서 두 서비스가 서로를 알지 못해 결합이 줄어듦
    • 메시지 수신 여부만 알고 누가 발행 했는지는 알 수 없음
  • 내구성

    • 중간 큐의 존재로 인해 컨슈머 서비스가 다운되도 메시지를 발행할 수 있다
  • 확장성

    • 메시지 발신자는 소비자의 응답을 기다릴 필요 없이 하던 일을 계속할 수 있다
    • 소비자가 메시지를 더 빠르게 처리하도록 하려면 인스턴스 수를 늘리면 된다(수평확장)
  • 유연성

    • 새로운 메시지 컨슈머를 쉽게 추가할 수 있다. (기존 서비스를 수정하지 않고!)

메시지 아키텍처의 단점

  • 메시지 처리의 의미론

    • 메시지 처리가 순서대로 되어야 하는지 고민해봐야 한다.
    • 순서대로 처리되지 않을때 발생할 문제를 설계 단계에서 부터 고려한다.
    • 메시지 처리 도중 실패하면 어떻게 할 것인가?
  • 메시지 가시성(?)

  • 메시지 코레오그래피

    • 코드가 선형적으로 처리되지 않기 때문에 비즈니스 로직 추론이 어려워진다.
    • 사용자 트랜잭션 순서가 바뀌고 다른 시점에 실행될 수 있는 서비스 로그를 꼼꼼히 살펴야 한다.

스프링 클라우드 스트림

  • 메시지 발행자와 소비자를 쉽게 구축할 수 있는 어노테이션 기반 F/W

  • 스프링 기반 마이크로서비스에 메시징을 쉽게 통합할 수 있다.

  • 메시징 플랫폼의 구현 세부 사항을 추상화 한다.

스프링 클라우드 스트림 아키텍처

  • 소스

  • 채널

  • 바인더

  • 싱크

스프링 클라우드 스트림 아키텍처

  • 소스를 사용해 메시지를 발행

  • 메시지는 POJO 형태로 표현

  • 소스는 메시지를 받아 직렬화하고 메시지를 채너로 발행한다.

소스(Source)

스프링 클라우드 스트림 아키텍처

  • 메시지를 보관할 큐를 추상화 한 것

  • 코드에서는 큐 이름을 직접 사용하지 않고 채널 이름을 사용

  • 큐가 변경되면 코드가 아닌 설정 파일(구성 정보)를 변경한다.

채널(Channel)

스프링 클라우드 스트림 아키텍처

  • 스프링 코드를 사용하여 특정 메시지 플랫폼과 통신

  • 바인더를 사용하면 메시지 발행 및 소비를 위해 별도의 라이브러리와 API를 제공하지 않아도 된다.

바인더(Binder)

스프링 클라우드 스트림 아키텍처

  • 싱크를 사용해 큐에서 메시지를 받는다.

  • 들어오는 메시지를 받기 위해 채널을 수신 대기 한다.

  • 메시지를 다시 POJO로 역직렬화 한다.

싱크(Sink)

스프링 클라우드 스트림을 사용한 이벤트 기반 아키텍처

By Young Jun Park (박영준)

스프링 클라우드 스트림을 사용한 이벤트 기반 아키텍처

스프링 클라우드 스트림에 대한 설명

  • 152