21-1. 비동기 메시징이란?
- 컴포넌트간 통신에 Redis나 NATS로 메시지 큐를 도입하면 시스템 성능과 확장성, 무중단으로 새 기능 추가 등의 이점이 있다.
- 모든 컴포넌트는 메시지 큐의 클라이언트가 되고 메시지를 보내는 컴포넌트는 Publisher, 메시지를 받는 컴포넌트는 Subscriber가 되어 각각의 큐들을 channel로 나눠 메시지를 구분한다.
21-2. 클라우드 네이티브 메시지 큐 사용하기
- 기존 예제의 어플리케이션은 데이커 쿼리 시 요청 완료까지 접속을 유지해야했지만 메시지 큐를 도입하면 connection 수보다 많은 작업을 처리할 수 있다.
- NATS는 메시지를 메모리에 저장하여 속도가 빠르기에 컨테이너 통신에 적합하다.
- MATS는 chennel 개념 없이 모든 메시지에 subject를 부여하여 메시지의 유형을 구분한다.
- Redis와 NATS는 메시지를 수신할 Subscriber가 없다면 메시지를 버린다.
- 비동기 메시징을 처리하기 위해 메시지 큐, 이벤트 발생 시 메시지를 발행하는 Publisher, 메시지를 수신해 이벤트를 처리하는 Subscriber가 필요하다.
21-3. 메시지 수신 및 처리
- 큐를 Subscribe하는 컴포넌트를 Message Handler라고 하며, 모든 메시지의 처리가 끝나면 애플리케이션 데이터의 상태가 일관적으로 정확해진다(작업중이 없으니).
- 이를 결과적 일관성이라고 하며, 모든 메시지 처리가 끝난 경우를 의미하는 이벤트를 만들어 그에 따라 화면을 반영하면 된다.
- 애플리케이션 구성 요소간 결합도를 느슨하게 만드는 이벤트 지향 아키텍처를 설계할 수 있다.
21-4. 메시지 핸들러로 기능 추가하기
- 핵심 이벤트를 메시지 큐에 Publish만 하면 컴포넌트 수정 없이 새 기능을 배포할 수 있고 문제 발생 시 메시지 핸들러만 중단시키면 된다.
21-5. 비동시 메시징 패턴 이해하기
- 위에서 다룬 Subscriber가 Published Message를 구독하는 형태를 Pub-Sub패턴이라고 한다. 이 패턴은 누가 퍼블리셔고 언제 작업이 끝나는지는 알 수 없다.
- Request-Response 패턴은 클라이언트가 메시지 큐에 메시지를 전달하고 응답을 기다린다. 이 경우 서버는 클라이언트를 기다리며 다른 작업을 할 수 있다.
- 그 외 패턴으로 명령을 보내고 응답을 기다리지 않는 fire-and-forget, 여러 Subscriber에게 메시지를 모내고 응답을 모으는 Scatter-Gatter 등이 있다.
- 서비스 중단 없이 새 기능을 배포하고 싶거나, 자원이 부족한 데이터베이스 서버를 보호하기 위해 핸들러 인스턴스를 줄이려면 메시지 큐가 적절하다.
이제 3학년..