Apache Kafka, ActiveMQ, Redis

1. Kafka: 오픈 소스 분산 이벤트 스트리밍 플랫폼으로, 대량의 데이터 스트리밍을 실시간으로 처리할 수 있도록 설계된 메시지 브로커(Message Broker)입니다.

 

source application(클릭로그/결제로그)과 target appplication(로그적재/로그처리)의 결합도를 줄이기 위해서 나왔다. 각종 데이터를 담는 topic, queue의 역할을 하는 것이 있다. 데이터를 넣는 역할은 Producer, 데이터를 가져가는 Consumer는 라이브러리로 되어있어 어플리케이션에서 쉽게 쓸 수 있음.

---

📌 Kafka의 주요 개념

1. Producer (생산자)

• Kafka에 데이터를 발행(전송)하는 클라이언트
• 데이터를 특정 토픽(Topic)에 보냄
• 데이터를 파티션(Partition) 단위로 나눠 저장

2. Broker (브로커)

• Kafka 서버를 구성하는 핵심 요소
• 여러 개의 브로커가 클러스터를 이루어 동작
• 데이터를 수신하고 저장하며, 필요할 때 Consumer에게 전달

3. Topic (토픽)

• Kafka에서 데이터를 구분하는 단위
• 하나의 토픽은 여러 개의 파티션으로 나뉨
• Producer가 데이터를 발행(Publish)하면, 토픽에 저장됨

4. Partition (파티션)

• 하나의 토픽은 여러 개의 파티션으로 구성됨
• 데이터를 분산하여 저장하고 처리 속도를 높이는 역할
• 동일한 메시지가 여러 파티션에 나뉘어 저장될 수 있음
• 리더(Leader) 파티션과 팔로워(Follower) 파티션으로 나뉨 (리더가 메인으로 데이터를 처리)

5. Consumer (소비자)

• Kafka에서 데이터를 구독(Subscribe)하는 클라이언트
• 특정 토픽의 데이터를 읽어 처리함
• Consumer Group을 형성해 분산 처리가 가능

6. Consumer Group (컨슈머 그룹)

• 다수의 컨슈머(Consumer)가 하나의 그룹을 형성하여 데이터를 분산 소비
• 하나의 파티션은 같은 컨슈머 그룹 내에서 오직 하나의 컨슈머만 처리 가능
• 여러 개의 컨슈머 그룹이 동일한 데이터를 중복 소비할 수 있음

7. Zookeeper

• Kafka 클러스터의 상태를 관리하는 코디네이터 역할
• 브로커 목록 관리, 리더 선출, 컨슈머 그룹 상태 관리 등의 역할 수행
• 최근에는 **KRaft (Kafka Raft)**라는 새로운 아키텍처로 대체 중

---

⚙ Kafka의 동작 방식

1. Producer가 특정 Topic에 데이터를 전송
2. Broker가 데이터를 Partition에 저장
3. Consumer가 Topic을 구독하여 데이터 소비
4. Consumer Group이 있을 경우, 각 Consumer는 다른 Partition의 데이터를 병렬로 처리
5. Kafka는 메시지를 삭제하지 않고 일정 기간 저장 (Retention Policy)

---

🔥 Kafka의 주요 특징

1. 고성능 및 확장성

• 파티션을 활용하여 데이터 분산 저장 및 병렬 처리 가능
• 다수의 브로커를 추가해 클러스터 확장 가능

2. 내구성(Durability)

• 데이터를 복제(Replication)하여 장애 발생 시에도 데이터 유실을 방지
• Leader-Follower 구조를 통해 고가용성(HA) 제공

3. 고가용성(High Availability)

• 리더 브로커 장애 발생 시, 팔로워가 리더로 승격되어 서비스 중단을 최소화

4. 실시간 처리

• 대량의 이벤트 데이터를 실시간으로 처리 가능
• Spark, Flink, Storm 등과 연동하여 실시간 스트리밍 분석 가능

5. 유연한 메시지 보존 정책

• 설정된 보존 기간(Retention Policy) 동안 메시지 저장 가능
• Consumer가 데이터를 중복 읽거나 특정 Offset에서 다시 읽기 가능

---

🔗 Kafka의 주요 활용 사례

1. 로그 및 이벤트 데이터 처리

• 서버 로그, 애플리케이션 이벤트 등을 실시간으로 수집 및 분석

2. 데이터 파이프라인

• 여러 시스템 간 데이터를 연결하여 실시간으로 전송

3. 실시간 스트리밍 분석

• Spark Streaming, Apache Flink, Apache Storm과 결합하여 실시간 데이터 분석 수행

4. IoT 데이터 수집

• 수많은 IoT 디바이스에서 발생하는 데이터를 처리 및 저장

5. 메시지 큐 시스템 대체

• 기존의 RabbitMQ, ActiveMQ 등을 대체할 수 있는 강력한 메시지 브로커 역할 수행

---

✅ 정리

• Kafka는 분산 메시징 시스템으로 실시간 데이터 처리, 로그 수집, 데이터 파이프라인 구축에 강력한 도구
• Producer → Broker → Consumer 구조로 동작
• 고성능, 확장성, 내구성, 실시간 처리 기능을 제공
• 다양한 실시간 데이터 처리 및 빅데이터 분석에 활용 가능

---

2. Apache ActiveMQ는 오픈 소스 메시징 브로커로, 다양한 프로토콜과 클라이언트 언어를 지원하는 강력한 메시지 큐 시스템입니다. JMS (Java Message Service) 표준을 준수하며, 비동기 메시징, 트랜잭션 지원, 신뢰성 있는 메시지 전달 등의 기능을 제공합니다.

ActiveMQ는 주로 전통적인 메시지 브로커 역할을 하며, 기업 애플리케이션 통합(EAI), 마이크로서비스 간 통신, 트랜잭션 기반 메시징 등에 사용됩니다.

---

📌 ActiveMQ의 주요 개념

1. Broker (브로커)

• 메시지를 송신자(Producer)와 수신자(Consumer) 간에 전달하는 역할

2. Queue (큐) - Point-to-Point 모델

• 메시지를 하나의 Consumer만 소비 가능 (1:1)
• 메시지가 처리될 때까지 저장되며, 한 번만 소비됨

3. Topic (토픽) - Publish/Subscribe 모델

• 여러 개의 Consumer가 동일한 메시지를 수신 가능 (1:N)
• 구독한 모든 Consumer가 메시지를 받을 수 있음

4. Persistent vs Non-Persistent 메시지

• Persistent 메시지: 디스크에 저장되어 브로커 장애 후에도 복구 가능
• Non-Persistent 메시지: 메모리에 저장되어 성능은 빠르지만 브로커 장애 시 데이터 손실 가능

5. Message Acknowledgment (ACK)

• Consumer가 메시지를 성공적으로 수신했음을 Broker에 알리는 방식
• Auto ACK, Client ACK, DUPS_OK, Transaction ACK 등 다양한 방식 제공

6. JMS (Java Message Service) 지원

• ActiveMQ는 JMS 표준을 준수하여 Java 기반 애플리케이션과 쉽게 연동 가능

---

💡 Kafka와 ActiveMQ를 함께 써야 할까?

Kafka와 ActiveMQ를 함께 사용하는 것은 일반적이지 않지만, 특정 상황에서는 필요할 수 있습니다.

Kafka와 ActiveMQ를 함께 사용하는 경우

✅ 기업 애플리케이션 + 실시간 스트리밍

• ActiveMQ는 기존 기업 애플리케이션(ERP, CRM)과의 통합에 강점이 있고,
• Kafka는 대량의 데이터 스트리밍과 로그 분석, 이벤트 스트리밍에 강점이 있음.
  → ActiveMQ로 트랜잭션 메시징을 처리하고, Kafka로 실시간 이벤트 스트리밍을 수행할 수 있음.

✅ 레거시 시스템과 최신 데이터 파이프라인 연결

• 기존 JMS 기반 시스템이 ActiveMQ를 사용하고 있는 경우
• 새로운 빅데이터/분산 환경에서는 Kafka가 더 적합
  → ActiveMQ에서 Kafka로 메시지를 전달하는 브릿지(Bridge) 구성 가능

✅ 비동기 트랜잭션 메시징 + 대규모 로그 처리

• ActiveMQ는 트랜잭션 메시징에 강점
• Kafka는 대량의 로그, 비동기 이벤트 처리에 강점
  → 두 개의 시스템을 병렬로 사용하여 각자의 강점을 활용

---

🔚 결론

1. Kafka는 대규모 데이터 스트리밍 및 로그 처리에 강점이 있음
2. ActiveMQ는 트랜잭션 기반 메시징 및 기존 기업 애플리케이션과의 통합에 강점이 있음
3. 두 시스템을 함께 사용할 필요는 없지만, 특정 환경에서는 결합하여 사용할 수도 있음
   • ✅ JMS 기반 애플리케이션을 유지하면서 Kafka로 데이터를 전달할 경우
   • ✅ 트랜잭션 메시징(ActiveMQ)과 실시간 이벤트 스트리밍(Kafka)을 함께 처리해야 하는 경우
   • ❌ 일반적인 메시지 큐 또는 스트리밍 중 하나의 역할만 필요할 경우에는 둘 중 하나만 선택하는 것이 효율적

---

1️⃣ 금융권 서비스 (트랜잭션 메시징 + 실시간 데이터 스트리밍)

📌 사용 이유

• ActiveMQ → 금융 시스템에서 중요한 **트랜잭션 메시징 (JMS 기반)**을 처리
• Kafka → 실시간으로 고객 활동 로그, 계좌 거래 이벤트를 분석

📌 실제 적용 사례

• ActiveMQ를 통해 은행 계좌 거래 요청을 처리 (ex. 입금, 출금, 대출 신청)
• 트랜잭션이 완료된 후, Kafka로 메시지를 전송하여 실시간 고객 알림, 대시보드 업데이트, 사기 탐지 시스템(Fraud Detection)과 연계
• Kafka Streams와 머신러닝 모델을 이용하여 이상 거래 탐지, 실시간 리스크 분석 수행

2️⃣ 이커머스 (주문 처리 + 실시간 추천 시스템)

📌 사용 이유

• ActiveMQ → 주문 처리와 같은 트랜잭션이 중요한 메시지 처리
• Kafka → 고객의 쇼핑 행동 데이터를 실시간으로 분석

📌 실제 적용 사례

• 고객이 제품을 주문하면, ActiveMQ를 통해 결제 승인, 주문 상태 업데이트를 트랜잭션 단위로 처리
• 주문 완료 후, Kafka에 메시지를 전송하여 실시간 재고 업데이트, 추천 시스템 트리거, 배송 상태 추적
• Kafka Streams를 이용하여 고객의 행동 데이터를 분석하고 개인화 추천 제공

3️⃣ 헬스케어 & 병원 시스템 (트랜잭션 기반 예약 + 실시간 환자 모니터링)

📌 사용 이유

• ActiveMQ → 병원 예약 시스템의 트랜잭션 메시지 처리
• Kafka → 환자의 실시간 건강 데이터를 수집하여 분석

📌 실제 적용 사례

• 환자가 온라인에서 진료 예약을 하면 ActiveMQ를 통해 트랜잭션 기반으로 예약 관리
• 병원 시스템에서 실시간으로 환자의 심박수, 혈압, 혈당 데이터를 Kafka로 전송하여 이상 상태 탐지 및 경고
• Kafka 데이터를 AI 기반으로 분석하여 응급 환자 예측, 병원 리소스 최적화

📌 결론: Kafka와 ActiveMQ를 함께 사용하는 경우

✔ 트랜잭션이 중요한 경우
→ ActiveMQ는 메시지 순서 보장, 트랜잭션 지원, JMS 연동 가능
✔ 대규모 이벤트 스트리밍이 필요한 경우
→ Kafka는 높은 처리량, 분산 환경에서 확장성 보장, 데이터 보존 가능

---

트랜잭션이 필요한 경우

✅ 은행 계좌 이체: 돈이 한 계좌에서 빠져나가고, 다른 계좌로 정확히 들어가야 함
✅ 온라인 쇼핑 결제: 결제가 완료된 후 재고 감소, 배송 정보 저장이 모두 정상적으로 수행되어야 함
✅ 항공권 예약: 한 좌석을 동시에 여러 사람이 예약할 수 없도록 보장
✅ 주문 처리 시스템: 주문이 성공하면 결제, 배송, 재고 차감이 동시에 이루어져야 함

 

예제: 온라인 쇼핑 주문 후 결제 성공

1) 고객 결제 완료

2) 결제 정보 데이터베이스 영구 저장(commit)

3) 서버가 다운되어도 결제 정보는 유지된다.

 

 

• ActiveMQ는 JMS 트랜잭션을 지원하여 메시지를 안전하게 처리하는 것이 중요할 때 유리
• Kafka는 기본적으로 트랜잭션을 지원하지 않지만, Kafka Streams를 활용하여 Exactly-Once 처리를 보장 가능

---

3. **Redis (Remote Dictionary Server)**는 오픈 소스 인메모리(in-memory) 데이터 저장소로, 빠른 성능과 다양한 데이터 구조 지원이 특징입니다. 일반적으로 캐시(cache), 세션 저장소(session store), 메시지 브로커(message broker), 실시간 데이터 처리 등의 용도로 사용됩니다.

Redis는 데이터를 RAM(메모리)에서 관리하기 때문에 읽기/쓰기 속도가 매우 빠름(마이크로초 단위). 또한 퍼시스턴스(데이터 지속성) 옵션이 있어 데이터를 디스크에 저장할 수도 있습니다.

---

📌 Redis의 주요 특징

1️⃣ 인메모리 데이터 저장소

• 데이터를 디스크가 아닌 메모리(RAM)에서 관리 → 빠른 속도(초당 수백만 건 처리 가능)
• 다만, RAM 기반이므로 대량의 데이터를 저장하면 비용이 증가할 수 있음

2️⃣ 다양한 데이터 구조 지원

• 단순한 Key-Value 저장뿐만 아니라 리스트(List), 해시(Hash), 셋(Set), 정렬된 셋(Sorted Set), 비트맵(Bitmap), 하이퍼로그로그(HyperLogLog) 등을 지원
• 이를 활용해 랭킹 시스템, 세션 관리, 실시간 분석 등이 가능

3️⃣ 메시지 브로커 기능 (Pub/Sub)

• Kafka, ActiveMQ와 유사하게 Publish/Subscribe(발행/구독) 메시징 시스템 지원
• 다만, Redis는 Persistent(영구 저장) 기능이 부족하므로, 단기적인 메시징에 적합

4️⃣ 분산 & 클러스터링 지원

• Redis Cluster를 사용하여 수평 확장 가능, 여러 개의 노드로 데이터를 분산하여 관리
• Master-Slave Replication으로 데이터 복제 및 장애 복구 지원

5️⃣ 데이터 영속성 (Persistence)

• 기본적으로 인메모리 DB이지만, 데이터를 디스크에 저장하는 방법 제공:
  • RDB (Redis Database Backup): 일정 주기로 데이터를 저장
  • AOF (Append Only File): 모든 연산을 로그로 기록하여 장애 복구 가능

6️⃣ 트랜잭션 지원

• Redis는 트랜잭션 기능을 제공하지만, 완전한 ACID 트랜잭션은 지원하지 않음
• MULTI, EXEC 명령어를 사용하여 여러 개의 명령어를 하나의 트랜잭션으로 실행 가능

---

📌 Kafka, ActiveMQ와 Redis를 함께 사용해야 할까?

Redis는 메모리 기반의 빠른 성능을 가지고 있으므로, 메시지 브로커로 사용할 수도 있지만 Kafka/ActiveMQ와의 역할이 다릅니다.

1️⃣ Kafka + Redis 사용 사례

✅ 실시간 로그 분석 & 캐싱

• Kafka는 대규모 로그 데이터를 수집하고,
• Redis는 가장 많이 조회되는 데이터를 캐싱하여 빠르게 제공

✅ Kafka에서 처리한 데이터를 Redis로 저장하여 빠르게 제공

• Kafka를 통해 실시간 데이터를 처리한 후, Redis에 캐시하여 빠르게 읽을 수 있도록 함
• 예제: 주식 거래 시스템에서 Kafka로 실시간 거래 데이터를 수집하고, Redis에 캐시하여 빠르게 조회 가능

2️⃣ ActiveMQ + Redis 사용 사례

✅ 세션 관리 & 메시지 큐 결합

• ActiveMQ에서 트랜잭션 메시징을 처리하고, Redis에서 사용자 세션을 관리
• 예제: 온라인 쇼핑몰에서 주문 요청을 ActiveMQ로 처리하고, Redis에 사용자 장바구니 데이터 캐싱

💡 요약

• Kafka, ActiveMQ, Redis는 각기 다른 목적에 맞게 사용됨
• Kafka는 대규모 스트리밍 데이터 처리
• ActiveMQ는 트랜잭션 기반 메시징
• Redis는 빠른 캐싱 및 간단한 Pub/Sub

🔹 Kafka와 Redis를 함께 사용하면 실시간 데이터 분석 & 빠른 조회가 가능
🔹 ActiveMQ와 Redis를 함께 사용하면 안정적인 트랜잭션 & 세션 캐싱 가능