EDA(Event-Driven Architecture)

이벤트 기반 아키텍처는 비동기식 메시지를 사용하여 상태변경을 표현하는 이벤트로 통신한다. 때문에 서비스가 높은 수준으로 분리되고 상태변경을 빠르게 적용할 수 있다.

메시징이 필요한 이유

• 서비스 간 호출 부하 최소화
• 데이터 엑세스 비용 절감
  • 각 서비스 간의 DB에 직접 접속을 최소화하기 위해 캐싱이나 동기화를 적용한다.
  • 이때, 캐싱을 위한 데이터는 일관성이 있어야 하며
  • 동기화를 위해서는 상태 변화를 인식해야 한다.

상태변화 전달하기

• 동기 방식으로 상태변화 전달(Redis)
  • 레디스는 분산 키-값 저장소 데이터베이스로 캐싱을 위해 사용된다.
  • 캐싱 프로세스
    • 원본 서비스에 요청하기 전 레디스 캐시 데이터를 확인
    • 캐시가 없는 경우 원본 서비스에 직접 요청하여 데이터 조회
    • 레디스 캐시에 저장
    • 원본 서비스 상태변화 시 레디스 캐시 무효화(참조 서비스 호출)
  • 단점
    • 원본 서비스와 강결합 및 비유연성
• 메시징 방식으로 상태변화 전달
  • 프로세스
    • 원본 서비스 데이터를 레디스 캐시에서 조회한다.
    • 원본 데이터 상태변화는 실시간으로 발행/소비되어 레디스 캐시에 갱신된다.
  • 장점
    • 느슨한 결합, 내구성, 확장성, 유연성
  • 단점
    • 메시지 처리 의미(발행과 소비의 동작방식에 대해 이해 필요)
    • 구현의 복잡성
    • 가시성

스프링 클라우드 스트림

이 프로젝트는 애플리케이션의 메시지 발행자와 소비자를 쉽게 구축할 수 있는 어노테이션 기반 프레임워크이다. 여러 메시지 플랫폼(RabbitMQ, Kafka)과 함께 사용할 수 있다.

스트림 컴포넌트

• 소스: 스프링에서 메시지를 발행하는 코드
• 채널: 메시지를 발행하는 영역
• 바인더: 메시지 시스템과 통신
• 싱크: 스프링에서 채널을 수신 대기하고 메시지를 처리하는 코드

구현하기

• 카프카, 레디스 구성
  • docker-compose.xml 파일에 추가 설정
• 원본 서비스에 메시지 생산자 구성
  • 의존성 추가
  • 부트스트랩 클레스에 @EnableBinding(Source.class) 설정
• 원본 서비스에서 메시지 발행 로직 구현
  • 스프링 클라우드 Source 인터페이스 주입
  • output() 메서드로 하나의 채널에서 메시지 발행
  • send()
• 참조 서비스에 메시지 소비자 구성
  • 의존성 추가
  • 부트스트랩 클레스에 @EnableBinding(Sink.class) 설정
  • 채널에서 메시지 받을 때 마다 실행할 메서드 정의

(예제)분산캐싱하기

• 참조 서비스에 레디스 서버 커넥션 설정
  • 의존성(jedis) 설정
  • 부트스트랩 클래스에 DB 커넥션(jedis) 및 RedisTemplate 설정
• …