Message Queue Use Cases
https://goodgid.github.io/Tech-How-To-Choose-A-Message-Queue-2/
Log Processing and Analysis
-
eCommerce 사이트의 경우
-
고객의 로그를 분석하여 상품 추천 등 데이터로 활용을 한다.
-
위 다이어그램은 ELK 스택을 사용하는 일반적인 아키텍처이다.
-
-
Kafka는 각 인스턴스에서 대용량 로그를 효율적으로 수집하고
-
ElasticSearch는 Kafka가 수집한 로그를 인덱싱하여 빠른 텍스트 검색을 할 수 있게 해 준다.
-
그리고 Kibana는 ElasticSearch에 올라간 데이터에 대해 검색 및 시각화 UI를 제공한다.
-
Data Streaming for Recommendations
-
유저가 어떤 제품을 클릭하면
-
Click Stream은 Kafka에 의해 수집되고
-
Flink는 Click Stream 데이터를 집계한다.
-
그렇게 수집된 데이터는 Data Lake에서 적절하게 제품과 고객 간의 관계를 형성하고 Machine Learning 학습 데이터로도 사용되어 고객에게 제품을 추천하는데 도움을 준다. 결과적으로 위 과정을 통해 사용자 편의성을 증가시키는 구조를 갖게 된다.
-
System Monitoring and Alerting
-
Log Processing and Analysis와 비슷하게 Monitoring과 Troubleshooting을 위해 System Metric 정보를 수집한다.
-
2개의 UseCase 차이는 Metric은 구조화된 데이터라면 Log는 비구조화된 텍스트이다.
-
Metric 데이터는 Kafka와 Flink로 전송되고
-
이렇게 수집된 데이터는 Real Time monitoring dashboard 및 Alerting System에 사용된다.
-
-
Metric 데이터는 다양한 수준으로 수집되고 그로 인해 전체 시스템을 보다 완벽하게 모니터링할 수 있게 만든다.
Delayed Messages
-
때로는 특정 메시지를 지연시키고 싶을 수 있다.
-
RabbitMQ는 메시지 헤더에 특정 값을 세팅하면 지연 기능을 사용할 수 있다.
- 반면 Kafka는 메시지를 실시간으로 전송하는 데에 중점을 두고 있으므로 지연시키는 기능은 명시적으로 내장되어 있지 않다.
-
그렇다고 지연 기능을 위해 RabbitMQ을 도입하는 건 멍청한 선택이다.
Kafka에서 지연 기능 사용 방법
-
타임스탬프와 함께 메시지 전송
-
메시지에 전송 시간을 포함하여
-
컨슈머가 메시지를 처리하기전에 로직을 태워서 요구 사항을 충족시킨다.
-
-
Topic을 활용한 Delay Queue
-
즉시 처리해야 하는 토픽과 지연시켜 처리해야 하는 토픽을 생성하여
-
상황에 맞는 요구 사항을 충족시킬 수 있다.
-
-
Apache Kafka Streams 또는 Kafka Connect를 사용한 처리
-
Kafka Streams 또는 Kafka Connect와 같은
-
Kafka의 스트리밍 라이브러리를 사용하여 메시지를 가져와서 지연시키는 작업을 수행할 수 있다.
-
-
추가 레이어 또는 서비스 도입
-
기존 Kafka 시스템에 추가적인 레이어 또는 서비스를 도입하여 지연 메시지를 처리할 수 있다.
- ex) 메시지를 지연시키고 필요한 시간이 경과하면 다른 토픽으로 전송한다.
-
Change Data Capture(CDC)
-
CDC(Change Data Capture)란 다른 시스템에 Replication 또는 Cache/Index 업데이트를 위해 DB 변경 사항을 Streaming 하는 개념을 뜻한다.
-
위그림을 보면 알 수 있듯이 Transaction Log는 Kafka로 전송되고 ElasticSearch, Redis 및 Replication DB는 그 목적에 맞게 데이터를 가공해 사용한다.
- 이러한 아키텍처는 데이터를 최신 상태로 유지하고 Horizontal Scalability를 쉽게 만든다.
-
예를 들어 또 다른 시스템을 추가하고자 한다면 Kafka Connector를 사용하여 스트리밍 하기만 하면 된다.
- 그래서 Kafka를 사용한 CDC는 굉장히 유연한 구조를 갖게 된다.
Application Migration
-
Legacy Services를 개선하는 것은 굉장히 어렵다. 그러나 MQ와 같은 미들웨어를 사용하면 위험을 줄일 수 있다.
-
예를 들어, 위 그림에서 Order Service를 개선하기 위해 기존 Order Service는 ORDER라는 Topic에 메시지를 전송하고 신규 Order Service는 ODERNEW라는 Topic에 메시지를 전송한다.
-
그리고 Pre-Migration Reconciliation은 ORDER와 ORDERNEW 값을 비교하여 만약 그 결과가 같다면 신규 Order Service는 문제가 없다고 판단할 수 있다.
-
-
정리하자면 Kafka Topic 개념을 활용하여 기존 Services와 신규 Services를 병렬로 운영하며 신규 Services에 대한 유효성을 검증을 손쉽게 할 수 있는 구조를 만들 수 있다.
- 즉 MQ를 사용하면 Legacy Services의 Migration Risk를 낮출 수 있다.
