팀 프로젝트) EKS 기반 3클러스터 아키텍처 설계

☁️ Datacenter / Kafka / Monitoring 분리의 이유

---

📌 들어가며

이번 프로젝트에서는 AWS EKS 환경에서 세 개의 클러스터를 독립적으로 운영하고 있다.

클러스터	주요 역할	주요 구성 요소
🏢 Datacenter Cluster	서비스 실행 및 로그 수집	System & Service InputGen, FluentBit/Fluentd, Prometheus Agent, Node Exporter
💬 Kafka Cluster	로그/이벤트 브로커링 및 데이터 스트리밍	Strimzi Kafka (Broker, KRaft 기반)
📊 Monitoring Cluster	중앙 관측 및 분석	Elasticsearch, Kibana, Grafana, Central Prometheus, Kafka Connector

이 구조는 단순히 워크로드를 분산하기 위한 것이 아니라, 안정성, 보안, 성능, 확장성을 동시에 확보하기 위한 설계이다.

---

🏗️ 1️⃣ Datacenter Cluster — 서비스와 로그의 중심

Datacenter Cluster는 실제 서비스와 로그가 발생하는 중심 클러스터이다.

주요 구성 요소

• system-inputgen, service-inputgen : 로그 생성기 (서비스 이벤트, 시스템 로그 등)
• FluentBit → Fluentd : 로그 수집 및 Kafka 전송
• Prometheus Agent : 메트릭 수집 후 중앙 Prometheus로 Remote Write
• Node Exporter : 노드 리소스 상태 모니터링

역할

• 모든 서비스 Pod의 로그와 메트릭을 1차 수집
• Kafka Cluster로 실시간 전송
• 클러스터 내부 자원만 다루기 때문에 보안적으로 폐쇄된 구조 유지

✅ 핵심 포인트: 서비스의 실행과 로그 수집이 한 곳에서 일어나는 “데이터 발생 영역”

---

⚙️ 2️⃣ Kafka Cluster — 로그 스트림의 백본

Kafka Cluster는 Datacenter와 Monitoring 사이의 데이터 전달 허브이다.
이곳에서 모든 로그와 메트릭이 “스트리밍 파이프라인” 형태로 이동한다.

주요 구성 요소

• Strimzi Kafka (KRaft 기반 Broker)
• 내부 Topic 구조:
  • service-topic, system-auth-topic, system-kmsg-topic, 등
  • 각 로그 유형별로 분리되어 관리

역할

• Datacenter에서 들어온 Fluentd 로그를 안정적으로 버퍼링
• Monitoring Cluster의 Kafka Connector가 해당 Topic을 구독하여
  Elasticsearch로 전달

✅ 핵심 포인트: “데이터 중계 계층 (Data Backbone)”으로서 클러스터 간 비동기 통신을 보장

---

📈 3️⃣ Monitoring Cluster — 중앙 관측 및 분석 허브

Monitoring Cluster는 모든 데이터의 최종 종착지이자 관측 중심이다.

주요 구성 요소

• Elasticsearch : 로그 저장 및 검색
• Kibana : 로그 분석 및 시각화
• Central Prometheus : Prometheus Agent로부터 메트릭 수집
• Grafana : 대시보드 및 알림 설정
• Kafka Connector : Kafka → Elasticsearch Sink 역할 수행

역할

• Datacenter와 Kafka에서 수집된 데이터를 중앙화
• Elasticsearch/Kibana로 로그 인덱싱 및 검색
• Prometheus + Grafana로 전체 시스템 상태를 실시간 시각화
• Kafka Connector를 통해 로그 파이프라인 자동화

✅ 핵심 포인트: “관측의 중앙 허브(Central Observability Plane)”로서 모든 데이터의 가시화를 담당

---

🔒 왜 이렇게 클러스터를 나누었을까?

구분	설명	기대 효과
⚡ 장애 격리 (Fault Isolation)	Datacenter 장애가 Monitoring으로 전파되지 않음	관측 시스템 안정성 확보
🔐 보안 분리 (Security Isolation)	로그 수집 영역과 분석 영역을 분리	민감 로그 접근 최소화
⚙️ 성능 분리 (Performance Isolation)	Kafka, Elasticsearch, Prometheus 같은 고부하 워크로드 분리	리소스 경쟁 최소화
🚀 확장성 (Scalability)	각 클러스터를 목적에 따라 독립 확장 가능	유연한 인프라 운영
🌍 관측 통합 (Centralized Observability)	Prometheus Agent → Central Prometheus, Kafka → Elasticsearch	전체 인프라의 단일 뷰 확보

---

🧠 구조적으로 얻는 효과

1. 서비스 안정성 극대화
   • 서비스와 관측 계층이 분리되어 장애 전파 차단
   • 모니터링 시스템이 다운되어도 서비스는 정상 작동
2. 운영 효율성과 자동화
   • Terraform + ArgoCD로 각 클러스터를 IaC 관리
   • GitOps 기반으로 배포/롤백 일관성 확보
3. 보안과 데이터 경계 명확화
   • Datacenter는 내부 수집만, Monitoring은 외부 대시보드만 담당
   • Kafka를 통해 안전한 데이터 경계 유지
4. 확장 가능한 Observability 구조
   • 클러스터가 추가되어도 Prometheus Agent만 배포하면 중앙 통합 가능
   • “하나의 Grafana에서 전체 인프라”를 모니터링

---

✅ 결론

세 개의 클러스터를 용도별로 분리한 이유는
안정성(Availability), 보안(Security), 성능(Performance), 확장성(Scalability)
네 가지를 모두 확보하기 위함이다.

 

클러스터	핵심 역할	이점
Datacenter	로그·메트릭 발생	서비스 운영 독립성
Kafka	데이터 브로커링	안정적 스트림 전달
Monitoring	관측·분석 허브	중앙 집중형 가시성 확보

---

✨ 한 문장 요약

“EKS 기반 3클러스터 구조는 서비스·데이터·관측을 완전히 분리하여
장애에 강하고, 보안적이며, 확장 가능한 인프라를 만든다.”