Elasticsearch는 늦게 도착한 메트릭을 거부하고 있었습니다. 이로 인해 파이프라인이 밀리기 시작했고, 더 많은 데이터가 늦게 도착하면서 거부가 더욱 늘어나게 되었습니다. 결국 파이프라인은 완전히 멈춰 섰습니다.

스냅샷에서 복원하고, 데이터를 다시 인덱싱하고, 수집 파이프라인을 다시 설계하여 복구해야 했습니다.

근본 원인은 인덱스 수명 주기 관리(ILM) 자체가 아니라, 시계열 데이터 스트림(TSDS)과 이를 통해 시간 제한 백킹(backing) 인덱스를 강제하는 방식에 있었습니다.

TSDS는 메트릭의 저장 공간 요구 사항을 40–70% 줄일 수 있지만, TSDS를 효율적으로 만드는 아키텍처 변경으로 인해 시간이 지남에 따라 인덱스의 동작 방식도 달라집니다. 이러한 변화는 ILM 정책을 설계하거나 수집 파이프라인에서 데이터가 늦게 도착할 수 있는 상황에서 중요합니다.

요약

TSDS를 사용하는 경우:

• 백킹 인덱스는 특정 시간 범위에 해당하는 문서만 허용합니다.

• 인덱스가 cold 또는 frozen으로 이동한 뒤 데이터가 늦게 도착하면, Elasticsearch는 해당 문서를 수용하지 않거나(설정된 경우) failure store로 라우팅합니다.

설계 규칙:

시계열 데이터 스트림이란 무엇인가요?

시계열 데이터 스트림(TSDS)은 메트릭 데이터에 최적화된 특수한 데이터 스트림입니다. 데이터는 관련 문서가 동일한 샤드 내에 위치하도록 라우팅되어 쿼리 및 검색에 최적화됩니다. Elasticsearch가 이를 수행하는 방법은 다음과 같습니다.

각 문서에는 다음이 포함됩니다.

• 타임스탬프.

• 시계열을 식별하는 dimension 필드.

• 측정값을 나타내는 metric 필드.

예를 들면 다음과 같습니다.

• 호스트당 CPU 사용량.

• 서비스별 요청 지연 시간.

• 센서별 온도 측정값.

dimensions는 측정하고자 하는 대상을 식별하는 반면, metrics는 시간에 따라 변하는 값을 나타냅니다.

dimensions

dimensions는 측정되는 엔티티를 설명합니다.

예:

다음과 같이 매핑에서 정의합니다.

metrics

metrics는 숫자 값을 나타내며 다음을 사용하여 정의됩니다.

일반적인 metric 유형:

• gauge: 오르내리는 값.

• counter: 재설정될 때까지 증가하는 값.

Elastic Agent는 주로 메트릭과 로그 데이터를 수집하므로, TSDS 인덱스를 직접 활성화하지 않은 경우에도 클러스터에 해당 인덱스가 여전히 존재할 수 있습니다.

_tsid 필드

Elasticsearch는 내부적으로 dimension 필드로부터 _tsid 값을 생성합니다. 이를 통해 동일한 dimensions를 가진 문서는 동일한 샤드로 라우팅되어 다음을 개선합니다.

• 압축.

• 쿼리 로컬리티.

• 집계 성능.

주요 차이점: 시간 제한 백킹 인덱스

기존 데이터 스트림은 항상 쓰기 인덱스라고 하는 가장 최근의 백킹 인덱스에 기록되지만, TSDS는 다르게 동작합니다.

각 TSDS 백킹 인덱스에는 정의된 시간 구간이 있으며 해당 구간에 해당하는 @timestamp 값을 가진 문서만 허용합니다.

문서가 인덱싱되면 Elasticsearch는 해당 타임스탬프를 담당하는 백킹 인덱스로 라우팅하는데, 이는 기존의 인덱스와 달리 TSDS가 여러 백킹 인덱스에 동시에 쓰기를 수행할 수 있음을 의미합니다.

그 예는 다음과 같습니다.

• 실시간 데이터 → 최신 인덱스.

• 지연된 데이터 → 해당 기간을 포함하는 이전 인덱스.

늦게 도착하는 데이터를 위한 설계

실제 수집 파이프라인은 메트릭을 제시간에 완벽하게 전달하는 경우가 거의 없습니다. 메트릭은 네트워크 장애, 백로그, 배치 수집, 엣지 디바이스의 연결 끊김 등으로 인해 지연될 수 있으며, 다시 연결되면 밀린 데이터를 시작합니다.

기존 인덱스는 이러한 지연을 조용히 흡수하지만, TSDS는 그렇지 않습니다.

문서의 타임스탬프가 쓰기 가능한 백킹 인덱스의 범위를 벗어나면 Elasticsearch가 이를 거부하므로, ILM 정책은 늦게 도착하는 데이터를 반드시 고려해야 합니다.

핵심 제약 조건

백킹 인덱스는 지연 데이터를 수용할 수 있을 만큼 충분히 오랫동안 쓰기 가능 상태를 유지해야 합니다.

실제로는 다음과 같다.

ILM은 롤오버 시점부터 인덱스 나이를 측정하므로, 운영 규칙은 다음과 같습니다.

예를 들어, 메트릭이 최대 6시간 늦게 도착할 수 있는 경우 인덱스는 롤오버 후 최소 6시간 동안 쓰기 가능한 상태로 유지되어야 합니다.

이러한 제약 조건을 고려하지 못한 것이 바로 앞서 설명한 데이터 수집 실패의 원인이었습니다. 늦게 도착한 데이터는 이전 인덱스로 전달됐는데, 해당 인덱스는 이미 cold 티어에 있어서 쓰기가 차단된 상태였습니다.

거부된 문서를 처리하는 방법

TSDS가 문서를 거부하면 Elasticsearch는 오류를 반환하는데, 이는 타임스탬프가 쓰기 가능한 인덱스 범위 내에 속하지 않음을 의미합니다. 데이터 수집 파이프라인이 이 오류를 어떻게 처리하느냐에 따라 데이터 손실이 발생할 수도 있고, 수집이 중단될 수도 있습니다.

거부된 문서를 처리하는 주요 메커니즘은 failure store입니다.

failure store(Elasticsearch 9.1 이상에서 권장)

Elasticsearch 9.1에서는 failure store를 도입하여 거부된 문서를 자동으로 수집합니다. Elasticsearch는 클라이언트에 오류를 반환하는 대신 실패한 문서를 데이터 스트림 내부의 전용 failure 인덱스에 기록합니다.

다음을 사용하여 오류를 검사할 수 있습니다:

failure store를 사용하면 수집 파이프라인이 거부 오류로 인해 막히는 것을 방지하면서, 실패한 데이터를 분석 또는 재인덱싱을 위해 보존할 수 있습니다.

거부 관련 문제 모니터링

늦게 도착하는 문제는 일반적으로 수집 이상 징후로 먼저 나타납니다. 다음과 같은 현상으로 먼저 감지될 수 있습니다.

• 인덱싱 속도의 급격한 감소.

• 거부된 문서 수의 급증.

• failure store 항목 수 증가.

• 파이프라인 입력과 출력 개수 간의 불일치.

이러한 신호를 기반으로 한 알림을 통해 운영자는 파이프라인이 중단되기 전에 문제를 감지할 수 있습니다. 워크플로우, 머신 러닝 작업 등 다양한 메커니즘을 활용해 탐지 및 알림을 자동화할 수 있습니다.

TSDS + ILM 마이그레이션 체크리스트

TSDS로 메트릭 클러스터를 마이그레이션하거나, ILM 계층화를 도입하거나, 메트릭이 기본적으로 TSDS인 Elasticsearch 버전으로 업그레이드하는 경우, 먼저 다음 항목을 검토하세요.

1. 수집 지연 시간 측정

ILM 정책을 변경하기 전에 다음 사항을 확인하세요.

• 정상적인 수집 지연 시간.

• 인시던트 상황에서의 최대 지연.

• 배치 파이프라인으로 인한 지연.

ILM 설계는 현실적으로 발생할 수 있는 최대 지연을 반드시 고려해야 합니다.

2. 인덱스 시간 구간 확인

TSDS 백킹 인덱스를 확인합니다.

다음을 확인하세요.

• time_series.start_time

• time_series.end_time

이러한 경계는 어떤 인덱스가 문서를 수용할 수 있는지를 결정합니다. 이러한 시간 구간을 이해하면 데이터가 어느 정도까지 지연될 수 있는지(거부되기 전까지)를 판단하는 데 도움이 됩니다.

3. 지연 데이터를 위한 hot 티어 크기 조정

백킹 인덱스는 지연 데이터를 처리할 수 있도록 충분한 기간 동안 쓰기 가능 상태를 유지해야 한다.

운영 규칙:

• warm_min_age > rollover_max_age + maximum_expected_lateness

메트릭이 6시간 늦게 도착할 수 있는 경우, 인덱스는 최소 6시간 동안 쓰기 가능 상태를 유지해야 한다는 점을 잊지 마세요.

4. 거부된 문서 처리 방식 결정

TSDS를 활성화하기 전에 전략을 선택하세요.

• failure store(Elasticsearch 9.1 이상에서 권장)

• Logstash dead letter queue.

• 지연 데이터 처리를 위한 대체 인덱스.

• 제한적인 데이터 손실 허용.

5. 데이터 수집 상태 모니터링

다음 항목에 대한 알림을 추가하세요.

• 인덱싱 속도 하락.

• 거부된 문서.

• failure store 증가

• 파이프라인 입력/출력 불일치.

늦게 도착하는 데이터 문제는 종종 수집 이상 징후로 먼저 나타납니다.

요약

시계열 데이터 스트림은 메트릭 워크로드의 스토리지와 성능을 크게 개선하지만, 중요한 아키텍처 변경을 수반합니다. 백킹 인덱스는 시간 기반으로 제한되며, 이는 ILM의 동작 방식에 영향을 미칩니다.

TSDS를 사용하는 경우:

• 인덱스는 지연 데이터를 수용할 수 있을 만큼 충분히 오랫동안 쓰기 가능 상태를 유지해야 합니다.

• 수집 파이프라인은 거부된 문서를 안정적으로 처리해야 합니다.

기억해야 할 핵심 규칙은 다음과 같습니다:

이 제약 조건을 중심으로 ILM 정책을 설계하면 TSDS는 메트릭 워크로드에 매우 효과적으로 작동합니다.

하지만 이를 무시하면 수집 파이프라인이 이러한 시간 경계를 직접 겪으며 문제를 발견하게 될 수 있습니다.

기존에는 크롤러 관리가 수작업으로 이루어졌고 오류가 발생하기 쉬운 프로세스였습니다. UI에서 직접 구성을 편집하고 크롤링 구성 복제, 롤백, 버전 관리 등으로 어려움을 겪어야 했습니다. 크롤러 구성을 코드로 취급하면 소프트웨어 개발에서 기대하는 반복성, 추적성 및 자동화와 같은 이점을 제공함으로써 이 문제를 해결할 수 있습니다.

이 워크플로우를 사용하면 Elastic Web Crawler나 App Search Crawler와 같은 이전 Elastic Crawler에서는 훨씬 더 까다로웠던 롤백, 백업, 마이그레이션 작업을 위해 CI/CD 파이프라인에 Open Web Crawler를 더 쉽게 도입할 수 있습니다.

이 글에서는 그 방법을 알아보겠습니다:

• GitHub를 사용하여 크롤링 구성 관리하기

• 배포하기 전에 파이프라인을 테스트할 수 있는 로컬 설정이 있습니다.

• 메인 브랜치에 변경 사항을 푸시할 때마다 새로운 설정으로 웹 크롤러를 실행하도록 프로덕션 설정을 만듭니다.

프로젝트 리포지토리는 여기에서찾을 수 있습니다. 이 글을 쓰는 현재, 저는 Elasticsearch 9.1.3과 Open Web Crawler 0.4.2를 사용하고 있습니다.

필수 구성 요소

• Docker 데스크톱

• Elasticsearch 인스턴스

• SSH 액세스 권한이 있는 가상 머신(예: AWS EC2) 및 Docker가 설치된 가상 머신

단계

1. 폴더 구조

2. 크롤러 구성

3. Docker-작성 파일(로컬 환경)

4. 깃허브 액션

5. 로컬 테스트

6. 프로덕션에 배포

7. 변경 및 다시 배포

폴더 구조

이 프로젝트의 파일 구조는 다음과 같습니다:

크롤러 구성

crawler-config.yml, 아래에 다음을 입력합니다:

제품 모의 사이트인 https://web-scraping.dev/products 에서 크롤링됩니다. 처음 세 개의 제품 페이지만 크롤링합니다. max_crawl_depth 설정은 크롤러가 seed_urls 으로 정의된 페이지보다 더 많은 페이지를 발견하지 못하도록 하여 그 안의 링크를 열지 않도록 합니다.

Elasticsearch host 및 api_key 는 스크립트를 실행하는 환경에 따라 동적으로 채워집니다.

Docker-작성 파일(로컬 환경)

로컬 docker-compose.yml, 의 경우, 프로덕션에 배포하기 전에 크롤링 결과를 쉽게 시각화할 수 있도록 크롤러와 단일 Elasticsearch 클러스터 + Kibana를 배포합니다.

크롤러가 Elasticsearch를 실행할 준비가 될 때까지 기다리는 방식에 주목하세요.

깃허브 액션

이제 새 설정을 복사하고 메인으로 푸시할 때마다 가상 머신에서 크롤러를 실행하는 GitHub 액션을 만들어야 합니다. 이렇게 하면 가상 머신에 수동으로 들어가서 파일을 업데이트하고 크롤러를 실행할 필요 없이 항상 최신 구성이 배포되어 있습니다. 가상 머신 공급자로 AWS EC2를 사용하겠습니다.

첫 번째 단계는 호스트(VM_HOST), 머신 사용자(VM_USER), SSH RSA 키(VM_KEY), Elasticsearch 호스트(ES_HOST), Elasticsearch API 키(ES_API_KEY)를 GitHub Action 시크릿에 추가하는 것입니다:

이렇게 하면 액션이 서버에 액세스하여 새 파일을 복사하고 크롤링을 실행할 수 있습니다.

이제 .github/workflows/deploy.yml 파일을 만들어 보겠습니다:

이 작업은 크롤러 구성 파일에 변경 사항을 푸시할 때마다 다음 단계를 실행합니다:

1. yml 구성에서 Elasticsearch 호스트 및 API 키 채우기

2. 구성 폴더를 VM에 복사합니다.

3. SSH를 통해 VM에 연결

4. 리포지토리에서 방금 복사한 구성으로 크롤링을 실행합니다.

로컬 테스트

로컬에서 크롤러를 테스트하기 위해, Docker의 로컬 호스트에 Elasticsearch 호스트를 채우고 크롤링을 시작하는 bash 스크립트를 만들었습니다. ./local.sh 을 실행하여 실행할 수 있습니다.

Kibana 개발자 도구를 살펴보고 web-crawler-index 이 올바르게 채워졌는지 확인해 보겠습니다:

프로덕션에 배포

이제 가상 머신에 크롤러를 배포하고 서버리스 Elasticsearch 인스턴스로 로그 전송을 시작하는 메인 브랜치로 푸시할 준비가 되었습니다.

그러면 가상 머신 내에서 배포 스크립트를 실행하고 크롤링을 시작하는 GitHub 액션이 트리거됩니다.

GitHub 리포지토리로 이동하여 "작업" 탭을 방문하면 작업이 실행되었는지 확인할 수 있습니다:

변경 및 다시 배포

눈에 띄는 점은 각 제품의 price 이 문서 본문 필드의 일부라는 점입니다. 가격을 별도의 필드에 저장하여 필터를 실행할 수 있도록 하는 것이 가장 이상적입니다.

crawler.yml 파일에 이 변경 사항을 추가하여 추출 규칙을 사용하여 product-price CSS 클래스에서 가격을 추출해 보겠습니다:

또한 가격에는 달러 기호($)가 포함되어 있으며, 범위 쿼리를 실행하려면 이 기호를 제거해야 합니다. 이를 위해 수집 파이프라인을 사용할 수 있습니다. 위의 새 크롤러 구성 파일에서 이를 참조하고 있습니다:

프로덕션 Elasticsearch 클러스터에서 해당 명령을 실행할 수 있습니다. 개발의 경우, 임시적이므로 다음 서비스를 추가하여 docker-compose.yml 파일에 파이프라인 생성 부분을 만들 수 있습니다. 또한 크롤러 서비스에 depends_on 을 추가하여 파이프라인이 성공적으로 생성된 후에 시작되도록 했습니다.

이제 `./local.sh` 을 실행하여 로컬에서 변경 사항을 확인해 보겠습니다:

훌륭합니다! 이제 변경 사항을 적용해 보겠습니다:

모든 것이 제대로 작동하는지 확인하려면 프로덕션 Kibana를 확인하면 변경 사항이 반영되어 달러 기호가 없는 새 필드로 가격이 표시되어야 합니다.

결론

Elastic Open Web Crawler를 사용하면 크롤러를 코드로 관리할 수 있으므로 개발부터 배포까지 전체 파이프라인을 자동화하고 임시 로컬 환경을 추가하고 크롤링된 데이터에 대해 프로그래밍 방식으로 테스트하는 등 몇 가지 예를 들 수 있습니다.

공식 리포지토리를 복제하고 이 워크플로우를 사용하여 자체 데이터 색인화를 시작할 수 있습니다. 이 문서에서 크롤러가 생성한 인덱스에 대해 시맨틱 검색을 실행하는 방법을 알아볼 수도 있습니다.

1. _mapping API를 사용하여 필드 정보 검색하기

2. _search API를 사용하여 필드 값 표시

3. 하위 필드 표시

4. Synthetic _source

5. 런타임 필드

1. 맵핑 API를 사용하여 필드 정보 검색하기

_mapping API를 사용하면 인덱스 또는 여러 인덱스에 대한 매핑 정의를 검색할 수 있습니다. 여기에는 필드, 데이터 유형 및 기타 속성에 대한 정보가 포함됩니다. 특정 인덱스에 대한 매핑을 검색하려면 다음 요청을 사용하세요:

예를 들어 my_index 이라는 인덱스가 있는 경우 다음 요청으로 해당 인덱스의 매핑을 검색할 수 있습니다:

응답에는 필드 및 해당 속성에 대한 정보가 포함된 인덱스에 대한 매핑 정의가 포함됩니다.

특정 필드에 대한 매핑을 검색할 수도 있습니다. 매핑이 상당히 크고 특정 필드에만 집중하려는 경우 유용할 수 있습니다. 특정 필드의 매핑을 검색하려면 다음 요청을 사용하세요:

다음 요청에서와 같이 쉼표로 이름을 구분하여 여러 필드의 매핑을 검색할 수도 있습니다:

2. search API를 사용하여 필드 값 표시하기

Elasticsearch 인덱스의 필드 값을 표시하려면 _search API를 사용하면 됩니다. _search API는 반환되는 필드를 제어할 수 있는 다양한 방법을 제공하며, 두 가지 주요 방법은 다음과 같습니다:

1. _source: _source 필드에는 수집 파이프라인이나 전처리 단계에 의해 변경된 사항을 포함하여 색인된 그대로의 원본 JSON 문서 본문이 포함되어 있습니다. 소스 문서의 특정 필드를 표시하려면 아래에서 설명하는 대로 소스 필터링을 구현합니다.

2. fields: fields 매개변수를 사용하면 색인 매핑을 기반으로 검색을 수행할 때 문서에서 특정 필드를 검색할 수 있습니다. _source 과 달리 fields 은 _source 을 참조하지 않고 저장된 필드, 문서 값 또는 런타임 필드의 값을 반환할 수도 있지만 문서 값이나 저장된 설정이 없는 표준 필드의 경우 _source 으로 되돌아갑니다. 이는 아래에서 살펴보겠지만 성능 등 많은 이점을 가져올 수 있습니다.

소스필드 사용

기본적으로 _search API는 색인된 원본 JSON 문서가 포함된 _source 필드를 반환합니다. 특정 필드를 표시하려면 검색 요청의 _source 매개변수에 필터를 추가할 수 있으며, 이를 소스 필터링이라고 합니다.

다음은 my_index 인덱스에 있는 문서에 대한 title 및 author 필드 값을 반환하는 검색 요청의 예입니다:

이 예제에서 _source 매개변수는 반환할 필드를 지정합니다.

더 많은 제어가 필요한 경우 _source 객체의 includes 및 excludes 속성을 사용할 수 있습니다. 예를 들어 아래 쿼리는 최상위 수준 title 필드와 author 의 author.description 을 제외한 모든 하위 필드를 반환합니다.

이 예제에서는 author.* 패턴을 사용하여 author 객체의 모든 직접 하위 필드를 검색합니다. 그런 다음 author.description 을 명시적으로 제외하여 다른 작성자 필드만 반환되도록 합니다. 이 경우에도 여전히 소스 JSON을 로드하고 구문 분석해야 하므로 성능이 향상되지는 않지만 네트워크를 통해 전송되는 응답의 크기를 줄일 수 있다는 점에 유의하세요.

필드 매개변수 사용

fields 매개변수를 사용하여 검색 응답에 반환되는 필드를 필터링할 수 있습니다. _source 대신 fields 을 사용하면 다음과 같은 여러 가지 이점이 있습니다:

• 성능 개선: fields 은 전체 _source 을 로드할 필요 없이 저장된 필드 또는 문서 값에서 직접 값을 반환할 수 있으므로 응답 페이로드 크기가 더 작아집니다.

• 형식화된 출력: 표준 필드의 경우 fields 은 _source 으로 되돌아가 값을 가져올 수 있지만, 인덱스 매핑을 확인하여 형식이 지정된 날짜와 같은 출력의 형식을 적절히 지정하여 집계 및 정렬에 사용되는 것과 일관성을 유지합니다.

• 런타임 필드에 대한 액세스: fields 은 원본 _source 에 없는 런타임 필드를 반환할 수 있습니다.

• 더 많은 혜택은 여기에서 확인할 수 있습니다.

예를 들어 my_index 인덱스에서 title 및 author 필드만 반환하려면 다음 검색 요청을 사용할 수 있습니다:

위의 쿼리에서는 소스 문서를 반환하지 않도록 _source 필드를 false로 설정했습니다. 이렇게 하면 응답의 페이로드 크기를 크게 최소화할 수 있지만 title 및 author 필드가 keyword 필드 유형이고 기본적으로 doc_values 이 활성화되어 있기 때문에 작동한다는 점을 기억하세요. 필드에 doc_values 가 활성화되어 있지 않고 _source 가 false로 설정되어 있으면, Elasticsearch는 이를 검색할 방법이 없으며 응답에서 건너뛰게 됩니다.

fields 응답은 값이 하나만 있는 경우에도 항상 각 필드에 대한 값 배열을 반환한다는 점에 유의하세요. 이는 Elasticsearch에 전용 배열 유형이 없고 모든 필드에 여러 개의 값이 있을 수 있기 때문입니다. Elasticsearch의 배열에 대한 자세한 내용을 보려면 여기를 클릭하세요.

필드를 검색하는 다른 방법

_source 또는 fields 을 사용하여 필드를 검색하는 것이 권장되는 방법이지만, 특정 사용 사례에 따라 다음과 같은 다양한 방법을 사용할 수 있습니다:

문서 값 필드: _source docvalue_fields매개 변수를 사용하여 검색할 수 있습니다. 문서 값은 _source 과 동일한 필드 값을 저장하지만 정렬 및 집계에 최적화된 온디스크 데이터 구조로 저장합니다.

_source 에 저장된 값과는 별개이므로 전체 _source 를 로드하지 않고도 특정 필드를 요청할 수 있습니다. 이 기능은 대규모 문서를 쿼리하지만 문서 값을 지원하는 작은 필드 몇 개만 필요한 경우에 유용합니다. docvalue_fields 사용의 또 다른 사용 사례는 아래 예제에서 볼 수 있듯이 date 및 numeric 필드에 사용자 지정 서식을 사용하려는 경우입니다.

doc_values 을 활성화한 필드 또는 keyword, date, 숫자 유형 및 boolean 과 같이 기본적으로 활성화된 필드 유형에 대해서만 작동하며, text 또는 annotated_text 에는 작동하지 않습니다.

이 예에서는 docvalue_fields 매개변수를 사용하여 전체 _source 문서를 로드하지 않고 title, author, published 필드를 검색합니다:

이 쿼리가 실행되면 Elasticsearch는 각 문서에 대해 _source 을 참조하는 대신 온디스크 컬럼형 저장소에서 직접 값을 가져옵니다. published 필드는 쿼리에 제공된 format 매개변수 덕분에 기본 형식이 아닌 epoch_millis 형식으로 반환됩니다.

저장된 필드: 매핑에서 특정 필드를 저장된 것으로 명시적으로 표시한 경우 stored_fields 매개변수를 사용하여 해당 필드를 필터링할 수 있습니다. 특정 필드에 대해서만 가벼운 응답을 원하거나 나중에 검색할 수 있도록 의도적으로 저장한 필드에 대해 이 기능을 사용하면 유용합니다. _source 과 별도로 저장되므로 이 방법은 _source 을 로드할 필요가 없는 경우에도 유용합니다.

이 옵션은 기본적으로 꺼져 있으며 일반적으로 권장되지 않는다는 점에 유의하세요. 원본 소스 문서의 특정 하위 집합을 반환하려면 대신 소스 필터링을 사용하세요.

아래 예제 쿼리에서는 stored_fields 매개 변수를 사용하여 "store”: true" 인덱스 매핑 구성이 있는 summary 필드를 검색합니다.

이 쿼리가 실행되면 Elasticsearch는 이 필드가 ”store”: true 로 표시되어 있는지 확인하며, 이 필드를 찾지 못하면 필드를 완전히 건너뜁니다.

3. 하위 필드 표시

인덱스에 하위 필드가 포함된 경우 점 표기법을 사용하여 fields 매개변수에서 필드 경로를 지정할 수 있습니다. 하위 필드는 중첩된 필드 유형과 다르다는 점에 유의하세요. 예를 들어 address.city 이라는 이름의 하위 필드가 있는 경우 다음과 같이 검색 응답에 포함할 수 있습니다:

이 예제에서는 검색 응답에 title, author, address.city 필드의 값이 포함됩니다.

4. 합성 _소스

_source 사용 기능을 유지하면서 디스크 공간도 절약하려면 인덱스 매핑에 합성 _source 을 사용하는 옵션이 있습니다. 합성 _source 은 _source 이 비활성화되어 있는 경우에도 Elasticsearch가 저장된 필드 및 문서 값과 같은 기존 데이터로부터 _source 을 재구성할 수 있도록 하는 기능입니다. 이렇게 하면 재구성이 즉시 이루어지므로 쿼리 시 속도가 약간 느려지는 대신 저장 공간을 많이 절약할 수 있습니다. 인덱스 설정에서 아래 값을 사용하여 이 기능을 사용하도록 설정합니다:

_search API를 사용할 때 전체 문서 표시, 소스 필터링, _source 를 사용할 수 있을 것으로 기대하는 Kibana와 같은 다른 기능 및 도구와의 호환성, 전체 _source 문서를 저장할 필요가 없는 것 등이 합성 _source 사용의 몇 가지 이점입니다.

5. 런타임 필드

런타임 필드를 사용하면 쿼리 시 또는 런타임 블록 아래의 인덱스 매핑에서 스크립트 필드를 정의할 수 있습니다. 이러한 필드는 색인화되지 않으므로 런타임 필드를 추가해도 색인 크기가 증가하지는 않지만 _source 에 표시되지 않습니다. 매핑에 정의된 런타임 필드는 영구적이며 모든 쿼리에서 사용할 수 있는 반면, 쿼리 시점에 정의된 런타임 필드는 임시적이며 해당 검색 요청에서만 사용할 수 있습니다.

런타임 필드 사용의 주요 이점은 이미 수집한 후 문서에 필드를 추가할 수 있어 매핑 결정을 간소화할 수 있다는 점입니다. 런타임 필드는 문자열 서식 지정이나 점수 계산과 같이 원본 문서에는 없지만 스크립트를 사용하여 생성된 값으로 문서를 보강하는 데도 유용합니다.

또한 런타임 필드는 결과 집합의 모든 문서에 대해 스크립트를 실행해야 하므로 성능이 저하될 수 있다는 점도 유의할 필요가 있습니다. 런타임 필드를 검색하려면 _search API에서 fields 매개 변수를 사용할 수도 있습니다.

결론

Elasticsearch 인덱스의 필드를 표시하는 방법은 인덱스 매핑 또는 _source 을 사용하여 단순히 값을 검색하는 것부터 fields, docvalue_fields 또는 제어 및 효율성을 높이기 위한 런타임 필드를 사용하는 고급 방법까지 다양합니다. 검색 환경을 최적화하려면 다양한 방법 간의 장단점을 이해하는 것이 중요합니다. 페이로드를 최적화하든, 문서를 보강하든, 저장 공간을 절약하기 위해 합성 _source 을 사용하든, Elasticsearch는 필요한 데이터를 필요한 방식으로 찾을 수 있는 여러 가지 도구와 기능을 제공합니다. 이러한 기법은 데이터 구조를 이해하고, 특정 필드를 식별하고, 문제를 해결하는 데 도움이 될 수 있습니다.

Logstash에는 데이터 구문 분석, 보강, 수정과 같은 일반적인 작업을 위한 몇 가지 기본 제공 필터가 포함되어 있습니다. 그러나 때로는 이러한 표준 필터가 제공할 수 있는 범위를 넘어서는 사용자 지정 로직이 필요한 시나리오가 발생할 수 있습니다. 바로 이 부분에서 루비 필터 플러그인이 등장합니다.

Ruby 필터 플러그인을 사용하면 Logstash 파이프라인 내에서 직접 사용자 정의 Ruby 코드를 실행할 수 있습니다. 표준 필터로 충분하지 않은 경우, 루비 필터를 사용하면 복잡한 데이터 변환을 처리하고, 사용자 지정 비즈니스 로직을 구현하거나, 외부 시스템과 통합할 수 있습니다.

이 블로그에서는 기본 사용법부터 고급 사용법까지 루비 필터를 사용하는 방법을 살펴봅니다.

루비 필터는 언제 사용해야 하나요?

Elastic의 컨설팅 아키텍트로서, 요즘은 최신 데이터 처리 엔진이 아니지만 데이터 처리 파이프라인에 Logstash를 사용하는 고객들을 자주 보게 됩니다. 복잡한 데이터 조작이나 사용자 지정 로직을 처리할 때 표준 필터의 한계로 인해 어려움을 겪는 경우가 많습니다. 이러한 경우 루비 필터를 사용하면 이러한 문제를 극복하는 데 도움이 될 수 있습니다.

Ruby 필터는 표준 Logstash 필터로 특정 요구 사항을 충족할 수 없을 때 유용합니다. 다음은 몇 가지 일반적인 사용 사례입니다:

• 심층 중첩 데이터 조작: 복잡한 JSON 구조, 배열 내의 배열을 수정하거나 콘텐츠에 따라 데이터를 동적으로 재구성합니다.

• 고급 문자열 처리: 비정형 텍스트에서 정형 데이터 구문 분석 및 추출

• 복잡한 비즈니스 로직 구현하기: 조건부 논리, 루프 또는 복잡한 계산이 필요한 사용자 지정 변환을 만듭니다.

기본 사용법

루비 필터의 작동 원리를 이해하기 위해 간단한 예제부터 살펴보겠습니다.

루비 필터 구성하기

Logstash 파이프라인을 생성할 때, 구성 파일을 /etc/logstash/conf.d 디렉터리에 배치해야 합니다. 또는 Logstash를 수동으로 부팅할 때 -f 옵션을 사용하여 구성 파일의 경로를 지정하면 파이프라인을 쉽게 실험할 수 있습니다.

구성 파일의 확장자는 .conf 여야 합니다.

Ruby 필터를 사용하려면 Logstash 파이프라인 구성(*.conf) 파일의 필터 섹션에 ruby 필터를 정의하세요. 다음은 기본적인 예입니다:

이 인라인 Ruby 필터는 Logstash 구성 내에서 Ruby 필터 인스턴스를 정의합니다. code 매개변수는 이 필터가 처리하는 각 이벤트에 대해 Logstash가 실행할 인라인 Ruby 스크립트를 제공합니다. 해당 스크립트 내부에는 이벤트 자체를 나타내는 event 변수가 있습니다. 이벤트 객체에는 Logstash로 전송된 원본 데이터와 Logstash의 필터 단계에서 생성된 모든 추가 필드가 포함되어 있습니다. event.get() 및 event.set() 과 같은 Logstash 이벤트 API를 통해 이러한 필드에 액세스할 수 있습니다. 이 예제 코드에서 event.set('new_field', 'Hello from Ruby!') 는 new_field 이라는 새 필드를 문자열 값 Hello from Ruby! 으로 설정합니다. 필요에 따라 이 code 블록에 다른 코드를 추가할 수 있습니다.

이 event 객체는 키-값 유형의 데이터 컨테이너로 작동하지만 일반적인 Ruby의 해시 객체가 아닙니다. 이벤트 API에 대해 자세히 알아보려면 이 공식 문서를 확인하세요.

루비 스크립트 외부화

간단한 변환의 경우 인라인 루비 코드가 편리합니다. 그러나 복잡한 로직이나 재사용 가능한 함수의 경우 코드를 외부 Ruby 스크립트로 옮기는 것이 좋습니다. 이렇게 하면 유지보수성이 향상되고 Logstash 파이프라인 구성이 깔끔하게 유지됩니다.

먼저 루비 스크립트를 만들어 my_ruby_script.rb 로 저장합니다. 스크립트는 이벤트를 처리하는 filter 메서드를 정의해야 합니다. 이 함수는 처리 중인 현재 이벤트를 나타내는 이벤트 객체를 인수로 받습니다. filter 메서드는 전송할 이벤트 배열을 반환해야 합니다. 이벤트를 삭제하려면 빈 배열을 반환합니다.

예를 들어 다음 스크립트는 message 필드를 읽고 길이를 계산한 다음 그 결과를 message_length 이라는 새 필드에 저장합니다.

그런 다음 path 옵션을 사용하여 스크립트를 참조하도록 루비 필터 구성을 설정합니다. 이렇게 하면 Logstash가 외부 스크립트를 로드하고 실행하도록 지시합니다. 외부 스크립트를 사용할 때는 파일이 존재하고 올바른 권한이 있는지 확인하세요.

이제 각 이벤트는 my_ruby_script.rb 의 filter 메서드로 전달되어 처리됩니다.

이 접근 방식을 사용하면 복잡한 로직을 보다 효과적으로 관리할 수 있으므로 Ruby 코드를 더 쉽게 테스트, 디버그 및 재사용할 수 있습니다.

고급 사용 방법

이 섹션에서는 Logstash에서 Ruby 필터를 사용하는 몇 가지 고급 예제를 살펴보겠습니다. 이 예제에서는 Ruby를 사용하여 데이터 변환을 수행하고, 이벤트를 보강하고, 사용자 지정 로직을 구현하는 방법을 보여드립니다.

중첩된 데이터 구조 조작하기

Logstash 이벤트는 Logstash가 처리하는 핵심 데이터 구조입니다. 배열 및 해시 같은 중첩된 데이터 구조를 포함하여 다양한 필드를 포함할 수 있습니다. 루비 필터를 사용하면 이러한 중첩 구조를 쉽게 조작할 수 있습니다.

루비 필터는 해시 및 배열과 같은 중첩된 데이터 구조를 처리할 수 있으므로 이러한 구조 내에서 필드를 수정하거나 추가할 수 있습니다. 이는 JSON과 같은 복잡한 데이터 형식을 다룰 때 유용합니다.

이 예제에는 입력 데이터에 중첩된 JSON 객체가 포함되어 있습니다. 루비 필터는 새로운 키-값 쌍을 추가하여 중첩된 데이터를 수정합니다. 중첩된 데이터에 대한 이러한 유형의 조작은 표준 Logstash 필터로는 불가능하므로, 복잡한 데이터 구조에 편리한 옵션으로 Ruby 필터를 사용할 수 있습니다.

단일 이벤트를 여러 이벤트로 분할

루비 필터를 사용하여 단일 이벤트를 여러 개의 이벤트로 분할할 수도 있습니다. 여러 항목이 포함된 단일 이벤트가 있고 각 항목에 대해 별도의 이벤트를 만들려는 경우에 유용합니다.

Elasticsearch의 수집 파이프라인이나 Beats/Elastic Agent의 프로세서 모두 이벤트 분할을 지원하지 않습니다. 이것은 Logstash의 가장 강력한 사용 사례 중 하나입니다.

분할 필터 사용

split 필터를 사용하여 지정된 필드를 기준으로 이벤트를 여러 개의 이벤트로 분할할 수 있습니다. 그러나 분할 중에 추가 변환이나 로직을 수행해야 하는 경우 분할 필터와 함께 루비 필터를 사용할 수 있습니다.

다음 예시에서는 한 줄의 XML 텍스트로 된 RSS 피드가 있습니다. 여기에는 여러 <item> 요소가 포함되어 있습니다. 루비 필터는 XML에서 <item> 요소를 추출하여 items 이라는 새 필드에 저장하는 데 사용됩니다. 그런 다음 분할 필터를 사용하여 items 필드를 기준으로 이벤트를 여러 개의 이벤트로 분할합니다.

다음과 같이 출력됩니다:

눈치채셨겠지만, 이 경우 ruby 필터는 필수 항목이 아닙니다. split 필터는 items 필드를 기준으로 이벤트를 여러 개의 이벤트로 분할하는 데 사용할 수 있으며, mutate 필터는 불필요한 필드를 제거하는 데 사용할 수 있습니다. 그러나 분할 중에 추가 변환이나 로직을 수행해야 하는 경우 루비 필터를 사용할 수 있습니다.

인라인 루비 스크립트 사용

또한 인라인 루비 스크립트를 사용하여 event.clone 메서드와 new_event_block variable, 예: new_event_block.call(new_event) 를 사용하여 단일 이벤트를 여러 개의 이벤트로 분할할 수도 있습니다. 이렇게 하면 데이터를 보존하면서 원래 이벤트를 기반으로 새 이벤트를 만들 수 있습니다.

다음은 루비 필터를 사용하여 단일 이벤트를 여러 개의 이벤트로 분할하는 방법의 예시입니다. 입력 및 출력은 이전 예제와 동일합니다.

외부 루비 스크립트 사용

외부 루비 스크립트를 사용하여 단일 이벤트를 여러 개의 이벤트로 분할할 수도 있습니다.

구성 파일입니다:

루비 스크립트는 split_event.rb 로 외부화해야 합니다:

filter 메서드는 이벤트 배열을 반환해야 한다는 점을 기억하세요. 들어오는 이벤트 객체를 복제하여 배열에 추가하여 여러 이벤트를 반환하거나 단일 이벤트를 하나의 요소가 있는 배열로 반환할 수 있습니다.

이렇게 하면 하나의 이벤트를 여러 개의 이벤트로 분할할 수 있습니다.

외부 명령 실행 및 출력 구문 분석

Logstash 실행 입력 플러그인을 사용하면 외부 명령을 실행할 수 있으며, 그 출력은 Logstash의 이벤트가 됩니다. 명령의 출력은 이벤트의 message 필드에 저장됩니다.

일반적으로 시스템 명령의 출력은 사람이 읽을 수 있지만, Logstash가 쉽게 구문 분석할 수 있는 JSON이나 기타 형식으로 구조화되어 있지 않습니다. 이를 처리하기 위해 루비 필터를 사용하여 출력을 구문 분석하고 거기서 정보를 추출할 수 있습니다.

다음은 exec 입력 플러그인을 사용하여 유닉스 계열 시스템에서 실행 중인 모든 프로세스를 나열하는 ps -ef 명령을 실행하는 예제입니다. 출력은 루비 필터로 파싱되어 각 프로세스에 대한 관련 정보를 추출합니다.

이 예에서는 exec 입력 플러그인을 사용하여 60초마다 ps -ef 명령을 실행합니다. 루비 필터는 출력을 처리하여 UID, PID, PPID, CPU 사용량(C), 시작 시간(STIME), TTY, 총 CPU 시간(TIME), 실행된 명령(CMD) 등 관련 필드를 추출합니다. 제 macOS 환경에서는 잘 작동하지만 시스템의 ps -ef 명령의 출력 형식과 일치하도록 정규식 패턴을 조정해야 할 수도 있습니다.

기본 제공 라이브러리 사용

루비 필터 플러그인을 사용하면 내장된 루비 라이브러리를 사용할 수 있어 다양한 작업에 매우 유용할 수 있습니다. 예를 들어 json 라이브러리를 사용하여 JSON 문자열을 구문 분석하거나 date 라이브러리를 사용하여 날짜를 조작할 수 있습니다.

다음은 json 라이브러리를 사용하여 필드에 저장된 JSON 문자열을 구문 분석하는 예제입니다:

매번 라이브러리가 필요하지 않도록 하려면 Ruby 필터 스크립트의 시작 부분에 require 문을 사용할 수 있도록 Ruby 코드를 외부화해야 합니다. 이렇게 하면 라이브러리가 한 번 로드되고 스크립트에서 사용할 수 있게 됩니다.

사용자 환경에서 어떤 라이브러리를 사용할 수 있는지 확인하려면 Ruby 필터에서 다음 코드를 실행하여 기본 제공 라이브러리를 나열할 수 있습니다:

참고: 기본 제공 라이브러리는 Logstash에서 공식적으로 지원되지 않으며, 동작이 변경되거나 향후 버전에서 제공되지 않을 수 있습니다. 본인 책임하에 사용하세요.

결론

Logstash Ruby 필터를 사용하면 Logstash 파이프라인의 기능을 사용자 정의하고 확장할 수 있습니다. 이 글에서는 루비 필터 사용의 기본 사항을 다루고 고급 사용 예제를 제공했습니다.

루비 필터를 활용하면 사용자 지정 로직이나 고급 조작이 필요한 복잡한 데이터 처리 작업을 처리할 수 있습니다. 중첩된 데이터 구조로 작업하거나 이벤트를 분할하거나 복잡한/비구조화 텍스트를 구문 분석하여 구조화된 JSON으로 변환하는 등, Ruby 필터는 특정 요구 사항을 충족하는 유연성을 제공합니다.

이 가이드가 Logstash Ruby 필터의 잠재력을 최대한 활용할 수 있는 지식과 영감을 제공해 주었기를 바랍니다. 행복한 스크립팅!

1. _mapping API를 사용하여 필드 정보 검색하기

2. API를 사용하여 필드 값 표시_search

3. 매개 변수를 사용하여 필드 필터링 fields

4. 중첩된 필드 표시

1. 맵핑 API를 사용하여 필드 정보 검색하기

_mapping API를 사용하면 인덱스 또는 여러 인덱스에 대한 매핑 정의를 검색할 수 있습니다. 여기에는 필드, 데이터 유형 및 기타 속성에 대한 정보가 포함됩니다. 특정 인덱스에 대한 매핑을 검색하려면 다음 요청을 사용하세요:

예를 들어 my_index 이라는 인덱스가 있는 경우 다음 요청으로 해당 인덱스의 매핑을 검색할 수 있습니다:

응답에는 필드 및 해당 속성에 대한 정보가 포함된 인덱스에 대한 매핑 정의가 포함됩니다.

특정 필드에 대한 매핑을 검색할 수도 있습니다. 매핑이 상당히 크고 특정 필드에만 집중하려는 경우 유용할 수 있습니다. 특정 필드의 매핑을 검색하려면 다음 요청을 사용하세요:

다음 요청에서와 같이 쉼표로 이름을 구분하여 여러 필드의 매핑을 검색할 수도 있습니다:

2. search API를 사용하여 필드 값 표시하기

Elasticsearch 인덱스의 필드 값을 표시하려면 _search API를 사용하면 됩니다. 기본적으로 _search API는 색인된 원본 JSON 문서가 포함된 _source 필드를 반환합니다. 특정 필드만 표시하려면 검색 요청에 _source 매개변수를 사용하면 됩니다.

다음은 my_index 인덱스에 있는 문서에 대한 title 및 author 필드 값을 반환하는 검색 요청의 예입니다:

이 예제에서 _source 매개변수는 반환할 필드를 지정합니다.

3. fields 매개변수를 사용하여 필드 필터링하기

fields 매개변수를 사용하여 검색 응답에 반환되는 필드를 필터링할 수도 있습니다. 특정 필드만 필요하고 응답의 크기를 줄이려는 경우 유용할 수 있습니다. fields 매개변수는 필드 이름 또는 와일드카드 패턴의 배열을 허용합니다.

예를 들어 my_index 색인에 있는 문서에 대해 title 및 author 필드만 반환하려면 다음 검색 요청을 사용할 수 있습니다:

소스 문서를 반환하지 않으려면 _source 매개 변수를 false로 설정해야 합니다.

text 데이터 유형이 있는 모든 필드를 반환하려면 다음과 같은 와일드카드 패턴을 사용할 수 있습니다:

4. 중첩된 필드 표시

인덱스에 중첩 필드가 포함된 경우, 점 표기법을 사용하여 fields 매개변수에서 중첩 필드 경로를 지정할 수 있습니다. 예를 들어 address.city 이라는 이름의 중첩 필드가 있는 경우 다음과 같이 검색 응답에 포함할 수 있습니다:

이 예제에서는 검색 응답에 title, author, address.city 필드의 값이 포함됩니다.

결론

결론적으로, Elasticsearch 인덱스에서 필드를 표시하려면 _mapping API를 사용하여 필드 정보를 검색하고 _search API를 사용하여 필드 값을 표시할 수 있습니다. _source 또는 fields 매개변수를 사용하여 검색 응답에 반환된 필드를 필터링하고 점 표기법을 사용하여 중첩된 필드를 표시할 수 있습니다. 이러한 기술은 데이터의 구조를 이해하고, 특정 필드를 식별하고, 문제를 해결하는 데 도움이 될 수 있습니다.

이 문서에서는 색인에서 필드를 제외하는 이유, 특정 필드를 제외하도록 Elasticsearch를 구성하는 방법, 그리고 그렇게 할 때 따라야 할 몇 가지 모범 사례에 대해 설명합니다.

인덱싱에서 필드를 제외하는 이유

1. 성능: 문서의 모든 필드를 색인하면 색인 시간이 길어지고 검색 성능이 저하될 수 있습니다. 검색이나 집계에 필요하지 않은 필드를 제외하면 Elasticsearch 클러스터의 전반적인 성능을 개선할 수 있습니다.

2. 저장소: 필드 인덱싱은 저장 공간을 소모합니다. 검색이나 집계에 필요하지 않은 필드를 제외하면 Elasticsearch 클러스터의 저장 공간 요구 사항을 줄이는 데 도움이 될 수 있습니다.

3. 인덱스 크기: Elasticsearch 인덱스의 크기는 색인되는 필드의 수와 직접적으로 관련이 있습니다. 불필요한 필드를 제외하면 색인 크기를 최소화할 수 있어 검색 및 색인 성능이 향상될 수 있습니다.

필드를 제외하도록 Elasticsearch 구성하기

Elasticsearch에서 필드를 색인되지 않도록 제외하려면 필드 매핑에서 "index" 속성을 사용하면 됩니다. "index" 속성을 "false"로 설정하면 Elasticsearch는 필드를 색인하지 않으며, 검색하거나 집계에 사용할 수 없게 됩니다.

다음은 Elasticsearch 매핑을 사용하여 필드를 색인에서 제외하는 방법의 예입니다:

이 예에서는 "field_to_exclude"라는 단일 필드를 사용하여 "my_index"라는 새 인덱스를 생성합니다. "index" 속성을 "false"로 설정하면, 이 필드를 색인하지 않도록 Elasticsearch에 지시하는 것입니다. 하지만 이 필드는 소스 문서에서 계속 사용할 수 있습니다.

인덱싱에서 필드를 제외하는 모범 사례

1. 데이터 분석하기: 인덱싱에서 필드를 제외하기 전에 데이터를 분석하고 검색 및 집계에 필요한 필드를 파악하는 것이 중요합니다. 이를 통해 제외할 필드에 대해 정보에 입각한 결정을 내릴 수 있습니다.

2. 변경 사항을 테스트합니다: 인덱싱에서 필드를 제외할 때는 변경 사항을 테스트하여 검색 및 집계 기능이 여전히 예상대로 작동하는지 확인하는 것이 중요합니다. 이렇게 하면 예기치 않은 문제나 성능 문제를 방지하는 데 도움이 됩니다.

3. 성능 모니터링: 색인에서 필드를 제외시킨 후, Elasticsearch 클러스터의 성능을 모니터링하여 변경 사항이 원하는 효과를 가져왔는지 확인합니다. 이를 통해 필요한 추가 최적화를 파악하는 데 도움이 될 수 있습니다.

4. 소스 필터링 사용: Elasticsearch에 필드를 저장해야 하지만 검색 가능하거나 집계에 사용할 수 없도록 하려면 소스 필터링을 사용하는 것을 고려하세요. 이렇게 하면 _source 필드에 필드를 저장하되 인덱스에서 제외할 수 있습니다.

결론

Elasticsearch에서 색인에서 필드를 제외하면 성능을 개선하고, 저장 비용을 절감하며, 전체 색인 크기를 최소화하는 데 도움이 될 수 있습니다. 데이터를 신중하게 분석하고 검색 및 집계에 필요한 필드를 이해하면 어떤 필드를 제외할지 정보에 입각한 결정을 내릴 수 있습니다. 항상 변경 사항을 테스트하고 Elasticsearch 클러스터의 성능을 모니터링하여 최적화가 원하는 효과를 가져오는지 확인하세요.

• 매핑 정의는 데이터 스키마를 지정합니다.

• 설정에서 샤드 크기와 새로 고침 빈도를 설정합니다. 

• 별칭은 인덱스에 대체 이름을 지정하는 데 사용됩니다.

문서를 처음 색인하거나 색인 생성 API를 사용하여 빈 색인을 만들면 데이터 스키마 및 별칭 없이 기본 설정으로 색인이 생성됩니다. 이러한 기본값은 개발 및 테스트 환경에서는 잘 작동하지만 프로덕션 환경에 맞게 인덱스를 사용자 지정해야 할 수도 있습니다.

프로덕션 환경에서 기본 매핑 및 설정으로 작업하면 색인 및 검색 성능이 저하될 수 있습니다. 인덱스를 수동으로 인스턴스화하는 작업은 지루하고 시간이 많이 걸리는 과정입니다. 정교한 매핑 스키마와 사용자 정의 설정 및 별칭이 있는 경우 모든 환경에서 이러한 인덱스를 다시 생성하는 것은 특히 비현실적입니다.

다행히도 Elasticsearch는 인덱스 템플릿형태로 인덱스를 생성할 때 미리 정의된 구성을 자동으로 적용할 수 있는 도구를 제공합니다.

색인 템플릿

인덱스 템플릿을 사용하면 사용자 정의 구성으로 인덱스를 만들 수 있습니다. 인덱스는 인스턴스화 중에 이러한 템플릿에서 설정된 수의 샤드 및 복제본 또는 필드 매핑과 같은 구성을 가져올 수 있습니다. 템플릿은 이름 패턴과 일부 구성으로 정의됩니다. 인덱스의 이름이 템플릿의 명명 패턴과 일치하면 템플릿에 정의된 구성으로 새 인덱스가 생성됩니다.

Elasticsearch는 버전 7.8에서 구성 가능한 템플릿으로 템플릿 기능을 업그레이드했습니다. 이 최신 버전은 이 문서에서 설명한 대로 훨씬 더 많은 재사용 가능한 인덱스 템플릿을 제공합니다.

인덱스 템플릿의 종류

색인 템플릿은 두 가지 범주로 분류할 수 있습니다:

• 색인 템플릿(또는 컴포저블 색인 템플릿): 구성 가능한 인덱스 템플릿은 단독으로 존재하거나 하나 이상의 구성 요소 템플릿으로 구성될 수 있습니다(두 번째 범주 참조).

• 컴포넌트 템플릿: 컴포넌트 템플릿은 필요한 구성을 정의하는 자체적으로 재사용 가능한 템플릿입니다. 일반적으로 컴포넌트 템플릿은 인덱스 템플릿과 연결될 것으로 예상됩니다. 각 컴포넌트 템플릿에는 하나 또는 여러 개의 인덱스 템플릿을 첨부할 수 있습니다. 

아래 이미지에서 볼 수 있듯이 인덱스 템플릿 A와 B는 서로 구성 요소 템플릿(이 경우 템플릿 3 하나만)을 공유합니다. 인덱스 템플릿은 하나 또는 여러 개의 구성 요소 템플릿으로 구성될 수 있으며, 각 구성 요소 템플릿은 하나 또는 여러 개의 인덱스 템플릿과 연결될 수 있습니다. 두 가지 유형의 템플릿은 모두 단독으로 존재할 수 있지만 컴포넌트 템플릿은 인덱스 템플릿에 첨부하지 않으면 아무 소용이 없습니다.

일반적인 아이디어는 조직이 다양한 필요에 따라 사용할 수 있도록 구성 요소 템플릿 카탈로그를 개발하고(예: 개별 환경에 맞는 다양한 구성 요소 템플릿 지정), 구성 가능한 인덱스 템플릿을 통해 다양한 인덱스에 이를 첨부하는 것입니다.

작성 가능한(색인) 템플릿을 만드는 방법

Elasticsearch는 인덱스 템플릿을 관리하기 위한 _index_template 엔드포인트를 제공합니다. 사용자는 이 템플릿에서 인덱스 이름 패턴과 함께 필요한 모든 매핑, 설정 및 별칭을 제공합니다. 주문 생성 로직을 담당하는 마이크로서비스 애플리케이션 고객 주문 서비스에 대한 템플릿을 만드는 예제를 살펴보겠습니다. 

와일드카드가 있는 패턴으로 표시되는 고객 주문에 대한 템플릿을 만들어야 한다고 가정해 보겠습니다: *orders. 이 템플릿에는 주문_날짜 필드, 샤드 및 복제본 번호와 같은 특정 매핑 및 설정이 있을 것으로 예상됩니다.

인덱스를 생성하는 동안 이 템플릿과 일치하는 모든 인덱스는 이 템플릿에 정의된 구성을 상속합니다. 예를 들어 검은_금요일_주문 인덱스에는 order_date 필드가 있고, 샤드는 5로 설정되며 복제본은 2로 설정됩니다. 이 외에도 이 템플릿에서 생성된 모든 인덱스는 단일 별칭 이름을 상속받습니다! 주문으로 정의된 인덱스 패턴과 미리 정의된 날짜 형식 dd-MM-yyyy를 가진 단일 oder_date 필드로 구성된 매핑 스키마를 사용하여 이 orders_template을 만들어 보겠습니다. 아래 코드는 이 인덱스 템플릿을 만드는 방법을 보여줍니다.

Kibana의 개발자 도구에서 이 쿼리를 실행하면 미리 정의된 매핑, 설정 및 별칭과 함께 *orders 인덱스 패턴으로 템플릿이 생성됩니다. index_patterns는 일치 패턴의 배열로, 이 패턴과 일치하는 인덱스는 템플릿 구성을 도출합니다. 다음을 실행하여 우리가 수행한 작업을 반복해야 하는 지속된 템플릿을 검색할 수 있습니다:

템플릿에 정의된 템플릿 속성을 만들 때 양수인 우선순위를 정의할 수도 있습니다. 모든 템플릿에는 우선순위가 정의되어 있으므로 다른 템플릿에서 충돌하는 변경 사항이 있을 경우 우선순위가 높은 값을 우선하여 이 값을 사용하여 해결됩니다. 아래에서 템플릿 우선 순위에 대해 자세히 알아보겠습니다.

템플릿으로 색인 만들기

이제 인덱스를 만들기 위한 청사진인 템플릿이 생겼으니 다음 단계는 인덱스를 만드는 것입니다. 인덱스 이름이 지정된 패턴과 일치하면 템플릿 구성이 자동으로 적용됩니다. 이를 증명하기 위해 아래 코드에서 볼 수 있듯이 검은 금요일_주문이라는 새로운 인덱스를 만들어 보겠습니다:

인덱스 이름(blackfriday_orders)이 템플릿에 정의된 명명 패턴과 일치하므로(예를 들어 *주문), 인덱스는 템플릿에서 파생된 모든 구성을 가져와야 합니다. 새로 생성된 인덱스를 검색하고 다음 코드를 실행하여 이것이 실제로 사실인지 확인해 보겠습니다:

반환됩니다:

응답에서 알 수 있듯이 검은 금요일 주문의 구성은 템플릿에서 상속되었습니다. 템플릿 구성을 성공적으로 상속할 수 있는 다양한 인덱스 조합을 시도해 볼 수 있습니다:

그러나 다음 인덱스는 이름이 패턴과 일치하지 않으므로 구성을 상속하지 않습니다:

기억해야 할 한 가지 중요한 점은 템플릿에서 파생된 모든 인덱스는 동일한 별칭(이 경우 all_orders)을 사용한다는 것입니다. 이러한 별칭을 사용하면 여러 인덱스가 아닌 이 단일 별칭으로 간단히 쿼리할 수 있다는 이점이 있습니다.

주문에 대한 템플릿을 생성하는 동안 일치하는 인덱스는 모두 템플릿 구성을 채택할 것으로 예상됩니다. 일반적으로 팀에서는 자의든 타의든 여러 가지 이유로 템플릿을 몇 개 더 만들 수 있습니다. 즉, 인덱스 이름이 두 개의 다른 템플릿 패턴과 일치하는 경우가 있습니다! Elasticsearch는 이러한 템플릿에서 어떤 구성을 적용해야 할지 결정해야 합니다. 다행히도 템플릿 우선순위를 사용하면 이 딜레마를 해결할 수 있습니다.

구성 요소 템플릿을 생성하는 방법

이 글의 앞부분에서 인덱스 템플릿에 대해 알아보았습니다. 구성이 내장된 템플릿을 만들면 몇 가지 단점이 있는데, 그 중 하나는 다른 템플릿으로 구성을 내보낼 수 없다는 점입니다. 고객 관련 템플릿(*고객)과 같이 유사한 구성을 원할 경우 전체 템플릿을 다시 만들어야 할 수도 있습니다. 즉, 일반적인 조직에서는 수십 개를 만들 수 있습니다(환경에 따라 몇 개 더 만들 수도 있습니다).

항상 재사용 가능성을 염두에 두고 템플릿을 재설계하기 때문에 Elasticsearch는 재사용 가능성을 염두에 두고 템플릿을 재설계했습니다. 컴포넌트 템플릿이 이에 적합합니다. DevOps 출신이라면 각 환경에 대해 미리 설정된 구성으로 인덱스를 만들어야 하는 요구 사항이 있을 것입니다. 이러한 각 구성을 수동으로 적용하는 번거로움 대신 각 환경에 대한 컴포넌트 템플릿을 만들 수 있습니다.

구성 요소 템플릿은 더 많은 인덱스 템플릿을 구성하는 데 사용할 수 있는 재사용 가능한 구성 블록에 불과합니다. 컴포넌트 템플릿은 인덱스 템플릿과 클럽화하지 않으면 아무런 가치가 없습니다. 구성 요소 템플릿 엔드포인트를 통해 노출됩니다. 이 모든 것이 어떻게 결합되는지 살펴봅시다.

인덱스 템플릿의 설정

앞서 인덱스 템플릿에서 정의한 설정을 추출하여 컴포넌트 템플릿을 만들어 보겠습니다. 설정_컴포넌트_템플릿에는 기본 샤드당 2개의 복제본이 있는 5개의 기본 샤드가 있어야 합니다. 아래 코드 목록에서 볼 수 있듯이 첫 번째 단계는 이 구성으로 컴포넌트 템플릿을 선언하고 실행하는 것입니다.

위의 코드에서 볼 수 있듯이 _component_template 엔드포인트를 사용하여 컴포넌트 템플릿을 생성합니다. 요청 본문에는 템플릿 객체에 템플릿 정보가 들어 있습니다. 이제 색인 템플릿의 다른 곳에서 settings_component_template을 사용할 수 있습니다. 한 가지 주목할 만한 차이점은 이 템플릿은 인덱스 패턴을 정의하지 않고 일부 속성을 구성하는 코드 블록에 불과하다는 점입니다.

매핑 템플릿

같은 방법으로 다른 템플릿을 만들어 보겠습니다. 이번에는 앞서 독립형 인덱스 템플릿에서 정의했던 매핑 스키마를 추출해 보겠습니다. 아래 코드는 스크립트를 보여줍니다:

별칭 템플릿

동일한 흐름에 따라 별칭이 있는 컴포넌트 템플릿(두 개의 별칭(all_orders 및 sales_orders))을 가질 수도 있습니다:

작성 가능한 색인 템플릿

이제 세 가지 컴포넌트 템플릿을 준비했으니 다음 단계는 이를 사용하는 것입니다. 예를 들어 christmas_orders에 대한 인덱스 템플릿을 사용하도록 허용하면 이 작업을 수행할 수 있습니다:

composed_of 태그는 이 템플릿을 구성하는 모든 컴포넌트 템플릿의 모음입니다. 이 경우 설정, 매핑 및 별칭 컴포넌트 템플릿을 선택합니다. 또한 이 템플릿이 다른 템플릿보다 우선하도록 우선순위를 높이고 있습니다. 템플릿이 준비되면 *주문 패턴과 일치하는 모든 인덱스는 이 세 가지 구성 요소 템플릿의 구성을 상속받게 됩니다.

하지만 고객과 같은 새 템플릿을 만들려면 기존 템플릿(settings_component_template)과 새로 만든 별칭(aliases_component_template - 아래 참조) 템플릿 중 하나만 사용하여 만들 수 있습니다:

인덱스 템플릿은 다음과 같습니다:

설정_컴포넌트_템플릿이 두 개의 다른 템플릿에서 (재)사용된 것을 보셨나요? 이것이 바로 컴포넌트 템플릿의 힘입니다.

인덱스 템플릿 우선순위

개발자가 기존 종목을 보지 않고 여러 개의 인덱스 템플릿을 만들 수 있습니다. 이러한 템플릿 각각에 우선순위를 설정하여 우선순위가 높은 템플릿이 사용되도록 하는 것이 중요합니다. 예를 들어, 다음 코드 스니펫에서 my_orders_template_1이 my_orders_template_2를 재정의합니다:

생성 중인 인덱스와 일치하는 템플릿이 여러 개 있는 경우, Elasticsearch는 일치하는 모든 템플릿의 모든 구성을 적용하지만 우선순위가 더 높은 모든 구성을 재정의합니다.

템플릿의 우선 순위

마지막으로 템플릿의 우선순위에 대해 궁금하실 텐데요, 구성 요소 템플릿에 정의된 구성이 기본 인덱스 템플릿 자체에 정의된 구성보다 우선하나요? 아니면 그 반대일까요? 몇 가지 규칙이 있습니다:

• 즉, 명시적으로 구성하여 만든 인덱스는 모든 항목보다 우선합니다. 즉, 명시적으로 구성하여 인덱스를 만들면 템플릿에 의해 재정의되지 않을 것으로 기대하지 마세요.

• 레거시 템플릿(버전 7.8 이전에 만든 템플릿)은 작성 가능한 템플릿보다 우선 순위가 낮습니다.

요약

• 인덱스에는 매핑, 설정 및 별칭이 포함됩니다. 매핑은 필드 스키마를 정의하고, 설정은 샤드 및 복제본 수와 같은 인덱스 파라미터를 설정하며, 별칭은 인덱스에 대체 이름을 부여합니다.

• 템플릿을 사용하면 미리 정의된 구성으로 인덱스를 만들 수 있습니다. 특정 템플릿에 정의된 인덱스 패턴과 일치하는 이름으로 인덱스 이름을 지정하면 템플릿에 따라 해당 인덱스가 자동으로 구성됩니다.

• Elasticsearch는 버전 7.8에서 구성 가능한 인덱스 템플릿을 도입했습니다. 구성 가능한 인덱스 템플릿을 사용하면 템플릿을 모듈화하고 버전을 관리할 수 있습니다.

• 컴포저블 템플릿은 하나 이상의 컴포넌트 템플릿으로 구성됩니다.

• 인덱스 템플릿에는 자체 구성도 정의할 수 있습니다.

• 컴포넌트 템플릿은 작성 가능한 인덱스 템플릿과 마찬가지로 미리 정의된 구성이 있는 재사용 가능한 템플릿입니다.

• 그러나 구성 요소 템플릿은 인덱스 템플릿의 일부가 되어야 하며, 인덱스 템플릿으로 '구성'되지 않으면 쓸모가 없습니다.

• 구성 요소 템플릿에는 인덱스 패턴이 정의되어 있지 않으므로 인덱스 템플릿의 일부가 될 것으로 '예상'되는 또 다른 이유입니다.

• 각 템플릿에는 양수인 우선순위가 있습니다. 숫자가 높을수록 해당 템플릿이 적용되는 우선 순위가 높아집니다.

이 문서에서는 주요 개념, 전제 조건 및 단계별 통합을 다루면서 Elasticsearch로 데이터를 수집하도록 Airbyte를 구성하는 방법에 대해 설명합니다.

에어바이트 기본 개념

에어바이트에는 몇 가지 필수 개념이 있습니다. 아래에서는 주요 내용을 강조합니다:

• 소스: 추출할 데이터의 출처를 정의합니다.

• 대상: 대상: 데이터를 전송하고 저장할 위치를 정의합니다.

• 연결: 동기화 빈도를 포함하여 소스와 대상 간의 관계를 구성합니다.

Airbyte와 Elasticsearch 통합

이 데모에서는 S3 버킷에 저장된 데이터를 Elasticsearch 인덱스로 마이그레이션하는 통합을 수행합니다. Airbyte에서 소스(S3)와 대상(Elasticsearch)을 구성하는 방법을 보여드리겠습니다.

필수 구성 요소

이 데모를 따라하려면 다음 전제 조건을 충족해야 합니다:

1. 데이터가 포함된 JSON 파일이 저장될 버킷을 AWS에 생성합니다.

2. Docker를 사용하여 로컬에 Airbyte를 설치합니다.

3. 수집된 데이터를 저장하기 위해 Elastic Cloud에서 Elasticsearch 클러스터를 생성합니다.

아래에서 이러한 각 단계에 대해 자세히 설명합니다.

Airbyte 설치

Airbyte는 Docker를 사용하여 로컬에서 실행하거나 사용 비용이 발생하는 클라우드에서 실행할 수 있습니다. 이 데모에서는 Docker가 포함된 로컬 버전을 사용하겠습니다.

설치하는 데 몇 분 정도 걸릴 수 있습니다. 설치 지침을 따르고 나면 Airbyte를 http://localhost:8000 에서 사용할 수 있습니다.

로그인한 후 연동 구성을 시작할 수 있습니다.

버킷 만들기

이 단계에서는 S3 버킷을 생성하기 위해 AWS 계정이 필요합니다. 또한 버킷에 대한 액세스를 허용하는 정책과 IAM 사용자를 만들어 올바른 권한을 설정하는 것이 중요합니다.

버킷에 다양한 로그 레코드가 포함된 JSON 파일을 업로드하고 나중에 Elasticsearch로 마이그레이션할 것입니다. 파일 로그에는 이 내용이 있습니다:

아래는 버킷에 로드된 파일입니다:

Elastic Cloud 구성

데모를 더 쉽게 하기 위해 Elastic Cloud를 사용하겠습니다. 아직 계정이 없는 경우 여기에서 무료 체험판 계정을 생성할 수 있습니다: Elastic Cloud 등록.

Elastic Cloud에서 배포를 구성한 후에는 다음과 같은 정보를 얻어야 합니다:

• Elasticsearch 서버의 URL입니다.

• Elasticsearch에 액세스하는 사용자입니다.

URL을 얻으려면 배포 > 내 배포로 이동하여 애플리케이션에서 Elasticsearch를 찾아 '엔드포인트 복사'를 클릭합니다.

사용자를 만들려면 아래 단계를 따르세요:

1. Kibana에 액세스 > 스택 관리 > 사용자.

2. 수퍼유저 역할을 가진 새 사용자를 만듭니다.

3. 필드를 채워 사용자를 만듭니다.

이제 모든 설정이 완료되었으므로 Airbyte에서 커넥터 구성을 시작할 수 있습니다.

소스 커넥터 구성

이 단계에서는 S3용 소스 커넥터를 만들겠습니다. 이를 위해 Airbyte 인터페이스에 액세스하고 메뉴에서 소스 옵션을 선택합니다. 그런 다음 S3 커넥터를 검색합니다. 아래에서는 커넥터를 구성하는 데 필요한 단계를 자세히 설명합니다:

1. Airbyte에 액세스하고 소스 메뉴로 이동합니다.

2. S3 커넥터를 검색하여 선택합니다.

3. 다음 매개변수를 구성합니다:

   1. 소스 이름: 데이터 소스의 이름을 정의합니다.

   2. 전달 방법: 레코드 복제를 선택합니다(구조화된 데이터에 권장).

   3. 데이터 형식: JSON 형식을 선택합니다.

   4. 스트림 이름: Elasticsearch에서 인덱스의 이름을 정의합니다.

   5. 버킷 이름: AWS에서 버킷의 이름을 입력합니다.

   6. AWS 액세스 키와 AWS 비밀 키를 입력합니다: 액세스 자격 증명을 입력합니다.

소스 설정을 클릭하고 유효성 검사를 기다립니다.

구성 대상 커넥터

이 단계에서는 대상 커넥터를 구성할 것이며, 이 커넥터는 Elasticsearch가 될 것입니다. 이렇게 하려면 메뉴에 액세스하여 대상 옵션을 선택합니다. 그런 다음 Elasticsearch를 검색하고 반환된 결과를 클릭합니다. 이제 이 연결의 구성을 진행하겠습니다:

1. Airbyte에 액세스하고 목적지 메뉴로 이동합니다.

2. Elasticsearch 커넥터를 검색하고 선택합니다.

3. 다음 매개변수를 구성합니다:

   1. 인증 방법: 사용자 이름/비밀번호를 선택합니다.

   2. 사용자 이름 및 비밀번호: Kibana에서 생성한 자격 증명을 사용합니다.

   3. 서버 엔드포인트: Elastic Cloud에서 복사한 URL을 붙여넣습니다.

대상 설정을 클릭하고 유효성 검사를 기다립니다.

소스 및 대상 연결 만들기

소스 및 대상이 생성되면 소스 및 대상 간의 연결이 생성되어 통합 생성이 완료됩니다.

다음은 연결을 만드는 방법에 대한 안내입니다:

1. 메뉴에서 연결로 이동하여 첫 번째 연결 만들기를 클릭합니다.

2. 다음 화면에서 기존 소스를 선택하거나 새 소스를 만들 수 있습니다. 이미 생성한 소스가 있으므로 소스 S3를 선택합니다.

3. 다음 단계는 목적지를 선택하는 것입니다. 이미 Elasticsearch 커넥터를 생성했으므로 구성을 완료하기 위해 이 커넥터가 선택됩니다.

다음 단계에서는 동기화 모드와 어떤 스키마를 사용할지 정의해야 합니다. 로그 스키마만 생성되었으므로 선택할 수 있는 옵션은 로그 스키마가 유일합니다.

4. 연결 구성 단계로 이동합니다. 여기에서 연결 이름과 통합 실행 빈도를 정의할 수 있습니다. 주파수는 세 가지 방법으로 구성할 수 있습니다:

• Cron: 사용자 정의 크론 표현식(예: 0 0 15 * * ?, 매일 15:00에)에 따라 동기화를 실행합니다;

• 예약됨: 지정된 시간 간격으로 동기화를 실행합니다(예 24시간마다, 2시간마다);

• 수동: 수동으로 동기화를 실행합니다.

이 데모에서는 수동 옵션을 선택하겠습니다.

마지막으로 연결 설정을 클릭하면 소스와 대상 간의 연결이 설정됩니다.

S3에서 Elasticsearch로 데이터 동기화하기

연결 화면으로 돌아오면 생성된 연결을 확인할 수 있습니다. 프로세스를 실행하려면 동기화를 클릭하기만 하면 됩니다. 그 순간부터 S3에서 Elasticsearch로 데이터 마이그레이션이 시작됩니다.

모든 것이 순조롭게 진행되면 동기화 상태가 표시됩니다.

Kibana에서 데이터 시각화하기

이제 Kibana로 이동하여 데이터를 분석하고 데이터가 올바르게 색인되었는지 확인하겠습니다. Kibana Discovery 섹션에서 로그라는 데이터 보기를 생성합니다. 이를 통해 동기화 이후에 생성된 로그 인덱스에만 존재하는 데이터를 탐색할 수 있습니다.

이제 색인된 데이터를 시각화하고 분석을 수행할 수 있습니다. 이렇게 해서 Airbyte를 사용해 전체 마이그레이션 흐름을 검증하고, 버킷에 있는 데이터를 로드하고 Elasticsearch에서 색인을 생성했습니다.

결론: Airbyte & Elasticsearch 통합

Airbyte는 데이터 통합을 위한 효율적인 도구로 여러 소스와 대상을 자동화된 방식으로 연결할 수 있는 것으로 입증되었습니다. 이 튜토리얼에서는 S3 버킷에서 Elasticsearch 인덱스로 데이터를 수집하는 방법을 시연하면서 프로세스의 주요 단계를 강조했습니다.

이 접근 방식은 대량의 데이터 수집을 용이하게 하고 복잡한 검색, 집계, 데이터 시각화와 같은 분석을 Elasticsearch 내에서 수행할 수 있게 해줍니다.

참고 자료

에어바이트 퀵스타트:

https://docs.airbyte.com/using-airbyte/getting-started/oss-quickstart#part-1-install-abctl

핵심 개념:

https://docs.airbyte.com/using-airbyte/core-concepts/

라마인덱스란 무엇인가요?

LlamaIndex는 특정 또는 비공개 데이터와 상호 작용할 수 있는 대규모 언어 모델(LLM)로 구동되는 에이전트 및 워크플로우를 쉽게 만들 수 있는 프레임워크입니다. 다양한 소스(API, PDF, 데이터베이스)의 데이터를 LLM과 통합하여 연구, 정보 추출, 문맥에 맞는 응답 생성 등의 작업을 수행할 수 있습니다.

주요 개념:

• 에이전트: 간단한 응답부터 복잡한 작업까지 다양한 작업을 수행하기 위해 LLM을 사용하는 지능형 어시스턴트입니다.

• 워크플로우: 고급 작업을 위해 에이전트, 데이터 커넥터 및 도구를 결합하는 다단계 프로세스입니다.

• 컨텍스트 증강: 외부 데이터로 LLM을 보강하여 학습의 한계를 극복하는 기술입니다.

엘라스틱서치와라마인덱스 통합:

Elasticsearch는 LlamaIndex와 함께 다양한 방식으로 사용할 수 있습니다:

• 데이터 소스: Elasticsearch Reader를 사용하여 문서를 추출합니다.

• 임베딩 모델: 시맨틱 검색을 위해 데이터를 벡터로 인코딩합니다.

• 벡터 저장소: 벡터화된 문서를 검색하기 위한 리포지토리로 Elasticsearch를 사용하세요.

• 고급 스토리지: 문서 요약 또는 지식 그래프와 같은 구조를 구성하세요.

LlamaIndex와 Elasticsearch를 사용하여 FAQ 검색 구축하기

데이터 준비

Elasticsearch 서비스 FAQ를 예로 들어보겠습니다. 각 문제는 웹사이트에서 추출하여 개별 텍스트 파일에 저장했습니다. 어떤 방식으로든 데이터를 정리할 수 있지만, 이 예에서는 파일을 로컬에 저장하는 방법을 선택했습니다.

예제 파일입니다:

모든 문제를 저장한 후 디렉토리는 다음과 같이 표시됩니다:

종속성 설치

Python 언어를 사용하여 수집 및 검색을 구현할 것이며, 제가 사용한 버전은 3.9입니다. 전제 조건으로 다음 종속성을 설치해야 합니다:

Elasticsearch와 Kibana는 버전 8.16.2를 실행하도록 docker-compose.yml을 통해 구성된 Docker로 생성됩니다. 이렇게 하면 로컬 환경을 더 쉽게 만들 수 있습니다.

LlamaIndex를 사용한 문서 수집

문서는 LlamaIndex를 사용하여 Elasticsearch로 색인됩니다. 먼저 로컬 디렉터리에서 파일을 로드할 수 있는 SimpleDirectoryReader를 사용하여 파일을 로드합니다. 문서를 로드한 후 벡터스토어인덱스를 사용하여 색인을 생성합니다.

라마인덱스의 벡터 스토어는 문서 임베딩의 저장 및 관리를 담당합니다. LlamaIndex는 다양한 유형의 벡터 저장소를 지원하며, 이 경우에는 Elasticsearch를 사용하겠습니다. StorageContext에서 Elasticsearch 인스턴스를 구성합니다. 컨텍스트가 로컬이므로 추가 매개 변수가 필요하지 않았습니다. 다른 환경에서의 구성은 설명서를 참조하여 필요한 매개 변수를 확인하세요: ElasticsearchStore 구성.

기본적으로 LlamaIndex는 OpenAI 텍스트 임베딩-ada-002 모델을 사용하여 임베딩을 생성합니다. 하지만 이 예제에서는 텍스트 임베딩 3-소형 모델을 사용합니다. 이 모델을 사용하려면 OpenAI API 키가 필요하다는 점에 유의하세요.

아래는 문서 수집을 위한 전체 코드입니다.

실행 후 문서가 아래와 같이 FAQ 색인에 색인됩니다:

RAG로 검색

검색을 수행하기 위해 ElasticsearchStore 클라이언트를 구성하여 index_name 및 es_url 필드를 Elasticsearch URL로 설정합니다. retrieval_strategy에서 벡터 검색을 위한 AsyncDenseVectorStrategy를 정의했습니다. AsyncBM25Strategy (키워드 검색) 및 AsyncSparseVectorStrategy (희소 벡터)와 같은 다른 전략도 사용할 수 있습니다. 자세한 내용은 공식 문서에서 확인할 수 있습니다.

다음으로, VectorStoreIndex 객체가 생성되며, 여기서 ElasticsearchStore 객체를 사용하여 vector_store를 구성합니다. as_retriever 메서드를 사용하면 유사성_top_k 매개변수를 통해 반환되는 결과의 수를 5로 설정하여 쿼리와 가장 관련성이 높은 문서를 검색합니다.

다음 단계는 RAG입니다. 벡터 검색 결과는 LLM을 위한 형식화된 프롬프트에 통합되어 검색된 정보에 따라 상황에 맞는 응답이 가능합니다.

프롬프트 템플릿에서는 프롬프트 형식을 정의하며, 여기에는 다음이 포함됩니다:

• 컨텍스트 ({context_str}): 검색기가 검색한 문서입니다.

• 쿼리 ({query_str}): 사용자의 질문입니다.

• 지침: 모델이 외부 지식에 의존하지 않고 상황에 따라 대응할 수 있도록 하는 지침입니다.

마지막으로 LLM이 프롬프트를 처리하고 상황에 맞는 정확한 응답을 반환합니다.

전체 코드는 아래와 같습니다:

이제 검색을 수행할 수 있습니다(예: "Elastic 서비스가 무료인가요?" ) 그리고 FAQ 데이터 자체를 기반으로 상황에 맞는 답변을 얻을 수 있습니다.

이 응답을 생성하기 위해 다음 문서가 사용되었습니다:

결론

LlamaIndex를 사용해 벡터 데이터베이스로서 Elasticsearch를 지원하는 효율적인 FAQ 검색 시스템을 만드는 방법을 시연했습니다. 임베딩을 사용해 문서를 수집하고 색인을 생성하여 벡터 검색을 가능하게 합니다. 프롬프트 템플릿을 통해 검색 결과가 컨텍스트에 통합되어 LLM으로 전송되면 검색된 문서를 기반으로 정확한 문맥에 맞는 응답을 생성합니다.

이 워크플로는 정보 검색과 상황에 맞는 응답 생성을 통합하여 정확하고 관련성 높은 결과를 제공합니다.

참고 자료

https://www.elastic.co/guide/en/cloud/current/ec-faq-getting-started.html

https://docs.llamaindex.ai/en/stable/api_reference/readers/elasticsearch/

https://docs.llamaindex.ai/en/stable/module_guides/indexing/vector_store_index/

https://docs.llamaindex.ai/en/stable/examples/query_engine/custom_query_engine/

https://www.elastic.co/search-labs/integrations/llama-index

Apache Airflow는 워크플로우를 생성, 예약 및 모니터링하도록 설계된 플랫폼입니다. ETL 프로세스, 데이터 파이프라인 및 기타 복잡한 워크플로를 오케스트레이션하는 데 사용되며 유연성과 확장성을 제공합니다. 시각적 인터페이스와 실시간 모니터링 기능을 통해 파이프라인을 보다 쉽고 효율적으로 관리할 수 있으며, 실행 진행 상황과 결과를 추적할 수 있습니다. 다음은 네 가지 주요 기둥입니다:

• 동적: 파이프라인은 파이썬으로 정의되어 동적이고 유연한 워크플로를 생성할 수 있습니다.

• 확장성: 에어플로우를 다양한 환경과 통합할 수 있고, 사용자 지정 오퍼레이터를 생성할 수 있으며, 필요에 따라 특정 코드를 실행할 수 있습니다.

• 우아함: 파이프라인은 깔끔하고 명시적인 방식으로 작성됩니다.

• 확장성: 모듈식 아키텍처는 메시지 대기열을 사용하여 임의의 수의 작업자를 조율합니다.

실제로 Airflow는 다음과 같은 시나리오에서 사용할 수 있습니다:

• 데이터 가져오기: Elasticsearch와 같은 데이터베이스로의 일일 데이터 수집을 오케스트레이션하세요.

• 로그 모니터링: 로그 파일의 수집과 처리를 관리한 다음 Elasticsearch에서 분석하여 오류나 이상 징후를 식별합니다.

• 여러 데이터 소스 통합: 서로 다른 시스템(API, 데이터베이스, 파일)의 정보를 Elasticsearch의 단일 레이어로 결합하여 검색과 보고를 간소화하세요.

공기 흐름에서 DAG(방향성 비순환 그래프) 이해하기

에어플로우에서 워크플로는 DAG(방향성 비순환 그래프)로 표현됩니다. DAG는 작업이 실행되는 순서를 정의하는 구조입니다. DAG의 주요 특징은 다음과 같습니다:

• 독립적인 작업별 구성: 각 작업은 작업의 단위를 나타내며 독립적으로 실행되도록 설계되었습니다.

• 시퀀싱: 작업이 실행되는 순서는 DAG에 명시적으로 정의되어 있습니다.

• 재사용성: DAG는 반복적으로 실행되도록 설계되어 프로세스 자동화를 용이하게 합니다.

공기 흐름 구성 요소

Airflow 에코시스템은 작업을 조율하기 위해 함께 작동하는 여러 구성 요소로 구성되어 있습니다:

• 스케줄러: 스케줄러: DAG를 예약하고 작업자가 실행할 작업을 보내는 역할을 담당합니다.

• 실행자: 작업 실행을 관리하여 작업자에게 위임합니다.

• 웹 서버: DAG 및 작업과 상호 작용하기 위한 그래픽 인터페이스를 제공합니다.

• Dags 폴더: 파이썬으로 작성된 DAG를 저장하는 폴더입니다.

• 메타데이터: 스케줄러와 실행자가 실행 상태를 저장하는 데 사용하는 도구의 저장소 역할을 하는 데이터베이스입니다.

아파치 에어플로우와 Elasticsearch

Apache Airflow와 Elasticsearch를 사용하여 Elasticsearch에서 작업과 색인 결과를 오케스트레이션하는 방법을 시연합니다. 이 데모의 목표는 Elasticsearch 인덱스의 레코드를 업데이트하는 작업 파이프라인을 생성하는 것입니다. 이 인덱스에는 사용자가 평점을 매기고 등급을 지정할 수 있는 영화 데이터베이스가 포함되어 있습니다. 매일 수백 개의 등급이 있는 시나리오를 상상해 보면 등급 기록을 계속 업데이트해야 합니다. 이를 위해 새로운 통합 등급을 검색하고 인덱스의 기록을 업데이트하는 DAG가 매일 실행되도록 개발될 것입니다.

DAG 흐름에는 등급을 가져오는 작업과 결과를 검증하는 작업이 있습니다. 데이터가 존재하지 않으면 DAG는 실패 작업으로 이동합니다. 그렇지 않으면 데이터가 Elasticsearch에서 색인됩니다. 점수 계산을 담당하는 메커니즘이 있는 메서드를 통해 등급을 검색하여 인덱스의 영화 등급 필드를 업데이트하는 것이 목표입니다.

Docker와 함께 Apache Airflow 및 Elasticsearch 사용

컨테이너화된 환경을 만들기 위해 Docker와 함께 Apache Airflow를 사용하겠습니다. "도커에서 에어플로우 실행하기" 가이드의 지침에 따라 에어플로우를 실제로 설정하세요.

Elasticsearch의 경우 Elastic Cloud의 클러스터를 사용하겠지만, 원하는 경우 Docker로 Elasticsearch를 구성할 수도 있습니다. 이미 영화 카탈로그가 포함된 인덱스가 생성되어 영화 데이터가 색인화되었습니다. 이러한 영화의 '등급' 필드가 업데이트됩니다.

DAG 생성

Docker를 통해 설치하면 Airflow가 인식할 수 있도록 DAG 파일을 배치해야 하는 dags 폴더를 포함한 폴더 구조가 생성됩니다.

그 전에 필요한 종속성이 설치되어 있는지 확인해야 합니다. 이 프로젝트의 종속성은 다음과 같습니다:

update_ratings_movies.py 파일을 만들고 작업 코딩을 시작합니다.

이제 필요한 라이브러리를 가져와 보겠습니다:

연결과 외부 API 사용을 추상화하여 Airflow와 Elasticsearch 클러스터 간의 통합을 간소화하는 구성 요소인 ElasticsearchPythonHook을 사용하겠습니다.

다음으로, 주요 인수를 지정하여 DAG를 정의합니다:

• dag_idDAG의 이름입니다.

• start_dateDAG가 시작되는 시기입니다.

• schedule: 주기를 정의합니다(이 경우 매일).

• doc_md문서를 가져와 에어플로우 인터페이스에 표시할 수 있습니다.

작업 정의하기

이제 DAG의 작업을 정의해 보겠습니다. 첫 번째 작업은 영화 등급 데이터를 검색하는 작업을 담당합니다. task_id 을 'get_movie_ratings' 으로 설정한 파이썬 오퍼레이터를 사용하겠습니다. python_callable 매개변수는 평점 가져오기를 담당하는 함수를 호출합니다.

다음으로 결과가 유효한지 검증해야 합니다. 이를 위해 BranchPythonOperator와 함께 조건문을 사용하겠습니다. task_id 은 'validate_result' 이 되고 python_callable 은 유효성 검사 함수를 호출합니다. op_args 매개 변수는 이전 작업의 결과인 'get_movie_ratings' 을 유효성 검사 함수에 전달하는 데 사용됩니다.

유효성 검사가 성공하면 'get_movie_ratings' 작업에서 데이터를 가져와서 Elasticsearch로 색인합니다. 이를 위해 새 작업인 'index_movie_ratings' 을 생성하여 PythonOperator를 사용합니다. op_args 매개변수는 'get_movie_ratings' 작업의 결과를 인덱싱 함수에 전달합니다.

유효성 검사 결과 실패로 표시되면 DAG는 실패 알림 작업으로 진행합니다. 이 예에서는 단순히 메시지를 인쇄하지만 실제 시나리오에서는 실패에 대해 알리도록 알림을 구성할 수 있습니다.

마지막으로 작업 종속성을 정의하여 올바른 순서로 실행되도록 합니다:

이제 DAG의 전체 코드를 따르세요:

DAG 실행 시각화

Apache Airflow 인터페이스에서 DAG의 실행을 시각화할 수 있습니다. "DAG" 탭으로 이동하여 생성한 DAG를 찾으면 됩니다.

아래에서 작업의 실행과 각 상태를 시각화하여 확인할 수 있습니다. 특정 날짜의 실행을 선택하면 각 작업의 로그에 액세스할 수 있습니다. index_movie_ratings 작업에서 인덱스에서 인덱싱 결과를 확인할 수 있으며, 성공적으로 완료되었음을 알 수 있습니다.

다른 탭에서는 작업 및 DAG에 대한 추가 정보에 액세스하여 잠재적인 문제를 분석하고 해결하는 데 도움을 받을 수 있습니다.

결론

이 문서에서는 Apache Airflow와 Elasticsearch를 통합하여 데이터 수집 솔루션을 만드는 방법을 보여드렸습니다. DAG를 구성하고, 동영상 데이터 검색, 유효성 검사, 인덱싱을 담당하는 작업을 정의하고, Airflow 인터페이스에서 이러한 작업의 실행을 모니터링하고 시각화하는 방법을 보여드렸습니다.

이 접근 방식은 다양한 유형의 데이터와 워크플로에 쉽게 적용할 수 있으므로 Airflow는 다양한 시나리오에서 데이터 파이프라인을 오케스트레이션하는 데 유용한 도구입니다.

참고 자료

Apache AirFlow

https://airflow.apache.org/

Docker로 Apache Airflow 설치

https://airflow.apache.org/docs/apache-airflow/stable/howto/docker-compose/index.html

Elasticsearch 파이썬 훅

https://airflow.apache.org/docs/apache-airflow-providers-elasticsearch/stable/hooks/elasticsearch_python_hook.html

파이썬 연산자

https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/python.html

필수 구성 요소

• 도커 및 도커 컴포즈: 컴퓨터에 도커 및 도커 컴포즈가 설치되어 있는지 확인합니다.

• Python 3.x: 생산자 및 소비자 스크립트를 실행합니다.

아파치 카프카 소개

Apache Kafka는 높은 확장성과 가용성, 내결함성을 지원하는 분산형 스트리밍 플랫폼입니다. Kafka에서는 주요 구성 요소를 통해 데이터 관리가 이루어집니다:

• 브로커: 생산자와 소비자 간의 메시지 저장 및 배포를 담당합니다.

• 주키퍼: 클러스터의 상태, 파티션 리더, 소비자 정보를 제어하여 카프카 브로커를 관리하고 조정합니다.

• 주제: 데이터가 게시되고 소비를 위해 저장되는 채널입니다.

• 소비자와 생산자: 생산자가 토픽에 데이터를 전송하는 동안 소비자는 해당 데이터를 검색합니다.

이러한 구성 요소는 함께 작동하여 데이터 스트리밍을 위한 강력한 프레임워크를 제공하는 카프카 생태계를 형성합니다.

프로젝트 구조

데이터 수집 프로세스를 이해하기 위해 데이터 수집 프로세스를 여러 단계로 나누었습니다:

• 인프라 프로비저닝: Kafka, Elasticsearch, Kibana를 지원하기 위한 Docker 환경 설정.

• 프로듀서 만들기: 로그 주제로 데이터를 전송하는 Kafka 프로듀서 구현하기.

• 소비자 생성: Elasticsearch에서 메시지를 읽고 색인하기 위한 Kafka 소비자 개발.

• 수집 유효성 검사: 전송 및 소비된 데이터를 확인하고 유효성을 검사합니다.

Docker Compose를 사용한 인프라 구성

필요한 서비스를 구성하고 관리하기 위해 Docker Compose를 활용했습니다. 아래에는 Apache Kafka, Elasticsearch, Kibana의 통합에 필요한 각 서비스를 설정하여 데이터 수집 프로세스를 보장하는 Docker Compose 코드가 나와 있습니다.

Elasticsearch Labs GitHub 리포지토리에서 직접 파일에 액세스할 수 있습니다.

카프카 프로듀서를 사용한 데이터 전송

프로듀서는 로그 주제에 메시지를 보낼 책임이 있습니다. 메시지를 일괄적으로 전송함으로써 네트워크 사용 효율을 높이고 일괄 전송의 양과 지연 시간을 각각 제어하는 batch_size 및 linger_ms 설정으로 최적화할 수 있습니다. acks='all' 구성은 중요한 로그 데이터에 필수적인 메시지를 영구적으로 저장할 수 있도록 합니다.

프로듀서를 시작할 때 아래와 같이 메시지가 토픽에 일괄적으로 전송됩니다:

Kafka Consumer를 통한 데이터 소비 및 색인화

소비자는 메시지를 효율적으로 처리하도록 설계되어 로그 주제에서 배치를 소비하고 Elasticsearch로 색인합니다. auto_offset_reset='latest' 을 사용하면 소비자가 이전 메시지를 무시하고 가장 최근 메시지부터 처리를 시작하고 max_poll_records=10 은 일괄 처리를 10개의 메시지로 제한합니다. fetch_max_wait_ms=2000 을 사용하면 소비자는 배치 처리 전에 충분한 메시지가 누적될 때까지 최대 2초 동안 기다립니다.

메인 루프에서 소비자는 로그 메시지를 소비하고, 처리하고, 각 배치를 Elasticsearch로 색인하여 지속적인 데이터 수집을 보장합니다.

Kibana에서 데이터 시각화하기

Kibana를 사용하면 Kafka에서 수집되어 Elasticsearch에서 색인된 데이터를 탐색하고 검증할 수 있습니다. Kibana의 개발 도구에 액세스하여 색인된 메시지를 보고 데이터가 예상대로인지 확인할 수 있습니다. 예를 들어, 카프카 프로듀서가 각각 10개의 메시지를 5개의 배치로 전송했다면 인덱스에 총 50개의 레코드가 표시되어야 합니다.

데이터를 확인하려면 개발 도구 섹션에서 다음 쿼리를 사용할 수 있습니다:

대응:

또한, Kibana는 분석을 보다 직관적이고 대화형으로 만드는 데 도움이 되는 시각화 및 대시보드를 생성하는 기능을 제공합니다. 아래에서 처리된 정보에 대한 이해를 높이기 위해 다양한 형식으로 데이터를 보여주는 대시보드와 시각화의 몇 가지 예를 볼 수 있습니다.

Kafka Connect를 통한 데이터 수집

Kafka Connect는 데이터베이스나 파일 시스템과 같은 데이터 소스와 대상(싱크) 간의 통합을 용이하게 하도록 설계된 서비스입니다. 데이터 이동을 자동으로 처리하는 사전 정의된 커넥터로 작동합니다. 저희의 경우, Elasticsearch는 데이터 싱크 역할을 합니다.

Kafka Connect를 사용하면 데이터 수집 프로세스를 간소화할 수 있으므로 데이터 수집 워크플로우를 Elasticsearch에 수동으로 구현할 필요가 없습니다. 적절한 커넥터를 사용하면 최소한의 설정과 추가 코딩 없이도 Kafka Connect를 통해 Kafka 토픽으로 전송된 데이터를 Elasticsearch에서 직접 색인할 수 있습니다.

카프카 커넥트로 작업하기

Kafka Connect를 구현하기 위해 Docker Compose 설정에 kafka-connect 서비스를 추가합니다. 이 구성의 핵심은 데이터 인덱싱을 처리할 Elasticsearch 커넥터를 설치하는 것입니다.

서비스를 구성하고 Kafka Connect 컨테이너를 생성한 후에는 Elasticsearch 커넥터를 위한 구성 파일이 필요합니다. 이 파일에는 다음과 같은 필수 매개변수가 정의되어 있습니다:

• connection.url: Elasticsearch용 연결 URL입니다.

• topics: 커넥터가 모니터링할 카프카 토픽(이 경우 "로그").

• type.name: Elasticsearch의 문서 유형(일반적으로 _doc).

• value.converter: Kafka 메시지를 JSON 형식으로 변환합니다.

• value.converter.schemas.enable: 스키마를 포함할지 여부를 지정합니다.

• schema.ignore 및 key.ignore: 인덱싱 중 Kafka 스키마 및 키를 무시하도록 설정합니다.

아래는 curl 명령어로 Kafka Connect에서 Elasticsearch 커넥터를 생성하는 방법입니다:

이 구성을 사용하면 Kafka Connect는 "logs" 항목으로 전송된 데이터를 자동으로 수집하고 Elasticsearch에서 색인하기 시작합니다. 이 접근 방식을 사용하면 추가 코딩 없이도 완전히 자동화된 데이터 수집 및 인덱싱이 가능하므로 전체 통합 프로세스를 간소화할 수 있습니다.

결론

Kafka와 Elasticsearch를 통합하면 실시간 데이터 수집과 분석을 위한 강력한 파이프라인이 만들어집니다. 이 가이드는 향후 더 복잡한 요구 사항에 적응할 수 있도록 Kibana에서 원활한 시각화 및 분석을 통해 강력한 데이터 수집 아키텍처를 구축하기 위한 기초적인 접근 방식을 제공합니다.

또한, Kafka Connect를 사용하면 데이터를 처리하고 색인하기 위한 추가 코드가 필요 없기 때문에 Kafka와 Elasticsearch 간의 통합이 훨씬 더 간소화됩니다. Kafka Connect를 사용하면 최소한의 구성으로 특정 토픽으로 전송된 데이터를 Elasticsearch에서 자동으로 색인할 수 있습니다.

아파치 카멜이란 무엇인가요?

Apache Camel은 다양한 시스템 연결을 간소화하는 오픈소스 통합 프레임워크로, 개발자는 시스템 통신의 복잡성에 대한 걱정 없이 비즈니스 로직에 집중할 수 있습니다. Camel의 중심 개념은 "경로(" )로, 메시지가 출발지에서 목적지까지 이동하는 경로를 정의하며 변환, 유효성 검사, 필터링 등의 중간 단계가 포함될 수 있습니다.

아파치 카멜 아키텍처

Camel은 "구성 요소" 를 사용하여 데이터베이스 및 메시징 서비스와 같은 다양한 시스템 및 프로토콜에 연결하고 "엔드포인트" 를 사용하여 메시지의 시작 및 종료 지점을 나타냅니다. 이러한 개념은 모듈식의 유연한 설계를 제공하므로 복잡한 통합을 효율적이고 확장 가능하게 구성하고 관리하기가 더 쉬워집니다.

Elasticsearch와 Apache Camel 사용

Apache Camel을 사용해 데이터를 Elasticsearch 클러스터로 수집하는 간단한 Java 애플리케이션을 구성하는 방법을 보여드리겠습니다. Apache Camel에 정의된 경로를 사용하여 Elasticsearch에서 데이터를 생성, 업데이트 및 삭제하는 프로세스도 다룹니다.

1. 종속성 추가하기

이 통합을 구성하는 첫 번째 단계는 프로젝트의 pom.xml 파일에 필요한 종속성을 추가하는 것입니다. 여기에는 Apache Camel 및 Elasticsearch 라이브러리가 포함됩니다. 새로운 Java API 클라이언트 라이브러리를 사용할 것이므로 camel-elasticsearch 컴포넌트를 가져와야 하며 버전은 camel-core 라이브러리와 동일해야 합니다.

Java 로우레벨 Rest 클라이언트를 사용하려면 Elasticsearch 로우레벨 Rest 클라이언트 구성 요소를 사용해야 합니다.

2. Camel 컨텍스트 구성 및 실행

구성은 경로를 정의하고 실행하는 기반이 되는 DefaultCamelContext 클래스를 사용하여 새 Camel 컨텍스트를 만드는 것으로 시작됩니다. 다음으로, Apache Camel이 Elasticsearch 클러스터와 상호 작용할 수 있도록 Elasticsearch 구성 요소를 구성합니다. ESlasticsearchComponent 인스턴스는 로컬 Elasticsearch 클러스터의 기본 주소인 localhost:9200 주소에 연결하도록 구성됩니다. 인증이 필요한 환경 설정의 경우 구성 요소를 구성하고 기본 인증을 활성화하는 방법에 대한 설명서( "구성 요소 구성 및 기본 인증 활성화" 참조)를 읽어보셔야 합니다.

그런 다음 이 구성 요소를 Camel 컨텍스트에 추가하여 정의된 경로가 이 구성 요소를 사용하여 Elasticsearch에서 작업을 수행할 수 있도록 합니다.

그 후 경로가 컨텍스트에 추가됩니다. 문서 일괄 색인, 업데이트, 삭제를 위한 경로를 생성합니다.

3. Camel 경로 구성

데이터 인덱싱

첫 번째로 구성할 경로는 데이터 인덱싱을 위한 것입니다. 영화 카탈로그가 포함된 JSON 파일을 사용하겠습니다. 경로는 src/main/resources/movies.json 에 있는 파일을 읽고, JSON 콘텐츠를 Java 객체로 역직렬화한 다음, 여러 메시지를 하나로 결합하는 집계 전략을 적용하여 Elasticsearch에서 일괄 작업을 수행할 수 있도록 구성됩니다. 메시지당 500개 항목의 크기가 구성되었으므로 대량으로 한 번에 500개의 필름을 색인합니다.

Elasticsearch 작업 일괄 라우팅

문서 배치가 Elasticsearch의 대량 작업 엔드포인트로 전송됩니다. 이 접근 방식은 대량의 데이터를 처리할 때 효율성과 속도를 보장합니다.

데이터 업데이트

다음 경로는 문서를 업데이트하는 것입니다. 이전 단계에서 일부 영화를 색인화했으며 이제 참조 코드로 문서를 검색하는 새 경로를 만든 다음 등급 필드를 업데이트합니다.

Elasticsearch 구성 요소가 등록되고 사용자 정의 경로 IngestionRoute가 추가되는 Camel 컨텍스트 (DefaultCamelContext) 를 설정합니다. 작업은 직접:업데이트-인제스트먼트 엔드포인트에서 경로를 시작하는 ProducerTemplate을 통해 문서 코드를 전송하는 것으로 시작됩니다.

다음으로, 이 흐름의 입력 엔드포인트인 IngestionRoute가 있습니다. 이 경로는 여러 파이프라인 연산을 수행합니다. 먼저, 코드별로 문서를 찾기 위해 Elasticsearch에서 검색을 수행합니다 (direct:search-by-id), 여기서 SearchByCodeProcessor는 코드를 기반으로 쿼리를 조합합니다. 그런 다음, 검색된 문서가 UpdateRatingProcessor에 의해 처리되고, 그 결과를 Movie 개체로 변환하고, 영화 등급을 특정 값으로 업데이트하고, 업데이트를 위해 업데이트된 문서를 다시 Elasticsearch로 전송할 수 있도록 준비합니다.

SearchByCodeProcessor 프로세서는 검색 쿼리를 실행하도록만 구성되었습니다:

UpdateRatingProcessor 프로세서는 등급 필드를 업데이트할 책임이 있습니다.

데이터 삭제

마지막으로 문서 삭제 경로가 구성됩니다. 여기서는 해당 ID를 사용하여 문서를 삭제합니다. Elasticsearch에서 문서를 삭제하려면 문서 식별자, 즉 문서가 저장되어 있는 인덱스를 알고 삭제 요청을 실행해야 합니다. Apache Camel에서는 아래와 같이 새 경로를 생성하여 이 작업을 수행합니다.

경로는 진입점 역할을 하는 direct:op-delete 엔드포인트에서 시작됩니다. 문서를 삭제해야 하는 경우 해당 문서의 식별자 (_id) 가 메시지 본문으로 수신됩니다. 그런 다음 경로에서는 메시지 본문에서 _id를 추출하는 간단한("${body}") 을 사용하여 이 식별자 값으로 indexId 헤더를 설정합니다.

마지막으로, 메시지는 URI_DELETE_OPERATION에 의해 지정된 엔드포인트로 전달되며, 이 엔드포인트는 해당 인덱스에서 문서 제거 작업을 수행하기 위해 Elasticsearch에 연결됩니다. 이제 경로를 생성했으므로, Elasticsearch 구성 요소를 포함하도록 구성된 Camel 컨텍스트 (DefaultCamelContext) 를 생성할 수 있습니다.

다음으로 OperationDeleteRoute 클래스에 의해 정의된 삭제 경로가 컨텍스트에 추가됩니다. 컨텍스트가 초기화된 상태에서 ProducerTemplate 을 사용하여 삭제해야 하는 문서의 식별자를 direct:op-delete 엔드포인트로 전달하면 삭제 경로가 트리거됩니다.

결론

Apache Camel과 Elasticsearch의 통합을 통해 강력하고 효율적인 데이터 수집이 가능하며, 색인, 업데이트, 삭제와 같은 다양한 데이터 조작 시나리오를 처리할 수 있는 경로를 정의할 수 있는 Camel의 유연성을 활용할 수 있습니다. 이 설정을 사용하면 복잡한 프로세스를 확장 가능한 방식으로 오케스트레이션하고 자동화하여 Elasticsearch에서 데이터를 효율적으로 관리할 수 있습니다. 이 예는 이러한 도구를 함께 사용하여 데이터 수집을 위한 효율적이고 적응력 있는 솔루션을 만드는 방법을 보여줍니다.

참고 자료

• 아파치 카멜

• 아파치 카멜 아키텍처

• 아파치 카멜 집계

• 파일 구성 요소

• Elasticsearch 구성 요소