ELK vs EFK 스택

💡ELK란?

ELK 스택은 로그 수집, 저장, 시각화를 위한 오픈소스 도구 조합이다.

• Elasticsearch: 수집한 로그를 저장하고 검색할 수 있는 검색 엔진
• Logstash: 로그 수집기, 다양한 포맷의 로그를 수집하고 변환하여 Elasticsearch로 전송
• Kibana: Elasticsearch에 저장된 데이터를 시각화하는 도구

💡EFK란?

EFK 스택은 ELK에서 Logstash 대신 Fluentd를 사용하는 조합이다.

• Fluentd: 로그 수집기, 경량이며 Kubernetes 친화적인 플러그인 구조를 가짐
• 나머지는 ELK와 동일 (Elasticsearch + Kibana)

스택	수집기	특징
ELK	Logstash	설정 복잡, 기능 풍부하지만 무거움
EFK	Fluentd	경량, Kubernetes에서 많이 사용됨, 설정 간편

• Logstash vs Fluentd
  • Logstash는 Java 기반, 시스템 자원 많이 사용
  • Fluentd는 C 및 Ruby 기반, 플러그인 유연성 높음

---

사용처

• 마이크로서비스 아키텍처(MSA) 환경에서 로그 수집 및 분석
• Kubernetes 클러스터에서 Pod별 로그 모니터링
• DevOps, SRE 팀의 로그 기반 문제 분석 및 시각화

---

Kubernetes 환경에서의 EFK 스택 역할

🚀 Kubernetes에서의 역할 및 작동 방식

🔹 1. 로그 수집 (Fluentd)

• 각 Node에 DaemonSet 형태로 Fluentd가 배포됨
• Node 내의 /var/log/containers/ 경로에서 Pod의 stdout/stderr 로그를 수집
• 다양한 필터 및 플러그인으로 로그 포맷 변경, 필터링 가능
• 로그를 Elasticsearch로 전송

🔹 2. 로그 저장/색인화 (Elasticsearch)

• Fluentd가 전달한 로그 데이터를 저장
• 로그를 시간순, 레이블, Pod 이름 등으로 색인 처리
• 고속 검색을 위한 구조 제공

🔹 3. 로그 시각화 (Kibana)

• Kibana를 통해 Elasticsearch의 데이터를 시각화
• 특정 시간대, 특정 Pod, Namespace, 로그 레벨별로 검색 가능
• 로그 기반 대시보드 생성 및 분석

---

📊 어떤 문제를 해결할 수 있을까?

문제	EFK를 통해 해결하는 방식
Pod가 갑자기 죽었는데 원인을 알 수 없음	Fluentd가 남긴 로그로 분석 가능
서비스가 느려졌는데 어느 지점에서 지연되는지 파악 불가	Kibana에서 서비스 간 로그 흐름 분석
수많은 마이크로서비스의 로그가 흩어져 있음	중앙 집중화된 로그 플랫폼 제공
특정 오류가 반복되는데 얼마나 자주 발생하는지 모름	Elasticsearch의 쿼리 기능으로 오류 발생 횟수 통계화

---

🧠 실무 적용 시 체크포인트

• Fluentd의 로그 필터링/태그 전략을 설계해야 함 (예: namespace별 구분)
• Elasticsearch의 보안 설정(X-Pack 등) 필요 시 고려
• Kibana에서 사용자 권한 관리 필요할 수 있음
• 로그 저장 용량 관리: retention 정책 설계

---

🛠 EFK 설치 예시 (Helm 기반)

```bash

Elasticsearch 설치

helm repo add bitnami https://charts.bitnami.com/bitnami helm install elasticsearch bitnami/elasticsearch

Kibana 설치

helm install kibana bitnami/kibana

Fluentd 설치 (Kubernetes 로그용 커스텀 config 필요)

helm install fluentd bitnami/fluentd
–set aggregator.configMap=fluentd-config