기술이야기 | 브레인즈컴퍼니

메인 페이지로 이동
블로그
기술이야기

블로그

카프카를 통한 로그 관리 방법

김채욱 2023.09.19

안녕하세요! 저는 개발4그룹에서 제니우스(Zenius) SIEM의 로그 관리 기능 개발을 담당하고 있는 김채욱 입니다. 제가 하고 있는 일은 실시간으로 대용량 로그 데이터를 수집하여 분석 후, 사용자에게 가치 있는 정보를 시각화하여 보여주는 일입니다.

이번 글에서 다룰 내용은 1) 그동안 로그(Log)에 대해 조사한 것과 2) 최근에 CCDAK 카프카 자격증을 딴 기념으로, 카프카(Kafka)를 이용하여 어떻게 로그 관리를 하는지에 대해 이야기해 보겠습니다.

PART1. 로그

1. 로그의 표면적 형태

로그(Log)는 기본적으로 시스템의 일련된 동작이나 사건의 기록입니다. 시스템의 일기장과도 같죠. 로그를 통해 특정 시간에 시스템에서 ‘어떤 일’이 일어났는지 파악할 수도 있습니다. 이렇게 로그는 시간에 따른 시스템의 동작을 기록하고, 정보는 순차적으로 저장됩니다.

이처럼 로그의 핵심 개념은 ‘시간’입니다. 순차적으로 발생된 로그를 통해 시스템의 동작을 이해하며, 일종의 생활기록부 역할을 하죠. 시스템 내에서 어떤 행동이 발생하였고, 어떤 문제가 일어났으며, 유저와의 어떤 교류가 일어났는지 모두 알 수 있습니다.

만약 시간의 개념이 없다면 어떻게 될까요? 발생한 모든 일들이 뒤섞이며, 로그 해석을 하는데 어려움이 생기겠죠.

이처럼 로그를 통해 시스템은 과거의 변화를 추적합니다. 똑같은 상황이 주어지면 항상 같은 결과를 내놓는 ‘결정론적’인 동작을 보장할 수 있죠. 로그의 중요성, 이제 조금 이해가 되실까요?

2. 로그와 카프카의 관계

자, 그렇다면! 로그(Log)와 카프카(Kafka)는 어떤 관계일까요? 우선 카프카는 분산 스트리밍 플랫폼으로서, 실시간으로 대용량의 데이터를 처리하고 전송하는데 탁월한 성능을 자랑합니다. 그 중심에는 바로 ‘로그’라는 개념이 있는데요. 좀 더 자세히 짚고 넘어가 보겠습니다.

3. 카프카에서의 로그 시스템

카프카에서의 로그 시스템은, 단순히 시스템의 에러나 이벤트를 기록하는 것만이 아닙니다. 연속된 데이터 레코드들의 스트림을 의미하며, 이를 ‘토픽(Topic)’이라는 카테고리로 구분하죠. 각 토픽은 다시 *파티션(Partition)으로 나누어, 단일 혹은 여러 서버에 분산 저장됩니다. 이렇게 분산 저장되는 로그 데이터는, 높은 내구성과 가용성을 보장합니다. *파티션(Partition): 하드디스크를 논리적으로 나눈 구역

4. 카프카가 로그를 사용하는 이유

로그의 순차적인 특성은 카프카의 ‘핵심 아키텍처’와 깊게 연결되어 있습니다. 로그를 사용하면, 데이터의 순서를 보장할 수 있어 대용량의 데이터 스트림을 효율적으로 처리할 수 있기 때문이죠. 데이터를 ‘영구적’으로 저장할 수 있어, 데이터 손실 위험 또한 크게 줄어듭니다.

로그를 사용하는 또 다른 이유는 ‘장애 복구’입니다. 서버가 장애로 인해 중단되었다가 다시 시작되면, 저장된 로그를 이용하여 이전 상태로 복구할 수 있게 되죠. 이는 ‘카프카가 높은 가용성’을 보장하는 데 중요한 요소입니다.

∴ 로그 요약

로그는 단순한 시스템 메시지를 넘어 ‘데이터 스트림’의 핵심 요소로 활용됩니다. 카프카와 같은 현대의 데이터 처리 시스템은 로그의 이러한 특성을 극대화하여, 대용량의 실시간 데이터 스트림을 효율적으로 처리할 수 있는 거죠. 로그의 중요성을 다시 한번 깨닫게 되는 순간이네요!

PART2. 카프카

로그에 이어 에 대해 설명하겠습니다. 들어가기에 앞서 가볍게 ‘구조’부터 알아가 볼까요?

1. 카프카 구조

· 브로커(Broker)

브로커는 *클러스터(Cluster) 안에 구성된 여러 서버 중 각 서버를 의미합니다. 이러한 브로커들은, 레코드 형태인 메시지 데이터의 저장과 검색 및 컨슈머에게 전달하고 관리합니다. *클러스터(Cluster): 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합

데이터 분배와 중복성도 촉진합니다. 브로커에 문제가 발생하면, 데이터가 여러 브로커에 데이터가 복제되어 데이터 손실이 되지 않죠.

· 프로듀서(Producer)

프로듀서는 토픽에 레코드를 전송 또는 생성하는 *엔터티(Entity)입니다. 카프카 생태계에서 ‘데이터의 진입점’ 역할도 함께 하고 있죠. 레코드가 전송될 토픽 및 파티션도 결정할 수 있습니다. *엔터티(Entity): 업무에 필요한 정보를 저장하고 관리하는 집합적인 것

· 컨슈머(Consumer)

컨슈머는 토픽에서 레코드를 읽습니다. 하나 이상의 토픽을 구독하고, 브로커로부터 레코드를 소비합니다. 데이터의 출구점을 나타내기도 하며, 프로듀서에 의해 전송된 메시지를 최종적으로 읽히고 처리되도록 합니다.

· 토픽(Topic)

토픽은 프로듀서로부터 전송된 레코드 카테고리입니다. 각 토픽은 파티션으로 나뉘며, 이 파티션은 브로커 간에 복제됩니다.

카프카로 들어오는 데이터를 조직화하고, 분류하는 방법을 제공하기도 합니다. 파티션으로 나눔으로써 카프카는 ‘수평 확장성과 장애 허용성’을 보장합니다.

· 주키퍼(ZooKeeper)

주키퍼는 브로커를 관리하고 조정하는 데 도움을 주는 ‘중앙 관리소’입니다. 클러스터 노드의 상태, 토픽 *메타데이터(Metadata) 등의 상태를 추적합니다. *메타데이터(Metadata): 데이터에 관한 구조화된 데이터로, 다른 데이터를 설명해 주는 데이터

카프카는 분산 조정을 위해 주키퍼에 의존합니다. 주키퍼는 브로커에 문제가 발생하면, 다른 브로커에 알리고 클러스터 전체에 일관된 데이터를 보장하죠.

∴ 카프카 구조 요약

요약한다면 카프카는 1) 복잡하지만 견고한 아키텍처 2) 대규모 스트림 데이터를 실시간으로 처리하는 데 있어 안정적이고 장애 허용성이 있음 3) 고도로 확장 가능한 플랫폼을 제공으로 정리할 수 있습니다.

이처럼 카프카가 큰 데이터 환경에서 ‘어떻게’ 정보 흐름을 관리하고 최적화하는지 5가지의 구조를 통해 살펴보았습니다. 이제 카프카에 대해 조금 더 명확한 그림이 그려지지 않나요?

2. 컨슈머 그룹과 성능을 위한 탐색

카프카의 가장 주목할 만한 특징 중 하나는 ‘컨슈머 그룹의 구현’입니다. 이는 카프카의 확장성과 성능 잠재력을 이해하는 데 중심적인 개념이죠.

컨슈머 그룹 이해하기

카프카의 핵심은 ‘메시지를 생산하고 소비’ 하는 것입니다. 그런데 수백만, 심지어 수십억의 메시지가 흐르고 있을 때 어떻게 효율적으로 소비될까요?

여기서 컨슈머 그룹(Consumer Group)이 등장합니다. 컨슈머 그룹은, 하나 또는 그 이상의 컨슈머로 구성되어 하나 또는 여러 토픽에서 메시지를 소비하는데 협력합니다. 그렇다면 왜 효율적인지 알아보겠습니다.

· 로드 밸런싱: 하나의 컨슈머가 모든 메시지를 처리하는 대신, 그룹이 부하를 분산할 수 있습니다. 토픽의 각 파티션은 그룹 내에서 정확히 하나의 컨슈머에 의해 소비됩니다. 이는 메시지가 더 빠르고 효율적으로 처리된다는 것을 보장합니다.

· 장애 허용성: 컨슈머에 문제가 발생하면, 그룹 내의 다른 컨슈머가 그 파티션을 인수하여 메시지 처리에 차질이 없도록 합니다.

· 유연성: 데이터 흐름이 변함에 따라 그룹에서 컨슈머를 쉽게 추가하거나 제거합니다. 이에 따라 증가하거나 감소하는 부하를 처리할 수 있습니다.

여기까지는 최적의 성능을 위한 ‘카프카 튜닝 컨슈머 그룹의 기본 사항’을 다루었으니, 이와 관련된 ‘성능 튜닝 전략’에 대해 알아볼까요?

성능 튜닝 전략

· 파티션 전략: 토픽의 파티션 수는, 얼마나 많은 컨슈머가 활성화되어 메시지를 소비할 수 있는지 영향을 줍니다. 더 많은 파티션은 더 많은 컨슈머가 병렬로 작동할 수 있음을 의미하는 거죠. 그러나 너무 많은 파티션은 *오버헤드를 야기할 수 있습니다. *오버헤드: 어떤 처리를 하기 위해 간접적인 처리 시간

· 컨슈머 구성: *fetch.min.bytes 및 *fetch.max.wait.ms와 같은 매개변수를 조정합니다. 그다음 한 번에 얼마나 많은 데이터를 컨슈머가 가져오는지 제어합니다. 이러한 최적화를 통해 브로커에게 요청하는 횟수를 줄이고, 처리량을 높입니다. *fetch.min.bytes: 한 번에 가져올 수 있는 최소 데이터 사이즈 *fetch.max.wait.ms: 데이터가 최소 크기가 될 때까지 기다릴 시간

· 메시지 배치: 프로듀서는 메시지를 함께 배치하여 처리량을 높일 수 있게 구성됩니다. *batch.size 및 *linger.ms와 같은 매개변수를 조정하여, 대기 시간과 처리량 사이의 균형을 찾을 수 있게 되죠. *batch.size: 한 번에 모델이 학습하는 데이터 샘플의 개수 *linger.ms: 전송 대기 시간

· 압축: 카프카는 메시지 압축을 지원하여 전송 및 저장되는 데이터의 양을 줄입니다. 이로 인해 전송 속도가 빨라지고 전체 성능이 향상될 수 있습니다.

· 로그 정리 정책: 카프카 토픽은, 설정된 기간 또는 크기 동안 메시지를 유지할 수 있습니다. 보존 정책을 조정하면, 브로커가 저장 공간이 부족해지는 점과 성능이 저하되는 점을 방지할 수 있습니다.

3. 컨슈머 그룹과 성능을 위한 실제 코드 예시

다음 그림과 같은 코드를 보며 조금 더 자세히 살펴보겠습니다. NodeJS 코드 중 일부를 발췌했습니다. 카프카 설치 시에 사용되는 설정 파일 *server.properties에서 파티션의 개수를 CPU 코어 수와 같게 설정하는 코드입니다. 이에 대한 장점들을 쭉 살펴볼까요? *server.properties: 마인크래프트 서버 옵션을 설정할 수 있는 파일

CPU 코어 수에 파티션 수를 맞추었을 때의 장점

· 최적화된 리소스 활용: 카프카에서는 각 파티션이 읽기와 쓰기를 위한 자체 *I/O(입출력) 스레드를 종종 운영합니다. 사용 가능한 CPU 코어 수와 파티션 수를 일치시키면, 각 코어가 특정 파티션의 I/O 작업을 처리합니다. 이 동시성은 리소스에서 최대의 성능을 추출하는 데 도움 됩니다.

· 최대 병렬 처리: 카프카의 설계 철학은 ‘병렬 데이터 처리’를 중심으로 합니다. 코어 수와 파티션 수 사이의 일치는, 동시에 처리되어 처리량을 높일 수 있습니다.

· 간소화된 용량 계획: 이 접근 방식은, 리소스 계획에 대한 명확한 기준을 제공합니다. 성능 병목이 발생하면 CPU에 *바인딩(Binding)되어 있는지 명확하게 알 수 있습니다. 인프라를 정확하게 조정할 수도 있게 되죠. *바인딩(Binding): 두 프로그래밍 언어를 이어주는 래퍼 라이브러리

· 오버헤드 감소: 병렬 처리와 오버헤드 사이의 균형은 미묘합니다. 파티션 증가는 병렬 처리를 촉진할 수 있습니다. 하지만 더 많은 주키퍼 부하, 브로커 시작 시간 연장, 리더 선거 빈도 증가와 같은 오버헤드도 가져올 수도 있습니다. 파티션을 CPU 코어에 맞추는 것은 균형을 이룰 수 있게 합니다.

다음은 프로세스 수를 CPU 코어 수만큼 생성하여, 토픽의 파티션 개수와 일치시킨 코드에 대한 장점입니다.

파티션 수와 컨슈머 프로세스 수 일치의 장점

· 최적의 병렬 처리: 카프카 파티션의 각각은 동시에 처리될 수 있습니다. 컨슈머 수가 파티션 수와 일치하면, 각 컨슈머는 특정 파티션에서 메시지를 독립적으로 소비할 수 있게 되죠. 따라서 병렬 처리가 향상됩니다.

· 리소스 효율성: 파티션 수와 컨슈머 수가 일치하면, 각 컨슈머가 처리하는 데이터의 양이 균등하게 분배됩니다. 이로 인해 전체 시스템의 리소스 사용이 균형을 이루게 되죠.

· 탄력성과 확장성: 트래픽이 증가하면, 추가적인 컨슈머를 컨슈머 그룹에 추가하여 처리 능력을 증가시킵니다. 동일한 방식으로 트래픽이 감소하면 컨슈머를 줄여 리소스를 절약할 수 있습니다.

· 고가용성과 오류 회복: 컨슈머 중 하나가 실패하면, 해당 컨슈머가 처리하던 파티션은 다른 컨슈머에게 자동 재분배됩니다. 이를 통해 시스템 내의 다른 컨슈머가 실패한 컨슈머의 작업을 빠르게 인수하여, 메시지 처리가 중단되지 않습니다.

마지막으로 각 프로세스별 컨슈머를 생성해서 토픽에 구독 후, 소비하는 과정을 나타낸 소스코드입니다.

∴ 컨슈머 그룹 요약

컨슈머 그룹은 높은 처리량과 장애 허용성 있는 메시지 소비를 제공하는 능력이 핵심입니다. 카프카가 어떤 식으로 운영되는지에 대한 상세한 부분을 이해하고 다양한 매개변수를 신중하게 조정한다면, 어떠한 상황에서도 카프카의 최대 성능을 이끌어낼 수 있습니다!

------------------------------------------------------------

©참고 자료

· Jay Kreps, “I Hearts Logs”, Confluent

· 위키피디아, “Logging(computing)”

· Confluent, “https://docs.confluent.io/kafka/overview.html”

· Neha Narkhede, Gwen Shapira, Todd Palino, “Kafka: The Definitive Guide”

------------------------------------------------------------

김채욱개발4그룹

실시간 대용량 로그 데이터의 수집 및 가공에 관심을 가지고 있습니다. 함께 발전해 나가는 개발을 추구합니다.

필진 글 더보기

추천 콘텐츠

효율적인 로그 모니터링과 실시간 로그 분석을 위한 OpenSearch PPL 활용 가이드 효율적인 로그 모니터링과 실시간 로그 분석을 위한 OpenSearch PPL 활용 가이드 오늘날 대규모 인프라 환경에서 발생하는 방대한 데이터를 관리하기 위해 로그 모니터링과 로그분석은 필수적인 요소가 되었습니다. OpenSearch(및 Elasticsearch)는 이 분야의 사실상 표준으로 자리 잡았으나, 이를 활용하는 엔지니어와 분석가들은 강력한 기능의 이면에 있는 ‘Query DSL’이라는 높은 진입 장벽을 마주하곤 합니다. JSON 형식을 기반으로 하는 DSL은 검색 조건을 매우 정밀하게 정의할 수 있다는 장점이 있습니다. 하지만 쿼리가 복잡해질수록 로직이 깊게 중첩되어 가독성이 떨어지고 생산성이 저하되는 구조적 문제를 안고 있습니다. 특히 1분 1초가 급한 장애 상황이나 보안 침해 사고를 분석해야 하는 SIEM(보안 정보 및 이벤트 관리) 환경에서, 수십 줄의 JSON 괄호를 맞추는 작업은 민첩한 대응을 방해하는 실질적인 걸림돌이 됩니다. 이러한 문제를 해결하기 위해 등장한 것이 바로 PPL(Piped Processing Language)입니다. PPL이 제안하는 새로운 분석 방식을 살펴보기 전, 먼저 우리가 기존 DSL 환경에서 겪어온 실제적인 어려움들을 통해 왜 방식의 변화가 필요한지 짚어보겠습니다. 1. 데이터 탐색의 어려움 1.1. OpenSearch DSL OpenSearch(및 Elasticsearch)는 검색 엔진 시장의 사실상 표준으로 자리 잡았지만, 데이터 분석가나 엔지니어들에게는 한 가지 큰 진입 장벽이 존재했습니다. 바로 Query DSL(Domain Specific Language)입니다. DSL은 JSON(JavaScript Object Notation) 형식을 기반으로 하며, 검색 쿼리의 구조를 매우 정밀하게 정의할 수 있다는 강력한 장점이 있습니다. 하지만 이는 동시에 인간의 직관과는 거리가 먼 방식이기도 합니다. DSL은 쿼리가 복잡해질수록 JSON 객체가 깊게 중첩되는 특성이 있기 때문입니다. 예를 들어 단순한 GROUP BY 집계를 수행하려 해도 aggs안에 terms, 그 안에 다시 aggs를 정의해야 하는 피라미드 구조가 형성됩니다. 일반적으로 데이터를 탐색하는 과정은 "A를 찾고, B를 제외한 뒤, C로 묶어서 계산한다"라는 선형적인 사고를 따릅니다. 하지만 DSL은 이 모든 조건을 하나의 거대한 JSON 객체로 구조화해야 하므로, 작성과 수정 시 높은 집중력을 요합니다. 또한 로그를 분석하거나 장애 원인을 파악하는 긴급한 상황에서, 수십 줄의 JSON 괄호 짝들은 가독성과 생산성을 저하시키는 요인이 됩니다. <예시 1.1: 지난 1시간 동안 500 에러가 발생한 상위 5개 IP 추출하기 위한 DSL문> 1.2. PPL(Piped Processing Language) PPL은 이러한 구조적 복잡성을 해결하기 위해 등장했습니다. 이름에서 알 수 있듯이, 파이프(Pipe, |)를 통해 데이터를 순차적으로 처리하는 언어입니다. PPL이 가져온 변화는 단순히 문법의 형태를 바꾼 수준에 그치지 않습니다. 데이터에 접근하는 패러다임 자체를 선언적 구조(JSON)에서 절차적 흐름(Pipeline)으로 전환시킨 것입니다. 이는 Unix와 Linux에서 익숙하게 사용되는 명령어 파이프라인 철학을 데이터 검색 엔진에 이식한 결과이기도 합니다. 이러한 방식의 변화 덕분에 사용자는 더 이상 복잡한 JSON의 계층 구조를 설계할 필요가 없습니다. 대신 "데이터를 가져오고, 필터링한 뒤, 통계를 낸다"는 인간의 자연스러운 사고 흐름에 맞춰 질의를 작성할 수 있게 되었습니다. 이는 결과적으로 쿼리 작성 시간을 단축시키고, 분석가의 의도를 더욱 명확하게 코드에 투영할 수 있게 해줍니다. <예시 1.2: 예시 1.2와 동일한 로직을 PPL로 작성한 경우> 2. PPL의 핵심 특징 및 장점 PPL을 도입해야 하는 이유는 단순히 쓰기 편해서가 아닙니다. 이는 데이터 분석의 접근성(Accessibility), 가독성(Readability), 유연성(Flexibility) 측면에서 근본적인 이점을 제공하기 때문입니다. 2.1. SQL-like Syntax 데이터 업계에서 SQL은 가장 보편적인 언어입니다. PPL은 SQL의 문법적 특성을 차용하여 접근성을 높였습니다. SELECT, WHERE, LIKE 등 익숙한 키워드를 그대로 사용하므로, 새로운 도구 도입에 따른 저항감을 최소화합니다. 2.2. Pipe ($|$) PPL의 가장 강력한 무기는 | (파이프) 연산자입니다. 이는 쿼리를 논리적 단계로 분해합니다. 1단계: 전체 데이터 가져오기 (source=logs) 2단계: 필요한 부분만 남기기 (| where status=500) 3단계: 불필요한 필드 버리기 (| fields timestamp, message) 이처럼 하나의 문제를 단계별로 쪼개며 순차적으로 해결할 수 있습니다. 이러한 방식은 디버깅의 용이성도 증가시킵니다. DSL은 쿼리가 실패하면 전체 JSON 구조를 다시 살펴봐야 하지만, PPL은 파이프를 하나씩 끊어가며 어느 단계에서 데이터가 의도와 다르게 변형되었는지 즉시 확인할 수 있습니다. 2.3. Aggregation의 추상화 OpenSearch의 집계(Aggregation) 기능은 강력하지만 DSL 작성이 매우 까다롭습니다. PPL은 이를 stats 명령어로 추상화했습니다. 기존 DSL 방식에서 집계를 하려면 버킷(Buckets)과 메트릭(Metrics)의 개념을 이해하고, 이를 JSON의 계층 구조로 쌓아 올려야 했습니다. 하지만 PPL은 이 복잡한 과정을 우리가 흔히 쓰는 SQL 스타일로 탈바꿈시켰습니다. 간단한 시나리오인 “카테고리별 평균 가격 구하기”를 DSL로 작성하면 aggs 안에 그룹핑을 위한 terms를 정의하고, 그 안에 다시 계산을 위한 aggs를 중첩해야 합니다. 평균을 구한다라는 쿼리의 의도보다 괄호와 같은 문법적 구조에 더 신경 써야 합니다. 그룹핑 조건이 늘어날수록 JSON은 기하급수적으로 깊어집니다. 반면 동일한 시나리오를 PPL로 작성하면 stats 이라는 명령어로 간단하게 표현할 수 있습니다. stats: "집계를 시작하겠다"는 선언입니다. avg(price): "무엇을 계산할지" 명시합니다. (Metric) by category: "무엇을 기준으로 묶을지" 명시합니다. (Bucket) 단 한 줄의 코드로 DSL의 복잡한 로직을 완벽하게 대체할 수 있습니다. 2.4. 동적 필드 생성 데이터 분석을 하다 보면, 인덱스에 저장된 원본 데이터(Raw Data)만으로는 부족할 때가 많습니다. - 용량이 bytes 단위로 저장되어 있어 보기 불편한 경우 - 파일 경로와 파일 이름이 하나의 필드에 있어 각각 분리해야 하는 경우 - 보낸 용량, 받은 용량만 있고 총 용량이 없는 경우 이를 해결하기 위해 데이터를 재색인(Reindexing)하는 것은 너무 복잡한 과정입니다. 하지만 PPL은 eval 명령어 하나로 쿼리 실행 시점에 필드를 즉석에서 생성합니다. 바이트 단위를 메가바이트로 변환하여 새로운 필드 size_mb를 만드는 로직은 eval 명령어와 간단한 연산자를 이용하여 작성할 수 있습니다. 원본 데이터에는 size_mb라는 필드가 존재하지 않습니다. 하지만 PPL이 실행되는 순간 계산되어, 마치 원래 있던 필드처럼 where 절에서 필터링 조건으로 사용하거나 fields로 출력할 수 있습니다. PPL의 eval은 데이터 저장 구조(Schema)가 분석의 한계가 되지 않도록, 분석가에게 데이터를 재정의할 수 있는 강력한 권한을 부여하는 기능입니다. 3. PPL 문법 해부 앞서 PPL이 데이터 분석에 제공하는 근본적인 이점들을 살펴보았습니다. 하지만 이러한 장점들을 실무에 온전히 녹여내기 위해서는 PPL이 데이터를 처리하는 방식, 즉 문법의 구조를 정확히 이해하는 과정이 필요합니다. PPL의 문법은 단순한 규칙의 나열이 아니라, 데이터의 흐름을 제어하는 그 자체입니다. 각 명령어는 이전 단계에서 넘어온 데이터를 가공하여 다음 단계로 넘겨주는 '필터' 역할을 수행합니다. 마치 공장의 컨베이어 벨트 위에서 원재료가 각 공정을 거쳐 완성품이 되는 것과 같은 원리입니다. 그럼 지금부터 데이터 분석 현장에서 가장 빈번하게 사용되는 6가지 핵심 명령어를 통해 PPL의 구조를 깊이 있게 살펴보겠습니다. 3.1. source 모든 PPL 쿼리의 시작점입니다. SQL의 FROM 절에 해당하지만, PPL에서는 search source=... 형태로 명시합니다. 단일 인덱스뿐만 아니라 와일드카드(*)를 사용하여 여러 인덱스를 동시에 조회할 수 있습니다. search source=logs-* : 'logs-'로 시작하는 모든 인덱스 조회. 3.2. where 분석에 불필요한 데이터를 걸러내는 단계입니다. SQL의 WHERE 절과 동일합니다. where는 파이프라인의 가장 앞단에 위치시키는 것이 성능상 유리합니다. 처리해야 할 데이터의 총량을 줄여주기 때문입니다. where는 AND, OR, NOT 논리 연산자와 in, like 등의 비교 연산자를 모두 지원합니다. 3.3. eval 원본 데이터에는 없지만 분석 시점에 필요한 새로운 데이터를 만들어냅니다. 기존 필드 값을 이용해 계산을 하거나 문자열을 조합하여 새로운 필드를 정의합니다. 3.4. stats SQL의 GROUP BY와 집계 함수를 합친 개념입니다. 문법: stats <function>(<field>) by <grouping_field> 집계함수: count, sum, avg, min, max와 같은 통계 분석에 필요한 함수를 제공합니다. 3.5. fields 최종 사용자에게 보여줄 데이터를 다듬는 과정입니다. SELECT 절과 유사합니다. 수백 개의 필드 중 분석에 필요한 핵심 필드만 남깁니다 (+로 포함, -로 제외 가능). rename: 기술적인 필드명(예: req_ts_ms)을 비즈니스 친화적인 이름(예: Response Time)으로 변경하여 가독성을 높입니다. 3.6. sort & head sort: 데이터의 정렬 순서를 정합니다. - 기호를 붙이면 내림차순(DESC)이 됩니다. (sort -count) head: SQL의 LIMIT와 같습니다. 상위 N개의 결과만 잘라냅니다. 대량의 데이터 분석 시 결과를 끊어서 확인하는 데 필수적입니다. 4. 실전 예제 지금까지 PPL의 기본 개념과 주요 명령어들을 살펴보았습니다. 하지만 도구의 진정한 가치는 이론적인 문법을 아는 것에 그치지 않고, 이를 실제 복잡한 데이터 환경에 어떻게 적용하느냐에 있습니다. 이제 우리가 현업에서 흔히 마주할 수 있는 구체적인 시나리오들을 통해, PPL이 실무적인 문제들을 얼마나 직관적이고 효율적으로 해결하는지 단계별로 알아보겠습니다. 4.1. Brute Force 공격 탐지 상황: 과도한 로그인 실패(401 Error) IP 식별 1) search source=access_logs: 엑세스 로그 전체를 가져옵니다. 2) where status = 401: 전체 로그 중 로그인 실패 로그만 남깁니다. 3) stats count() as fail_count by client_ip: IP 주소별로 실패 횟수를 집계합니다. 이제 데이터는 개별 로그가 아니라 'IP별 요약 정보'가 됩니다. 4) where fail_count > 50: 50회 이상 실패한 의심 IP만 필터링합니다. (집계 후 필터링 - SQL의 HAVING 절과 유사) 5) sort -fail_count: 가장 공격 빈도가 높은 IP를 최상단에 노출합니다. 4.2. 카테고리별 매출 분석 상황: 상품 카테고리별 매출 현황과 평균 단가 확인 1) eval revenue = price * quantity: price와 quantity 필드를 곱하여, 원본 데이터에 없던 revenue(매출액) 필드를 실시간으로 계산해냅니다. 2) stats sum(revenue) as total_sales, avg(revenue) as avg_order_value by category: 카테고리 기준으로 총 매출(sum)과 평균 주문액(avg)을 동시에 계산합니다. 3) head 10: 상위 10개 카테고리만 추출하여 리포트용 데이터를 완성합니다. 4.3. 시간대별 트래픽 추이 시각화 상황: 지난 24시간 동안 웹 서버의 트래픽 변화 1) span(timestamp, 10m): 연속적인 시간 데이터를 10분 단위로 자릅니다. 2) stats count() as request_count by ...: 잘라낸 10분 단위별로 요청 수(count)를 셉니다. 결과: 이 쿼리의 결과는 그대로 라인 차트(Line Chart)나 바 차트(Bar Chart)로 시각화하기 완벽한 형태(X축: 시간, Y축: 횟수)가 됩니다. 5. PPL 성능 최적화와 고려사항 PPL은 사용자가 직관적으로 쿼리를 작성할 수 있게 돕지만, 그 이면에서는 방대한 데이터를 처리하는 무거운 작업이 수행됩니다. 도구의 편리함이 시스템의 부하로 이어지지 않도록, 쿼리 효율성을 고려하는 분석 습관을 갖추는 것이 중요합니다 5.1. 성능 최적화 방안 PPL 쿼리는 파이프라인 구조이기 때문에, 앞단에서 데이터의 크기를 줄일수록 전체 실행 속도가 기하급수적으로 빨라집니다. 1) where는 search 바로 뒤에 오는 것이 좋습니다. 데이터를 집계(stats)하거나 정렬(sort)한 뒤에 필터링하는 것은 낭비입니다. 불필요한 데이터를 메모리에 올리기 전에 where 절로 과감하게 잘라내야 합니다. 2) 필요한 필드만 명시하는 것이 좋습니다. OpenSearch 문서는 수십, 수백 개의 필드를 가질 수 있습니다. fields 명령어를 사용하여 분석에 꼭 필요한 필드만 남기면 네트워크 전송량과 메모리 사용량을 획기적으로 줄일 수 있습니다. 5.2. PPL vs DSL 언제 무엇을 써야 할까? PPL이 등장했다고 해서 기존의 DSL(Domain Specific Language)이 사라지는 것은 아닙니다. 두 언어는 태생적 목적이 다릅니다. 이 둘을 상호 보완적인 관계로 이해하고 적재적소에 사용하는 것이 좋습니다. 1) PPL을 써야 하는 경우 - 사람 중심, 탐색, Ad-hoc 분석, 운영/보안 PPL은 사람이 데이터를 봐야 하는 상황에 최적화되어 있습니다. 사고의 흐름이 끊기지 않고 빠르게 질문을 던지고 답을 얻어야 하는 상황입니다. * 상황 A: 장애 발생 시 긴급 원인 분석 "지금 500 에러가 급증하는데, 특정 API에서만 발생하는 건가?" 긴급 상황에서 복잡한 JSON 괄호를 맞출 시간은 없습니다. PPL로 빠르게 필터링(where)하고 집계(stats)하여 원인을 좁혀나가야 합니다. * 상황 B: 보안 위협 헌팅 "지난 1주일간 새벽 시간에만 접속한 관리자 계정이 있는가?" 데이터를 이리저리 돌려보고, 조건을 바꿔가며 숨겨진 패턴을 찾아내는 '탐색적 분석'에는 수정이 용이한 PPL이 압도적으로 유리합니다. * 상황 C: 비개발 직군의 데이터 접근 기획자(PM), 마케터, 데이터 분석가가 직접 데이터를 추출해야 할 때. SQL에 익숙한 이들에게 JSON DSL을 학습시키는 것은 비효율적입니다. PPL은 이들에게 데이터 접근 권한을 열어주는 열쇠가 됩니다. 2) DSL을 써야 하는 경우 키워드: 기계 중심, 애플리케이션 개발, 정밀도, 검색 튜닝 DSL은 애플리케이션이 데이터를 조회할 때 최적화되어 있습니다. 코드로 구현되어 시스템의 일부로 동작하거나, 매우 정교한 검색 로직이 필요할 때 사용합니다. * 상황 A: 검색 서비스 기능 구현 쇼핑몰 검색창, 자동 완성, 추천 시스템 등 최종 사용자에게 노출되는 기능을 개발할 때. Java, Python, Go 등의 클라이언트 라이브러리(SDK)는 객체 지향적인 JSON 구조(DSL)와 완벽하게 매핑됩니다. 코드로 쿼리를 조립하기에는 DSL이 훨씬 안정적입니다. * 상황 B: 정교한 검색 랭킹 튜닝 function_score, boosting, slop 등 검색 품질을 미세하게 조정하는 기능은 DSL만이 100% 지원합니다. PPL은 '분석'에 강하지만 '검색 랭킹' 제어력은 약합니다. * 상황 C: 초고성능 최적화가 필요한 고정 쿼리 수천만 건의 데이터를 0.1초 안에 조회해야 하는 API 백엔드. DSL은 필터 캐싱, 라우팅 제어 등 엔진 내부의 최적화 기능을 극한까지 활용할 수 있는 세밀한 옵션들을 제공합니다.\ 3) 정리 지금까지 OpenSearch의 PPL(Piped Processing Language)에 대해 깊이 있게 살펴보았습니다. 과거에는 OpenSearch 데이터를 분석하려면 'JSON 괄호와의 싸움'을 피할 수 없었습니다. 하지만 PPL의 등장으로 이제 SQL을 아는 개발자, 데이터 분석가, 심지어 비개발 직군까지도 데이터와 직접 대화할 수 있는 길이 열렸습니다. PPL이 가져온 변화는 명확합니다. - 직관성: 사고의 흐름대로 파이프(|)를 연결하여 로직을 구현합니다. - 생산성: 복잡한 집계 코드를 단 한 줄로 압축합니다. - 협업: 누구나 읽고 이해할 수 있는 코드로 팀 간 커뮤니케이션이 원활해집니다. 여러분의 데이터 인프라에 OpenSearch가 있다면, 오늘 당장 복잡한 JSON 대신 PPL을 입력해 보시길 권합니다. 단순히 쿼리 언어를 바꾸는 것을 넘어, 데이터 속에 숨겨진 인사이트를 발견하는 속도가 달라질 것입니다. 2026.01.07