ELK 스택(Elasticsearch · Logstash · Kibana)

1. 개요

가. 정의

대용량 로그·이벤트 데이터를 수집(Logstash/Beats)→색인·검색(Elasticsearch)→시각화(Kibana) 하는 오픈소스 로그 분석 스택으로, 경량 수집기 Beats를 포함해 Elastic Stack으로 불린다.

ELK는 세 오픈소스의 머리글자를 딴 이름이지만, 본질은 "비정형 로그를 검색 가능한 구조로 바꿔 실시간으로 질의·분석"하는 파이프라인이다. 관계형 DB가 정형 데이터를 행·열로 다루는 것과 달리, 로그는 형식이 제각각이고 초당 수만 건씩 쏟아지므로 전통적 RDBMS로는 저장·검색이 비효율적이다. ELK는 이 문제를 역색인(Inverted Index) 기반 검색엔진으로 해결한다.

나. 등장 배경 및 필요성

MSA·클라우드 네이티브 환경에서는 하나의 요청이 수십 개 서비스를 거치므로, 로그가 각 서버·컨테이너에 흩어진다. 장애가 나면 어느 서버 로그를 봐야 할지조차 알기 어렵다. 그래서 로그를 한곳에 모아(중앙 집중) 서비스·시간·상관관계로 검색할 수 있는 관측성(Observability) 기반이 필요해졌다. ELK는 상용 APM·SIEM 대비 도입 비용이 낮고, 색인·검색·시각화를 한 스택으로 제공해 로그 통합·실시간 분석의 사실상 표준이 되었다.

2. 구성 요소

flowchart LR
  B[Beats<br/>경량 수집 에이전트] --> L[Logstash<br/>수집·파싱·변환]
  L --> E[Elasticsearch<br/>색인·검색·집계]
  E --> K[Kibana<br/>시각화·대시보드]
  B -.직접 적재.-> E

각 구성요소는 파이프라인의 한 단계를 맡으며, 역할이 분리되어 있어 필요에 따라 선택적으로 조합한다. 예컨대 변환이 필요 없으면 Beats에서 Elasticsearch로 직접 적재해 Logstash를 생략할 수 있다.

Beats(수집): 각 서버에 설치되는 경량 에이전트로, Filebeat(로그 파일)·Metricbeat(지표)·Packetbeat(네트워크)처럼 목적별로 나뉜다. 자원 점유가 작아 수천 대 서버에 부담 없이 배포된다.
Logstash(변환): input→filter→output 파이프라인으로 로그를 파싱한다. 핵심은 Grok 필터로, 192.168.0.1 - GET /api 200 같은 비정형 문자열을 client_ip, method, status 필드로 구조화한다. 무거운 대신 강력한 변환이 가능하다.
Elasticsearch(핵심): Lucene 기반 분산 검색엔진으로, 역색인으로 전문 검색을, 집계(Aggregation)로 통계를 실시간 제공한다. ELK의 심장부다.
Kibana(시각화): 검색·대시보드·알림 UI. KQL 질의로 로그를 탐색하고, 시계열·히스토그램·지도 등으로 시각화한다.

구성	역할	특징
Beats	경량 수집	서버당 배포, 저부하
Logstash	파싱·변환·적재	Grok 등 강력한 필터
Elasticsearch	색인·검색·집계	역색인·분산·실시간
Kibana	시각화·알림	대시보드·탐색 UI

3. 핵심 기술 원리

ELK의 성능은 Elasticsearch의 두 가지 설계에서 나온다. 첫째, 역색인은 "문서→단어"가 아니라 "단어→해당 단어를 포함한 문서 목록"으로 색인을 뒤집어 둔다. 그래서 "error를 포함한 로그"를 찾을 때 전체를 훑지 않고 error 항목이 가리키는 문서만 즉시 반환한다. 이것이 수억 건 로그에서도 밀리초 단위 검색이 가능한 이유다.

둘째, 분산·샤딩이다. 인덱스를 여러 샤드(shard) 로 쪼개 노드에 분산하고, 각 샤드를 복제(replica) 해 둔다. 데이터가 늘면 노드를 추가(수평 확장)하고, 노드가 죽어도 복제본으로 서비스가 유지(고가용성)된다. 다만 샤드가 지나치게 많으면 오히려 오버헤드가 커지므로 샤드 수 설계가 운영의 관건이다.

기술	원리	효과
역색인	단어→문서 매핑	빠른 전문 검색
분산·샤딩	인덱스 분할·복제	수평 확장·HA
집계	색인 위 통계 연산	실시간 대시보드

4. 활용 분야

로그 분석이 기본이지만, "검색+집계+시각화"라는 특성 덕에 활용 폭이 넓다. SIEM(보안 정보·이벤트 관리) 에서는 방화벽·인증 로그를 모아 이상 로그인·공격 패턴을 실시간 탐지하고, 관측성(APM) 에서는 응답 지연·에러율을 추적한다. 예를 들어 특정 API의 5xx 에러가 급증하면 Kibana 대시보드에서 즉시 스파이크로 나타나고, 알림(Watcher)으로 담당자에게 통지된다.

분야	활용 예
로그 분석	앱·시스템 로그 통합, 장애 원인 추적
보안(SIEM)	이상 탐지·위협 헌팅·컴플라이언스
관측성(APM)	지연·에러율 모니터링, 트레이싱

5. 고려사항 및 시사점

비용·수명주기 관리: 로그는 무한히 쌓이므로 ILM(Index Lifecycle Management) 으로 오래된 인덱스를 Hot→Warm→Cold→삭제로 자동 계층화해 저장 비용을 통제해야 한다.
라이선스 이슈: Elastic이 라이선스를 SSPL로 변경하면서, AWS 주도의 오픈소스 포크인 OpenSearch가 등장했다. 벤더 종속·비용 관점에서 대체 검토가 필요하다.
표준 연계: 최근에는 OpenTelemetry 표준으로 로그·지표·트레이스를 통합 수집하는 흐름이라, ELK도 OTel 수집 파이프라인과 연계하는 방향으로 진화하고 있다.
운영 부담: 클러스터 튜닝(샤드·힙·매핑)이 까다로워, 관리형 서비스(Elastic Cloud) 활용도 대안이다.

한 줄 요약: ELK 스택은 Beats/Logstash(수집·변환)→Elasticsearch(역색인·분산 검색)→Kibana(시각화) 로 대용량 비정형 로그를 실시간 검색·분석하는 오픈소스 스택으로, 로그 분석·SIEM·관측성에 쓰이며 ILM·라이선스(OpenSearch)·OpenTelemetry 연계가 운영 과제다.