Metrics & Log Platform on ECK

Projects |

Metrics & Log Platform on ECK

EKS 클러스터에 ECK(Elastic Cloud on Kubernetes)를 오픈소스로 직접 구축하고, 서로 다른 VPC에 분산된 전사 서버(EC2, EKS)를 연결하여 메트릭과 로그를 한곳으로 수집하는 플랫폼입니다.
담당: 플랫폼 아키텍처 설계, 수집 경로 확보, Agent 배포와 관리, 대시보드 구축

1. Overview

EKS 클러스터에 ECK(Elastic Cloud on Kubernetes)를 오픈소스로 직접 구축하고, 여러 VPC에 분산된 전사 서버(EC2, EKS)의 메트릭과 로그를 중앙에서 수집하는 플랫폼을 구축했습니다.

Fleet Server를 통해 각 서버에 Elastic Agent를 중앙 배포/관리하고, Kibana에서 리소스 사용 추이와 로그를 확인할 수 있도록 대시보드를 구성했습니다.

Where This Fits in Company-wide Monitoring

범위도구
핵심 PG 영역Datadog
그 외 서버Elastic Stack (이 프로젝트)

전사 모니터링은 두 도구가 영역을 나눠 담당하고 있으며, 이 프로젝트는 후자를 맡습니다. Elastic Stack 운영이 안정화되면 통합 범위를 넓히는 것을 검토하고 있습니다.

Scope: In and Out

구분내용
수집서버 메트릭(CPU, Memory, Disk), 컨테이너 로그
확인리소스 사용 추이, 로그 검색, Kibana 대시보드
별도 영역알림 규칙 적용 범위와 장애 대응 절차는 이 플랫폼과 분리해 관리

데이터를 수집/가시화하는 것과 장애를 자동으로 탐지/통보하는 것은 다른 문제이며, 이 플랫폼은 전자를 담당합니다.

2. Background

기존에는 외부 SaaS 모니터링이 일부 서버만 커버하고 있었고, 나머지 서버에는 모니터링 도구 자체가 없는 상태였습니다.

장애가 발생해도 서버마다 SSH로 접속해서 수동으로 확인해야 했고, 리소스 트렌드 파악이나 사전 대응이 불가능했습니다.

이를 해결하기 위해 ECK를 직접 구축하여 나머지 서버를 한곳에서 관측할 수 있는 플랫폼을 만들게 되었습니다.

3. Problem Statement

문제영향
상당수 서버에 모니터링 도구 없음장애 시 서버별 SSH 접속으로 수동 확인
기존 SaaS 모니터링은 일부 서버만 커버나머지 서버는 사각지대
리소스 트렌드 파악 불가Disk Full 등 사전 대응 불가능
서버가 여러 VPC에 분산수집 경로 없이는 중앙 수집 불가
EKS 컨테이너 로그 수집 없음MSA 서비스 디버깅 어려움

4. Architecture

Data Tiers & Backup

구분노드용도스토리지
Hot (조회 계층)3실시간 대시보드, 최근 데이터EBS gp3
Cold (조회 계층)3과거 데이터 조회EBS st1
S3 스냅샷 (백업)-매일 02:00 스냅샷, 장기 보관S3

Hot과 Cold는 Kibana에서 바로 조회되는 온라인 데이터 계층이고, S3 스냅샷은 조회 대상이 아닌 백업입니다.

Basic 라이선스 범위에서 구축했기 때문에 searchable snapshots를 사용할 수 없어, S3는 일반 스냅샷 저장소로만 쓰고 조회는 Hot/Cold에서만 이루어지도록 보관 기간을 설계했습니다.

Restore Verification

백업이 존재한다는 것과 복원이 된다는 것은 다른 문제이므로, S3 스냅샷에서의 복원 절차를 직접 수행해 확인했습니다.

Core Components

  • ECK on EKS: Elasticsearch 8.17.0 클러스터 - Hot 3노드 / Cold 3노드 (오픈소스 직접 구축)
  • Kibana: 메트릭/로그 시각화 및 대시보드
  • Fleet Server: Elastic Agent 중앙 관리 (정책 배포, 버전 관리)
  • ILM: 자동 데이터 이동 (Hot → Cold → Delete)
  • SLM: 매일 02:00 S3 스냅샷 (장기 보관)
  • DaemonSet: EKS 컨테이너 로그 자동 수집

Establishing the Collection Path

수집 대상 서버가 여러 VPC에 흩어져 있어, Elasticsearch 클러스터까지 도달할 경로가 필요했습니다.

현재는 수집 대상 EC2의 NAT 공인 출구 IP를 internet-facing NLB의 인바운드 허용 범위에 등록하는 방식으로 연결되어 있습니다.

다만 내부 모니터링 트래픽이 공인 경로를 거치는 구조이므로, internal NLB 등 사설 통신 경로로의 전환을 검토 중입니다. (검토 단계이며 아직 적용하지 않았습니다.)

5. Current Status

항목상태
Fleet 등록 AgentEC2 + EKS 대상 배포/관리 중
수집 메트릭CPU, Memory, Disk (/, /data)
대시보드전 대상 서버 리소스 대시보드 구축 완료 (Kibana)
EKS 로그DaemonSet으로 컨테이너 로그 수집
스냅샷매일 02:00 S3 자동 백업 (복원 절차 검증 완료)
고도화진행 중 (로그 파이프라인 확장, 알림 연동, 사설 경로 전환 검토)

6. Results

지표BeforeAfter
모니터링 커버리지일부 서버만 (SaaS)SaaS 미커버 서버까지 확대
리소스 확인서버별 SSH 접속Kibana 통합 대시보드
Agent 관리없음Fleet 중앙 관리
수집 경로VPC별 단절여러 VPC에서 중앙 수집
데이터 보관없음S3 매일 스냅샷
EKS 로그수집 없음DaemonSet 자동 수집

7. Limitations & Next Steps

  • 내부 모니터링 트래픽의 공인 경로 의존을 줄이기 위한 사설 통신 경로 전환
  • 로그 파이프라인 확장 및 알림 규칙 연동
  • Basic 라이선스 제약(searchable snapshots 미지원) 하에서의 장기 데이터 조회 전략 개선

8. Used Skills

  • ECK (Elastic Cloud on Kubernetes) - 오픈소스 직접 구축
  • Elasticsearch 8.17.0
  • Kibana (대시보드/시각화)
  • Elastic Agent + Fleet Server
  • EBS gp3 (Hot) / st1 (Cold) / S3 (Snapshot)
  • ILM, SLM
  • Kubernetes DaemonSet
  • NLB, Security Group, NAT Gateway