대규모 시스템에서 로그는 단순한 기록이 아니라, 장애 진단과 보안 분석, 운영 자동화를 위한 핵심 데이터 소스입니다. 하지만 로그 수집량이 기하급수적으로 늘어나면 기존 Logstash 기반 아키텍처는 JVM 오버헤드와 자원 점유 문제로 병목이 발생하기 쉽습니다.
이런 한계를 보완하기 위해 주목받는 것이 Filebeat입니다. 경량 Go 기반으로 설계된 Filebeat은 CPU와 메모리 부담을 최소화하고, 수집과 전송에 집중함으로써 분산 환경에서도 안정적으로 동작할 수 있습니다. 이번 글에서는 왜 Logstash 대신 Filebeat을 선택하게 되었는지, 그리고 이를 통해 어떤 운영상의 안정성과 효율성을 확보할 수 있었는지 살펴보겠습니다.
통합로그관리 시스템 개발 초창기 파일 로그 수집 에이전트로 Logstash를 사용했습니다. 그러나 고객사의 폭발적인 로그 증가와 대규모 환경 요구사항에 효과적으로 대응하고 시스템의 안정성을 위해, 로그 수집 에이전트를 Filebeat로 전환하게 되었습니다. 왜? Logstash 기반 아키텍처를 바꾸었는지, 그리고 Filebeat 도입이 가져온 기술적 이점과 주요 설정은 무엇인지 자세히 살펴보겠습니다.
* 수집 에이전트 교체, 무엇이 문제였고 무엇을 얻었나?
수집해야 할 로그 소스(서버, 네트워크 장비, 보안 솔루션 등)가 폭발적으로 증가하면서, 기존의 Logstash 기반 수집 아키텍처는 다음과 같은 근본적인 한계에 직면했습니다.
안정적인 SIEM 운영을 위해서는 수집 에이전트의 경량화, 안정성, 리소스 효율성 확보가 최우선 과제였으며, 그 해답으로 Filebeat를 선택하게 되었습니다.
Filebeat는 Logstash의 경량화된 버전으로, 에이전트 수집 역할을 담당합니다. 즉, 로그가 생성되는 서버에 설치되어 로그 파일을 읽고 바로 OpenSearch(이전의 Elasticsearch) 또는 Kafka와 같은 목적지로 전송하는 역할을 합니다. Filebeat는 Go 언어로 개발되어 메모리 사용량이 극히 적고, CPU 부하도 거의 발생시키지 않습니다.
Filebeat로 변경은 단순히 도구를 바꾼 것이 아닌, 로그 파이프라인의 효율성과 안정성을 극대화하는 전략적 선택이었습니다.
다음으로는 Logstash에서 Filebeat로 전환함으로써 얻은 주요 장점과 기술적인 이점, 그리고 Filebeat의 주요 설정에 대해 살펴보겠습니다.
Filebeat로의 전환은 성능 개선을 넘어, 파일 수집 아키텍처를 현대적인 분산 처리 구조로 진화시켜 안정성, 유연성, 개발 효율이라는 세 가지 핵심 이점을 확보했습니다.
(How Filebeat works)
Filebeat의 가장 중요한 기능 중 하나는 백프레셔(Backpressure) 메커니즘입니다.
Filebeat는 데이터를 전송하는 중앙 시스템(Kafka 또는 OpenSearch Ingest Node)에 부하가 걸려 처리 속도가 느려질 경우, 스스로 로그 전송 속도를 늦춥니다. 이 지능적인 흐름 제어 덕분에 중앙 시스템의 과부하를 막고, 데이터 파이프라인이 붕괴되는 것을 방지하여 안정적인 로그 흐름을 보장합니다.
Filebeat는 탁월한 운영 유연성을 제공합니다. 특히 filebeat.config.inputs 기능을 활용한 동적 설정 관리는 Filebeat 재시작 없이 새로운 로그 소스를 실시간으로 추가/변경할 수 있게 해 운영의 유연성을 극대화합니다.
Zenius SIEM 역시 설정 편집 기능을 제공하여 이러한 운영 유연성을 확보하고 있습니다.
fields.* 기능을 이용해 수집 단계에서 로그 유형(mtype) 등을 태깅하여 중앙 시스템의 ECS(Elastic Common Schema) 기반 정규화를 위한 '분류 키' 역할을 합니다.
ECS를 통해 모든 로그가 표준화되므로, 상관관계 분석 및 일관된 검색/시각화 효율이 극대화됩니다.
*여기서 ECS란?*
ECS는 보안 이벤트, 로그 등 모든 데이터를 공통된 필드 이름으로 정의하는 표준 스키마입니다. 서로 다른 로그 소스(예: Apache, Windows 이벤트)에서 수집된 데이터라도 ECS를 적용하면 동일한 표준 필드(source.ip, destination.port 등)를 갖게 되어 검색과 분석이 용이해집니다.
예시) cpu_pct 라는 ECS가 있다면 “cpu > 60” 검색 시 해당 ESC가 적용된 모든 로그를 찾아 로그의 수집,출처 및 내용을보여줄 수 있음
*SIEM에서의 이점 극대화*
- 일관성 확보: 모든 로그가 ECS를 기반으로 표준화되므로, 분석가들은 매번 다른 필드 이름을 외울 필요 없이 표준화된 필드로 일관성 있게 검색 및 대시보드를 구축할 수 있습니다.
- 분석 효율성 확보: 모든 로그가 공통 스키마를 따르기 때문에 상관관계 분석(Correlation)을 효율적으로 수행하여 보안 위협을 신속하고 정확하게 식별하는 데 큰 도움이 됩니다.
결론적으로, Filebeat의 fields.* 기능은 단순 태깅을 넘어, 데이터를 중앙에서 ECS로 효율적이고 정확하게 정규화하기 위한 SIEM 아키텍처의 필수적인 개발 포인트입니다.
다음 내용에서는 Filebeat의 구체적인 작동 방식을 정의하는 주요 설정들을 살펴보겠습니다.
Filebeat를 사용하기 위해서는 filebeat.yml 파일에 주요 설정을 정의해야 합니다. 이 파일에는 어떤 로그 파일을 모니터링할지, 어떤 포맷으로 데이터를 전송할지, 그리고 어떤 목적지로 보낼지에 대한 정보가 포함됩니다.
로그 파일 수집 자체를 제외한 Filebeat의 실행 환경, 관리 유연성, 데이터 전송 메커니즘, 그리고 운영 안정성을 정의합니다. 이러한 설정은 SIEM 아키텍처의 견고함을 결정하는 핵심 요소입니다.
(설정은 환경에 따라 변경 가능하며 아래는 예시로 설정한 부분을 설명 합니다.)
Filebeat가 어떤 로그 파일을 읽고 수집할지 정의하며, 수집된 로그에 메타데이터를 부여하는 핵심 부분입니다. 가장 일반적인 설정은 paths를 사용하여 로그 파일의 경로를 지정하는 것입니다.
위 설정은 /var/log/secure/ 파일을 읽도록 Filebeat에 지시합니다. fields를 사용하여 로그에 메타데이터를 추가할 수 있습니다.
로그를 목적지로 전송하기 직전에 간단한 가공을 수행하여 중앙 시스템의 부하를 줄이고 필수 메타데이터를 추가할 수 있습니다.
(메타데이터 추가 예시)
(Drop 설정 예시, (ex)Linux audit log 수집 시 특정 경로의 로그 제외 설정)
로그 수집 및 가공을 마친 데이터를 전송할 최종 목적지를 정의합니다. 아래 예시에서는 Kafka를 목적지로 사용하여 대규모 로그 처리 및 부하 분산의 이점을 확보합니다.
Filebeat의 filebeat.yml에 있는 다양한 설정 옵션들은 로그 수집의 안정성과 효율성을 결정하는 핵심적인 요소입니다. 이러한 주요 설정 기능들을 적절히 활용한다면, 대규모 환경에서도 안정적이고 효율적인 수집 체계를 성공적으로 구축할 수 있습니다.
이제 마지막으로, Zenius SIEM에서 이러한 Filebeat 설정 기능들이 실제로 어떻게 활용되었는지 살펴보겠습니다.
Zenius SIEM 솔루션은 Filebeat의 기술적 장점을 실제 운영 환경에서 활용 할 수 있도록 YML 설정 편집 및 중앙 집중식 관리 기능을 제공합니다. 이는 대규모 에이전트 환경의 운영 부담을 획기적으로 줄여주며, 고객이 Filebeat의 세밀한 기술적 기능을 직접 제어하고 커스터마이징할 수 있게 합니다.
Zenius SIEM은 운영자가 Filebeat의 설정을 세밀하게 제어하고 편리하게 관리할 수 있도록 GUI 기반 YML 편집기를 제공합니다. 운영자는 이 환경에서 Filebeat의 모든 YML 설정 (Inputs, Processors, Output 등)을 직접 수정하고 커스터마이징 할 수 있습니다.
특히 로그 수집 안정성에 필수적인 핵심 기능, 예를 들어, 멀티라인 패턴, negate, match, tail files, 동시 수집 파일 수, include lines, exclude lines은 별도의 전용 인터페이스를 통해 더욱 편리하게 설정할 수 있도록 지원하여, 복잡한 설정도 쉽게 관리할 수 있습니다.
수백 대의 서버에 설치된 Filebeat 에이전트의 설정을 관리하고 설정과 동시에 Filebeat의 동적 설정 기능 (filebeat.config.inputs 등)을 활용하여 에이전트 재시작 없이 즉시 변경 사항을 반영한다는 것입니다. 이는 서비스 중단 없이 운영 환경을 유지할 수 있게 해줍니다.
분산된 로그 수집 환경을 통합적으로 관리하기 위해, Zenius SIEM은 에이전트 제어 및 상태 모니터링 기능을 제공합니다. 각 에이전트의 실행 상태 확인, 원격 재시작, 버전 관리 등의 제어 기능을 단일 시스템에서 제공하여, 운영자가 분산된 에이전트 환경을 쉽게 관리하고 장애 발생 시 신속하게 대응할 수 있도록 돕습니다.
(수집 상태 모니터링 기능)
(에이전트 관리 기능)
지금까지 Logstash에서 Filebeat로의 전환 배경과 그 이유, Filebeat의 주요 기능과 설정, 그리고 Zenius SIEM 환경에서의 실제 활용 사례를 중심으로 살펴보았습니다. 이번 전환은 단순한 에이전트 교체를 넘어, 대규모 환경의 요구사항에 보다 적합한 아키텍처를 구축하기 위한 전략적인 선택이었습니다.
Filebeat 도입을 통해 Zenius SIEM은 다음과 같은 측면에서 운영 기반을 한층 강화할 수 있었습니다:
Go 언어 기반의 경량 구조로 서버 자원 사용을 최소화하고, 백프레셔(Backpressure) 및 레지스트리(Registry) 기능을 통해 로그 유실 없는 안정적인 수집 환경을 구현했습니다.
동적 설정 관리 기능을 통해 다양한 환경에서 유연하게 운영할 수 있었으며, ECS 필드 구조(fields.*)를 적극 활용해 로그 분석과 데이터 정규화를 보다 체계적으로 수행할 수 있게 되었습니다.
Zenius SIEM은 이러한 Filebeat를 중앙 집중식 관리 시스템과 통합하여, 고객 환경에 최적화된 안정적이고 효율적인 로그 수집 서비스를 제공하고 있습니다.
지금까지 Logstash에서 Filebeat로의 전환을 통해 어떤 기술적 변화가 있었고, 그것이 실제 운영 환경에 어떻게 적용되었는지를 정리해 보았습니다. 변화하는 IT 환경 속에서 로그 수집 방식 또한 지속적으로 진화하고 있으며, 앞으로도 이에 대한 다양한 시도와 고민은 계속될 것입니다.
Zenius SIEM의 개발을 담당하고 있습니다.
