[완독정리]스프링 마이크로서비스 코딩 공작소 8.메시지와 EDA, 마이크로서비스의 사례-길벗

마이크로서비스에서의 캐싱

- 캐싱된 데이터는 서비스의 모든 인스턴스에 일관성이 있어야 한다. 

- 컨테이너 메모리에 조직데이터를 캐싱해서는 안된다. 서비스를 호스팅하는 런타임 컨테이너는 종종 크기 제약이 있으며 다양한 엑세스 패턴으로 데이터를 엑세스한다. 

- 업데이트나 삭제 연산으로 레코드가 변경될 때 서비스는 상태 변화를 인식해야 한다. 

 

동기식 요청-응답 방식으로 상태 변화 전달의 특징

- 서비스간 강한 결합

- 쉽게 깨지는 서비스 관계

- 조직 서비스 변경에 관심있는 새 소비자를 추가할 때 경직성

 

메시징을 사용해 서비스 간 상태 변화 전달의 특징

- 메시징 방식을 사용하면 서비스 사이에 큐를 삽입한다. 데이터의 상태가 변할때 메시지를 발행하여 변경사항을 전달한다. 

- 느슨한 결합

- 내구성

- 확장성

- 유연성

 

메시지 아키텍처의 단점

- 메시지 처리의 의미론 : 소비 순서를 기반으로 어떻게 동작할지의 메시지가 순서대로 처리되지 않을때 어떤일이 발생할지 이해해야 한다. 

- 메시지 가시성 : 메시지가 처리될 때 트랜젝션을 추적하기 위해 상관관계 ID를 사용하는 것도 애플리케이션에서 발생하는 일을 이해하고 디버깅하는데 매우 중요하다.

- 메시지 코레오그래피 : 메시징 기반 애플리케이션은 코드가 더이상 단순한 요청-응답 모델을 사용해 선형적으로 처리되지 않기 대문에 애플리케이션 비즈니스 로직을 추론하는 것은 더 어려워진다. 

 

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

- 스프링 클라우드에서 메시지를 발행하고 소비스하는데 다음 4개의 컴포넌트가 관련되어 있다. 

- 소스 : 서비스가 메시지를 발행할 준비가 되면 소스를 사용해 메시지를 발행한다. 소스는 메시지를 받아 직렬화하고 메시지를 채널로 발행한다. 

- 채널 : 메시지 생산자와 소비자가 메시지를 발행하거나 소비한 후 메시지를 보관할 큐를 추상화 한것이다. 

- 바인더 : 스프링 클라우드 스트림 프레임워크의 일부인 스프링 코드로 특정 메시지 플랫폼과 통신한다. 바인더를 사용하면 메시지를 발행하고 소비하기 위해 플랫폼마다 별도의 라이브러리와 API를 제공하지 않고도 메시징을 사용할 수 있다. 

- 싱크 : 서비스는 싱크를 사용해 큐에서 메시지를 받는다. 싱크는 들어오는 메시지를 위해 채널을 수신 대기하고, 메시지를 다시 POJO로 역직렬화 한다. 

※ 카프카 란?

대용량, 대규모 메시지 데이터를 빠르게 처리하도록 개발된 메시징 플랫폼

 

※ REDIS 란?

REDIS(REmote Dictionary Server)는 메모리 기반의 “키-값” 구조 데이터 관리 시스템이며, 모든 데이터를 메모리에 저장하고 조회하기에 빠른 Read, Write 속도를 보장하는 비 관계형 데이터베이스이다.

 

 

스프링 클라우드 스트림 사용 사례 : 분산 캐싱

레디스를 분산 캐시로 사용하는 것은 클라우드에서 마이크로서비스를 개발한는 것과 관련이 많다. 

- 일반적으로 보유한 데이터 조회 성능을 향상시킨다. 

- 데이터를 가진 Dynamo 테이블의 부하 및 비용을 줄인다. 

- 회복성을 높여주는 데이터 저장소(Dynamo)에 성능 문제가 있을때는 적절히 성능을 저하시킬 수 있다. 

 

어노테이션 : 

@EnableBinding(Source.class) : 스프링 클라우드 스트림에 애플리케이션을 메시지 브로커로 바인딩하라고 알린다. Source.class를 사용하면 해당 서비스가 Source클래스에 정의된 채널들을 이용해 메시지 브로커와 통신하게 된다. 

@EnableBinding(Sink.class) : 들어오는 메시지를 수신할 수 있게 Sink 인터페이스에 정의된 채널을 사용하도록 서비스에 지시한다. 이 애너테이션은 스프링 클라우드 스트림에 기본 스프링 Sink 인터페이스를 사용해 메시지 브로커를 바인딩 하라고 지정한다. 

@StreamListener : 입력 채널에 메시지가 수신될 때마다 매서드를 실행하도록 스프링 클라우드 스트림을 설정한다.