Elasticsearch의 도큐먼트 URL 구조

  • Elasticsearch에서는 단일 도큐먼트마다 고유한 URL을 갖습니다.
  • 도큐먼트 접근 URL 구조:
    http://<호스트>:<포트>/<인덱스>/_doc/<도큐먼트 ID>
    
  • Elasticsearch 6.x 이전 버전에서는 다음과 같은 구조였으나,
    http://<호스트>:<포트>/<인덱스>/<도큐먼트 타입>/<도큐먼트 ID>
    
    Elasticsearch 7.0부터도큐먼트 타입 개념이 제거되고 _doc으로 접근해야 합니다.

데이터 입력 (Create & Update)

PUT 요청으로 도큐먼트 입력

PUT my_index/_doc/1
{
  "name": "Jongmin Kim",
  "message": "안녕하세요 Elasticsearch"
}
  • 결과 예시
    {
      "_index": "my_index",
      "_type": "_doc",
      "_id": "1",
      "_version": 1,
      "result": "created",
      "_shards": {"total": 2, "successful": 1, "failed": 0},
      "_seq_no": 0,
      "_primary_term": 1
    }
    
  • 같은 ID로 다시 입력하면 기존 데이터가 덮어쓰기(Overwrite)되며 "result": "updated" 로 변경됩니다.

데이터 덮어쓰지 않고 새 도큐먼트만 입력 (_create 사용)

PUT my_index/_create/1
{
  "name": "Jongmin Kim",
  "message": "안녕하세요 Elasticsearch"
}
  • 이미 ID가 존재하는 경우 오류 발생:
    {
      "error": {
        "type": "version_conflict_engine_exception",
        "reason": "document already exists"
      },
      "status": 409
    }
    

데이터 조회 (Read)

GET 요청으로 도큐먼트 조회

GET my_index/_doc/1
  • 응답 예시:
    {
      "_index": "my_index",
      "_type": "_doc",
      "_id": "1",
      "_version": 1,
      "found": true,
      "_source": {
        "name": "Jongmin Kim",
        "message": "안녕하세요 Elasticsearch"
      }
    }
    
  • 삭제된 도큐먼트 또는 없는 도큐먼트 조회 시
    {
      "_index": "my_index",
      "_type": "_doc",
      "_id": "1",
      "found": false
    }
    

데이터 수정 (Update)

부분 업데이트 (_update API 사용)

  • 특정 필드만 수정할 때 사용 (doc 키워드 활용)
POST my_index/_update/1
{
  "doc": {
    "message": "안녕하세요 Kibana"
  }
}
  • 응답 결과 (_version 증가)
    {
      "_index": "my_index",
      "_type": "_doc",
      "_id": "1",
      "_version": 2,
      "result": "updated",
      "_shards": {"total": 2, "successful": 1, "failed": 0}
    }
    
  • 주의사항: 내부적으로 기존 도큐먼트를 가져와 변경 후 새 도큐먼트로 재저장하는 방식이므로 부분 업데이트처럼 보이지만 실제로는 전체 덮어쓰기가 발생합니다.

데이터 삭제 (Delete)

도큐먼트 삭제

DELETE my_index/_doc/1
  • 응답 결과
    {
      "_index": "my_index",
      "_type": "_doc",
      "_id": "1",
      "result": "deleted"
    }
    
  • 삭제된 도큐먼트 조회 시
    {
      "_index": "my_index",
      "_type": "_doc",
      "_id": "1",
      "found": false
    }
    

전체 인덱스 삭제

DELETE my_index
  • 응답 결과
    {
      "acknowledged": true
    }
    
  • 삭제된 인덱스의 도큐먼트 조회 시 오류 발생
    {
      "error": {
        "type": "index_not_found_exception",
        "reason": "no such index"
      },
      "status": 404
    }
    

자동 생성되는 도큐먼트 ID 활용

POST 요청으로 자동 생성되는 도큐먼트 ID

POST my_index/_doc
{
  "name": "Jongmin Kim",
  "message": "안녕하세요 Elasticsearch"
}
  • 응답 결과 (_id가 자동 생성됨)
    {
      "_index": "my_index",
      "_type": "_doc",
      "_id": "ZuFv12wBspWtEG13dOut",
      "_version": 1,
      "result": "created"
    }
    

Elasticsearch 6.x 이전 버전과의 차이점

항목 6.x 이전 버전 7.0 이후
도큐먼트 URL 구조 /index/type/id /index/_doc/id
새 도큐먼트 입력 PUT index/type/id/_create PUT index/_create/id
부분 업데이트 (_update API) POST index/type/id/_update POST index/_update/id

정리

작업 HTTP 메서드 예제
도큐먼트 입력 PUT PUT my_index/_doc/1
자동 ID 생성 POST POST my_index/_doc
부분 업데이트 POST POST my_index/_update/1 {"doc": {"message": "변경됨"}}
도큐먼트 조회 GET GET my_index/_doc/1
도큐먼트 삭제 DELETE DELETE my_index/_doc/1
전체 인덱스 삭제 DELETE DELETE my_index

🎯 추가로 알아두면 좋은 개념

  1. 버전 관리 (_version): Elasticsearch는 도큐먼트의 변경 시 버전을 증가시킵니다.
  2. 샤드 & 레플리카: 데이터를 분산 저장하여 고가용성을 유지합니다.
  3. Query DSL: 복잡한 검색 기능을 위한 JSON 기반의 질의 언어입니다.
  4. Bulk API: 대량의 데이터를 한 번에 처리할 수 있는 API입니다.

 

'Elastic Search > Elastic 데이터 처리' 카테고리의 다른 글

[Elasticsearch] Search API  (0) 2025.02.03
[Elasticsearch] REST API  (0) 2025.02.03

REST API 개요

  • Elasticsearch는 HTTP 프로토콜 기반의 REST API를 제공합니다.
  • 자원(Resource)마다 고유한 URL을 사용하며, **HTTP 메서드(PUT, POST, GET, DELETE)**로 데이터를 처리합니다.
  • 이러한 시스템을 RESTFul 시스템이라고 합니다.

REST API 방식과 비 REST 방식 비교

방식 요청 방식 예제
비REST 방식 개별 페이지 접근 또는 매개변수 방식 http://user.com/input.jsp?name=kim&age=38&gender=m
RESTFul 방식 단일 URL과 HTTP 메서드 활용 PUT http://user.com/kim -d {"name":"kim", "age":38, "gender":"m"}

예제: 사용자 정보(name=kim, age=38, gender=m) 처리 방식 비교

  비REST 방식 RESTFul 방식
입력 http://user.com/input.jsp?name=kim&age=38&gender=m PUT http://user.com/kim -d {"name":"kim", "age":38, "gender":"m"}
조회 http://user.com/get.jsp?name=kim GET http://user.com/kim
삭제 http://user.com/delete.jsp?name=kim DELETE http://user.com/kim

Elasticsearch REST API 활용

(1) 클러스터 정보 조회

  • HTTP 요청 방법: GET http://localhost:9200
  • curl 명령어 사용 예제
    curl -XGET "http://localhost:9200"
    
  • 응답 예시 (JSON)
    {
      "name" : "Jongminui-MacBook-Pro.local",
      "cluster_name" : "elasticsearch",
      "cluster_uuid" : "hpmT8TPiR1Kk69YNao9V3w",
      "version" : {
        "number" : "7.3.0",
        "build_flavor" : "default",
        "build_type" : "tar",
        "build_hash" : "de777fa",
        "build_date" : "2019-07-24T18:30:11.767338Z",
        "lucene_version" : "8.1.0"
      },
      "tagline" : "You Know, for Search"
    }
    
  • 응답 정보 설명
    필드명 설명
    name 노드명
    cluster_name 클러스터명
    cluster_uuid 클러스터 고유 ID
    version.number Elasticsearch 버전
    lucene_version Lucene 버전
    tagline 기본 태그라인

Kibana Dev Tools

  • REST API를 쉽게 실행하기 위한 도구
  • Kibana 실행 방법
    1. Elastic 공식 웹사이트에서 Kibana 다운로드: https://www.elastic.co
    2. 압축 해제 후 실행
      • 리눅스/Mac: bin/kibana
      • 윈도우: bin/kibana.bat
    3. 기본 실행 포트: 5601
    4. 실행 후 웹 브라우저에서 접속: http://localhost:5601
  • 설정 파일 (kibana.yml) 수정
    • Elasticsearch가 다른 호스트에서 실행될 경우: 
    • elasticsearch.url: "http://localhost:9200"
    • Kibana 실행 포트를 변경하려면:
      server.port: 5601
      
  • Dev Tools 주요 기능
    기능 설명
    쿼리 자동 완성 API 호출 시 자동 완성 기능 제공
    호스트 경로 자동 적용 기본적으로 http://localhost:9200를 사용
    curl 명령 복사 기능 입력한 명령을 curl 명령어로 변환 가능

REST API를 활용한 Elasticsearch 데이터 조작

작업 HTTP 메서드 예제
문서 생성/업데이트 PUT PUT http://localhost:9200/index/_doc/1 -d '{"name":"kim", "age":38}'
문서 조회 GET GET http://localhost:9200/index/_doc/1
문서 삭제 DELETE DELETE http://localhost:9200/index/_doc/1
검색(Query DSL 사용) POST POST http://localhost:9200/index/_search -d '{"query": {"match": {"name": "kim"}}}'

추가적으로 알아야 할 내용

개념 설명
Index 관계형 DB의 "테이블" 개념
Document 하나의 데이터 레코드 (JSON 형식)
Shard & Replica 데이터를 분산 저장하고 백업하는 구조
Query DSL Elasticsearch의 강력한 검색 기능을 지원하는 JSON 기반의 질의 언어

정리

  • Elasticsearch는 HTTP REST API를 활용하여 데이터를 관리합니다.
  • RESTFul 방식을 사용하여 단일 URL과 HTTP 메서드(GET, PUT, DELETE 등)로 요청을 처리합니다.
  • curl 명령어를 이용하여 쉽게 API 요청을 보낼 수 있습니다.
  • Kibana Dev Tools를 활용하면 REST API 호출을 간편하게 실행할 수 있습니다.
  • 문서 조회, 생성, 수정, 삭제 등의 작업은 REST API를 통해 JSON 기반으로 수행됩니다.

 

Elasticsearch 커스텀 플러그인 개발

📌 Elasticsearch는 기본적으로 강력한 기능을 제공하지만, 특정한 기능을 추가하거나 성능을 개선하려면 커스텀 플러그인을 개발해야 합니다.

  • 플러그인은 Ingest Processor 추가, Query 확장, REST API 확장 등의 기능을 수행할 수 있습니다.

Elasticsearch Plugin 개발 환경 설정

Elasticsearch 플러그인은 Java로 개발되며,
Gradle을 사용하여 빌드하고 Elasticsearch Core API를 활용합니다.


(1) 개발 환경 준비

📌 필수 요구사항

  • JDK 17 이상
  • Elasticsearch 8.x 버전
  • Gradle 7.x 이상
  • IntelliJ IDEA 또는 Eclipse (권장)

(2) 플러그인 프로젝트 생성

Elasticsearch의 플러그인은 Gradle 프로젝트로 구성됩니다.

mkdir my-elasticsearch-plugin
cd my-elasticsearch-plugin

(3) build.gradle 설정

Gradle을 사용하여 Elasticsearch 플러그인 프로젝트를 설정합니다.

plugins {
    id 'java'
    id 'elasticsearch.esplugin' version '8.0.0'
}

group = 'org.elasticsearch.plugin'
version = '1.0'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.elasticsearch:elasticsearch:8.0.0'
    testImplementation 'junit:junit:4.13.2'
}

esplugin {
    name 'my-custom-plugin'
    description 'Custom Elasticsearch Plugin'
    classname 'org.elasticsearch.plugin.MyPlugin'
}

Elasticsearch 플러그인 Gradle 설정을 완료.


커스텀 Ingest Processor 개발

Elasticsearch의 Ingest Processor색인 전에 데이터를 변환하는 기능을 수행합니다.


(1) MyCustomProcessor.java 생성

package org.elasticsearch.plugin;

import org.elasticsearch.ingest.AbstractProcessor;
import org.elasticsearch.ingest.IngestDocument;
import org.elasticsearch.ingest.Processor;

import java.util.Map;

public class MyCustomProcessor extends AbstractProcessor {

    private final String field;
    private final String prefix;

    protected MyCustomProcessor(String tag, String field, String prefix) {
        super(tag);
        this.field = field;
        this.prefix = prefix;
    }

    @Override
    public IngestDocument execute(IngestDocument document) {
        String value = document.getFieldValue(field, String.class);
        document.setFieldValue(field, prefix + value);
        return document;
    }

    @Override
    public String getType() {
        return "my_custom";
    }

    public static class Factory implements Processor.Factory {
        @Override
        public MyCustomProcessor create(Map<String, Processor.Factory> factories, String tag, Map<String, Object> config) {
            String field = (String) config.get("field");
            String prefix = (String) config.get("prefix");
            return new MyCustomProcessor(tag, field, prefix);
        }
    }
}

이 플러그인은 특정 필드의 값을 가져와서 prefix를 추가하는 기능 수행.


(2) MyPlugin.java 생성

package org.elasticsearch.plugin;

import org.elasticsearch.plugins.IngestPlugin;
import org.elasticsearch.plugins.Plugin;
import org.elasticsearch.ingest.Processor;

import java.util.Map;

public class MyPlugin extends Plugin implements IngestPlugin {
    @Override
    public Map<String, Processor.Factory> getProcessors(Processor.Parameters parameters) {
        return Map.of("my_custom", new MyCustomProcessor.Factory());
    }
}

플러그인을 Elasticsearch에 등록.


(3) 플러그인 빌드 및 설치

./gradlew build
elasticsearch-plugin install file:///path/to/my-custom-plugin.zip

플러그인을 빌드하고 Elasticsearch에 설치.


(4) Ingest Pipeline 설정

PUT _ingest/pipeline/custom_pipeline
{
  "description": "My Custom Processor Pipeline",
  "processors": [
    {
      "my_custom": {
        "field": "message",
        "prefix": "[CUSTOM] "
      }
    }
  ]
}

message 필드에 [CUSTOM] 접두어를 추가하는 Ingest Pipeline 설정.


(5) 테스트 데이터 색인

PUT my-index/_doc/1?pipeline=custom_pipeline
{
  "message": "Hello Elasticsearch"
}
GET my-index/_search

결과: "message": "[CUSTOM] Hello Elasticsearch" 로 변환됨.


Java 클라이언트 (High-Level REST Client) 사용법

Elasticsearch의 Java 클라이언트를 사용하면 Elasticsearch API를 손쉽게 호출 가능.


(1) pom.xml 또는 build.gradle 설정

<dependency>
    <groupId>org.elasticsearch.client</groupId>
    <artifactId>elasticsearch-java</artifactId>
    <version>8.0.0</version>
</dependency>

Elasticsearch Java 클라이언트 추가.


(2) Java에서 Elasticsearch 연결

import co.elastic.clients.elasticsearch.ElasticsearchClient;
import co.elastic.clients.elasticsearch._types.query_dsl.Query;
import co.elastic.clients.transport.endpoints.BooleanResponse;
import co.elastic.clients.transport.rest_client.RestClientTransport;
import org.apache.http.HttpHost;
import org.elasticsearch.client.RestClient;
import org.elasticsearch.client.RestHighLevelClient;

public class ElasticsearchService {

    private static final String ELASTICSEARCH_URL = "http://localhost:9200";

    public static void main(String[] args) throws Exception {
        RestClient restClient = RestClient.builder(new HttpHost("localhost", 9200)).build();
        ElasticsearchClient client = new ElasticsearchClient(new RestClientTransport(restClient));

        // 인덱스 존재 여부 확인
        BooleanResponse exists = client.indices().exists(c -> c.index("my-index"));
        System.out.println("Index exists: " + exists.value());

        // 문서 색인
        client.index(i -> i.index("my-index").id("1").document(Map.of("message", "Hello from Java Client")));

        // 문서 검색
        Query query = Query.of(q -> q.match(m -> m.field("message").query("Hello")));
        var response = client.search(s -> s.index("my-index").query(query), Map.class);

        System.out.println("Search result: " + response.hits().hits());
    }
}

Elasticsearch에 연결하여 색인 및 검색 수행.


Elasticsearch 커스텀 플러그인 개발 정리

기능 설명
Plugin 개발 환경 설정 Java, Gradle, Elasticsearch API 사용
Custom Ingest Processor 색인 전에 데이터를 변환하는 커스텀 프로세서 개발
Java 클라이언트 활용 REST API 호출 없이 Java에서 Elasticsearch 연동 가능

 

Elasticsearch 운영 및 모니터링

📌 Elasticsearch를 안정적으로 운영하기 위해서는 **모니터링, 메모리 관리, 인덱스 라이프사이클 관리(ILM), 애플리케이션 성능 모니터링(APM)**이 필수적입니다.


Monitoring (클러스터 및 노드 상태 모니터링)

Elasticsearch의 클러스터 및 노드 상태를 _cluster/stats, _nodes/stats API를 사용하여 실시간 모니터링할 수 있습니다.


(1) 클러스터 상태 조회

GET _cluster/health

🔹 응답 예시

{
  "cluster_name": "my-cluster",
  "status": "yellow",
  "number_of_nodes": 3,
  "number_of_data_nodes": 2,
  "active_primary_shards": 5,
  "active_shards": 10,
  "unassigned_shards": 1
}

"status":

  • "green" → 모든 샤드가 정상적으로 할당됨.
  • "yellow" → 일부 복제본(Replica)이 할당되지 않음.
  • "red" → 일부 프라이머리 샤드(Primary Shard) 할당 불가 (데이터 손실 가능).

(2) 클러스터 통계 조회

GET _cluster/stats

샤드 개수, 노드 수, 디스크 사용량 등 클러스터 전반적인 상태 확인.


(3) 노드 상태 조회

GET _nodes/stats

각 노드의 CPU, 메모리, 디스크 사용량 확인 가능.


(4) Elasticsearch에 Kibana X-Pack Monitoring 연동

  • Kibana의 Stack Monitoring 기능을 사용하면 Elasticsearch의 상태를 시각적으로 모니터링 가능.
  • xpack.monitoring.collection.enabled: true 설정 필요.
xpack.monitoring.collection.enabled: true

Elasticsearch 클러스터와 노드 상태를 Kibana에서 실시간으로 모니터링.


Elasticsearch Heap Memory 관리

Elasticsearch는 JVM Heap Memory를 사용하기 때문에 메모리 관리가 중요합니다.
JVM Heap이 부족하면 GC(가비지 컬렉션) 오버헤드 증가 → 성능 저하 발생.


(1) Heap Memory 크기 확인

GET _nodes/stats/jvm

🔹 응답 예시

{
  "nodes": {
    "node-1": {
      "jvm": {
        "mem": {
          "heap_used_percent": 75,
          "heap_used_in_bytes": 8048000000,
          "heap_max_in_bytes": 10737418240
        }
      }
    }
  }
}

Heap 사용량이 75% 이상이면 메모리 최적화 필요.


(2) Heap Memory 설정 (jvm.options)

-Xms4g
-Xmx4g

Heap 크기는 전체 서버 메모리의 50% 이하로 설정 (최대 32GB 미만).


(3) 가비지 컬렉션 튜닝 (jvm.options)

-XX:+UseG1GC

G1GC(Garbage First Garbage Collector) 사용하여 GC 성능 최적화.


Index Lifecycle Management (ILM)

ILM(Index Lifecycle Management)은 인덱스의 라이프사이클을 자동으로 관리하는 기능입니다.
이를 통해 디스크 공간 절약, 성능 최적화, 자동 삭제가 가능합니다.


(1) ILM 정책 생성

PUT _ilm/policy/log_policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_size": "50gb",
            "max_age": "7d"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "allocate": {
            "number_of_replicas": 1,
            "include": { "box_type": "warm" }
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

7일 또는 50GB가 넘으면 새로운 인덱스로 롤오버 → 30일 후 Warm 노드로 이동 → 90일 후 삭제.


(2) ILM 정책을 인덱스에 적용

PUT _index_template/logs_template
{
  "index_patterns": ["logs-*"],
  "template": {
    "settings": {
      "index.lifecycle.name": "log_policy"
    }
  }
}

새로 생성되는 logs-* 인덱스에 ILM 정책 자동 적용.


Elastic APM (Application Performance Monitoring)

Elastic APM은 애플리케이션의 성능을 모니터링하고 문제를 분석할 수 있도록 도와줍니다.


(1) Elastic APM 서버 설치

docker run -d --name apm-server -p 8200:8200 --user=apm-server elastic/apm-server:8.x

APM 서버를 실행하여 애플리케이션 데이터를 수집할 준비 완료.


(2) APM 설정 (apm-server.yml)

apm-server:
  host: "0.0.0.0:8200"

output.elasticsearch:
  hosts: ["http://localhost:9200"]

APM 데이터를 Elasticsearch로 전송.


(3) 애플리케이션에 APM 에이전트 적용

🔹 Node.js (Express)

require('elastic-apm-node').start({
  serviceName: 'my-node-app',
  serverUrl: 'http://localhost:8200'
});

APM 에이전트를 Node.js 애플리케이션에 추가하여 성능 모니터링.


(4) Kibana에서 APM 데이터 확인

  • Kibana → APM 메뉴에서 응답 시간, 에러율, 트랜잭션 분석 가능.
  • Slow Query 분석, 서비스간 연관 관계 분석 지원.

Elasticsearch 운영 및 모니터링 정리

기능 설명
클러스터 및 노드 모니터링 _cluster/stats, _nodes/stats API를 사용하여 상태 모니터링
Heap Memory 관리 JVM Heap 크기 조정, G1GC 사용하여 성능 최적화
Index Lifecycle Management (ILM) 오래된 인덱스를 자동으로 이동 및 삭제하여 저장 공간 절약
Elastic APM 애플리케이션 성능 및 트랜잭션 모니터링

 

Logstash 및 Beats 활용 (ELK Stack 구성)

📌 ELK Stack은 Elasticsearch, Logstash, Kibana를 포함하는 로그 및 데이터 분석 솔루션입니다.

  • Logstash: 다양한 데이터 소스로부터 데이터를 수집 및 변환하여 Elasticsearch에 전달
  • Beats: 경량 데이터 수집기(Filebeat, Metricbeat, Heartbeat)
  • Kafka 연동: 대용량 데이터 스트리밍을 위한 Apache Kafka와 Elasticsearch 연결

Logstash를 이용한 데이터 수집 및 변환

Logstash는 다양한 소스로부터 데이터를 수집하여 필터링, 변환 후 Elasticsearch로 전송하는 도구입니다.


(1) Logstash 설치

wget https://artifacts.elastic.co/downloads/logstash/logstash-8.x.x-linux-x86_64.tar.gz
tar -xzf logstash-8.x.x-linux-x86_64.tar.gz
cd logstash-8.x.x-linux-x86_64

Logstash 다운로드 및 압축 해제 후 실행 준비.


(2) Logstash 기본 구성 (logstash.conf)

Logstash의 설정 파일은 Input → Filter → Output 구조를 가집니다.

input {
  file {
    path => "/var/log/syslog"
    start_position => "beginning"
  }
}

filter {
  grok {
    match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host} %{GREEDYDATA:log}" }
  }
  date {
    match => [ "timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
    target => "@timestamp"
  }
}

output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "syslog-%{+YYYY.MM.dd}"
  }
}

파일 로그(/var/log/syslog)를 읽고 변환하여 Elasticsearch에 저장.
grok을 사용하여 timestamp, host, log 필드로 분리.
데이터를 날짜별 인덱스로 저장 (syslog-YYYY.MM.dd).


(3) Logstash 실행

bin/logstash -f logstash.conf

Logstash 실행 후 데이터를 Elasticsearch로 전송.


(4) Elasticsearch에서 데이터 확인

GET syslog-*/_search
{
  "query": {
    "match_all": {}
  }
}

Elasticsearch에서 Logstash를 통해 수집된 로그 데이터 조회.


Beats 활용 (Filebeat, Metricbeat, Heartbeat)

Beats는 경량 데이터 수집기로, 개별 서버에서 실행되며 Logstash 또는 Elasticsearch로 데이터를 전송할 수 있습니다.


(1) Filebeat - 로그 파일 수집

Filebeat는 파일 로그를 모니터링하고 전송하는 경량 데이터 수집기입니다.

📌 Filebeat 설정 (filebeat.yml)

filebeat.inputs:
  - type: log
    paths:
      - /var/log/syslog

output.elasticsearch:
  hosts: ["http://localhost:9200"]
  index: "filebeat-%{+YYYY.MM.dd}"

파일 로그(/var/log/syslog)를 모니터링하고 Elasticsearch에 저장.


(2) Metricbeat - 시스템 메트릭 수집

Metricbeat는 CPU, 메모리, 네트워크 등의 시스템 메트릭을 수집합니다.

📌 Metricbeat 설정 (metricbeat.yml)

metricbeat.modules:
  - module: system
    metricsets:
      - cpu
      - memory
      - network
    enabled: true
    period: 10s

output.elasticsearch:
  hosts: ["http://localhost:9200"]
  index: "metricbeat-%{+YYYY.MM.dd}"

CPU, 메모리, 네트워크 메트릭을 10초마다 수집하여 Elasticsearch에 저장.


(3) Heartbeat - 서비스 상태 모니터링

Heartbeat는 웹 서비스 및 TCP, ICMP 등의 연결 상태를 모니터링합니다.

📌 Heartbeat 설정 (heartbeat.yml)

heartbeat.monitors:
  - type: http
    schedule: '@every 10s'
    urls:
      - "http://localhost:5601"
      - "http://localhost:9200"

output.elasticsearch:
  hosts: ["http://localhost:9200"]
  index: "heartbeat-%{+YYYY.MM.dd}"

Elasticsearch와 Kibana 상태를 10초마다 체크하여 Elasticsearch에 저장.


Kafka와 Elasticsearch 연동

대량의 로그 및 이벤트 데이터를 실시간으로 처리할 때 Kafka를 중간 버퍼로 사용하여 Elasticsearch로 전송할 수 있습니다.


(1) Kafka 설치 및 실행

wget https://downloads.apache.org/kafka/3.0.0/kafka_2.13-3.0.0.tgz
tar -xzf kafka_2.13-3.0.0.tgz
cd kafka_2.13-3.0.0

# Zookeeper 실행
bin/zookeeper-server-start.sh config/zookeeper.properties

# Kafka 실행
bin/kafka-server-start.sh config/server.properties

Zookeeper와 Kafka를 실행하여 메시지 큐 준비.


(2) Kafka에 로그 데이터 전송

bin/kafka-topics.sh --create --topic logs --bootstrap-server localhost:9092
bin/kafka-console-producer.sh --topic logs --bootstrap-server localhost:9092

Kafka 토픽(logs)을 생성하고 로그 메시지를 입력하여 테스트.


(3) Logstash를 사용하여 Kafka → Elasticsearch 데이터 전송

input {
  kafka {
    bootstrap_servers => "localhost:9092"
    topics => ["logs"]
    group_id => "logstash-group"
  }
}

filter {
  json {
    source => "message"
  }
}

output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "kafka-logs-%{+YYYY.MM.dd}"
  }
}

Kafka에서 데이터를 읽어 Elasticsearch로 저장.


(4) 데이터 확인

GET kafka-logs-*/_search
{
  "query": {
    "match_all": {}
  }
}

Kafka를 통해 전달된 로그 데이터가 Elasticsearch에 정상적으로 저장되었는지 확인.


Logstash 및 Beats 활용 정리

기능 설명
Logstash 다양한 데이터 소스를 수집하여 Elasticsearch로 전달
Filebeat 로그 파일을 모니터링하고 전송
Metricbeat 시스템 메트릭(CPU, 메모리 등) 수집
Heartbeat 서비스 및 네트워크 상태 모니터링
Kafka 연동 대용량 로그를 Kafka → Elasticsearch로 스트리밍

 

Elasticsearch 보안 및 인증 설정

📌 Elasticsearch는 기본적으로 X-Pack Security 기능을 제공하며,

  • 사용자 인증, 역할 기반 액세스 제어(RBAC), TLS/SSL 암호화, API 키 인증 등의 보안 기능을 설정할 수 있습니다.

Role-based Access Control (RBAC) - 역할 기반 접근 제어

RBAC(Role-Based Access Control)은 사용자별 역할(Role)을 정의하여 접근 권한을 제한하는 기능입니다.
이를 통해 읽기(Read), 쓰기(Write), 관리(Admin) 등의 권한을 유연하게 설정할 수 있습니다.


(1) 사용자 생성

bin/elasticsearch-users useradd john_doe -p mypassword -r read_role

사용자 john_doe를 생성하고 read_role 역할 부여.


(2) 역할(Role) 생성

PUT _security/role/read_role
{
  "indices": [
    {
      "names": ["logs-*"],
      "privileges": ["read"]
    }
  ]
}

read_role 역할을 생성하여 logs-* 인덱스에 대한 읽기 권한만 부여.


(3) 역할(Role)을 사용자에게 할당

PUT _security/user/john_doe
{
  "password": "mypassword",
  "roles": ["read_role"],
  "full_name": "John Doe",
  "email": "john@example.com"
}

사용자 john_doe에게 read_role 역할을 할당.


(4) 사용자 인증 테스트

curl -u john_doe:mypassword -X GET "http://localhost:9200/logs-2024/_search"

john_doe는 logs-* 인덱스에 대해 읽기(read)는 가능하지만 쓰기(write)는 불가능.


TLS/SSL 설정 (X-Pack Security)

TLS/SSL을 설정하면 Elasticsearch와 Kibana 간의 통신을 암호화하여 데이터 보호할 수 있습니다.


(1) 인증서 및 키 생성

bin/elasticsearch-certutil cert --pem --keep-ca-key

Elasticsearch 인증서를 생성 (config/certs 디렉토리에 저장됨).


(2) Elasticsearch TLS 설정 (elasticsearch.yml)

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.http.ssl.keystore.path: certs/elastic-certificates.p12

Elasticsearch 노드 간 통신 및 HTTP API 요청을 SSL로 보호.


(3) Kibana TLS 설정 (kibana.yml)

elasticsearch.ssl.certificateAuthorities: ["/etc/kibana/certs/ca.pem"]
server.ssl.enabled: true
server.ssl.certificate: "/etc/kibana/certs/kibana.pem"
server.ssl.key: "/etc/kibana/certs/kibana-key.pem"

Kibana가 TLS를 통해 Elasticsearch에 연결하도록 설정.


(4) Elasticsearch 보안 설정 적용

bin/elasticsearch-setup-passwords interactive

내장 사용자(elastic, kibana_system, logstash_system 등)의 비밀번호 설정.


API Key 및 User Authentication

API Key 인증을 사용하면 사용자 비밀번호 없이 Elasticsearch API에 안전하게 접근할 수 있습니다.


(1) API Key 생성

POST _security/api_key
{
  "name": "my_api_key",
  "role_descriptors": {
    "limited_access": {
      "indices": [
        {
          "names": ["logs-*"],
          "privileges": ["read"]
        }
      ]
    }
  }
}

logs-* 인덱스에 대해 읽기 권한을 가진 API Key 생성.


(2) API Key를 사용하여 Elasticsearch 요청

curl -H "Authorization: ApiKey <your_api_key>" -X GET "https://localhost:9200/logs-2024/_search"

API Key를 사용하여 Elasticsearch에 안전하게 접근.


(3) API Key 확인 및 삭제

GET _security/api_key
DELETE _security/api_key/<api_key_id>

API Key의 목록을 조회하거나 특정 API Key 삭제 가능.


보안 및 인증 설정 정리

기능 설명
RBAC (Role-based Access Control) 사용자별 역할(Role) 설정 및 접근 제어
TLS/SSL 설정 Elasticsearch-Kibana 간 통신 암호화
API Key 인증 비밀번호 없이 안전하게 API 접근 가능

 

Kibana 연동 및 데이터 시각화

📌 Kibana는 Elasticsearch의 데이터를 시각화하고 분석하는 도구로,

  • 강력한 UI를 제공하여 로그 분석, 모니터링, 데이터 탐색을 쉽게 수행할 수 있습니다.

Kibana 설치 및 기본 사용법

(1) Kibana 설치 (로컬)

wget https://artifacts.elastic.co/downloads/kibana/kibana-8.x.x-linux-x86_64.tar.gz
tar -xzf kibana-8.x.x-linux-x86_64.tar.gz
cd kibana-8.x.x-linux-x86_64
./bin/kibana

기본적으로 http://localhost:5601에서 실행됨.


(2) Kibana 설정 (kibana.yml)

server.port: 5601
elasticsearch.hosts: ["http://localhost:9200"]

Elasticsearch와 연결할 주소를 설정.


(3) Kibana 실행 후 첫 화면

  • Index Patterns 생성 → Elasticsearch 데이터를 Kibana에서 사용할 준비
  • Discover, Visualization, Dashboard 등의 기능 제공

Discover - 데이터 탐색

📌 Discover 메뉴에서 데이터를 검색하고 필터링

  • Elasticsearch 인덱스 데이터를 Kibana UI에서 검색
  • 시간 필터(Time Filter) 적용 가능
  • JSON 원본 데이터 확인 가능

예제: 최근 7일 동안 status: 404인 로그 검색

  1. Discover 메뉴에서 인덱스 선택 (logs-*)
  2. 쿼리 입력
    status: 404
    
  3. 시간 범위 선택 (Last 7 days)
  4. 필터 추가 (host.name: "server-01")
  5. 원하는 필드 선택하여 테이블로 표시

Visualization - 데이터 시각화

📌 Kibana의 시각화 기능을 사용하여 데이터를 그래프로 표현

지원하는 주요 차트 유형

시각화 유형 설명
Bar Chart 범주형 데이터 비교
Line Chart 시간에 따른 변화 분석
Pie Chart 비율 비교
Metric 단일 값 표시 (예: 총 방문자 수)
Gauge 임계값을 시각적으로 표시
Data Table 테이블 형식으로 데이터 표현
Map 지리적 데이터 시각화

(1) 예제: 상태 코드별 요청 수 Bar Chart 생성

  1. Kibana → Visualize → Create Visualization → Bar Chart 선택
  2. Y축(Aggregation): Count 선택
  3. X축(Bucket - Terms Aggregation): status.keyword 선택
  4. 필터 적용 (예: 특정 서버 host.name: "server-01")
  5. Save & Add to Dashboard

HTTP 응답 코드(200, 404, 500 등)의 분포를 시각화 가능.


(2) 예제: 평균 응답 시간(Line Chart)

  1. Create Visualization → Line Chart 선택
  2. Y축(Aggregation): avg(response_time) 선택
  3. X축(Bucket - Date Histogram): @timestamp 선택
  4. Save & Add to Dashboard

시간에 따른 응답 속도의 변화를 분석할 수 있음.


Dashboard - 대시보드 생성

📌 여러 개의 시각화 패널을 조합하여 하나의 대시보드 생성

예제: 웹 서버 모니터링 대시보드

  1. Kibana → Dashboard → Create New Dashboard
  2. 시각화 추가
    • 상태 코드별 요청 수 (Bar Chart)
    • 평균 응답 시간 (Line Chart)
    • 총 요청 수 (Metric)
    • 에러 발생 비율 (Pie Chart)
  3. 필터 추가 (예: 특정 서버별 분석)
  4. Save & 공유 가능 (Share 버튼 사용)

Dev Tools - Elasticsearch Query 실행

Kibana의 Dev ToolsElasticsearch Query DSL을 직접 실행할 수 있는 UI입니다.

Dev Tools 실행 방법

  1. Kibana → Dev Tools 클릭
  2. Query 입력 & 실행 (Ctrl + Enter)

(1) Elasticsearch 인덱스 조회

GET _cat/indices?v

Elasticsearch에 존재하는 모든 인덱스 목록 확인.


(2) 특정 문서 검색

GET logs-2024/_search
{
  "query": {
    "match": { "status": "500" }
  }
}

HTTP 500 에러 로그 검색.


(3) Aggregation을 활용한 상태 코드별 요청 수 집계

GET logs-2024/_search
{
  "size": 0,
  "aggs": {
    "status_count": {
      "terms": {
        "field": "status.keyword"
      }
    }
  }
}

각 상태 코드별 요청 수를 집계하여 반환.


Kibana 연동 및 데이터 시각화 정리

기능 설명
Kibana 설치 kibana.yml에서 Elasticsearch 연결 설정
Discover 데이터 탐색 및 검색, 필터링 수행
Visualization 데이터를 차트로 시각화 (Bar, Line, Pie, Metric 등)
Dashboard 여러 개의 시각화를 조합하여 대시보드 구성
Dev Tools Elasticsearch Query DSL 직접 실행

 

Elasticsearch Scaling (확장 전략)

📌 Elasticsearch는 데이터 증가에 따라 확장(Scaling) 가능한 구조를 제공합니다.

  • 이를 효과적으로 운영하기 위해 다양한 샤딩 전략, 클러스터 확장, 데이터 라이프사이클 관리, 클러스터 간 검색 및 복제, 백업 및 복구 기능을 활용해야 합니다.

Hot-Warm-Cold 아키텍처

Hot-Warm-Cold 아키텍처데이터의 중요도와 접근 빈도에 따라 노드를 분리하여 성능과 비용을 최적화하는 방법입니다.

노드 유형 설명 저장 데이터 유형 하드웨어 사양
Hot 노드 가장 빈번하게 사용되는 데이터 저장 최근 데이터 (실시간 검색) 고성능 CPU, SSD
Warm 노드 자주 검색되지 않는 과거 데이터 저장 중기 데이터 (로그 데이터) 중간 성능 CPU, HDD
Cold 노드 거의 검색되지 않는 데이터 저장 장기 보관 데이터 (백업용) 저사양 CPU, 대용량 HDD

Hot-Warm-Cold 아키텍처의 장점

  • Hot 노드는 빠른 검색 속도를 유지.
  • Warm/Cold 노드는 저비용 스토리지(HDD)를 사용하여 비용 절감.
  • **ILM (Index Lifecycle Management)**와 함께 사용하여 자동 데이터 이동 가능.

(1) 노드 역할 설정 (elasticsearch.yml)

node.roles: [hot]
node.roles: [warm]
node.roles: [cold]

각 노드에 역할을 부여하여 특정 데이터를 저장할 수 있도록 설정.


(2) ILM(인덱스 라이프사이클 관리) 정책 적용

PUT _ilm/policy/log_policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_size": "50gb",
            "max_age": "7d"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "allocate": {
            "number_of_replicas": 1,
            "include": { "box_type": "warm" }
          }
        }
      },
      "cold": {
        "min_age": "90d",
        "actions": {
          "allocate": {
            "include": { "box_type": "cold" }
          }
        }
      }
    }
  }
}

새로운 데이터는 Hot 노드에서 시작 → 30일 후 Warm 노드로 이동 → 90일 후 Cold 노드로 이동.


Cross Cluster Search (CCS) & Cross Cluster Replication (CCR)

**CCS (Cross Cluster Search)**와 **CCR (Cross Cluster Replication)**은
여러 개의 클러스터를 연결하여 확장성을 확보하는 방식입니다.


(1) Cross Cluster Search (CCS) - 여러 클러스터 검색

  • 여러 개의 Elasticsearch 클러스터에서 데이터를 검색 가능.
  • 물리적으로 분리된 클러스터라도 단일 API로 통합 검색 수행.

📌 클러스터 설정

search.remote.cluster_one.seeds: ["192.168.1.100:9300"]
search.remote.cluster_two.seeds: ["192.168.1.101:9300"]

클러스터 cluster_one과 cluster_two를 원격 검색 대상으로 추가.


📌 Cross Cluster Search 쿼리

GET cluster_one:products,cluster_two:orders/_search
{
  "query": {
    "match": { "name": "스마트폰" }
  }
}

cluster_one의 products 인덱스와 cluster_two의 orders 인덱스를 동시에 검색.


(2) Cross Cluster Replication (CCR) - 클러스터 간 데이터 복제

  • 클러스터 A → 클러스터 B로 데이터 복제 (마스터-슬레이브 구조).
  • 장애 발생 시 DR(Disaster Recovery) 시스템으로 활용 가능.

📌 리더 인덱스 생성 (Primary Cluster)

PUT /products
{
  "settings": {
    "index": {
      "soft_deletes.enabled": true
    }
  }
}

CCR을 위해 soft_deletes.enabled를 활성화해야 함.


📌 팔로워 인덱스 설정 (Secondary Cluster)

PUT /products_follower/_ccr/follow
{
  "remote_cluster": "primary_cluster",
  "leader_index": "products"
}

primary_cluster의 products 인덱스를 products_follower 인덱스로 복제.


Snapshot & Restore (백업 및 복구)

스냅샷(Snapshot) & 복원(Restore) 기능은 클러스터 백업 및 장애 발생 시 데이터 복구에 사용됩니다.

주요 특징

  • 백업 대상: 전체 클러스터, 특정 인덱스, 설정 데이터.
  • 저장 위치: S3, HDFS, Azure, Google Cloud Storage, NFS 등.

(1) 스냅샷 저장소 등록

PUT _snapshot/my_backup
{
  "type": "fs",
  "settings": {
    "location": "/mnt/backup"
  }
}

/mnt/backup 디렉토리를 사용하여 백업 저장소 생성.


(2) 스냅샷 생성 (백업)

PUT _snapshot/my_backup/snapshot_2024_01
{
  "indices": "products,orders",
  "ignore_unavailable": true,
  "include_global_state": false
}

products, orders 인덱스를 백업 (클러스터 전체가 아닌 특정 인덱스만 백업 가능).


(3) 스냅샷 확인

GET _snapshot/my_backup/_all

현재 저장된 모든 스냅샷 목록 확인.


(4) 스냅샷 복구 (Restore)

POST _snapshot/my_backup/snapshot_2024_01/_restore
{
  "indices": "products",
  "ignore_unavailable": true
}

백업된 products 인덱스를 복구.


Elasticsearch Scaling 전략 정리

기능 설명
Hot-Warm-Cold 아키텍처 데이터 라이프사이클에 따라 노드 분리 (성능 & 비용 최적화)
Cross Cluster Search (CCS) 여러 개의 클러스터에서 검색 수행
Cross Cluster Replication (CCR) 클러스터 간 데이터 복제 (DR 시스템 구축 가능)
Snapshot & Restore 데이터 백업 및 복구

 

Ingest Pipeline 개요

📌 Ingest PipelineElasticsearch에 데이터를 색인하기 전에 가공하는 기능입니다.

  • 데이터를 저장하기 전 변환, 정제, 필터링을 자동으로 수행.
  • Logstash 없이도 데이터 변환을 직접 수행 가능.
  • **Processors(프로세서)**를 이용하여 데이터를 변환 (set, rename, grok 등).

Ingest Pipeline을 활용한 데이터 변환

(1) Ingest Pipeline 생성

아래 예제는 set, rename, grok을 활용하여 데이터를 변환하는 Ingest Pipeline을 생성합니다.

PUT _ingest/pipeline/log_pipeline
{
  "description": "Log processing pipeline",
  "processors": [
    {
      "set": {
        "field": "log_level",
        "value": "INFO"
      }
    },
    {
      "rename": {
        "field": "old_field",
        "target_field": "new_field"
      }
    },
    {
      "grok": {
        "field": "message",
        "patterns": ["%{IP:client_ip} - %{USERNAME:user} \\[%{HTTPDATE:timestamp}\\] \"%{WORD:method} %{URIPATHPARAM:request} HTTP/%{NUMBER:http_version}\" %{NUMBER:status}"]
      }
    }
  ]
}

설명

  • "set": "log_level" 값을 "INFO"로 설정.
  • "rename": "old_field"을 "new_field"로 변경.
  • "grok": 정규식 패턴을 적용하여 로그 데이터를 IP, 사용자, 시간, HTTP 요청 등으로 파싱.

(2) Ingest Pipeline 테스트

POST _ingest/pipeline/log_pipeline/_simulate
{
  "docs": [
    {
      "_source": {
        "old_field": "deprecated_value",
        "message": "192.168.1.1 - johndoe [10/Feb/2024:10:00:00 +0000] \"GET /index.html HTTP/1.1\" 200"
      }
    }
  ]
}

🔹 응답 예시

{
  "docs": [
    {
      "doc": {
        "_source": {
          "log_level": "INFO",
          "new_field": "deprecated_value",
          "client_ip": "192.168.1.1",
          "user": "johndoe",
          "timestamp": "10/Feb/2024:10:00:00 +0000",
          "method": "GET",
          "request": "/index.html",
          "http_version": "1.1",
          "status": "200"
        }
      }
    }
  ]
}

"message" 필드가 자동으로 파싱되어 개별 필드(client_ip, user, timestamp 등)로 변환됨.


(3) Ingest Pipeline을 적용하여 데이터 색인

PUT /logs/_doc/1?pipeline=log_pipeline
{
  "old_field": "deprecated_value",
  "message": "192.168.1.1 - johndoe [10/Feb/2024:10:00:00 +0000] \"GET /index.html HTTP/1.1\" 200"
}

새로운 데이터가 색인될 때 자동으로 Ingest Pipeline이 실행되어 변환됨.


Reindex API를 사용한 데이터 마이그레이션

Reindex API는 기존 데이터를 새로운 인덱스로 복사할 때 사용합니다.

  • 인덱스 구조 변경이 필요할 때 활용.
  • 데이터를 새로운 인덱스로 이동하면서 Ingest Pipeline을 적용 가능.

(1) 기존 데이터 조회

GET old_index/_search
{
  "size": 5
}

기존 old_index 데이터 확인.


(2) 새로운 인덱스 생성

PUT new_index
{
  "mappings": {
    "properties": {
      "new_field": { "type": "keyword" },
      "log_level": { "type": "keyword" },
      "client_ip": { "type": "ip" },
      "timestamp": { "type": "date" }
    }
  }
}

새로운 데이터 스키마 적용.


(3) Reindex 실행

POST _reindex
{
  "source": {
    "index": "old_index"
  },
  "dest": {
    "index": "new_index",
    "pipeline": "log_pipeline"
  }
}

기존 old_index 데이터를 new_index로 복사하면서 log_pipeline을 적용.


(4) 데이터 마이그레이션 확인

GET new_index/_search
{
  "size": 5
}

데이터가 정상적으로 변환되어 저장되었는지 확인.


Ingest Pipeline & Reindex API 정리

기능 설명
Ingest Pipeline 데이터 색인 전에 자동으로 변환/정제
Set Processor 특정 필드의 값을 설정
Rename Processor 필드 이름 변경
Grok Processor 정규식 패턴을 사용하여 필드 추출
Reindex API 기존 데이터를 새로운 인덱스로 복사
Reindex + Pipeline 데이터를 이동하면서 자동 변환 적용

 

쿼리 DSL (Query DSL) 활용

📌 Elasticsearch의 Query DSL(Domain-Specific Language)은 강력한 검색 기능을 제공하는 JSON 기반의 검색 언어입니다.

  • 다양한 검색 쿼리를 조합하여 원하는 데이터를 빠르게 찾을 수 있음.
  • 기본적인 Match, Term, Bool, Range, Multi-Match 쿼리를 활용할 수 있음.
  • Aggregation(집계) 기능을 사용하여 데이터 분석 가능.

Match Query vs Term Query 차이점

쿼리 유형 설명 적용 대상 필드 형태소 분석
Match Query 형태소 분석을 적용한 검색 (전문 검색) text 타입 O
Term Query 정확한 값 일치 검색 keyword, integer, boolean X

(1) Match Query (전문 검색)

  • text 필드에 대해 형태소 분석을 수행하여 검색.
  • 단어가 포함된 문서들을 검색할 때 사용.
GET /products/_search
{
  "query": {
    "match": {
      "name": "Elasticsearch 책"
    }
  }
}

"name" 필드에서 "Elasticsearch 책"과 관련된 문서 검색.


(2) Term Query (정확한 일치 검색)

  • keyword, integer, boolean 타입 필드에 대해 정확한 값 검색.
  • 필터링 또는 정렬을 수행할 때 사용.
GET /products/_search
{
  "query": {
    "term": {
      "category": "IT"
    }
  }
}

"category"가 정확히 "IT"인 문서 검색.


Bool Query (must, should, must_not, filter)

Bool Query여러 개의 쿼리를 조합하여 검색할 때 사용합니다.

Bool Query 옵션 설명
must 모든 조건을 충족하는 문서 (AND 연산)
should 하나 이상의 조건을 충족하는 문서 (OR 연산)
must_not 해당 조건을 제외 (NOT 연산)
filter 조건을 충족하지만 점수(Score)에 영향을 주지 않음

(1) Bool Query 예제

GET /products/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "name": "Elasticsearch" } },
        { "term": { "category": "IT" } }
      ],
      "should": [
        { "match": { "description": "데이터 검색" } }
      ],
      "must_not": [
        { "term": { "stock": false } }
      ],
      "filter": [
        { "range": { "price": { "gte": 20000, "lte": 50000 } } }
      ]
    }
  }
}

설명

  • must: "name" 필드에 "Elasticsearch" 포함 + "category"가 "IT"인 문서.
  • should: "description"에 "데이터 검색"이 포함되면 점수(Score) 증가.
  • must_not: "stock"이 false인 문서는 제외.
  • filter: 가격이 20,000 ~ 50,000 범위 내인 문서만 검색 (점수에 영향 없음).

Range Query (숫자, 날짜 검색)

Range Query는 숫자 또는 날짜 필드에 대해 범위 조건 검색을 수행할 때 사용합니다.

(1) 숫자 범위 검색

GET /products/_search
{
  "query": {
    "range": {
      "price": {
        "gte": 20000,
        "lte": 50000
      }
    }
  }
}

price가 20,000 이상, 50,000 이하인 문서 검색.


(2) 날짜 범위 검색

GET /products/_search
{
  "query": {
    "range": {
      "release_date": {
        "gte": "2023-01-01",
        "lte": "2023-12-31",
        "format": "yyyy-MM-dd"
      }
    }
  }
}

release_date가 2023년 내인 문서 검색.


Multi-Match Query (여러 필드 검색)

Multi-Match Query여러 개의 필드에서 동일한 검색어를 찾을 때 사용합니다.

GET /products/_search
{
  "query": {
    "multi_match": {
      "query": "Elasticsearch",
      "fields": ["name", "description"]
    }
  }
}

"name"과 "description" 필드에서 "Elasticsearch" 포함 문서 검색.


Aggregation(집계) 기본

**Aggregation(집계)**는 데이터를 분석하고 요약할 때 사용합니다.

  • SQL의 GROUP BY, SUM, AVG와 유사한 기능을 제공.
  • 주요 Aggregation 유형
    • Bucket Aggregation → 데이터를 그룹화 (terms, histogram 등).
    • Metric Aggregation → 평균, 합계 계산 (avg, sum, min, max 등).
    • Pipeline Aggregation → 집계 결과를 추가 연산.

(1) 카테고리별 문서 수 집계 (Terms Aggregation)

GET /products/_search
{
  "size": 0,
  "aggs": {
    "category_count": {
      "terms": {
        "field": "category.keyword"
      }
    }
  }
}

"category" 필드의 각 값별 문서 개수 집계.

🔹 응답 예시

{
  "aggregations": {
    "category_count": {
      "buckets": [
        { "key": "IT", "doc_count": 10 },
        { "key": "Electronics", "doc_count": 5 }
      ]
    }
  }
}

✅ "IT" 카테고리에 10개 문서, "Electronics" 카테고리에 5개 문서 존재.


(2) 가격의 평균, 최대, 최소값 집계

GET /products/_search
{
  "size": 0,
  "aggs": {
    "price_stats": {
      "stats": {
        "field": "price"
      }
    }
  }
}

✅ price 필드의 최소값, 최대값, 평균값 계산.

🔹 응답 예시

{
  "aggregations": {
    "price_stats": {
      "min": 15000,
      "max": 60000,
      "avg": 37500,
      "sum": 150000
    }
  }
}

쿼리 DSL 활용 정리

쿼리 유형 설명
Match Query text 필드 검색 (형태소 분석 적용)
Term Query 정확한 일치 검색 (keyword, integer, boolean)
Bool Query must, should, must_not, filter 조건 조합
Range Query 숫자 및 날짜 범위 검색
Multi-Match Query 여러 개의 필드에서 검색
Aggregation 데이터 분석 및 요약

결론

  • Match Query는 형태소 분석을 적용한 검색, Term Query는 정확한 일치 검색.
  • Bool Query를 사용하면 복합 검색 가능.
  • Range Query는 숫자 및 날짜 검색에 활용.
  • Multi-Match Query를 사용하면 여러 필드에서 검색 가능.
  • Aggregation을 사용하면 데이터를 그룹화하고 통계 분석 가능.

 

+ Recent posts