ELK 와 EFK 파헤치기

🎯 ELK vs EFK: 어떤 로그 스택이 나에게 맞을까?

1. ELK와 EFK란?

• ELK
  • Elasticsearch: 분산형 검색·분석 엔진으로, 로그를 인덱싱하고 빠르게 검색할 수 있음
  • Logstash: 다양한 소스에서 로그를 수집·변환·전송하는 Java 기반 파이프라인 플랫폼
  • Kibana: Elasticsearch 데이터를 시각화하는 웹 기반 대시보드
• EFK
  • Elasticsearch와 Kibana는 동일
  • 로그 수집기인 Logstash 대신 Fluentd(또는 Fluent Bit) 사용
  • Fluentd는 CNCF 프로젝트로, 경량·Kubernetes 친화적

2. 아키텍처 비교

[로그 소스]
    ├── ELK: Logstash → Elasticsearch → Kibana
    └── EFK: Fluentd/Fluent Bit → Elasticsearch → Kibana

 

• Logstash: JVM 기반, 강력한 grok 필터링, 다양한 입출력 플러그인 지원
  
• Fluentd/Fluent Bit: C/Ruby 또는 C 기반, 경량, Kubernetes용 데몬셋에 최적화

3. 주요 비교 포인트

항목	ELK (Logstash)	EFK (Fluentd / Fluent Bit)
성능/리소스	무겁고 메모리 사용 많음 (1 GB 이상 상태 흔함)	경량, Fluent Bit는 수십 MB 수준으로 효율적
설정 난이도	grok 기반 복잡한 필터, 유연성 높음	단순한 태그 기반 라우팅, 설정 쉬움
확장성	다양한 Elastic 플러그인, 모놀리식 시스템에 적합	CNCF 생태계, 쿠버네티스/Prometheus와 호환성 우수
안정성	내부 큐에 메모리 사용 → 장애 시 로그 손실 위험 있음	디스크 버퍼링 가능 → 장애 시 메시지 손실 최소화 가능
운영 편의성	Kibana에서 관리 UI 제공	Fluentd UI 별도 실행, 모니터링용 데몬 필요

4. 언제 어떤 스택을 선택해야 할까?

• ELK 추천 시나리오
  • 로그 필터링·파싱·가공이 다양한 환경
  • 모놀리식 서버 기반, JVM 환경 전반에 익숙한 팀
  • Elastic 제품군과 깊은 연동이 필요한 경우
• EFK 추천 시나리오
  • Kubernetes 클러스터 위의 컨테이너 로그 수집 필요
    
  • 리소스 제한 환경 혹은 수십~수백 MB 일 단위로 가볍게 운영하고 싶은 경우
  • CNCF 생태계와 연계해 로그 + 메트릭 + 이벤트 통합 모니터링을 구축하고 싶을 때

5. 결론 & 추천 조합

• MSA / 컨테이너 기반 → → EFK (Fluentd / Fluent Bit + Elasticsearch + Kibana)
• 모놀리식 / 강력한 처리 필요 → → ELK (Logstash + Elasticsearch + Kibana)
• 더 가볍게 운영하려면 → Filebeat + Fluentd + Elasticsearch + Kibana (BEFK 조합도 가능)