팀 프로젝트) Kafka 구조 완벽 정리

🧱 Kafka : Producer → Broker → Topic → Consumer 흐름 이해하기

우리 프로젝트에서는 Datacenter, Kafka, Monitoring 이렇게 3개의 Kubernetes 클러스터를 구성하여
로그 수집부터 시각화까지 완전한 분산 데이터 파이프라인을 운영하고 있다.

이 중 Kafka Cluster는 데이터 허브로서 로그를 중계하고,
Monitoring Cluster에서는 Kafka Connect(ES Sink)가 이를 받아 Elasticsearch + Kibana로 분석한다.

이번 포스트에서는 이 구조의 핵심인 Kafka의 내부 구조와 데이터 흐름,
그리고 Kafka Connect를 Monitoring Cluster에 둔 이유를 함께 살펴본다.

---

🌐 전체 데이터 플로우

[Datacenter Cluster]
 ├─ auth_inputgen → system-auth-topic
 ├─ kmsg_inputgen → system-kmsg-topic
 └─ service_inputgen → service-topic
           │
           ▼
[Kafka Cluster]
 ├─ Kafka Brokers (2)
 ├─ Topics (auth, kmsg, service)
 └─ Replication & Storage
           │
           ▼
[Monitoring Cluster]
 ├─ Kafka Connect (Elasticsearch Sink)
 ├─ Elasticsearch
 └─ Kibana

---

⚙️ Kafka의 기본 구성요소 이해하기

Kafka는 “데이터 스트림 플랫폼”으로서, Producer → Broker → Topic → Consumer 구조로 동작한다.
하나씩 살펴보자 👇

---

🧩 1️⃣ Producer — 로그를 Kafka로 보내는 주체

Producer는 데이터를 생성해서 Kafka로 전송하는 애플리케이션이다.
Datacenter Cluster에 배포된 Input Generator 파드들이 이 역할을 수행한다.

Producer	역할	전송 대상 Topic
auth_inputgen	인증/접근 로그	system-auth-topic
kmsg_inputgen	커널 메시지 로그	system-kmsg-topic
service_inputgen	서비스 로그	service-topic

각 InputGen은 Fluentd → Kafka 구조를 통해 실시간 로그를 스트리밍한다.

---

📦 2️⃣ Topic — 메시지를 저장하는 논리적 채널

Kafka의 Topic은 메시지가 저장되는 공간이자 데이터의 분류 단위다.
Kafka에서는 여러 Producer와 Consumer가 Topic을 통해 데이터를 교환한다.

💡 쉽게 말하면, Topic은 “로그 종류별 데이터 파이프라인 이름”이다.

 

우리 시스템에서는 로그의 성격에 따라 세 개의 Topic을 운영 중이다.

• system-auth-topic — 인증 로그
• system-kmsg-topic — 커널 로그
• service-topic — 서비스 애플리케이션 로그

---

🔀 3️⃣ Partition — Topic 내부의 데이터 분할 단위

Partition은 '병렬성'을 위한 단위로 “하나의 Topic 안에서” 데이터를 분산 처리하기 위한 기술이다.
즉, 데이터의 종류를 구분하는 용도가 아니라, 처리 성능을 높이기 위한 용도

예를 들어:

Topic: service-log
Partitions: 3

 

• Partition 0 → Web 서버 로그
• Partition 1 → API 서버 로그
• Partition 2 → Batch 서버 로그

이런 식으로 “같은 종류의 로그이지만, 처리 주체가 다른” 경우에 병렬화를 위해 partition으로 분할할 수 있다.

즉, Topic은 내부적으로 여러 Partition으로 쪼개질 수 있고 Partition은 Kafka의 병렬성과 처리 성능을 좌우한다.

하지만 우리는 각 Topic을 1개의 Partition으로 유지하고 있다.
그 이유는 다음과 같다 👇

로그 타입이 고정되어 있고, 각 로그 스트림의 처리량이 상대적으로 낮기 때문에 순서 보장(Ordered Delivery)을 유지하는 것이 더 중요했기 때문이다.

 

즉, 단일 Partition 구조는 단순하고 안정적이며, 로그 순서를 완벽히 유지할 수 있다.

---

🧱 4️⃣ Broker — 실제 데이터를 저장하는 Kafka 서버

Kafka Broker는 메시지를 실제로 저장하고, Producer/Consumer의 요청을 처리하는 서버다.
우리 Kafka Cluster는 2개의 Broker Pod로 구성되어 있으며(AZ가 2개이기 때문), Strimzi Operator를 이용해 관리된다 (KRaft 모드 활성화).

설정	항목값
default.replication.factor	2
min.insync.replicas	2
num.partitions	1
log.retention.hours	72

이 설정 덕분에 각 메시지는 2개의 Broker에 복제되어 장애에도 안전하게 유지된다.

---

👥 5️⃣ Consumer & Consumer Group — 데이터를 읽는 주체

Kafka에서는 Consumer가 Topic으로부터 데이터를 읽는다.
Consumer들은 Consumer Group 단위로 동작하며, 하나의 Partition은 한 Consumer만 담당한다.

우리 프로젝트에서 Consumer 역할을 하는 것은 바로
👉 Monitoring Cluster에 위치한 Kafka Connect (Elasticsearch Sink Connector) 이다.

Consumer	역할	위치
Kafka Connect (ES Sink)	Kafka 로그를 Elasticsearch로 전송	Monitoring Cluster

---

🧠 왜 Kafka Connect를 Monitoring Cluster에 뒀을까?

보통 Kafka Connect는 Kafka Cluster 안에 두는 경우가 많지만, 우리 프로젝트에서는 Monitoring Cluster에 배포했다.

이 설계에는 명확한 이유가 있다 👇

🔹 1️⃣ 네트워크 경계 분리 (보안 + 관리 용이성)

• Kafka Cluster는 데이터 브로커링 전용 클러스터로 최소한의 외부 접근만 허용한다.
• Monitoring Cluster는 외부 API Gateway, Elasticsearch, Kibana 등 다양한 외부 연동 컴포넌트를 포함하므로, Kafka Connect를 이곳에 둠으로써 보안과 접근 제어를 분리했다.

🔹 2️⃣ 리소스 분리 (부하 최소화)

• Kafka Connect는 CPU·메모리 부하가 높은 Consumer 역할을 한다.
• Broker와 같은 노드에 두면 성능 저하가 발생할 수 있기 때문에, 별도의 Cluster에서 독립적으로 운영함으로써 Kafka의 안정성을 보장했다.

🔹 3️⃣ 로그 수집 → 분석 파이프라인의 자연스러운 연결

• Monitoring Cluster에는 Elasticsearch, Kibana가 함께 존재한다.
• Kafka Connect를 같은 클러스터에 두면, 네트워크 지연을 최소화하고 Elasticsearch Sink Connector의 전송 효율을 극대화할 수 있다.

---

🔁 6️⃣ 전체 데이터 흐름 요약

[Datacenter Cluster]
 ├─ auth_inputgen → system-auth-topic
 ├─ kmsg_inputgen → system-kmsg-topic
 └─ service_inputgen → service-topic
           │
           ▼
[Kafka Cluster]
 ├─ Kafka Brokers (2)
 ├─ Topic Replication Factor: 3
 └─ Data Retention: 72 hours
           │
           ▼
[Monitoring Cluster]
 ├─ Kafka Connect (ES Sink Connector)
 ├─ Elasticsearch (Index 관리)
 └─ Kibana (로그 시각화)

---

🧾 Kafka 핵심 개념 요약표

개념	설명	우리 시스템 예시
Producer	Kafka로 데이터를 보내는 주체	auth/kmsg/service inputgen
Broker	데이터를 저장하는 Kafka 서버	kafka-cluster (2개 노드)
Topic	데이터의 분류 단위	service-topic, system-auth-topic, system-kmsg-topic
Partition	Topic 내부의 분할 단위	각 Topic 1개
Consumer	데이터를 읽는 주체	Kafka Connect (ES Sink)
Consumer Group	Consumer 협업 단위	connect-es-sink-group

---

💬 정리: 이렇게 구성한 이유

✅ Kafka Cluster = 데이터 허브 (Broker 중심) → 외부 접근 최소화, 고가용성 중심 구조

✅ Monitoring Cluster = 데이터 분석 플랫폼 → Kafka Connect + Elasticsearch + Kibana 통합 관리

✅ Kafka Connect를 Monitoring에 둔 이유 → 보안 분리 + 리소스 분리 + 네트워크 효율성 극대화

---

🧩 한 문장 요약

Datacenter Cluster에서 발생한 로그를 Kafka Cluster를 거쳐 Monitoring Cluster로 전달하고,
Kafka Connect가 Elasticsearch로 실시간 전송함으로써 보안, 안정성, 확장성 모두 갖춘 완전한 로그 파이프라인을 구축했다.

---

이 구성이 진짜 운영 환경에서도 많이 쓰이는 구조로 Kafka Cluster는 브로커링만 전담해서 안정성을 확보하고,
Connect·Elastic 쪽은 분석 도메인에 가까운 Monitoring Zone으로 분리하는 방식을 선택했다.