2025 07 24
2025-07-24¶
Delayed MQ¶
참고: https://blog.leocat.kr/notes/2018/07/31/rabbitmq-delayed-queue
- RabbitMQ에서 Delayed MQ를 구현할 수 있는 방법 2가지
1. Delayed Queue 설정
- https://www.rabbitmq.com/community-plugins
- 커뮤니티 플러그인으로
rabbitmq_delayed_message_exchange가 있음.x-delayed-type을 넣어 exchange 생성하면 사용 가능
- 해당 플러그인은 Erlang Mnesia 테이블에 메시지 저장 + 타이머 기반 라우팅 시점 결정
- 싱글 카피로 구성되기 때문에 클러스터의 한 개 노드에만 디스크 장애가 발생해도 지연중인 메시지가 유실됨
- RabbitMQ가 Mirror/Quorom 으로 장애에 대처하는 것과 다르게, RabbitMQ 입장에서 라우팅 기다리는 메시지의 HA 보장할 수 없음
- 또한 15분으로
x-delay를 설정했으나 3일 후 라우팅되는 이슈도 있었음. - 프로덕션에서 쓰기 부적절할 수 있음 2. RabbitMQ-native Delayed Queue
- 이후 처리되길 바라는 시간만큼 ttl 설정하여 queue에 넣음
- ttl 만료되어 해당 메시지 DLX로 이전
- DLX를 컨슈밍하여 처리하면, 기다리는 것과 같은 효과
- 해당 방식 추천
Akka actor 대신 RabbitMQ¶
- Akka Actor에서 초당 100건 처리하면 어려울까?
- 경량 쓰레드를 통해 동시성/분산처리 지원하지만 한계가 있음
- Blocking 작업에 취약
- Actor 메시지 큐 과부하 (메모리 사용량이 늘어남)
- Backpressure 한계: 처리속도 제어가 어려움
- 장기간 Blocking 발생시 전체 처리 지연도 가능. 하나가 18초 지연되면 actor pool 충분히 큰게 아니라면 성능 저하 가능
- Akka로만 처리하려면 actor pool tuning, backpressure 조치가 필요할 듯
- RabbitMQ
- 큐잉 기반 버퍼링: 메시지가 큐에 남아 순차 처리되어, publisher/client
- prefetchCount 등 소비자 속도 조절: rabbitMQ 플로우 조절 가능
- 워크로드 분산: 병렬처리하여 scale-out에 용이
- 생산자/소비자 서비스 분리도 가능: 개발 언어 무관, 타 시스템 연동도 가능
- 비동기/이벤트 기반 구조: 전체 서비스 응답성 해치지 않고 처리 가능
- 차이
- Akka Actor: 어플리케이션 내부의 동시성/상태캡슐화/이벤트 수신-응답-복구에 초점
- 복잡한 병렬/분산 상태관리/격리/장애 복구/선언적 동시성 제어가 필수인 시스템에 더 강력
- MQ: 시스템간 비동기적 데이터 전달에 최적화
- Akka Actor: 어플리케이션 내부의 동시성/상태캡슐화/이벤트 수신-응답-복구에 초점
VectorDB, ElasticSearch¶
- VectorDB
- 고차원의 벡터 데이터(숫자 배열)을 효율적으로 저장 + 유사도 기반 검색할 수 있도록 특화된 DB
- RDB는 정확한 일치로 데이터 찾지만...
- VectorDB는 이미지/문장/오디오 등 비정형 데이터를 임베딩으로 벡터화 -> 수십~수천 차원의 숫자 리스트 변환 -> 벡터 거리/유사도로 기준 가장 비슷한 항목 찾음
- 주요 특징
- 대용량, 고차원 벡터 데이터 저장/관리 최적화
- 빠른 유사도 기반 검색 (k-Nearest Neighbor Search)
- RAG, AI 기반 추천, 의미 검색 등에서 최신 AI 활용 분야에서 많이 사용
- 메타데이터, 벡터값 함께 관리
- ES
- ES는 텍스트 기반 검색엔진이지만, 최근에는 벡터 데이터 타입도 지원하여 VectorDB 역할 수행도 가능
- 비정형 텍스트 데이터를 대상으로 빠르고 정확하게 원하는 정보 추출하도록 설계
dense_vector: 고차원 벡터 데이터 저장 가능
- ES는 텍스트 기반 검색엔진이지만, 최근에는 벡터 데이터 타입도 지원하여 VectorDB 역할 수행도 가능