도커 교과서 21장 메시지 큐를 이용한 비동기 통신

21장 메시지 큐를 이용한 비동기 통신

21.1 비동기 메시징이란?

동기 통신

• 소프트웨어의 컴포넌트는 대개 동기적으로 통신한다.
• 클라이언트가 서버에 접속 요청을 보내고, 서버의 응답을 기다린 다음 접속을 종료하는 전체 과정이 동기적으로 이뤄진다.
• 동기적 통신을 할 때 서버가 다운되거나, 응답 시간이 오래 걸리는 경우, 네트워크 수준에서 실패한 경우 등이 문제가 된다.

비동기 통신

• 비동기 통신을 적용하려면 클라이언트와 서버 사이에 계층이 하나 추가된다.
• 클라이언트가 큐에 요청을 보내고, 서버는 큐를 주시하다가 메시지를 수신하고 처리한다.
• 그렇다면 비동기 통신이 무조건 좋은가? 에 대한 답은 아니다.
• 큐를 제공하는 기술의 신뢰성이 뛰어나야 하며, 큐 기술의 사용량이 비싸다는 큰 단점이 있다.
• 도커를 사용하면 엔터프라이즈급 안정성을 갖춘 오픈 소스 큐 시스템을 도입해 문제를 해결할 수 있다.
• 또한, 경량 컨테이너에서 메시지 큐를 실행하면 애플리케이션 마다 별도의 전용 큐를 사용할 수 있고, 모든 환경에서 동일하게 도입할 수 있다.
• 메시지 큐를 이용한 비동기 통신의 경우 전달자와 수신자의 결합을 느슨하게 하는 방법으로 애플리케이션의 성능과 확장성을 개선할 수 있다.

Redis Message Queue

• Redis 를 활용하여 비동기 메시지 큐를 구현할 수 있다.
• 메시지 큐에는 크게 Publisher 와 Subscriber 가 존재한다.
• 발행자(Publisher) 는 메시지를 보내는 주체이며, 구독자(Subscriber) 는 메시지르 받는 주체이다.

$ docker network create ch21

$ docker container run -d --name redis --network ch21 diamol/redis

$ docker logs redis --tail 1

# Publisher 컨테이너
$ docker run -d --name publisher --network ch21 diamol/redis-cli -r 50 -i 5 PUBLISH channel21 ping

$ docker logs publisher

# Subscriber 컨테이너
$ docker run -it --name subscriber --network ch21 diamol/redis-cli SUBSCRIBE channel21

Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel21"
3) (integer) 1
1) "message"
2) "channel21"
3) "ping"
1) "message"
2) "channel21"
3) "ping"

21.2 클라우드 네이티브 메시지 큐 사용하기

NATS

• NATS 는 CNCF 재단에서 관리하는 프로젝트로, 높은 완성도와 신뢰도를 바탕으로 많이 사용되고 있다.
• NATS 는 메시지를 메모리에 저장하며, 속도가 매우 빠르고 컨테이너 간의 통신에 적합하다.
• NATS 에는 채널 개념이 존재하지 않고, 모든 메시지에 Subject 를 부여한다.
• subject 를 통해서 메시지 유형을 구분하며, 원하는 명명 규칙을 적용할 수 있다.
• 이를 통해 Subscriber 는 해당 Subject 를 구독하면 된다.

$ vi message-queue

version: "3.7"

services:
  todo-web:
    image: diamol/ch21-todo-list
    ports:
      - 8080:80
    networks:
      - app-net

  todo-db:
    image: diamol/postgres:11.5
    networks:
      - app-net

  message-queue:
    image: diamol/nats
    ports:
      - "8222:8222"
    networks:
      - app-net

  save-handler:
    image: diamol/ch21-save-handler
    networks:
      - app-net

networks:
  app-net:

$ docker compose up -d message-queue

$ docker logs todo-list-message-queue_1

[1] 2025/01/16 04:46:10.381523 [INF] Starting nats-server version 2.1.9
[1] 2025/01/16 04:46:10.381536 [INF] Git commit [7c76626]
[1] 2025/01/16 04:46:10.381640 [INF] Starting http monitor on 0.0.0.0:8222
[1] 2025/01/16 04:46:10.381661 [INF] Listening for client connections on 0.0.0.0:4222
[1] 2025/01/16 04:46:10.381666 [INF] Server id is NBPKEDLHJMXTO3NDKAXR6OERYRJXK2N5XIS5Z7YFBQ3G3JOH544I5SKG
[1] 2025/01/16 04:46:10.381667 [INF] Server is ready
[1] 2025/01/16 04:46:10.381753 [INF] Listening for route connections on 0.0.0.0:6222

$ curl <http://localhost:8222/connz>

만약, 메시지 큐에 전달했지만 큐를 구독하는 구독자가 없을 경우

• 보통의 메시지 큐는 구독자가 없을 경우 DLQ(Dead Letter Queue) 에 메시지를 저장한다.
• 그러나, Redis 와 NATS 의 경우 구도자가 없으면 해당 메시지를 그대로 버린다.
• 즉, Redis 와 NATS 는 구독한 시점 이후부터 발행된 메시지만 수신할 수 있다.

21.3 메시지 수신 및 처리

• Message Queue 를 구독하는 컴포넌트를 메시지 핸들러라고 한다.
• 대게 메시지의 종류마다 이를 처리하는 메시지 핸들러가 하나씩 필요하다.
• 예시에서 사용되는 to-do 애플리케이션에는 할 일 이벤트 메시지를 받아, DB 에 추가하는 역할을 하는 메시지 핸들러가 필요하다.
• 이렇듯 메시지 핸들러(Worker) 를 따로 두게 되면 스케일 아웃에 용이하다.
• 메시지 큐가 급증하는 부하의 버퍼와 같은 역할을 한다.
• 사용자가 아무리 많아도 동시에 메시지 핸들러를 통해 메시지가 하나씩 소비되므로 들어오는 SQL 커넥션은 메시지 핸들러 개수로 제한된다.

결과적 일관성

• 비동기 메시지의 경우 작업이 완료되는데 약간의 시간이 발생한다.
• 이러한 부수 효과를 결과적 일관성이라고 한다.
• 모든 메시지의 처리가 끝나면 애플리케이션 데이터의 상태가 정확해지는데, 그 이전 시점에는 일관성이 깨질 수 있다.
• 이를 해결하기 위해 메시지가 모두 처리가 완료되었다는 이벤트를 통해 데이터를 갱신함으로써 해결할 수 있다.

21.4 메시지 핸들러로 기능 추가하기

이벤트 지향 아키택처

• 이벤트 지향 아키텍처는 애플리케이션이 모든 일을 즉각 동기적으로 처리하는 대신 이벤트를 통해 다른 구성 요소에 자신의 현재 상태를 알리는 방식이다.
• 이벤트를 발행하는 로직을 변경하지 않고도 이벤트 처리 로직을 바꿀 수 있으므로 애플리케이션의 구성 요소 간 결합도를 느슨하게 하는 효과가 있다.

메시지 핸들러를 이용하여 새 기능 추가하기

• 메시지 핸들러를 이용하여 새로운 기능을 추가하는 가장 쉬운 방법은 새로운 메시지 핸들러의 그룹을 만들고, 모든 메시지를 수신하도록 하되 이벤트 처리를 다르게 하는 것이다.
• 이렇게하면 기존 컨테이너에는 수정이 일어나지 않고, 신규 기능에 대한 컨테이너만 실행시키면 되기 때문에 배포의 부담이 크게 낮아진다.

21.5 비동기 메시징 패턴 이해하기

Pub-Sub (Publish-Subscribe) 패턴

• 발행자(Publisher) 가 메시지를 특정 주제(Topic) 이나 채널 (Channel) 에 게시하면, 해당 주제를 구독(Subscribe) 한 모든 구독자(Subscriber) 가 메시지를 받는 방식이다.
• 이 패턴에서는 퍼블리셔가 메시지를 사용한 것이 누구고, 어떻게 처리하며, 언제 처리가 끝나는지 알 수 없다.
• 한 명의 발행자가 여러 구독자에게 메시지를 전달해야 하는 다대다 통신에 사용한다.
• 상황에 따라 Pub/Sub 패턴이 적합하지 않을 수 있다.

Rquest-Response 패턴

• 클라이언트가 메시지 큐에 메시지를 전달하고 응답을 기다린다.
• 메시지 핸들러는 요청 메시지를 처리한 다음 메시지 큐에 응답한다.
• 메시지 큐는 다시 응답을 클라이언트에게 전달한다.
• 하나의 요청에 대해 하나의 응답이 매핑되는 일대일 통신이다.
• 핸들러와 클라이언트가 기다리는 동안 다른 작업을 할 수 있다는 비동기 메시징의 장점을 그대로 유지하면서도 일반적인 동기 서비스 호출을 대체할 수 있다.