Kibana Dashboards API에서 이전 버전과의 호환성이 의미하는 사항

기술 미리 보기 기간에는 릴리스 간에 API 형태가 변경될 수 있었습니다.[1] 이제는 그렇지 않습니다. 정식 출시(GA)는 다음을 의미합니다.

• 완전한 이전 버전과의 호환성. 시간이 지남에 따라 새 필드와 패널 유형이 추가되지만, 기존 필드와 동작은 변경되지 않습니다. 향후 호환성이 깨지는 변경 사항은 매우 신중하게 검토되며, 새로운 주요 스택 버전에서만 도입됩니다.

• 프로덕션 준비 및 완전한 지원. API에는 Elastic의 완전한 지원 보증이 적용됩니다. 자동화된 배포, 환경 승격 및 프로그래밍 방식의 대시보드 관리에 이 API를 프로덕션 환경에서 안심하고 사용할 수 있습니다.

태그, Markdown 및 Links 패널을 위한 새로운 Kibana API 엔드포인트

Elastic 9.5에서는 대시보드를 분류하고 필터링할 수 있는 태그용 새로운 독립형 엔드포인트도 도입합니다. 이제 전용 CRUD 엔드포인트를 통해 태그를 프로그래밍 방식으로 관리할 수 있어, 여러 환경에서 대규모로 대시보드를 더 쉽게 구성할 수 있습니다.

새로운 Markdown 및 Links 패널 엔드포인트는 현재 Serverless에서 제공되며, 다음 스택 릴리스인 9.6에 추가될 예정입니다.

Kibana Dashboards API는 어떤 패널 유형을 지원하나요?

Dashboards API는 9.5의 모든 by-value 패널을 지원합니다. by-value 패널은 재사용을 위해 저장된 라이브러리 패널과 달리 대시보드에 직접 정의된 패널입니다. 지원되는 모든 패널 유형에는 타입이 지정되고 검증된 스키마가 있습니다.

패널 유형

상태

XY 차트

지원됨

메트릭

지원됨

파이

지원됨

게이지

지원됨

히트맵

지원됨

데이터 테이블

지원됨

트리맵

지원됨

Discover 세션

지원됨

컨트롤

지원됨

Markdown

지원됨

Links

지원됨

ML 패널

지원됨

Observability 패널

지원됨

Maps

출시 예정

Vega

출시 예정

Kibana 대시보드를 코드로 관리하는 방법

Dashboards API를 사용하면 코드 기반의 대시보드를 위한 전체 워크플로우를 구현할 수 있습니다. 대시보드를 차이 비교가 가능한 깔끔한 JSON으로 내보내고, 이를 단일 정보 원천으로 Git에 커밋하며, 풀 리퀘스트에서 변경 사항을 검토하고, 개발·스테이징·프로덕션 전반에 동일한 정의를 배포할 수 있습니다. 대시보드를 코드로 관리하기 시작했다면 Git을 단일 정보 원천으로 취급해야 합니다. UI에서 직접 변경한 내용은 다음 배포 시 덮어써집니다.

대시보드를 스페이스, 클러스터 또는 단계 간에 이동할 때 가장 큰 과제는 대시보드가 데이터 뷰와 라이브러리 시각화 같은 객체를 ID로 참조한다는 점입니다. 이러한 ID는 자동 생성되며 환경마다 다르므로, 한 환경에서 내보낸 대시보드가 다른 환경에는 존재하지 않는 객체를 가리킬 수 있습니다. 이를 처리하는 방법은 자동화 수준이 높은 순서부터 낮은 순서까지 다음 세 가지입니다.

• Terraform 사용. Elastic Stack Terraform provider는 각 리소스를 추적하고 환경별 ID를 자동으로 매핑하므로, 대시보드를 개발 환경에서 프로덕션으로 승격할 때 참조가 일관되게 유지됩니다.

• by-value Elasticsearch Query Language (ES|QL) 패널 정의. 가장 이식성이 높은 패널 생성 방법은 대시보드에서 ES|QL을 직접 사용해 시각화를 정의하는 것입니다. ES|QL 쿼리는 쿼리 내에 지정한 인덱스에서 읽어 오므로, 패널에는 데이터 뷰나 라이브러리 객체에 대한 외부 참조가 없습니다. 그 결과 완전히 독립적이고 이식 가능한 대시보드가 만들어집니다..

• 일치하는 ID 할당. 데이터 뷰나 라이브러리 시각화와 같은 저장된 객체를 참조하는 경우, ID를 자동 생성하는 POST 대신 PUT(업서트)을 사용하여 선택한 ID로 객체를 생성하세요. logs-prod와 같이 사람이 읽을 수 있는 ID를 사용하면 여러 환경에서 쉽게 재사용하고 식별할 수 있습니다.

이러한 이식성 패턴과 코드 기반의 대시보드를 위한 전체 워크플로우에 관한 자세한 안내는 코드 기반의 대시보드 관리 설명서를 참조하세요.

PUT을 사용하여 Dashboards API로 Kibana 대시보드 생성

다음은 POST 대신 PUT을 사용해 대시보드 이름인 service-health-overview를 사용자 지정 ID로 할당하고, 메트릭 패널을 포함한 대시보드를 생성하는 간단한 예입니다. 동일한 로직은 라이브러리에 저장되는 독립형 시각화를 만들 때도 적용됩니다.

Kibana Dashboards API 로드맵: Maps, Vega 및 독립형 엔드포인트

Elastic은 API 기능 범위를 활발히 확장하고 있습니다. 다음으로는 Maps 및 Vega 패널 지원을 추가하고, 이들 패널의 타입이 지정된 스키마를 제공합니다. 또한 기존 대시보드 패널 지원 범위를 넘어 Discover 세션용 독립형 CRUD 엔드포인트와 Vega, Maps 및 Annotations용 독립형 CRUD 엔드포인트도 구축하고 있습니다. 이 엔드포인트는 대시보드 수명 주기와 분리됩니다.

전체 스키마 정의는 Dashboards API 설명서에서 확인하세요. Terraform 사용자는 Elastic Stack Terraform provider를 통해 정식 출시된 Dashboards API를 사용할 수 있습니다.

참고

1. 핵심 엔드포인트는 기술 미리보기와 비교해 변경되지 않았습니다. 9.4를 대상으로 통합을 구축했다면 9.5에서도 작동합니다. 호환성이 깨지는 변경 사항은 대시보드 목록 표시 및 기간 단위 형식에 영향을 주는 사소한 변경 두 가지뿐이며, 여기에서 설명합니다.

Kibana의 AI 대시보드 생성 기능, 무엇이 새로워졌을까요

기능

기술 미리보기(9.4)

정식 출시(9.5)

오류 처리

실패한 ES|QL 쿼리에 대한 재시도 없음

쿼리 검사 및 조정을 통해 최대 3회까지 자동 재시도

ES|QL 생성 비용

모든 쿼리가 기본 모델을 통해 라우팅됨

계층형 모델 라우팅, 최대 5분의 1 비용

기간 범위

고정된 기본 창

데이터 시간 분포에 기반한 자동 선택

필터 제어

지원되지 않음

가장 관련성 높은 필드에 대해 자동으로 추가됨

Vega-Lite 차트

지원되지 않음

산점도, 박스플롯, 조건부 서식, 맞춤형 툴팁을 포함한 자연어 기반 생성

차트 편집

지원되지 않음

자연어를 통해 기존 Vega-Lite 패널 편집

AI 대시보드 생성을 위한 자동 오류 복구

기술 미리보기 단계에서는 에이전트가 실패한 ES|QL 쿼리를 재시도하지 않았습니다. 9.5에서는 쿼리 오류를 감지하면 최대 3회까지 재시도하며, 포기하기 전에 각 오류를 검사하고 쿼리를 조정합니다. 실제로 이를 통해 대부분의 빈 패널 문제가 해결되며, 대시보드가 처음부터 제대로 렌더링됩니다.

Elastic 9.5에서 AI 대시보드 생성 비용이 더 저렴해진 이유는 무엇일까요?

대시보드 생성의 모든 단계가 동일한 수준의 추론을 필요로 하는 것은 아닙니다. 9.5에서는 ES|QL 생성이 기본적으로 더 가벼운 모델을 통해 처리되며, 필요한 경우에만 기본 모델로 대체됩니다. 사용 중인 커넥터가 Anthropic의 Claude Opus 4.8을 사용한다면, 모든 패널에 걸쳐 ES|QL 생성 비용이 5분의 1로 줄어든다는 의미입니다

데이터에 기반한 자동 기간 범위 선택

대시보드는 올바른 데이터 구간을 보여 줄 때만 유용합니다. 이제 에이전트는 사용자가 특정 기간 범위를 요청하지 않는 한, 쿼리하는 데이터에 적합한 기간 범위를 선택하기 위해 개선된 논리를 적용합니다. 고정된 창을 기본값으로 사용하는 대신, 데이터의 시간 분포를 고려해 그에 맞게 조정합니다. 실시간 인시던트라면 지난 1시간, 트렌드 분석이라면 지난 90일이 되는 식입니다.

AI 생성 대시보드의 자동 필터 제어

이제 대시보드 생성 기능이 제어, 즉 기본 쿼리를 수정하지 않고도 뷰어가 필드 값을 기준으로 대시보드를 좁혀볼 수 있는 대화형 필터를 지원합니다. 대시보드를 생성할 때 에이전트는 필터링하기에 가장 관련성 높은 필드에 대한 제어를 상단에 자동으로 추가합니다.

자연어로 만드는 Vega-Lite 차트: 기본 제공 범위를 넘어선 차트 유형과 서식

Vega와 Vega-Lite는 Kibana에서 다양한 차트 유형과 맞춤형 옵션을 지원합니다. 9.5부터는 직접 코드를 작성하지 않고도 일반 언어만으로 이를 만들 수 있습니다. 

산점도, 박스플롯 및 기타 다양한 Vega-Lite 차트 유형

산점도, 박스플롯 차트, 패싯 처리된 소형 다중 차트, 버블 차트, 그리고 (히스토그램과 히트맵을 결합하는 등의) 합성 차트를 비롯한 다양한 차트 유형이 Vega-Lite에서 지원됩니다. 예를 들어 응답 시간 대 요청 크기의 산점도를 서비스 이름별로 색상을 구분해서 보여줘와 같은 프롬프트를 입력하면, 올바른 데이터 매핑이 적용된 Vega-Lite 패널이 생성됩니다. 이때 차트는 Kibana의 기본 색상 팔레트를 사용해 대시보드의 나머지 요소와 자연스럽게 어우러집니다.

표준 차트에 조건부 서식, 맞춤형 툴팁, 레이블 적용

막대, 선, 영역 차트처럼 이미 대시보드에 기본으로 내장된 차트 유형이라 하더라도, 기본 기능만으로는 부족한 세밀한 제어가 필요할 때가 있습니다. 이럴 때 채팅을 통한 Vega-Lite가 그 부족한 부분을 채워 줍니다. 몇 가지 예는 다음과 같습니다.

• 조건부 색상 서식: 임계값을 초과하는 데이터 요소를 다른 색상으로 표시합니다. 예를 들어 특정 메트릭이 서비스 수준 목표(SLO)를 초과해 급증할 때, 선이나 막대의 데이터 요소를 빨간색으로 바꾸는 식입니다. 에이전트에게 내 라인 차트에서 500ms를 초과하는 포인트는 모두 빨간색으로 바꿔줘와 같이 요청해 보세요.

  

• 사용자 지정 표시 및 레이블: 데이터 포인트에 이모티콘, 기호 또는 텍스트 레이블을 추가하여 한눈에 상태를 파악할 수 있습니다.

  

• 맞춤형 툴팁: 차트의 축에는 포함되지 않는 추가 메트릭, 맥락 정보, 계산된 값 등으로 마우스 오버 시 표시되는 정보를 더욱 풍부하게 만듭니다. 각 막대의 전체 레코드 수와 비율(%)을 보여 주는 툴팁을 추가해줘와 같이 요청해 보세요.

  

이 기능은 기존 Vega 차트를 편집할 때도 동일하게 작동합니다. 색상 스케일 변경, 축 조정, 마크 유형 전환처럼 Vega-Lite 패널에 손질이 필요할 때, JSON 코드를 직접 파고들 필요 없이 채팅에서 원하는 변경 사항을 설명하기만 하면 됩니다.

Kibana에서 자연어 기반 Vega-Lite 생성 기능을 구축한 방법

문장 하나로 Vega-Lite 차트를 생성하는 것은 모델에게 JSON을 달라고 한 번에 요청하는 단순한 프롬프트 작업이 아닙니다. 저희는 자연어로 표현된 의도를 검증되고 데이터에 기반한 차트로 전환하는 소규모 에이전틱 파이프라인을 구축했습니다.

요청이 들어오면 에이전트는 먼저 Vega-Lite가 적합한지 판단합니다. Vega-Lite 요청인 경우, Elasticsearch에 대한 실제 ES|QL 쿼리를 바탕으로 시각화를 구성한 다음, 모델을 사용해 Vega-Lite 코드를 생성합니다. 렌더링 전에 결과는 정규화 계층을 거치며, 여기서 스키마를 수정하고 표준 쿼리를 연결합니다. 또한 렌더링 안전성을 위한 변환도 적용합니다.

몇 가지 설계 선택이 이 워크플로우의 신뢰성을 뒷받침합니다.

• 유형이 지정된 도구 호출: 차트 생성은 대화창에 자유 형식의 Vega-Lite 코드를 붙여넣는 방식이 아니라, 구조화된 도구 호출로 이루어집니다.

• 제약된 생성: 모델은 정의된 스키마 내에서 Vega-Lite 코드를 생성하므로, 출력 결과가 더 예측 가능하고 검증하기 쉬워집니다.

• 엄선된 예시: 패싯 처리, 레이어드 마크, 히트맵과 같은 구조적 패턴이 기본 데이터를 그대로 복사하지 않으면서도 지침을 제공합니다.

• 실행 및 검증 루프: 쿼리는 차트 작성 전에 실행되며, 검증에 실패하면 ES|QL 생성을 위한 수정 재시도가 트리거됩니다.

Kibana에서 AI 대시보드 생성과 Vega-Lite 차트 사용해 보기

자연어 기반 대시보드 생성과 Vega-Lite 차트를 사용해 보려면, Elastic 9.5로 업그레이드하거나(또는 무료 체험 시작하기), Kibana에서 채팅을 열어 보세요. 그런 다음 여러분의 데이터로 대시보드를 만들어달라고 요청해 보세요. Vega-Lite의 경우, 산점도나 버블 차트와 같이 평소 만들어보고 싶었지만 시도하지 못했던 차트 유형을 요청해 보세요. 결과가 원하는 대로 나오지 않으면, 에이전트에게 무엇을 바꿔야 할지 알려주세요. 에이전트가 여러분과 함께 반복하며 수정해 나갑니다.

이 경우 엔터프라이즈 라이선스가 필요합니다. 시작해 보세요.

이 게시물에서 설명된 모든 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.

매년 자연재해로 인해 응급 상황 담당자, 군 지휘관, 공공 안전 담당자들은 촉박한 시간 내에 중대한 결정을 내려야 합니다. 이러한 결정은 전통적으로 전화 연락망, 스프레드시트, 수십 명에게 분산된 제도적 지식에 의존합니다. 조정에 따른 오버헤드만으로도 중요한 시간이 소요됩니다.

이 게시물은 위협을 탐지하고, 물류를 추론하며, 자동으로 조처하는 재난 대응에 있어 Elastic이 반응형 에이전틱 조정 시스템을 지원하는 방법을 보여줍니다. 이를 구체화하기 위해 다음과 같은 시뮬레이션을 구축했습니다. 햄프턴 로즈 해안선을 위협하는 가상의 카테고리 4 허리케인이 7개 군사 기지에 걸쳐 137,000명 이상의 인원에 대한 자동 재배치를 트리거합니다.

면책 조항: 이는 시연 목적으로 제작된 전적으로 가상의 시나리오입니다. 허리케인 ELARA-26은 존재하지 않습니다. 기지 위치는 실제 공개 지리 데이터(미 국방부[DoD] 군사 기지, 훈련장 및 훈련 지역[MIRTA] 데이터 세트)를 기반으로 하지만 인원수, 수용 인원, 자산, 연락처 이메일, 임무 프로필과 같은 모든 작전 데이터는 완전히 허구입니다. 이 데모의 어떤 내용도 실제 군사 준비 태세, 역량 또는 작전 절차를 반영하지 않습니다.

자동화된 재난 대응에 지리공간 및 에이전틱 조정이 필요한 이유

자연재해가 중요 인프라를 위협하면 다음과 같은 즉각적인 조정 과제가 발생합니다.

• 어떤 시설이 영향 구역에 있습니까?

• 몇 명의 인원이 이동해야 합니까?

• 어디로 이동할 수 있으며, 해당 시설에 수용 능력이 있습니까?

• 지금 누구에게 알려야 합니까?

이 질문들은 기다려 주지 않습니다. 답도 마찬가지입니다.

파이프라인 배포: 필수 구성 요소 및 설정

예제 리포지토리의 여기에 있는 지침에 따라 Cloud Connect를 통해 Elastic Inference Service(EIS)를 사용하는 로컬 Elastic 클러스터를 배포하세요.

Elasticsearch 에이전틱 재난 대응 파이프라인 작동 원리

파이프라인에는 엔드 투 엔드 방식으로 함께 작동하는 7개의 계층이 있습니다.

1. 데이터 수집: Elasticsearch로 전송된 Global Disaster Alert and Coordination System(GDACS) 재난 이벤트

2. 수집 파이프라인: GeoJSON이 수집되어 Elastic Common Schema (ECS)로 정규화됩니다.

3. 지리 공간 보강: 이벤트의 영향 영역 폴리곤이 인덱싱된 군사 기지 경계와 매칭됩니다.

4. 경보: 재난이 기지과 교차할 때 Kibana 탐지 규칙이 실행됩니다.

5. 워크플로우 자동화: 경보는 AI 에이전트 대화를 시작하는 Kibana 워크플로우를 트리거합니다.

6. AI 추론: 에이전트는 영향을 받는 시설, 해당 시설의 자산 및 가장 가까운 지원 시설을 분석하여 모든 자산과 인력의 재배치를 결정합니다.

7. 이메일 알림: 에이전트는 입출입 인력 및/또는 자산에 대해 모든 수신자에게 이메일을 발송합니다.

각 계층을 살펴보겠습니다.

1단계: 지리적 경계가 있는 군사 기지 색인

기반은 source.coop/seerai/hifld의 DoD MIRTA 데이터 세트입니다. 이 데이터 세트는 각 기지에 대해 Point 유형의 geo_shape을 제공하며, 전체 경계 폴리곤이 아닌 중심 좌표를 제공합니다.

mitra-facilities 인덱스의 각 기지 문서는 MIRTA가 제공하는 범위를 넘어 운영 프로필 데이터(모두 가상)로 보강됩니다.

이 풍부한 인덱스는 AI 에이전트가 단순히 "인근 기지는 다음과 같습니다"가 아니라 "가용 수용 인원, 호환되는 임무 유형, 유입되는 자산을 수용할 물류를 갖춘 기지는 다음과 같습니다"와 같은 지능적인 할당 결정을 내릴 수 있도록 지원합니다.

2단계: GDACS 이벤트 수집 및 정규화

GDACS는 지진, 열대 저기압, 홍수, 산불, 화산 및 가뭄에 대한 실시간 GeoJSON을 게시합니다. Elastic은 이 피드를 데이터 스트림(logs-gdacs.events-*)으로 수집합니다. 여기에 원시 GeoJSON을 ECS 필드로 정규화하는 사용자 지정 수집 파이프라인이 사용됩니다.

GDACS 수집 파이프라인은 주목할 만한 몇 가지 작업을 수행합니다.

지오메트리 추출: 중심점은 지도에 표시할 수 있도록 geo_point로 저장되고, 영향 폴리곤은 gdacs.affected_area에 geo_shape으로 저장되며, 이 필드는 나중에 교차 쿼리에 사용됩니다.

심각도 정규화: 재난 유형마다 심각도 척도가 다릅니다. 열대성 저기압은 풍속 km/h로 측정되며, 지진은 리히터 규모로 측정됩니다. 파이프라인은 모든 재난을 정규화된 0–100 점수로 맵핑합니다.

정규화된 심각도 점수는 탐지 규칙에서 경보 심각도 매핑에 사용되는 severity_level 레이블(low, medium, high, critical)에 매핑됩니다.

ECS 정렬: event.kind: alert, event.category: threat, event.start/event.end에 매핑된 타임스탬프, 및 중복 제거를 위한 안정적인 핑거프린트 기반 _id.

3단계: 지리공간 보강: 인덱스 시점에 영향을 받는 시설 찾기

Elasticsearch의 geo_match enrich 정책은 인덱스 시 재해 폴리곤을 모든 기지 경계와 매칭하므로 쿼리 시 조인이 필요하지 않습니다. 검색 시 쿼리를 실행하는 대신, 수집 파이프라인의 enrich 프로세서를 사용하여 문서가 색인될 때 재난의 영향 폴리곤을 모든 기지 경계와 매칭합니다.

enrich 정책은 geo_match 정책입니다.

프로세서는 수집 파이프라인의 끝에서 실행됩니다.

INTERSECTS는 재난 폴리곤과 경계가 닿거나 겹치는 모든 기지는 물론 부분적인 교차까지도 포착합니다. 그 결과 모든 GDACS 이벤트 문서는 영향 구역에 어떤 기지가 있는지 정확히 알려주는 affected_facilities 중첩 배열과 함께 저장됩니다. 조인 쿼리는 필요하지 않습니다.

4단계: 탐지 규칙: 시설 영향에 대한 경보

Kibana 탐지 규칙은 logs-gdacs.events-* 데이터 스트림을 모니터링하며 GDACS 이벤트가 하나 이상의 영향을 받는 시설로 보강될 때 실행됩니다.

이 규칙은 매시간 일정으로 실행되며(now-1h부터 now까지의 기간 대상), 동적 심각도 매핑을 사용합니다. gdacs.severity_level 필드는 수집 파이프라인에서 계산되어 경보 심각도를 자동으로 구동합니다.

경보 심각도 또한 필드 매핑을 통해 위험 점수를 결정합니다.

규칙이 실행되면 기지 이름, 유형 및 위치로 보강된 affected_facilities 배열을 포함한 전체 경보 컨텍스트가 Kibana 워크플로우로 다운스트림 전달됩니다.

5단계: 워크플로우 자동화: 경고를 에이전트에 연결

Kibana 워크플로우는 탐지에서 응답으로의 인계를 처리합니다. 자연재해 응답 워크플로우는 경보에 의해 트리거됩니다.

전체 경보 페이로드(재해 유형, 심각도, 영향 지역 및 영향을 받은 기지 목록)가 초기 컨텍스트로 AI 에이전트에 전달됩니다. 그다음부터는 에이전트가 이어받아 처리합니다.

6단계: AI 에이전트: 데이터에서 조율된 조치로

mitra.response 에이전트는 전체 경보 페이로드를 받아 단일 에이전트 루프 내에서 범위를 평가하고, 수용 시설을 찾고, 인력을 배정하며, 대피 및 수용 알림을 발송하는 등의 모든 작업을 사람의 개입 없이 수행합니다.

에이전트는 두 가지 도구를 사용할 수 있습니다.

• mitra.nearest_facility는 geo_shape 쿼리를 사용하여 mitra-facilities 인덱스에 쿼리 작업을 수행하고, 주어진 좌표로부터의 거리를 기준으로 정렬하여 가용 용량이 있는 인근 활성 기지를 최대 50개까지 반환합니다.

• mitra.send_email은 시설 객체의 JSON 배열을 순회하고 형식이 지정된 대피 또는 수용 알림을 발송합니다.

에이전트의 지침 세트는 명확한 워크플로우를 정의합니다.

1. 상황을 평가합니다. 경보의 구문을 분석하고, 영향을 받는 시설을 식별하며, 재난 범위를 결정합니다.

2. 이전해야 할 항목을 목록화합니다. 인원수, 중요 자산, 시설별 수용 요건 등입니다.

3. 대상 기지를 찾습니다. mitra.nearest_facility를 영향을 받는 각 기지에 호출하고 위험 구역에 여전히 있는 기지를 필터링하여 제외합니다.

4. 할당 결정을 내립니다. 단일 대 다중 시설 솔루션, 군종 호환성, 수용 인원, 자산 지원을 면밀히 추론합니다.

5. 조정 이메일을 발송합니다. 출발 시설에 대피 명령을 발송하고 수용 시설에 수용 통지를 발송합니다.

6. 요약 보고를 생성합니다. 검토를 위해 영향을 받는 모든 시설, 총 인원, 이동된 자산, 대상 시설 및 모든 우려 사항에 대한 간단한 요약을 채팅에 생성합니다.

에이전트의 할당 로직은 실제 제약 조건을 따릅니다. 수용 인원을 초과하지 않고, 가능한 경우 동일 군종 내 재배치를 우선하며, 여러 군종에서 초과 인원이 발생할 경우 합동 기지를 활용하고, 이동 시간을 최소화할 수 있도록 거리를 우선적으로 고려합니다.

최근접 시설 도구

기본 워크플로우 쿼리는 원형 필터가 포함된 geo_shape와 _geo_distance 정렬을 사용합니다.

가용 인원은 수용 인원에서 현재 인원수를 뺀 값을 계산하는 스크립트 필드를 통해 쿼리 시 계산됩니다. 에이전트는 한도를 초과하지 않고 여러 대상에 인원을 할당하기 위해 이를 사용합니다.

허리케인 ELARA-26: 137,000명 인력에 대한 에이전틱 조율, 엔드 투 엔드

허리케인 ELARA-26은 버지니아주 햄프턴 로즈 지역에 상륙할 것으로 예상되는 카테고리 4 폭풍(최대 풍속 213km/h)입니다. GDACS 이벤트가 수집되면, 영향 받는 지역의 폴리곤이 해당 지역의 7개 주요 군사 기지과 교차합니다. 탐지 규칙이 실행됩니다. 워크플로우가 에이전트 대화를 시작합니다.

단일 에이전틱 루프 내에서 에이전트가 완료한 작업:

• 영향 구역 내에서 총 137,372명의 인원이 포함된 시설 7곳을 식별했습니다.

• 폭풍 경로 외부의 수용 시설을 찾기 위해 mitra.nearest_facility를 호출했습니다.

• 가용 수용 인원 및 거리를 기준으로 9개 수용 시설에 인력을 분산 배치했습니다.

• 영향을 받은 7개 기지 모두에 대피 명령을 생성하여 발송했습니다.

• 9개 수용 시설 모두에 접수 알림을 생성하여 발송했습니다.

• 아래와 유사한 전체 조정 요약이 생성되었습니다.

대피한 시설:

시설

인력(명)

노퍽 해군 기지

50,000

리틀 크릭-포트 스토리 합동원정기지

18,000

오시아나 해군 항공 기지

15,355

오세아나 해군 항공 기지 댐 넥 별관

17,509

NG 주 군사 보호구역 캠프 펜들턴

9,707

랭글리-유스티스 합동기지

15,000

요크타운 해군 무기 기지

11,801

수용 시설:

시설

거리

유입 인력(명)

포트 그렉-아담스

97km

~40,000

콴티코 해병대 기지

148km

~30,000

인디언 헤드 해군 지원 기지

151km

~30,000

앤드루스 합동기지

180km

~30,000

패턱센트 리버 해군 항공기지

141km

~10,000

NG MTA 캠프 버트너

174km

~5,000

NG 베서니 비치 훈련장

209km

~4,707

리바나 스테이션

140km

~7,500

국방 종합 보급 센터

22km

~6,000

재배치된 자산에는 수송 차량, 헬리콥터, 순찰정, 의료 부대, 공병 차량, 발전기, 급수 트레일러, 대피소 키트 및 통신 시스템이 포함됩니다.

자동화된 이메일 알림

에이전트가 할당 계획을 확정한 후, mitra.send_email을 호출하여 단 한 번의 처리 과정으로 16개의 이메일을 발송했습니다. 즉, 영향을 받는 7개 모든 기지에 대한 대피 명령과 9개 모든 수용 기지에 입소 통지가 발송된 것입니다. 각 메시지에는 도착 기지, 유입 인원수, 이동할 자산 및 조정 담당 연락처가 포함되었습니다. 전화 연락망을 거치느라 몇 시간이나 걸렸을 작업이 에이전트의 추론이 완료되는 즉시 자동으로 완료되었습니다.

RAG 및 정책 그라운딩을 통한 에이전틱 재난 대응 확장

이 데모는 인원 수, 거리, 운영 상태와 같은 정형 데이터만을 기반으로 합니다. Elastic의 시맨틱 검색 및 검색 증강 생성(RAG) 기능은 두 가지 추가 기능을 통해 에이전트를 훨씬 더 스마트하게 만들 수 있습니다.

과거 응답 검색: 과거 사후 조치 보고서, 연방재난관리청(FEMA) 인시던트 요약 및 재난 대응 기록을 벡터 임베딩으로 인덱싱합니다. 새 이벤트가 발생하면 에이전트는 유사한 이벤트가 어떻게 처리되었는지 시맨틱 검색하여, 인원 계산만이 아닌 조직 지식을 바탕으로 할당 결정을 내릴 수 있도록 합니다.

정책 및 교리 기반: 국방부 비상 관리 지침, 기지 운영 연속성 계획 및 지휘관 지침을 인덱싱합니다. 에이전트는 응답에 적용되는 실제 정책을 검색하고 인용할 수 있으므로, 모든 결정이 추론이 아닌 교리에 근거하도록 보장합니다.

둘 다 동일한 Elastic 네이티브 접근 방식을 따릅니다, 추론 파이프라인이 인덱스 생성 시점에 임베딩을 생성하고, 시맨틱 검색 도구가 에이전트에 노출됩니다. 조정 파이프라인은 동일하게 유지됩니다. 에이전트는 계속 더 똑똑해집니다.

Elasticsearch가 에이전틱 공공 부문 응답에 적합한 플랫폼인 이유

Elasticsearch는 챗봇이 아닙니다. 대시보드도 아닙니다. 위협을 탐지하고, 복잡한 물류 문제를 추론하며, 인간의 개입 없이 137,000명의 이동을 조율한 반응형 에이전틱 워크플로우 시스템입니다. 이러한 결과는 기반이 되는 모든 기능이 단일 통합 플랫폼에 존재하기 때문에 가능합니다.

Elasticsearch의 지리 공간 지원(geo_point, geo_shape, 보강 정책 및 거리 기반 정렬)은 교차점 탐지와 시설 조회를 대규모로 가능하게 하는 공간 추론을 처리합니다. 시맨틱 검색과 벡터 임베딩은 에이전트를 사실에 기반하게 하여, AI 추론이 환각된 가정이 아닌 실제 데이터에 기반하도록 보장합니다. Kibana의 탐지 엔진, Workflows, Agent Builder 및 Agent Builder 도구는 외부 연결 코드 없이 원시 이벤트에서 조정된 작업으로 이어지는 파이프라인에 모든 것을 연결합니다.

Elastic만큼 이 모든 것을 통합하는 플랫폼은 없습니다. 실시간 색인, 지리 공간 정밀도, 시맨틱 검색 및 에이전트 기반 오케스트레이션을 모두 하나의 스택에서 제공하고 엔터프라이즈급 보안 및 통합 가시성을 기본 제공한다는 점은 이러한 기능 중 하나는 잘 수행하지만 나머지는 직접 통합해야 하는 도구와 Elastic의 차별점입니다.

비상 관리, 소방, 법 집행 및 공중 보건을 위한 에이전틱 지리공간 응답

사람, 시설, 실시간 이벤트가 교차하는 모든 곳에 동일한 아키텍처가 적용됩니다. 특정 데이터는 변경됩니다. 파이프라인은 변경되지 않습니다.

비상 관리: FEMA 및 주 비상관리국은 대피소 위치, 대기 구역, 취약 계층을 수신되는 국립기상청(NWS) 악천후 폴리곤과 매핑하여 폭풍이 상륙하기 전에 자동화된 자원 사전 배치를 트리거할 수 있습니다.

소방 및 응급 의료 서비스: 소방서는 산불 경계선 또는 건물 화재 클러스터에 유닛 위치 및 대응 영역을 오버레이하여, 적절한 장비를 갖춘 가장 가까운 가용 유닛으로 상호 지원 요청을 자동으로 라우팅할 수 있습니다.

법 집행: 기관은 수동 분류를 기다리지 않고도 활성 인시던트 위치를 학교 구역, 중요 인프라, 경찰관 위치와 연관시켜 위치 기반 봉쇄 알림이나 리소스 배치를 트리거할 수 있습니다.

공립학교 안전: 교육구는 캠퍼스 경계를 기준으로 실시간 위협 피드를 모니터링할 수 있습니다. 위협이 학교 경계와 교차하는 경우, 에이전트는 디스패처가 전화를 받기도 전에 관리 부서에 즉시 알리고, 봉쇄 통신을 시작하며, 법 집행 기관의 응답을 조율할 수 있습니다.

공중 보건: 보건 당국은 질병 감시 데이터 또는 환경 위험 구역을 진료소 위치, 인구 밀도 레이어, 공급 창고 재고와 대조하여 리소스가 가장 필요한 곳으로 전달할 수 있습니다.

부문

사용 사례

Elastic 기능

비상 관리

NWS 악천후 폴리곤과 대피소 위치 매칭

geo_shape 보강 + Kibana 워크플로우

소방 및 EMS

산불 경계에 유닛 위치 오버레이

위치 기반 정보 라우팅 + 가장 가까운 시설 쿼리

법 집행

인시던트를 학교 구역 및 경찰관 위치에 상호 연관

위치 인식 경보 규칙 + 에이전트 디스패치

공립학교 안전

캠퍼스 경계에 대한 위협 피드 모니터링

탐지 규칙 + 자동화된 알림

공중 보건

위험 구역을 진료소 위치 및 보급소에 매칭

시맨틱 검색+지리공간 보강

데이터는 시나리오마다 다릅니다. 수집, 인덱스 시 보강, 교차점 탐지, 에이전틱 응답 트리거 및 조치라는 기본 패턴은 모두 동일합니다. Elastic은 공공 부문 조직에 한 번 구축한 후 어디서나 적용할 수 있는 플랫폼을 제공합니다.

이 게시물에서 설명된 모든 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.

이 에이전트는 대시보드를 처음부터 구축할 뿐만 아니라 기존에 이미 보유한 대시보드와도 함께 작동합니다. 대시보드를 보고 있는 상태에서 AI Chat 사이드바를 열면 자동으로 첨부됩니다. 메트릭이 급증한 이유를 묻거나, 리전별로 분석하거나, 비교 패널을 추가할 수 있습니다. 기존 대시보드는 최종 결과물이 아니라 출발점이 됩니다.

내부 구현 방식: AI Chat로 대시보드를 구축한 방법

우리는 스킬을 통해 에이전트에게 특정 작업을 가르칩니다. 스킬은 주어진 문제를 어떻게 처리할지에 대한 구조화된 설명입니다. 하지만 대시보드 스킬을 구축하려면 LLM이 유효한 Kibana 대시보드를 생성할 수 있도록 해야 했고, 기존의 Saved Object API는 이를 매우 번거롭게 만들었습니다. 깊게 중첩된 JSON 구조, 버전 간 미묘한 변경 사항, 취약한 참조 관계 등이 문제였습니다. 우리는 다른 접근 방식이 필요했습니다.

프로그램 기반 대시보드를 위한 맞춤형 API

새로운 Dashboards API는 바로 이러한 시나리오를 위해 설계되었습니다. 원시 내부 상태를 노출하는 대신, 모든 패널 유형에 대해 타입이 지정되고 검증된 스키마를 제공합니다. 이 API는 깔끔한 외부 구조와 Kibana 내부 표현 간의 변환을 처리하므로, 에이전트는 대시보드에 무엇을 포함해야 하는지에만 집중하고 형식을 어떻게 구성할지는 신경 쓰지 않아도 됩니다.

하나의 스킬, 하나의 도구, 다양한 작업

dashboard-management 스킬은 순서가 지정된 작업 배열을 허용하는 단일 manage_dashboard 도구를 제공합니다. 각 작업은 독립적인 동작으로, 메타데이터 설정, 마크다운 패널 추가, 자연어를 기반으로 ES|QL 기반 시각화 생성, 기존 패널 편집, 패널을 접을 수 있는 섹션으로 그룹화, 그리드에서 항목 위치 변경 등이 포함됩니다.

에이전트는 대시보드의 제목, 설명, 섹션, 그리고 각 섹션에 포함된 모든 패널까지 한 번의 호출로 설명할 수 있습니다.

작업은 순서대로 실행되므로 이후 단계에서 이전 단계를 참조하고 이를 기반으로 확장할 수 있습니다. 이 설계는 대화가 구현 세부 사항보다는 의도에 집중할 수 있도록 합니다.

시각화 파이프라인: 자연어에서 ES|QL을 거쳐 시각화로

대시보드를 요청하면 에이전트는 인덱스, 필드 매핑, 유형 등 데이터를 탐색한 다음 시각화를 계획하고 manage_dashboard를 호출합니다.

각 패널은 자체적인 파이프라인을 거치며, 차트 유형 선택, ES|QL 생성, 시각화 구성, 검증 단계로 처리됩니다. 우리는 이 과정을 메인 에이전트 스레드와 분리했는데, 시각화 생성에는 패널당 여러 모델 호출이 필요하고 이를 메인 컨텍스트에 포함하면 컨텍스트 윈도우가 불필요하게 커지고 추론이 흐려질 수 있기 때문입니다.

manage_dashboard 내부에서 모든 패널이 동시에 생성된 뒤 순서대로 재조립됩니다. 그 결과, 내장된 패널로 구성된 완전한 대시보드가 만들어지며, 고립된 시각화나 동기화 문제는 발생하지 않습니다.

대시보드 도구에 시각화 생성을 통합한 이유

초기 접근 방식에서는 별도의 create_visualization 도구를 사용해 패널당 한 번씩 호출한 뒤 각 결과를 대시보드 도구에 전달했습니다. 이 방식은 작동하기는 했지만, 모든 시각화마다 개별 도구 호출, 자체 수명 주기, 그리고 명시적인 핸드오프가 필요했습니다. 더 큰 문제는 대화에서 시각화를 수정해도 해당 변경 사항이 대시보드 패널에 반영되지 않아 사용자 혼란을 초래했다는 점입니다.

우리는 시각화 생성 기능을 manage_dashboard에 직접 포함시켰습니다. 동일한 병렬 워크플로는 그대로 실행되지만, 패널은 중간 attachment 없이 대시보드 구조로 조립됩니다. 호출 수 감소, 동기화 문제 없음, 단일 수명 주기로 작동합니다.

독립형 시각화는 여전히 작동합니다. 기존 차트를 첨부 참조를 통해 대시보드에 추가할 수 있지만, 처음부터 빌드하는 경우 인라인 생성이 더 깔끔한 방법입니다.

보안 팀을 위한 스킬

SOC 분석가와 탐지 엔지니어는 조사 도중 대시보드 편집기로 왔다 갔다 할 여유가 없습니다. AI Chat을 사용하면 규칙 유형, 호스트 또는 MITRE 전술별 알림 볼륨을 요청하고 약 1분 내에 스레드에서 바로 확인할 수 있습니다. 헌팅이 진행됨에 따라 프로세스 실행 이상, 네트워크 연결, 타임라인 비교와 같은 패널을 컨텍스트를 유지한 채 레이어처럼 쌓아갈 수 있습니다.

완료되면 저장하세요. 대시보드는 인시던트 이후 분석을 위한 참고 자료, 다음 분석가를 위한 시작점, 또는 주간 위협 브리핑으로 활용되며 별도의 재설명이 필요하지 않습니다.

이 블로그 게시물에서 보안 팀이 대시보드 생성 및 최근 출시된 AI Chat 기능을 어떻게 활용할 수 있는지 자세한 내용을 확인하세요.

통합 가시성 및 사이트 신뢰성 엔지니어(SRE) 사용 사례

새벽 2시에 서비스 장애가 발생하면 대시보드를 처음부터 다시 구축할 시간이 없습니다. AI Chat을 통해 SRE는 필요한 메트릭(서비스별 p99 지연 시간, 배포 이벤트 대비 오류율, 지난 1시간 동안의 포드 재시작 등)을 설명하고 약 1분 내에 조사 스레드에서 전체 대시보드를 얻을 수 있습니다. 상황이 점차 명확해짐에 따라 에이전트는 단계적으로 세밀하게 다듬을 수 있습니다. 패널을 추가하고, 시간 범위를 변경하고, 리전별로 분류할 수 있습니다.

대시보드를 저장하면 비상 상황실(war room)에서 인시던트 브릿지에 참여하는 모든 사람이 동일한 패널과 동일한 분석 구성을 즉시 활용할 수 있습니다. 인시던트 이후에는 사후 분석의 기반이 됩니다.

그럼 이제 무엇을 해야 할까요?

토큰 최적화, 더 풍부한 전체 화면 경험, 확장된 패널 지원, 그리고 지속적인 품질 개선을 진행 중입니다. 기술 프리뷰 단계는 우선순위를 함께 결정해 나가는 시기입니다. 누락된 부분이 있다면 상단 메뉴의 '피드백 제출' 아이콘을 통해 알려주세요.

직접 사용해 보기

체험판을 시작하거나 Elastic 9.4로 업그레이드한 후, 전체 화면 모드에서 AI Chat을 열고 실제 조사에 적용해 보세요. 에이전트에게 확인 중인 메트릭을 차트로 생성하도록 요청한 뒤, 다음 단계 분석을 요청하세요. 이야기가 완성되면 저장하고 공유하세요. 동일한 패널과 동일한 분석 구성을 그대로 활용할 수 있어 별도로 재설명이 필요하지 않습니다. 엔터프라이즈 라이선스가 필요합니다(시작하기). 이 게시물에서 설명된 모든 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.

대시보드 로딩 시 Kibana가 데이터를 가져오는 방법

대시보드가 열리면 대부분의 패널(내부적으로는 임베더블이라고 부릅니다)이 하나 이상의 Elasticsearch 쿼리를 실행합니다. 하지만 동기(Sync) 검색의 단순한 요청 및 응답 방식 대신 우리는 강력한 비동기(Async) 검색(문서)을 사용합니다.

비동기 검색을 이용하면 쿼리 결과가 특정 HTTP 요청 세션에 종속되지 않고, Elasticsearch 내에 안정적으로 유지됩니다. 이 방식은 다음과 같은 측면에서 중요한 역할을 합니다.

• 네트워크가 불안정한 상황에서도 데이터 로딩의 회복 탄력성을 보장합니다.

• 사용자가 오래 걸리는 대시보드나 Discover 세션을 기다리는 동안 Kibana에서 다른 작업을 할 수 있도록 백그라운드 검색 기능을 지원합니다.

최초 쿼리가 제출되면 Kibana는 해당 검색 프로세스를 모니터링하여 완료 시점을 감지하고 결과 집합을 가져옵니다.

전통적인 폴링 방식이 Kibana 대시보드 로딩 시간에 미치는 영향

전통적인 폴링 구조에서 Kibana는 쿼리를 제출한 뒤 초기 연결을 닫고, 이후 Elasticsearch를 주기적으로 조회하여 완료 여부를 확인합니다.

쿼리가 제출되면 Elasticsearch가 검색을 마친 후 결과를 반환할 수 있도록 잠시 시간을 둡니다. 검색이 그만큼 빠르게 완료된다면 단순한 요청과 응답으로 마무리됩니다. 반면 실행 시간이 더 긴 검색의 경우 초기 연결이 닫힌 후 Kibana가 완료 여부를 주기적으로 확인하기 시작합니다. 이러한 방식을 폴링이라고 합니다.

전통적인 폴링 방식의 성능 저하 요소

위 그림에서 볼 수 있듯이 이 방식에는 성능상 약점이 있습니다. 검색이 Kibana의 대기 시간 중에 완료될 가능성이 높아 그만큼 시간이 낭비됩니다.

최악의 경우(대기 시간이 시작되자마자 검색이 완료될 때)에는 폴링 주기 전체가 고스란히 낭비됩니다.

백오프 전략의 영향

폴링을 수행할 때 백오프 전략을 적용하는 것은 일반적인 관행입니다. 즉, 검색 시간이 길어질수록 폴링 빈도를 낮추는 방식을 의미합니다.

하지만 이는 검색 시간이 길어질수록 잠재적인 시간 손실도 함께 늘어남을 의미합니다.

폴링 주기가 톱니형 지연 패턴을 유발하는 이유

이러한 요소들이 결합되면서 시간 손실은 계단식 톱니 함수 형태를 띠게 됩니다.

여기서 정점은 최악의 시나리오를, 저점은 최선의 시나리오를 나타냅니다. 즉, 전통적인 폴링 방식은 검색 시간과 네트워크 조건에 따라 시간 손실이 전혀 없을 수도, 혹은 전체 폴링 주기만큼 고스란히 발생할 수도 있음을 보여줍니다.

지속적 폴링: Kibana가 대기 시간을 제거하는 방법

전통적인 폴링 방식의 문제는 Kibana와 Elasticsearch 간의 상호 조율이 근본적으로 부족하다는 점입니다. 가장 이상적인 것은 결과가 준비되는 즉시 Kibana가 이를 바로 감지하는 것입니다. 그렇다면 폴링 패턴을 뒤집어, 대기 시간 없이 대부분의 시간을 Elasticsearch를 확인하는 데 사용하면 어떨까요?

이처럼 롱 폴링과 대기 시간이 없는 구조가 결합되어 결과는 준비되는 즉시 제공됩니다.

HTTP/1 성능 저하

이론은 확실합니다. 그렇다면 왜 이 Kibana 배포 환경에서는 지속적 폴링을 켰을 때 오히려 성능이 크게 떨어지는 것처럼 보일까요?

핵심은 이 배포 환경이 HTTP/1 기반으로 구동되고 있다는 점입니다. HTTP/1에서는 HTTP 요청이 TCP 커넥션과 1:1로 매핑됩니다. 따라서 몇 개의 오래 지속되는 폴링 요청이 브라우저의 제한된 커넥션 풀을 독점하게 되고, 이로 인해 다른 요청들이 대기열에 쌓이게 됩니다.

반면 HTTP/2+에서는 멀티플렉싱을 통해 네트워크 요청이 TCP 커넥션을 공유할 수 있으므로 이러한 문제가 발생하지 않습니다.

결론적으로 지속적 폴링은 HTTP/2+ 환경에서는 큰 장점이 되지만 HTTP/1 환경에서는 오히려 악영향을 미치게 됩니다.

HTTP/1

HTTP/2+

TCP 연결

HTTP 요청당 하나

멀티플렉싱(다수의 요청이 연결 공유)

지속적 폴링 동작 방식

성능 저하(연결 풀 고갈)

이점 극대화(결과 즉시 전달)

최적의 폴링을 위한 Kibana의 HTTP 프로토콜 감지 방법

HTTP/2는 권장 프로토콜이자 Kibana 9.0부터의 기본값입니다. 따라서 이러한 성능 향상 기능을 릴리스하지 않을 이유가 없었습니다. 반면 HTTP/1에서의 사용자 경험은 저하가 너무 심해 아직 프로토콜을 업그레이드하지 않은 온프레미스 배포 환경에 위험을 감수하고 적용할 수는 없었습니다. 답은 명확했습니다. 현재 어떤 프로토콜이 사용 중인지 감지하고, 그에 맞는 최적의 폴링 전략을 적용하는 것입니다.

물론 Kibana 서버가 자체적으로 어떤 프로토콜로 통신하고 있는지는 충분히 파악할 수 있습니다. 하지만 걸림돌이 하나 있습니다. 병목을 유발하는 결정적 요인은 브라우저의 커넥션 풀이라는 점입니다. 즉, 진짜 중요한 것은 브라우저가 어떤 프로토콜로 통신하는가입니다.

프록시로 인해 이러한 구간의 프로토콜이 항상 일치하지는 않기 때문입니다.

만약 서버 프로토콜을 기준으로 최적화를 진행한다면 다음과 같은 두 가지 오류가 발생할 수 있습니다.

1. 지속적 폴링을 적용해서는 안 되는 상황에 적용하여 사용자 경험을 저하시키거나,

2. 반대로 적용해야 하는 상황에 적용하지 못해 최적화 기회를 놓치는 것입니다.

다행히 최신 브라우저에서는 PerformanceObserver를 활용해 완료된 요청의 최종 네트워크 홉 프로토콜을 감지하는 방법을 제공합니다. 따라서 첫 번째 쿼리가 제출될 때의 프로토콜을 모니터링하고 이를 기준으로 최적화를 수행합니다.

실험 결과: Kibana의 지속적 폴링과 전통적 폴링 비교

지속적 폴링을 검증하기 위해 1초에서 23초 사이의 쿼리 지연 시간이 있는 대시보드를 생성한 후, 최적화 기능을 켰을 때와 껐을 때의 로딩 시간을 각각 측정했습니다. 이어서 성능 향상 폭을 측정하고자 지속적 폴링 적용 여부에 따라 대시보드를 로드해 보았습니다. 어느 쪽이 먼저 도달하는지 시합하며 테스트를 진행하는 과정은 꽤 흥미진진했습니다.

이 패턴은 앞서 보았던 톱니형 다이어그램과 일치합니다. 특정 쿼리 실행 시간대에서는 성능 향상 폭이 미미했지만 다른 시간대에서는 수 초의 시간을 단축하는 결과를 보였습니다.

결론

이번 최적화는 전통적인 폴링 방식에 내재된 고유의 지연 시간을 더 효율적인 지속적 폴링 전략으로 성공적으로 대체합니다. 가장 큰 과제는 HTTP/1 배포 환경에서의 성능 저하를 막기 위해 이 최적화 기능을 조건부로 적용하는 것이었습니다. 우리는 브라우저의 PerformanceObserver를 이용해 최종 네트워크 홉에서 사용 중인 프로토콜을 안정적으로 감지함으로써 이 문제를 해결했습니다.

실험실 테스트 결과 역시 이 이론을 뒷받침하며 지속적 폴링이 결과가 준비되는 즉시 데이터를 전달함을 보여줍니다. 이는 결과적으로 사용자 경험의 확연한 개선으로 이어져 데이터 로딩 속도를 최대 25%까지 단축합니다.

이번 작업은 사용자의 인사이트 확보 시간을 줄이기 위한 우리의 지속적인 노력의 최신 성과입니다. Kibana를 Elasticsearch 데이터에 대한 더 투명한 프록시로 기능하게 함으로써 우리가 혁신을 이끌어낼 수 있는 영역 내에서 성능의 한계를 한 단계 더 끌어올렸습니다. 앞으로의 행보도 기대해 주세요!

(지난 2025년, Thomas Neirynk가 Kibana 대시보드 성능 개선의 목적과 방법론에 대해 훌륭하게 정리해 준 바 있습니다. 본 글은 해당 이니셔티브의 후속 업데이트입니다.)

Kibana 대시보드 빌더란 무엇인가요?

원하는 대시보드를 평이한 영어로 설명하고 대화형 차트, 드래그 앤 드롭 레이아웃, 원클릭 내보내기 기능을 갖춘 대시보드가 나타나는 것을 볼 수 있다면 어떨까요?

바로 example-mcp-dashbuilder로 가능합니다. 오픈 소스(모델 컨텍스트 프로토콜(MCP)) 애플리케이션으로, AI 어시스턴트를 Elasticsearch에 연결하여 대화를 통해 완전한 Kibana 대시보드를 만들 수 있게 해줍니다. 메뉴를 클릭하지 않아도 됩니다. 시각화 구성을 수동으로 작성할 필요가 없습니다. 필요한 사항을 설명하기만 하면 AI가 데이터를 탐색하고, Elasticsearch 쿼리 언어(ES|QL) 쿼리를 작성하고, 차트를 만들고, 실시간 대화형 대시보드를 에디터의 채팅 창 내에서 제공합니다.

몇 초 만에 프롬프트에서 대시보드까지

실제 작동 사례를 소개해 드리겠습니다. 다음과 같이 입력하세요.

"Logstash-*를 사용하여 총 요청 수, 시간 경과에 따른 전송 바이트 수, 주요 지역별 트래픽 소스 및 응답 코드 분석을 포함하는 웹 트래픽 대시보드를 만들어 줘."

그럼 AI는 다음을 수행합니다.

1. 데이터 검색: 인덱스를 나열하고 필드 매핑을 검사합니다.

2. ES|QL 쿼리 작성: 올바른 집계를 사용하여 스키마에 맞게 조정합니다.

3. 시각화 생성: 막대형 차트, 선형 차트, 스파크라인이 있는 메트릭, 히트맵, 원형 차트를 생성합니다.

4. 모두 구성: 접을 수 있는 섹션, 의미 있는 제목, 적절한 레이아웃 등으로 구성합니다.

5. 인터랙티브 미리보기 렌더링: 채팅 바로 안에서 툴팁, 시간 선택기, 드래그 앤 드롭 기능을 제공합니다.

각 차트는 생성되는 즉시 인라인으로 표시되므로 실시간으로 진행 상황을 볼 수 있습니다. 그러면 view_dashboard 모든 패널이 Kibana의 48열 그리드에 배치된 전체 대시보드가 표시됩니다.

단일 차트 미리보기를 인라인으로 제공합니다.

ES|QL 기반

모든 데이터 검색은 Elasticsearch의 파이핑 쿼리 언어인 ES|QL을 사용합니다. AI는 단순히 원시 쿼리를 전달하는 것이 아니라, 또한 각 시각화 유형에 대해 올바르고 효율적인 쿼리를 작성하기 위해 ES|QL 구문에 대한 기본 제공 지식과 데이터 구조에 대한 정보를 사용합니다.

서버에는 MCP 리소스로 포괄적인 ES|QL 참조가 포함되어 있습니다. AI는 쿼리를 작성하기 전에 이 참조를 읽고 사용 가능한 명령어, 함수 및 패턴을 이해합니다. 데이터 시각화 모범 사례 가이드(리소스로도 제공됨)와 결합된 AI는 쿼리 방법뿐만 아니라 좋은 시각화가 무엇인지도 알고 있습니다.

• 시계열 데이터에는 BUCKET(@timestamp, 1 day)을 사용하고, 시간 필드에는 항상 SORT를 사용합니다.

• 원형 차트는 | SORT value DESC | LIMIT 6로 6개의 슬라이스로 제한합니다.

• 카테고리 비교를 위한 막대형 차트, 추세를 위한 꺾은선형 차트, 핵심 성과 지표(KPI)를 위한 메트릭을 선택합니다.

개방형 분석을 통한 AI 기반 데이터 탐색

머릿속으로 구상했던 대시보드를 실제로 구축하는 것은 별개의 문제입니다. "이 색인에서 흥미로운 점은 무엇입니까?" 라고 질문하고 유용한 답변을 얻으려면 AI가 단순히 그리는 방법뿐만 아니라 탐색하는 방법도 알아야 합니다.

example-mcp-dashbuilder는 구조화된 탐색 흐름을 정의하는 analysis://guidelines 리소스를 제공합니다. 데이터 프로파일링, 대상 집계 실행, 조사할 가치가 있는 패턴 표면화, 가장 흥미로운 결과에 대한 차트 작성, 사용자가 다음에 원하는 드릴다운 쿼리 제안 등입니다. 트리거 구문, 즉 "내 로그 분석" 또는 "이 인덱스에서 패턴 찾기"와 같은 구문은 AI가 다른 작업을 수행하기 전에 플레이북을 읽도록 하므로, 개방형 프롬프트는 무작위로 모인 차트가 아닌 일관성 있는 조사를 생성합니다.

결과: 인공지능에게 익숙하지 않은 인덱스를 전달하고 대시보드와 짧은 목록("여기 내가 발견한 것이 있는데, 이것들 중 어떤 것을 파헤쳐볼까요?" 프롬프트)이라는 시작점을 얻을 수 있습니다.

Kibana 대시보드 내보내기 및 가져오기: 전체 과정

내보내기/가져오기 왕복은 이미 Kibana에서 작업 중인 팀에게 example-mcp-dashbuilder가 진정으로 유용해지는 곳입니다. example-mcp-dashbuilder는 그 자체로 에디터 안에 있는 대화형 대시보드 표면이지만, 작업을 거기에 가두지는 않습니다. 여기에서 구축된 대시보드는 사용자가 원할 때 Kibana로 이동할 수 있으며, 기존 Kibana 대시보드는 AI 지원 편집을 위해 다른 방식으로 가져올 수 있습니다.

Kibana로 내보내기

만족스러운 대시보드가 완성되면 하나의 명령으로 내보낼 수 있습니다.

"이 대시보드를 Kibana로 내보내기"

모든 패널이 실제 Kibana Lens 시각화로 변환됩니다. 번역은 다음을 보존합니다.

• ES|QL 쿼리: Lens ES|QL 데이터 소스로 직접 전송됩니다.

• 그리드 위치: Kibana에서 사용하는 것과 동일한 48열 시스템을 사용하므로 레이아웃이 동일하게 보입니다.

• 사용자 지정 색상: 계열 팔레트, 메트릭 배경, 히트맵 색상 램프입니다.

그 결과 완전한 기능을 갖춘 Kibana 대시보드입니다. 스크린샷이 아닙니다. 임베드가 아닙니다. Kibana에서 공유하고 계속 편집할 수 있는 실제 대시보드입니다.

Kibana 대시보드와 Cursor 채팅의 대시보드를 나란히 배치하였습니다.

Kibana에서 가져오기

왕복은 반대 방향으로도 작동합니다.

"ID abc-123으로 Kibana 대시보드 가져오기"

이렇게 하면 기존 Kibana 대시보드가 가져오고, Lens 시각화가 편집 가능한 차트 구성으로 다시 변환되며, 그리드 레이아웃과 섹션이 유지되고, 모든 것이 example-mcp-dashbuilder로 로드됩니다. 거기에서 자연어로 수정하고 다시 내보낼 수 있습니다.

따라서 AI는 기존 Kibana 워크플로우를 대체하는 것이 아니라 기존 워크플로우의 협력자가 됩니다.

사용자 지정 테마 및 색상

브랜드 대시보드가 필요하신가요? 그냥 다음과 같이 물어보세요.

"사용자 지정 색상을 사용하여 핑크 테마의 대시보드를 만들어줘"

모든 시각화 유형은 사용자 지정 색상 구성을 지원합니다.

• 차트: palette는 계열 및 슬라이스에 대해 16진수 색상 배열을 허용합니다.

• 메트릭: color는 배경색을 설정합니다.

• 히트맵: colorRamp는 낮은 값부터 높은 값까지 그라데이션을 정의합니다.

AI는 테마 요청을 자연스럽게 파악합니다. 예를 들어 "바다 테마"라고 입력하면 파란색과 청록색이 선택됩니다. "브랜드 색상과 일치시켜 줘"라고 말하고 16진수 값을 제공하면, 내보내기 시 Kibana에 해당 색상이 그대로 적용됩니다.

사용자 지정 색상이 적용된 테마형 대시보드.

example-mcp-dashbuilder의 작동 방식: MCP 아키텍처

example-mcp-dashbuilder는 AI 어시스턴트를 외부 도구 및 데이터에 연결하기 위한 개방형 표준인 MCP를 기반으로 합니다. 다음은 상위 수준 아키텍처입니다.

MCP 서버는 인라인 미리 보기에서 데이터를 가져오고, 레이아웃 변경 사항을 유지하고, 시간 필드를 감지하는 데 사용하는 몇 가지 내부 "앱 전용" 도구와 함께 ES|QL 쿼리 실행부터 대시보드 내보내기까지 AI가 직접 호출할 수 있는 25개의 도구를 제공합니다. 데이터 시각화 모범 사례 가이드, ES|QL 참조, 개방형 프롬프트에 대한 심층 분석 플레이북("내 로그 분석", "이 색인에서 흥미로운 점") 등 세 가지 리소스를 제공합니다. 그리고 stdio 또는 HTTP 중 하나를 통해 실행되며, HTTP 전송은 스트리밍 가능한 응답과 세션 관리를 지원하므로 여러 클라이언트가 하나의 서버에 연결할 수 있습니다.

MCP 앱은 인터랙티브 미리보기입니다. React, Elastic Charts, Elastic UI로 구성되어 하나의 독립형 HTML 파일에 묶여 있습니다. AI가 view_dashboard를 호출하거나 차트를 만들 때, 호스트는 이 HTML을 샌드박스 iframe에 렌더링합니다. 이 앱은 전적으로 MCP 앱 프로토콜을 통해 서버와 통신하며, callServerTool()을 통해 데이터를 가져오고, 레이아웃을 저장하고, 시간 필드를 감지합니다. 로컬호스트 서버가 없으며, 구성할 포트도 없고, 외부 네트워크 의존성도 없습니다.

이는 MCP 호환 클라이언트인 Cursor, Claude Desktop, Claude.ai, VS Code with Copilot 등과 작동합니다.

example-mcp-dashbuilder는 어떤 차트 유형을 지원하나요?

현재 작성 시점에서, 가장 일반적인 대시보드 시나리오를 다루는 6가지 차트 유형이 지원됩니다.

유형

가장 적합

예

바

카테고리 비교

지리적 출처별 요청

라인

시간에 따른 추세

시간당 전송된 바이트 수

영역

시간에 따른 볼륨

시간에 따른 요청량

파이

전체 조각(최대 6개)

응답 코드 분포

메트릭

스파크라인이 있는 단일 KPI

시간별 추세를 포함한 총 요청 수

히트맵

2차원에 걸친 패턴

주중 및 시간별 요청

대시보드는 정리용 접이식 섹션, 자동 시간 필드 감지가 가능한 시간 선택기, 여러 대시보드 간 저장 및 전환 기능을 지원합니다, 병렬 채팅 세션은 모든 툴 호출에 연결된 dashboardId를 통해 서로 격리되어 있습니다.

example-mcp-dashbuilder를 설치하고 실행하는 방법

example-mcp-dashbuilder는 오픈 소스이며 사용할 준비가 되어 있습니다. Node.js 22+, Elasticsearch 인스턴스(로컬 또는 Elastic Cloud), MCP 호환 클라이언트가 필요합니다.

Claude Desktop: GitHub Releases에서 최신 .mcpb를 다운로드하시고, 두 번 클릭합니다. Claude Desktop은 Elasticsearch 자격 증명을 입력하라는 메시지를 표시합니다.

Cursor / Claude Code / VS Code Copilot: 릴리스된 타르볼을 MCP 구성에 지정하세요. 클론이 필요 없으며 npm install도 필요 없습니다.

ES_NODE, ES_API_KEY(또는 ES_USERNAME / ES_PASSWORD) 및 KIBANA_URL을 환경 변수로 설정합니다. 소스에서 작업하고 싶다면 리포지토리를 복제하고 로컬 Elasticsearch와 Elastic Cloud(Cloud ID + API 키)를 모두 처리하는 대화형 마법사를 위해 npm run setup을 실행하세요.

그리고 구축을 시작합니다.

"로그 인덱스를 탐색해서 가장 통찰력 있는 대시보드를 만들어 줘."

그 이후 과정은 AI가 진행합니다. 😉

로드맵: example-mcp-dashbuilder에 추가될 기능

이것은 초기 버전으로, 현재 적극적으로 개발 중입니다. 집중하는 영역은 다음과 같습니다:

• 더 많은 차트 유형: 게이지, 도넛, 트리맵, 데이터 테이블, 태그 클라우드 등 Lens의 모든 기능을 사용할 수 있습니다.

• 대시보드를 Git에 푸시: 버전 관리 및 코드 검토 워크플로를 위해 대시보드 구성을 저장소에 기록합니다.

• 오류 UX 개선: ES|QL 쿼리 실패 시 더 자세한 피드백과 함께 일반적인 수정 사항을 제안합니다.

• 더 풍부한 분석 흐름: 심층 분석 플레이북을 확장하여 더 많은 데이터 형태(로그, 메트릭, 추적)를 다룰 수 있습니다.

해당 도구로 구축하신 내용을 알려 주시면 감사하겠습니다. 사용해 보고 문제를 제기하고 팀에 가장 유용한 시각화 및 워크플로우가 무엇인지 알려주세요.

GitHub: elastic/example-mcp-dashbuilder

감사의 말씀

구현에 기여해 주신 Walter Rafelsberger 및 Tim Schnell에게 감사드립니다.

FAQ

example-mcp-dashbuilder란 무엇인가요? example-mcp-dashbuilder는 AI 어시스턴트를 Elasticsearch에 연결하는 오픈 소스 MCP(모델 컨텍스트 프로토콜) 애플리케이션입니다. 일반 영어로 Kibana 대시보드를 설명하며, ES|QL 쿼리를 자동으로 생성하고, 시각화를 만들며, 에디터의 채팅 창 내에서 실시간 대화형 대시보드를 제공합니다.

example-mcp-dashbuilder는 데이터를 검색하는 데 어떤 쿼리 언어를 사용하나요? 모든 데이터 검색은 Elasticsearch의 파이프 쿼리 언어인 ES|QL을 사용합니다. MCP 서버에는 AI가 쿼리를 작성하기 전에 읽는 기본 제공 ES|QL 참조가 포함되어 있어 각 시각화 유형에 대한 올바른 구문과 효율적인 집계를 보장합니다.

example-mcp-dashbuilder로 구축한 대시보드를 Kibana로 내보낼 수 있나요? 예. "이 대시보드를 Kibana로 내보내기"를 실행하면 ES|QL 쿼리, 48열 그리드 레이아웃, 사용자 정의 색상 및 시리즈 팔레트를 보존하면서 모든 패널이 실제 Kibana Lens 시각화로 변환됩니다. 결과는 스크린샷이나 임베드가 아니라 완전히 작동하는 Kibana 대시보드입니다.

기존 Kibana 대시보드를 AI 지원 편집을 위해 example-mcp-dashbuilder로 가져올 수 있나요? 예. Kibana 대시보드 ID를 제공하면 기존 대시보드를 가져오고, Lens 시각화를 편집 가능한 차트 구성으로 변환한 뒤 example-mcp-dashbuilder로 불러옵니다. 그런 다음 자연어를 사용하여 대시보드를 수정하고 Kibana로 다시 내보낼 수 있습니다.

어떤 MCP 클라이언트가 example-mcp-dashbuilder와 호환되나요? example-mcp-dashbuilder는 Cursor, Claude Desktop, Claude.ai 및 Copilot이 포함된 VS Code를 비롯한 MCP 호환 클라이언트와 함께 작동합니다. stdio 및 HTTP 전송을 모두 지원하며, 로컬호스트 서버나 포트 구성이 필요하지 않습니다.

example-mcp-dashbuilder는 어떤 차트 유형을 지원하나요? 현재 버전은 막대, 선, 면적, 파이, 메트릭(스파크라인 포함), 히트맵 등 6가지 차트 유형을 지원합니다. 계획된 추가 사항에는 Kibana Lens의 전체 기능에 맞추기 위한 게이지, 도넛, 트리맵, 데이터 테이블 및 태그 클라우드가 포함됩니다.

example-mcp-dashbuilder를 실행하려면 무엇이 필요하나요? Node.js 22 이상, Elasticsearch 인스턴스(로컬 또는 Elastic Cloud), MCP 호환 클라이언트가 필요합니다. 환경 변수 ES_NODE, ES_API_KEY (또는 ES_USERNAME/ES_PASSWORD), 그리고 KIBANA_URL을 설정하세요. Claude Desktop의 경우 GitHub 릴리즈에서 .mcpb 파일을 다운로드하고 더블 클릭하여 설치합니다.

변수 제어란 무엇인가요?

이전에 Kibana 대시보드를 사용해 본 적이 있다면, 아마도 클래식 대시보드 제어를 알고 계실 것입니다. 데이터에서 값을 표시하여 몇 번의 클릭만으로 항목을 필터링할 수 있는 편리한 드롭다운입니다.

변수 제어는 겉보기에는 비슷해 보이지만, 독창적인 차별점이 있습니다. 대시보드의 모든 패널을 자동으로 필터링하는 대신, 개별 시각화 내의 ES|QL 쿼리에 직접 연결할 수 있습니다.

즉, 사용자가 각 제어가 적용되는 위치를 결정할 수 있습니다. 더욱 좋은 점은, 시간 간격 조정, 분석 필드 전환, 시각화 매개변수 실시간 변경 등 다양한 창의적인 트릭에 활용할 수 있다는 것입니다. 기본적으로, 대시보드는 진정한 상호 작용 경험을 제공하여 인사이트를 더 빠르고 쉽게 얻을 수 있습니다.

변수 제어 사용 사례

좋습니다, 변수 제어는 유용한 것 같은데요. 그렇다면 실제로 무엇을 할 수 있을까요? 대시보드 수준을 높이는 몇 가지 예는 다음과 같습니다.

선택한 시각화 필터링

일부 시각화는 필터링하고 다른 시각화는 그대로 두고 싶으신가요? 변수 제어를 사용하면 바로 그렇게 할 수 있습니다. 응답할 패널을 선택하고 시각화의 기반이 되는 ES|QL 쿼리에 연결하세요.

다른 시간 간격을 선택하세요

사용자에게 '5분', '1시간', '1일' 등 원하는 시간 버킷으로 전환할 수 있는 권한을 부여합니다. 미리 정의된 간격으로 변수 제어를 작성하고 시계열 쿼리에 연결합니다.

함수 변경

각 작업에 대해 여러 차트를 생성하는 대신, 대시보드 사용자가 최대값, 평균값, 다양한 백분위수 또는 다른 집계기를 선택할 수 있도록 합니다.

다양한 필드로 그룹화

조사 중에는 데이터를 다양한 차원으로 세분화해야 할 때가 있습니다. 변수 제어를 통해 여러 '그룹별' 필드를 정의하고, 대시보드 사용자들이 자신만의 인사이트를 발견하는 데 가장 적합한 필드를 선택할 수 있게 할 수 있습니다.

어떻게 만들 수 있나요?

변수 제어를 만드는 가장 쉽게 (그리고 아마도 가장 즐겁게 만드는) 방법은 시각화의 ES|QL 쿼리 편집기에서 직접 만드는 것입니다. 쿼리를 입력하기 시작하고 자동 완성 메뉴를 사용하면 Kibana가 제어 구성을 훌륭히 도와줍니다.

하지만 변수 자체에서 시작하고 싶다면 패널 추가 → 제어 → 변수 제어 로 이동하여 제어를 만든 후 시각화에 변수를 추가할 수도 있습니다.

예제 1: 다중 값 선택 기능을 갖춘 필터링 제어

1. ES|QL 쿼리로 구동되는 시각화를 선택하고 WHERE 절에서 '제어 생성'을 클릭합니다.

2. 자동으로 변수 생성 플라이아웃으로 리디렉션되며, '쿼리에서 값 가져오기' 유형이 선택되고 변수 이름이 이미 입력되어 있습니다. 시각화 쿼리에서 작동하려면 컨트롤의 이름이 항상 '?...'로 시작해야 합니다.

대시보드에서 선택된 시간 범위에 따라 필드의 값을 가져오고 업데이트하려면 보통 이런 쿼리가 필요합니다.

3. 제어를 저장하면 대시보드 상단에 제어가 나타나고, 시각화 쿼리가 변수 제어 이름으로 업데이트됩니다.

4. 제어에 다중 값 선택을 추가하려면 쿼리에서 MV_CONTAINS 함수를 사용하고 2단계에서 제어 생성 시 '다중 선택 허용'을 선택해야 합니다(9.3부터 사용 가능).

예제 2: 시간 간격 제어

시계열을 구축하는 경우, 날짜 히스토그램 간격에 대한 변수 제어를 쉽게 추가할 수 있습니다.

1. 시계열에 대한 ES|QL 쿼리를 작성할 때 '제어 생성'을 클릭합니다. 간격 변수를 만들 때는 BUCKET 대신 TBUCKET 을(를) 사용하는 것이 좋습니다. '1시간', '1일'과 같은 더 읽기 쉬운 간격을 허용하기 때문입니다. TBUCKET 에 곧 자동 옵션이 추가되어 시간 범위에 자동으로 적응할 수 있게 됩니다.

2. 드롭다운 메뉴에서 옵션을 채울 간격을 정의합니다.

3. 드롭다운 메뉴에서 다른 간격을 선택하고 시각화가 어떻게 변하는지 확인합니다.

예제 3: 함수용 변수

1. '정적 값' 유형의 제어를 사용하여 변수를 생성하고 드롭다운 값에 함수 이름을 추가합니다. 함수를 대체하려면 '??...'로 시작하는 변수 이름을 사용하는 것이 중요합니다.

2. ES|QL 쿼리에 변수 이름을 포함합니다.

예제 4: 필드를 위한 변수

1. '정적 값' 유형의 제어를 사용하여 원하는 필드 이름을 작성할 수 있습니다. 필드에서 작동하려면 '??...'로 시작하는 변수 이름을 사용하는 것이 중요합니다.

2. 시각화 쿼리에서 원하는 위치에 변수를 참조합니다.

Discover의 변수 제어

변수 컨트롤은 단순한 대시보드 기능이 아닙니다. Discover의 ES|QL 편집기에서도 직접 사용할 수 있습니다. Discover에서 더 빠른 데이터 탐색 경험을 위한 제어를 생성하고, 이를 대시보드로 가져올 수 있으며, 그 반대로도 가능합니다.

기술적 세부 사항

이제 변수 제어에는 쿼리에서 참조할 수 있는 부분과 사용해야 하는 명명 접두사(값의 경우 "?...", 필드 또는 함수의 경우 "??...")와 같은 몇 가지 규칙이 있다는 것을 눈치채셨을 것입니다. 변수는 단순히 클라이언트 측에서 스트링 치환만 하는 것이 아니기 때문입니다. 실제로는 쿼리 언어 자체에서 1급 시민으로 처리됩니다(ES|QL에서 매개변수로 알려짐).

이 디자인은 몇 가지 큰 장점을 제공합니다. 첫째, Kibana는 각 변수의 맥락을 이해할 수 있어, 자동으로 구성 설정을 생성하고 미리 채울 수 있습니다. 또한 훨씬 더 안전합니다. 언어가 변수 입력의 유효성을 엄격하게 검사하여 악의적인 주입을 방지하고, 이상이 있을 경우 우아하게 오류를 처리합니다. 또한 복잡한 유효성 검사 및 오류 처리를 클라이언트가 아닌 서버로 전환하여 성능과 안정성을 향상합니다. 성능에 대한 참고 사항을 말씀드리자면, 빠른 쿼리는 대시보드보다 먼저 로드되기 대문에 쿼리가 느리면 전체 대시보드 성능에 영향을 미칠 수 있으므로 빠른 쿼리를 포함하는 변수를 작성하는 것이 가장 좋습니다.

물론, 이 아키텍처에는 현재로서 몇 가지 제약이 있습니다. 변수는 아직 필터링에 '모두' 옵션을 지원하지 않으며, 현재 LIKE또는 FROM (데이터 소스 전환용)과 같은 특정 연산자와 함께 사용할 수 없습니다. 좋은 소식은? 이러한 기능을 추가하기 위해 열심히 노력하고 있습니다.

제어의 미래가 가져올 변화

여기서 멈추지 않습니다! 주목하고 있는 개선 사항 일부는 다음과 같습니다.

✨ 대시보드 어디에나 컨트롤을 배치할 수 있는 기능

✨ 제어 체인 연결 - 한 제어의 출력이 다음 제어의 입력이 되는 것

✨ 변수에 대한 '모든' 선택과 같은 더 나은 선택 옵션

✨ 새로운 제어 유형(검색 유형 제어 및 데이터 소스용 변수)

✨ 그리고 많은 분들이 요청했던 삶의 질을 향상하는 추가 기능(예: 일반 제어 사전 필터링)

아이디어나 피드백이 있으시면 언제든지 알려주시기 바랍니다.

이 글에서는 이를 실현하는 방법에 대해 설명합니다. 대시보드의 이미지를 가져와서 매핑을 분석한 다음 Kibana를 전혀 건드리지 않고도 대시보드를 생성하는 애플리케이션을 만들어 보겠습니다!

단계:

1. 배경 & 애플리케이션 워크플로

2. 데이터 준비

3. LLM 구성

4. 애플리케이션 기능

배경 & 애플리케이션 워크플로

가장 먼저 떠오른 생각은 LLM이 전체 NDJSON 형식의 Kibana 저장 개체를 생성한 다음 Kibana로 가져오도록 하는 것이었습니다.

몇 가지 모델을 사용해 보았습니다:

• Gemini 2.5 프로

• GPT o3 / o4-미니 하이 / 4.1

• 클로드 4 소네트

• Grok 3

• 딥씽크(딥씽크 R1)

그리고 프롬프트는 간단하게 시작했습니다:

각 비주얼리제이션을 작성하는 방법에 대한 몇 가지 예시와 자세한 설명을 살펴봤지만 운이 없었습니다. 이 실험에 관심이 있으시다면 여기에서 자세한 내용을 확인할 수 있습니다.

이 접근 방식을 사용한 결과, LLM에서 생성된 파일을 Kibana에 업로드하려고 할 때 이러한 메시지가 표시되었습니다:

이는 생성된 JSON이 유효하지 않거나 형식이 잘못되었음을 의미합니다. 가장 흔한 문제는 불완전한 NDJSON을 생성하거나, 매개변수를 착각하거나, 아무리 강제 적용을 시도해도 NDJSON 대신 일반 JSON을 반환하는 LLM이었습니다.

검색 템플릿이 LLM 프리스타일보다 더 효과적이었다는 이 글에서 영감을 받아 전체 NDJSON 파일을 생성하도록 요청하는 대신 템플릿을 LLM에 제공하고 코드에서 LLM이 제공한 매개변수를 사용하여 적절한 시각화를 만들기로 결정했습니다. 이 접근 방식은 실망스럽지 않았고 예측 가능하고 확장 가능하며 이제 코드가 무거운 작업을 수행하므로 LLM이 아닌 코드가 작업을 수행하게 되었습니다.

애플리케이션 워크플로우는 다음과 같습니다:

간단하게 설명하기 위해 일부 코드는 생략하지만, 전체 애플리케이션의 작업 코드는 이 노트북에서찾을 수 있습니다.

필수 구성 요소

개발을 시작하기 전에 다음이 필요합니다:

1. Python 3.8 이상

2. Venv Python 환경

3. 엔드포인트 및 API 키와 함께 실행 중인 Elasticsearch 인스턴스

4. 환경 변수 이름 OPENAI_API_KEY에 저장된 OpenAI API 키입니다:

데이터 준비

데이터의 경우, 간단하게 유지하면서 Elastic 샘플 웹 로그를 사용하겠습니다. 여기에서 해당 데이터를 클러스터로 가져오는 방법을 알아보세요.

각 문서에는 애플리케이션에 요청을 보낸 호스트에 대한 세부 정보와 함께 요청 자체 및 응답 상태에 대한 정보가 포함되어 있습니다. 아래는 문서 예시입니다:

이제 방금 로드한 인덱스( kibana_sample_data_logs)의 매핑을 가져와 보겠습니다:

나중에 로드할 이미지와 함께 매핑을 전달하겠습니다.

LLM 구성

구조화된 출력을 사용하여 이미지를 입력하고 함수에 전달해야 하는 정보가 포함된 JSON을 수신하여 JSON 객체를 생성하도록 LLM을 구성해 보겠습니다.

종속성을 설치합니다:

Elasticsearch는 인덱스 매핑을 검색하는 데 도움이 됩니다. Pydantic을 사용하면 파이썬으로 스키마를 정의한 다음 LLM에 따르도록 요청할 수 있으며, LangChain은 LLM과 AI 도구를 더 쉽게 호출할 수 있도록 도와주는 프레임워크입니다.

LLM에서 원하는 출력을 정의하기 위해 Pydantic 스키마를 생성합니다. 이미지에서 알아야 할 것은 차트 유형, 필드, 비주얼리제이션 제목 및 대시보드 제목입니다:

이미지 입력은 제가 방금 그린 대시보드를 보내드리겠습니다:

이제 LLM 모델 호출과 이미지 로딩을 선언합니다. 이 함수는 생성하려는 대시보드의 이미지와 Elasticsearch 인덱스의 매핑을 수신합니다.

with_structured_output 을 사용하면 Pydantic Dashboard 스키마를 LLM이 생성할 응답 객체로 사용할 수 있습니다. Pydantic을 사용하면 유효성 검사를 통해 데이터 모델을 정의할 수 있으므로 LLM 출력이 예상 구조와 일치하는지 확인할 수 있습니다.

이미지를 base64로 변환하여 입력으로 보내려면 온라인 변환기를 사용하거나 코드로 변환할 수 있습니다.

LLM에는 이미 Kibana 대시보드에 대한 컨텍스트가 있으므로 프롬프트에서 모든 것을 설명할 필요는 없으며, Elasticsearch 및 Kibana와 함께 작동한다는 것을 잊지 않도록 하기 위한 몇 가지 세부 사항만 설명하면 됩니다.

프롬프트를 자세히 살펴 보겠습니다:

섹션

이유

귀하는 Kibana 버전 9.0.0의 이미지에서 Kibana 대시보드를 분석하는 전문가입니다.

이를 강화하는 것이 바로 Elasticsearch이며, Elasticsearch 버전은 LLM이 오래되거나 유효하지 않은 매개변수를 착각할 가능성을 줄여줍니다.

대시보드 이미지와 Elasticsearch 인덱스 매핑이 제공됩니다.

LLM의 잘못된 해석을 피하기 위해 이미지가 대시보드에 관한 것이라고 설명합니다.

다음은 대시보드의 기반이 되는 인덱스의 인덱스 매핑입니다. 이를 사용하여 데이터와 사용 가능한 필드를 이해하는 데 도움이 됩니다. 인덱스 매핑: {index_mappings}

LLM이 유효한 필드를 동적으로 선택할 수 있도록 매핑을 제공하는 것이 중요합니다. 그렇지 않으면 여기에 매핑을 하드 코딩하여 너무 딱딱하게 만들거나 올바른 필드 이름이 포함된 이미지에 의존할 수 있는데, 이는 신뢰할 수 없습니다.

이미지에 표시되는 내용에 따라 각 시각화와 관련된 필드만 포함합니다.

가끔 이미지와 관련이 없는 필드를 추가하려고 시도하기 때문에 이 기능을 추가해야 했습니다.

그러면 표시할 시각화 배열이 있는 객체가 반환됩니다:

LLM 응답 처리

에서 샘플 2x2 패널 대시보드를 만든 다음 대시보드 가져오기 API를 사용하여 JSON으로 내보낸 다음, 패널을 시각화 템플릿(파이, 막대, 메트릭)으로 저장하여 일부 매개 변수를 교체하여 질문에 따라 다른 필드로 새로운 시각화를 만들 수 있습니다.

템플릿 JSON 파일은 여기에서 확인할 수 있습니다. 나중에 대체할 개체 값을 {variable_name}로 변경한 방법에 유의하세요.

LLM이 제공한 정보를 바탕으로 어떤 템플릿을 사용하고 어떤 값을 대체할지 결정할 수 있습니다.

fill_template_with_analysis 는 시각화의 JSON 템플릿, 제목, 필드, 그리드에 있는 시각화의 좌표 등 단일 패널에 대한 매개변수를 받습니다.

그런 다음 템플릿의 값을 바꾸고 최종 JSON 시각화를 반환합니다.

간단하게 하기 위해 LLM이 생성하기로 결정한 패널에 정적 좌표를 할당하고 위 이미지와 같은 2x2 그리드 대시보드를 생성합니다.

LLM에서 결정한 시각화 유형에 따라 JSON 파일 템플릿을 선택하고 fill_template_with_analysis 을 사용하여 관련 정보를 바꾼 다음 새 패널을 나중에 대시보드를 만드는 데 사용할 배열에 추가합니다.

대시보드가 준비되면, 대시보드 만들기 API를 사용해 새 JSON 파일을 Kibana로 푸시하여 대시보드를 생성합니다:

스크립트를 실행하고 대시보드를 생성하려면 콘솔에서 다음 명령을 실행합니다:

최종 결과는 다음과 같습니다:

결론

LLM은 텍스트를 코드로 변환하거나 이미지를 코드로 변환할 때 강력한 시각적 기능을 발휘합니다. 또한 대시보드 API를 사용하면 JSON 파일을 대시보드로 전환할 수 있으며, LLM과 몇 가지 코드를 사용하면 이미지를 Kibana 대시보드로 전환할 수 있습니다.

다음 단계는 다양한 그리드 설정, 대시보드 크기 및 위치를 사용하여 대시보드 시각적 요소의 유연성을 개선하는 것입니다. 또한 더 복잡한 시각화 및 시각화 유형에 대한 지원을 제공하면 이 애플리케이션에 유용한 추가 기능이 될 것입니다.

첫 번째 Spotify Wrapped 분석과의 차이점

첫 번째 블로그에서는 Spotify 내보내기를 직접 사용했으며 정규화 작업이나 기타 데이터 처리를 수행하지 않았습니다. 이번에는 동일한 데이터를 사용하되, 데이터의 활용도를 높이기 위해 몇 가지 데이터 처리를 수행할 것입니다. 이를 통해 다음과 같은 훨씬 더 복잡한 질문에 답할 수 있습니다:

• 내 상위 100곡의 평균 재생 시간은 어떻게 되나요?

• 내 상위 100위 안에 있는 노래의 평균 인기도는 얼마인가요?

• 노래의 평균 청취 시간은 얼마나 되나요?

• 가장 많이 건너뛴 트랙은 무엇인가요?

• 언제 트랙을 건너뛰는 것을 좋아하나요?

• 하루 중 특정 시간대에 다른 시간대보다 더 많이 듣나요?

• 특정 요일에 다른 요일보다 더 많이 듣나요?

• 특별히 관심 있는 달인가요?

• 가장 긴 청취 시간을 기록한 아티스트는 무엇인가요?

Spotify Wrapped는 매년 재미있는 경험을 선사하며 올해 청취한 음악을 보여줍니다. 전년 대비 변화를 제공하지 않으므로 한때 상위 10위 안에 들었으나 지금은 사라진 아티스트를 놓칠 수 있습니다.

분석을 위한 Spotify 래핑 데이터 처리

첫 번째 게시물과 두 번째 게시물에서 데이터를 처리하는 방식에는 큰 차이가 있습니다. 첫 번째 게시물의 데이터로 계속 작업하려면 일부 필드 이름 변경을 고려해야 할 뿐만 아니라 hour of day 같은 특정 추출을 즉석에서 수행하려면 ES|QL로 되돌려야 합니다.

그럼에도 불구하고 여러분 모두 이 게시물을 팔로우할 수 있어야 합니다. Spotify에서 Elasticsearch 리포지토리로 데이터 처리가 수행되면 Spotify API에 노래의 재생 시간, 인기도를 요청하고 일부 필드의 이름을 바꾸고 개선하는 작업이 포함됩니다. 예를 들어 Spotify 내보내기의 artist 필드는 문자열일 뿐이며 기능이나 멀티 아티스트 트랙을 나타내지 않습니다.

대시보드로 Spotify 래핑된 데이터 시각화하기

데이터를 시각화하기 위해 Kibana에서 대시보드를 만들었습니다. 대시보드는 여기에서 사용할 수 있으며 Kibana 인스턴스로 가져올 수 있습니다. 대시보드는 상당히 광범위하며 위의 많은 질문에 대한 답변을 제공합니다.

몇 가지 질문과 답변 방법을 함께 알아보세요!

내 상위 100곡의 평균 재생 시간은 어떻게 되나요?

이 질문에 답하기 위해 Lens 또는 ES|QL을 사용할 수 있습니다. 세 가지 옵션을 모두 살펴 보겠습니다. 이 질문을 Elasticsearch 방식으로 올바르게 표현해 보겠습니다. 상위 100곡을 찾은 다음 모든 곡을 합친 평균 재생 시간을 계산하려고 합니다. Elasticsearch 용어로는 두 개의 집계가 됩니다:

1. 상위 100곡 파악하기

2. 100곡의 평균 재생 시간을 계산합니다.

Lens

Lens에서는 새 렌즈를 만들고 테이블로 전환한 다음 title 필드를 테이블로 끌어다 놓으면 됩니다. 그런 다음 title 필드를 클릭하고 크기를 100으로 설정하고 accuracy 모드를 설정합니다. 그런 다음 duration 필드를 테이블로 끌어다 놓고 last value 을 사용해야 하므로 각 노래의 마지막 지속 시간 값만 필요합니다. 같은 노래의 지속 시간은 한 번만 사용할 수 있습니다. 이 last value 집계 하단에 요약 행에 대한 드롭다운이 있으며 average 을 선택하면 요약 행이 표시됩니다.

ES|QL

ES|QL은 DSL & 집계에 비해 매우 새로운 언어이지만 매우 강력하고 사용하기 쉽습니다. ES|QL에서 동일한 질문에 답하려면 다음 쿼리를 작성합니다:

이 ES|QL 쿼리를 단계별로 안내해 드리겠습니다:

1. from spotify-history - 이것이 우리가 사용하고 있는 인덱스 패턴입니다.

2. stats duration=max(duration), count=count() by title - 이것은 첫 번째 집계로, 각 곡의 최대 재생 시간과 각 곡의 개수를 계산하고 있습니다. 렌즈에서 사용하는 last value 대신 max 을 사용하는데, 이는 현재 ES|QL에 이름이나 성이 없기 때문입니다.

3. sort count desc - 각 곡의 재생 횟수를 기준으로 노래를 정렬하므로 가장 많이 들은 곡이 맨 위에 표시됩니다.

4. limit 100 - 결과를 상위 100곡으로 제한합니다.

5. stats Average duration of the songs=avg(duration) - 곡의 평균 재생 시간을 계산합니다.

특별히 관심 있는 달이 있나요?

이 질문에 답하기 위해 런타임 필드와 ES|QL의 도움으로 Lens를 사용할 수 있습니다. 바로 눈에 띄는 것은 데이터에 month 을 직접 나타내는 필드가 없고 @timestamp 필드에서 계산해야 한다는 점입니다. 이를 수행하는 방법에는 여러 가지가 있습니다:

1. 런타임 필드를 사용하여 렌즈에 전원을 공급합니다.

2. ES|QL

저는 개인적으로 ES|QL이 더 깔끔하고 빠른 솔루션이라고 생각합니다.

DATE_EXTRACT 함수를 활용하여 @timestamp 필드에서 월을 추출한 다음 이를 집계할 수 있습니다. ES|QL 시각화를 사용하여 이를 대시보드에 놓을 수 있습니다.

아티스트당 연간 청취 시간은 얼마나 되나요?

그 이면에는 아티스트의 문제가 일회성으로 끝나는지, 아니면 재발하는지를 파악하기 위한 목적이 있습니다. 제 기억이 맞다면 Spotify는 연도별 상위 5명의 아티스트만 표시합니다. 6위 아티스트가 항상 같은 순위를 유지하거나 10위 이후에는 순위가 크게 바뀌나요?

이를 가장 간단하게 표현한 것 중 하나가 백분율 막대 차트입니다. 이를 위해 Lens를 사용할 수 있습니다. 다음 단계를 따르세요:

listened_to_ms 필드를 끌어다 놓습니다. 이 필드는 노래를 들은 시간(밀리초)을 나타냅니다. 이제 기본적으로 Lens는 median 집계를 생성하지만 이를 원하지 않는 경우 sum 으로 변경합니다. 상단에서 막대 차트 유형으로 stacked 대신 percentage 을 선택합니다. 분석 결과를 보려면 artist 을 선택하고 상위 10위라고 말합니다. Advanced 드롭다운에서 accuracy mode 을 선택하는 것을 잊지 마세요. 이제 모든 색상 블록은 해당 아티스트의 음악을 얼마나 많이 들었는지 나타냅니다. 시간 선택기에 따라 막대는 며칠, 몇 주, 몇 달, 몇 년의 값을 나타낼 수 있습니다. 주별 분석을 원하는 경우 @timestamp 을 선택하고 mininum interval 을 year 으로 설정합니다. 제 경우에는 Fred Again.. 이 가장 많이 들은 아티스트이며, 전체 청취 시간 중 거의 12% 이 Fred Again.. 에서 소비되었다는 것을 알 수 있습니다. 또한 2024년에 Fred Again.. 은 약간 감소했지만 Jamie XX 은 크게 성장한 것을 알 수 있습니다. 막대의 크기만 비교해 보겠습니다. 또한 2024년에도 Billie Eilish 이 지속적으로 재생되는 동안 바가 넓어지는 것을 알 수 있습니다. 즉, 2023년보다 2024년에 Billie Eilish 을 더 많이 들었습니다.

전체 청취 시간 대비 아티스트별 상위 트랙과 전체 청취 시간은 어떻게 되나요?

정말 어려운 질문입니다. 제가 하고 싶은 말이 무엇인지 설명해 보겠습니다. Spotify는 단일 아티스트의 인기 곡 또는 전체 인기 곡 5곡을 알려줍니다. 확실히 흥미롭긴 하지만 아티스트의 고장은 어떤가요? 반복해서 재생하는 한 곡에만 모든 시간이 소비되나요, 아니면 고르게 분배되나요?

새 렌즈를 만들고 유형으로 Treemap 을 선택합니다. metric 의 경우 이전과 동일하게 sum 을 선택하고 listened_to_ms 을 입력란으로 사용합니다. group by 의 경우 두 개의 값이 필요합니다. 첫 번째는 artist 이고 두 번째는 title 으로 추가합니다. 중간 결과는 다음과 같습니다:

이를 상위 100명의 아티스트로 변경하고 고급 드롭다운에서 other 을 선택 해제하고 정확도 모드를 사용하도록 설정해 보겠습니다. 제목의 경우 상위 10위로 변경하고 정확도 모드를 활성화합니다. 최종 결과는 다음과 같습니다:

이것이 지금 우리에게 정확히 무엇을 말해줄까요? 시간 구성 요소를 살펴보지 않고도 Spotify의 전체 청취 기록에서 5.67% 을 Fred Again.. 청취하는 데 사용했음을 알 수 있습니다. 특히 그 시간 중 1.21% 을 들으며 Delilah (pull me out of this) 을 들었습니다. 한 아티스트를 점유하는 곡이 한 곡만 있는지, 아니면 다른 곡도 있는지 살펴보는 것도 흥미롭습니다. 트리맵 자체는 이러한 데이터 분포를 표현하기에 좋은 형태입니다.

특정 시간 및 요일에 청취해야 하나요?

Heat Map 을 활용한 Lens 시각화를 통해 매우 간단하게 대답할 수 있습니다. 새 렌즈를 만들고 Heat Map 을 선택합니다. Horizontal Axis dayOfWeek 필드를 선택하고 상위 3번 대신 로 설정합니다. Top 7 Vertical Axis 의 경우 hourOfDay 을, Cell Value 의 경우 Count of records 을 선택하면 됩니다. 이제 이 패널이 생성됩니다:

이 렌즈 주변에는 통역할 때 방해가 되는 몇 가지 성가신 것들이 있습니다. 조금 정리해 보겠습니다. 우선 범례에 너무 신경 쓰지 않고 상단의 삼각형, 사각형, 원이있는 기호를 사용하고 비활성화합니다.

이제 성가신 두 번째 부분은 요일 정렬입니다. 월요일, 수요일, 목요일 등 원하는 날짜로 지정할 수 있습니다. hourOfDay 이 올바르게 정렬되었습니다. 날짜를 정렬하는 방법은 재미있는 해킹으로 Top Values 대신 Filters 을 사용하도록 하는 것입니다. dayOfWeek 을 클릭하고 Filters 을 선택하면 다음과 같은 화면이 표시됩니다:

이제 날짜를 입력하기만 하면 됩니다. 하루에 하나의 필터만 사용하세요. "dayOfWeek" : Monday 를 클릭하고 Monday 레이블을 지정한 다음 헹구고 반복합니다.

하지만 이 모든 과정에서 한 가지 주의할 점은 Spotify는 시간대 정보 없이 UTC+0으로 데이터를 제공한다는 점입니다. 물론 IP 주소와 청취한 국가를 제공하면 이를 통해 시간대 정보를 유추할 수도 있지만, 이는 불안정할 수 있고 미국처럼 여러 시간대가 있는 국가에서는 너무 번거로울 수 있습니다. Elasticsearch와 Kibana는 표준 시간대를 지원하며 @timestamp 필드에 올바른 표준 시간대를 입력하면 Kibana가 자동으로 시간을 브라우저 시간으로 조정하기 때문에 이것은 중요합니다.

최종적으로 완성되면 이런 모양이 될 것이며, 근무 시간에는 매우 적극적으로 청취하고 토요일과 일요일에는 덜 듣는다는 것을 알 수 있습니다.

결론

이 블로그에서는 Spotify 데이터가 제공하는 복잡한 기능에 대해 좀 더 자세히 살펴봤습니다. 몇 가지 간단하고 빠르게 비주얼리제이션을 시작하고 실행할 수 있는 몇 가지 방법을 보여드렸습니다. 자신의 청취 기록을 이 정도까지 제어할 수 있다는 것은 정말 놀라운 일입니다. 시리즈의 다른 부분도 확인해 보세요:

• 1부: Kibana로 래핑된 나만의 Spotify를 만드는 방법

• 3부: 이상 징후 탐지 집단 작업

• 4부: 데이터에서 관계 감지하기

• 5부: 벡터로 최고의 음악 친구 찾기

다음은 이 튜토리얼에서 구성할 내용을 보여주는 다이어그램입니다.

Ollama로 로컬 추론 설정하기

Ollama는 로컬 추론을 위한 엄선된 오픈 소스 모델 세트를 빠르게 테스트할 수 있는 훌륭한 방법으로, AI 개발자들 사이에서 인기 있는 도구입니다.

Ollama를 베어메탈에서 실행하기

Mac, Linux, Windows에서 로컬로 설치하는 것은 사용 가능한 로컬 GPU 기능을 활용하는 가장 쉬운 방법이며, M 시리즈 Apple 칩을 사용하는 경우 특히 그렇습니다. Ollama를 설치한 후, 다음 명령어로 DeepSeek R1을 다운로드하고 실행할 수 있습니다.

하드웨어에 맞게 매개변수 크기를 조정하는 것이 좋습니다. 사용 가능한 크기는 여기에서 확인할 수 있습니다.

터미널에서 모델과 채팅할 수 있지만, 명령에서 CTL+d를 누르거나 '/bye'를 입력해 명령을 종료해도 모델은 계속 실행됩니다. 모델이 여전히 실행 중인지 확인하려면 다음을 입력합니다.

컨테이너에서 Ollama 실행하기

또는 Ollama를 가장 빠르게 실행하는 방법은 Docker와 같은 컨테이너 엔진을 활용하는 것입니다. 환경에 따라 로컬 머신의 GPU를 사용하는 것이 항상 간단하지는 않지만, 컨테이너에 다중 GB 모델에 맞는 RAM과 저장 공간이 있다면 간단히 테스트 환경을 구성하는 것은 어렵지 않습니다.

Docker에서 Ollama를 바로 실행 가능한 상태로 만드는 것은 다음을 실행하는 것만큼이나 간단합니다.

이렇게 하면 현재 디렉터리에 'ollama'라는 디렉터리가 생성되고, 컨테이너 안에 마운트되어 Ollama 구성뿐만 아니라 모델도 모두 저장할 수 있습니다. 사용하는 매개변수의 수에 따라 몇 GB에서 수십 GB까지 다양할 수 있으므로, 충분한 여유 공간이 있는 볼륨을 선택합니다.

참고: 만약 컴퓨터에 Nvidia GPU가 있다면, Nvidia 컨테이너 툴킷을 설치하고 위의 Docker 실행 명령에 “--gpus=all”을 추가하세요.

Ollama 컨테이너가 머신에서 실행되면 deepseek-r1과 같은 모델을 가져올 수 있습니다.

베어메탈 접근 방식과 유사하게, 하드웨어에 맞게 매개변수 크기를 조정해야 할 수도 있습니다. 사용 가능한 크기는 https://ollama.com/library/deepseek-r1에서 확인할 수 있습니다.

모델을 가져오기가 완료되면 '/bye'를 입력하여 프롬프트를 종료할 수 있습니다. 모델이 여전히 실행 중인지 확인하려면 다음을 입력합니다.

curl을 사용하여 로컬 추론 테스트하기

curl을 사용하여 로컬 추론을 테스트하려면 다음 명령을 실행할 수 있습니다. JSON 내러티브 응답을 쉽게 읽을 수 있도록 stream:false를 사용하고 있습니다.

‘OpenAI 호환’ Ollama 및 RAG 프롬프트 테스트

편리하게도, Ollama는 Kibana를 비롯한 다양한 도구와의 호환성을 위해 OpenAI의 동작을 모방하는 REST 엔드포인트도 제공합니다.

이 복잡한 프롬프트를 테스트하면 모델이 문제를 추론하도록 훈련된 <think> 섹션이 포함된 콘텐츠가 생성됩니다.

Ollama를 Kibana에 연결하기

Elasticsearch를 효과적으로 사용하는 방법 중 하나는 'start-local' 개발 스크립트를 활용하는 것입니다.

Kibana와 Elasticsearch가 네트워크에서 Ollama에 접근할 수 있는지 확인하세요. Elastic Stack의 로컬 컨테이너 설정을 사용하는 경우, 호스트 머신으로의 네트워크 경로를 얻기 위해 'localhost'를 'host.docker.internal' 또는 'host.containers.internal'로 바꿔야 할 수도 있습니다.

Kibana에서 Stack Management(스택 관리) > Alerts and Insights(알림 및 인사이트) > Connectors(커넥터)로 이동합니다.

일반 설정 경고 확인 시 조치 방법

xpack.encryptedSavedObjects.encryptionKey가 올바르게 설정되었는지 확인해야 합니다. 이는 Kibana를 로컬 Docke로 설치할 때 흔히 놓치는 단계이므로, Docker 구문으로 문제를 해결하는 방법을 단계별로 안내해 드리겠습니다.

컨테이너가 종료될 때 변경 사항이 저장되도록 kibana/config 디렉터리를 지속적으로 유지해야 합니다. docker-compose.yml에서 내 Kibana 컨테이너 볼륨은 다음과 같습니다.

이제 키 저장소를 생성하고 커넥터 키가 일반 텍스트로 저장되지 않도록 값을 설정할 수 있습니다.

전체 클러스터를 완전히 재부팅하여 변경 사항이 적용되도록 합니다.

커넥터 생성하기

커넥터 구성 화면(Kibana에서 Stack Management(스택 관리) > Alerts and Insights(알림 및 인사이트) > Connectors(커넥터))에서 커넥터를 생성하고 'OpenAI' 유형을 선택합니다.

커넥터를 다음 설정으로 구성합니다.

• 커넥터 이름: Deepseek (Ollama)

• OpenAI 공급자 선택: 기타(OpenAI 호환 서비스)

• URL: http://localhost:11434/v1/chat/completions

  • ollama 경로를 올바르게 지정합니다. 컨테이너 내부에서 호출할 경우 host.docker.internal 또는 이에 해당하는 주소로 대체해야 합니다.

• 기본 모델: deepseek-r1:7b

• API 키: 임의의 값을 입력합니다. 입력 항목이 필요하지만 값 자체는 중요하지 않습니다.

8.17 버전에서는 커넥터 설정에서 Ollama에 대한 맞춤형 커넥터 테스트가 현재 작동하지 않지만, 곧 출시될 Kibana 8.18 빌드에서는 이 문제가 해결됩니다.

커넥터는 다음과 같습니다.

Elasticsearch로 벡터 임베딩 데이터 가져오기

이미 Playground에 익숙하고 데이터가 설정되어 있다면 아래의 Playground 단계로 건너뛸 수 있지만, 빠른 테스트 데이터가 필요한 경우 _inference API가 설정되어 있는지 확인해야 합니다. 8.17부터는 머신 러닝 할당이 동적으로 이루어지므로, e5 다국어 밀도 벡터를 다운로드하고 활성화하려면 Kiban 개발 도구에서 다음을 실행하기만 하면 됩니다.

아직 다운로드하지 않은 경우, 이렇게 하면 Elastic의 모델 리포지토리에서 e5 모델이 다운로드됩니다.

다음으로 퍼블릭 도메인 도서를 RAG 컨텍스트로 로드해 보겠습니다. Project Gutenberg에서 'Alice’s Adventures in Wonderland'를 다운로드할 수 있는 곳은 다음과 같습니다: 링크 이 파일을 .txt로 저장하세요.

Elasticsearch > 홈 > 파일 업로드로 이동

텍스트 파일을 선택하거나 드래그 앤 드롭한 후 'Import' 버튼을 클릭합니다.

'Import data(데이터 가져오기)' 화면에서 'Advanced(고급)' 탭을 선택한 다음 인덱스 이름을 'book_alice'로 설정합니다.

'Automatically created fields(자동 생성 필드)' 바로 아래에 있는 작은 'Add additional field(추가 필드 추가)' 옵션을 선택합니다. 'Add semantic text field(시맨틱 텍스트 필드 추가)'를 선택하고 추론 엔드포인트를 '.multilingual-e5-small-elasticsearch'로 변경합니다. Add(추가)를 선택하고 Import(가져오기)를 선택합니다.

로드 및 추론이 완료되면 Playground로 이동할 준비가 됩니다.

Playground에서 RAG 테스트하기

Kibana에서 Elasticsearch > Playground로 이동합니다.

Playground 화면에서 녹색 체크 표시와 'LLM Connected(LLM 연결됨)'가 표시되면 커넥터가 존재함을 의미합니다. 이것은 우리가 방금 위에서 만든 Ollama 커넥터입니다. Playground에 대한 더 자세한 가이드는 여기에서 찾을 수 있습니다.

파란색 'Add data sources(데이터 소스 추가)'를 클릭하고, 이전에 만든 book_alice 인덱스를 선택합니다. 또는 임베딩을 위해 추론 API를 활용하는 이전에 구성한 다른 인덱스를 선택해도 됩니다.

Deepseek는 강력한 정합 특성을 지닌 연쇄 사고(chain-of-thought) 모델입니다. 이는 RAG의 관점에서 보면 좋은 점도 있고 나쁜 점도 있습니다. 연쇄 사고(chain-of-thought) 훈련은 Deepseek가 인용문에서 겉보기에 모순되는 진술을 합리화하는 데 도움이 될 수 있지만, 훈련 지식과의 강한 정합성 때문에 맥락 기반 정보보다 자체 세계관을 선호할 수도 있습니다. 의도는 좋지만, 이러한 강한 정합성 때문에 LLM은 우리 내부 지식이 충분히 포함되지 않았거나 훈련 데이터에 잘 반영되지 않은 주제를 다룰 때 지시하기 어려운 것으로 알려져 있습니다.

Playground 설정에서 시스템 프롬프트를 'You are an assistant for question-answering tasks using relevant text passages from the book Alice in wonderland'로 입력하고 나머지 기본값은 그대로 수락했습니다.

'Who was at the tea party?'라는 질문에 대한 답변은 'Answer: The March Hare, the Hatter, and the Dormouse were at the tea party. [Citation: position 1 and 2]'이며, 이 답변은 정답입니다.

<think> 태그에서 Deepseek가 질문에 답하기 위해 인용문의 내용을 확실히 숙고했음을 알 수 있습니다.

정합성 한계 테스트

Deepseek를 테스트하기 위해 지적 난이도가 높은 시나리오를 만들어 보겠습니다. Deepseek의 훈련 데이터가 사실이 아니라고 알고 있는 음모론을 인덱스로 만들 예정입니다.

Kibana 개발 도구에서 다음 인덱스와 데이터를 생성해 보겠습니다.

이러한 음모론은 LLM의 기반이 될 것입니다. 공격적인 시스템 프롬프트를 사용했음에도 불구하고, Deepseek은 우리가 제시한 사실을 받아들이지 않습니다. 우리의 개인 데이터가 더 신뢰할 수 있고, 근거가 있거나, 조직의 요구 사항에 부합하는 상황이었다면 이는 용납될 수 없는 일입니다.

테스트 질문 'are birds real?'(설명 know your meme)에 대한 답변은 'In the provided context, birds are not considered real, but in reality, they are real animals. [Context: position 1]'입니다. 이 테스트는 DeepSeek R1이 7B 매개변수 수준에서도 강력하다는 것을 입증하지만, 데이터 세트에 따라 RAG에 최적의 선택이 아닐 수도 있습니다.

그래서 우리는 무엇을 배웠나요?

요약하자면:

• Ollama와 같은 도구에서 로컬로 모델을 실행하는 것은 모델 동작을 살펴볼 수 있는 좋은 옵션입니다.

• DeepSeek R1은 추론 모델로, RAG와 같은 사용 사례에 있어 장단점을 안고 있습니다.

• Playground는 AI 호스팅의 초기 시대에 사실상 표준이 되고 있는 OpenAI와 유사한 REST API를 통해 Ollama와 같은 추론 호스팅 프레임워크에 연결할 수 있습니다.

전반적으로, 우리는 로컬 '에어 갭' RAG가 얼마나 발전했는지에 깊은 인상을 받았습니다. Elasticsearch, Kibana를 비롯한 사용 가능한 개방형 가중치 모델의 도구는 2023년에 처음 개인정보 보호 우선 AI 검색에 대해 작성한 이후 크게 발전했습니다.

Kibana를 사용하여 위치 기반 정보 데이터 가져오기

이전 블로그의 예제에 사용된 데이터는 내부적으로 통합 테스트에 사용하는 데이터를 기반으로 했습니다. 사용자의 편의를 위해 Kibana를 사용하여 쉽게 가져올 수 있는 몇 가지 CSV 파일 형태로 여기에 포함시켰습니다. 데이터는 공항, 도시, 도시 경계가 혼합되어 있습니다. 다음에서 데이터를 다운로드할 수 있습니다:

• airports.csv

  • 여기에는 세 개의 데이터 세트가 병합되어 있습니다:

    • Natural Earth의공항(이름, 위치 및 관련 데이터)

    • SimpleMaps의도시 위치

    • 전 세계 공항 데이터베이스의공항 고도

• airport_city_boundaries.csv

  • 여기에는 위의 공항 및 도시 이름이 하나의 새로운 소스로 병합되어 있습니다:

    • 오픈스트리트맵의도시 경계

짐작할 수 있듯이, ES|QL의 지리적 공간 기능을 테스트하기 위해 이러한 데이터 소스를 위의 두 파일로 결합하는 데 시간을 보냈습니다. 구체적인 데이터 요구 사항과 완전히 같지는 않을 수 있지만, 이를 통해 어떤 것이 가능한지에 대한 아이디어를 얻을 수 있기를 바랍니다. 특히 몇 가지 흥미로운 점을 보여드리고자 합니다:

• 다른 색인 가능한 데이터와 함께 지리공간 필드가 있는 데이터 가져오기

• geo_point 및 geo_shape 데이터를 모두 가져와 쿼리에서 함께 사용

• 공간 관계를 사용하여 조인할 수 있는 두 인덱스로 데이터 가져오기

• 향후 가져오기를 용이하게 하기 위한 수집 파이프라인 생성(Kibana 이후)

• 수집 프로세서의 몇 가지 예는 csv, convert 및 split

이 블로그에서는 CSV 데이터 작업에 대해 설명하지만,Kibana를 사용해 위치 기반 데이터를 추가하는 방법에는 여러 가지가 있다는 것을 이해하는 것이 중요합니다. 맵 애플리케이션 내에서 CSV, GeoJSON 및 ESRI 셰이프파일과 같은 구분된 데이터를 업로드할 수 있으며 맵에서 직접 도형을 그릴 수도 있습니다. 이 블로그에서는 Kibana 홈 페이지에서 CSV 파일을 가져오는 데 중점을 두겠습니다.

공항 가져오기

첫 번째 파일인 airports.csv, 에는 우리가 처리해야 할 몇 가지 흥미로운 문제가 있습니다. 첫째, 열에는 CSV 파일에서는 일반적으로 볼 수 없는 추가 공백이 열을 구분합니다. 둘째, type 필드는 다중 값 필드이므로 별도의 필드로 분할해야 합니다. 마지막으로 일부 필드는 문자열이 아니므로 올바른 유형으로 변환해야 합니다. 이 모든 작업은 Kibana의 CSV 가져오기 기능을 사용하여 수행할 수 있습니다.

Kibana 홈페이지에서 시작하세요. "통합을 추가하여 시작하기" 라는 섹션이 있으며, 여기에는 "파일 업로드" 라는 링크가 있습니다:

이 링크를 클릭하면 "파일 업로드" 페이지로 이동합니다. 여기에서 airports.csv 파일을 끌어다 놓으면 Kibana가 파일을 분석하여 데이터 미리 보기를 표시합니다. 구분 기호를 쉼표로, 첫 번째 행을 헤더 행으로 자동으로 감지해야 합니다. 그러나 모든 필드가 text 또는 keyword 이라고 가정하여 열 사이의 여분의 공백을 잘라내거나 필드 유형을 결정하지 않았을 수 있습니다. 이 문제를 해결해야 합니다.

Override settings 을 클릭하고 Should trim fields, Apply 확인란을 선택하여 설정을 닫습니다. 이제 필드 유형을 수정해야 합니다. 다음 페이지에서 Import 을 클릭하세요.

먼저 인덱스 이름을 선택한 다음 Advanced 을 선택하여 필드 매핑 및 수집 프로세서 페이지로 이동합니다.

여기서는 인덱스에 대한 필드 매핑과 데이터를 가져오기 위한 수집 파이프라인을 모두 변경해야 합니다. 첫째, Kibana는 scalerank 필드를 long 으로 자동 감지했지만 location 및 city_location 필드를 keyword 로 잘못 인식했을 가능성이 높습니다. geo_point 으로 편집하면 다음과 같은 매핑이 완성됩니다:

여기에는 약간의 유연성이 있지만, 어떤 유형을 선택하느냐에 따라 필드가 색인되는 방식과 가능한 쿼리 종류에 영향을 미칩니다. 예를 들어 location 을 keyword 으로 남겨두면 지리공간 검색 쿼리를 수행할 수 없습니다. 마찬가지로 elevation 을 text 으로 남겨두면 숫자 범위 쿼리를 수행할 수 없습니다.

이제 수집 파이프라인을 수정할 차례입니다. Kibana가 scalerank 를 위의 long 로 자동 감지했다면, 필드를 long 로 변환하는 프로세서도 추가했을 것입니다. elevation 필드에 비슷한 프로세서를 추가해야 하는데, 이번에는 double 으로 변환합니다. 파이프라인을 편집하여 이 변환이 제대로 이루어지도록 합니다. 이를 저장하기 전에 type 필드를 여러 필드로 분할하는 변환을 한 번 더 수행하려고 합니다. 다음 구성을 사용하여 파이프라인에 split 프로세서를 추가합니다:

최종 수집 파이프라인은 다음과 같아야 합니다:

location 및 city_location 필드에 변환 프로세서를 추가하지 않았습니다. 이는 필드 매핑의 geo_point 유형이 이미 이러한 필드에 있는 데이터의 WKT 형식을 이해하고 있기 때문입니다. geo_point 유형은 WKT, GeoJSON 등을 포함한 다양한 형식을 이해할 수 있습니다. 예를 들어 CSV 파일에 latitude 와 longitude 에 대한 두 개의 열이 있는 경우, 이를 단일 geo_point 필드로 결합하려면 script 또는 set 프로세서를 추가해야 합니다(예. "set": {"field": "location", "value": "{{lat}},{{lon}}"}).

이제 파일을 가져올 준비가 되었습니다. Import 을 클릭하면 방금 정의한 매핑과 수집 파이프라인을 사용하여 데이터를 인덱스로 가져옵니다. 데이터를 수집하는 데 오류가 있는 경우, Kibana가 여기에 보고하므로 소스 데이터 또는 수집 파이프라인을 편집하고 다시 시도할 수 있습니다.

새 수집 파이프라인이 생성된 것을 확인할 수 있습니다. 이는 Kibana의 Stack Management 섹션으로 이동하여 Ingest pipelines 을 선택하면 볼 수 있습니다. 여기에서 방금 만든 파이프라인을 확인하고 필요한 경우 편집할 수 있습니다. 실제로 Ingest pipelines 섹션은 수집 파이프라인을 만들고 테스트하는 데 사용할 수 있으며, 훨씬 더 복잡한 수집을 계획하는 경우 매우 유용한 기능입니다.

이 데이터를 바로 살펴보고 싶다면 뒷부분으로 건너뛰고, 도시 경계도 가져오려면 계속 읽으세요.

도시 경계 가져오기

airport_city_boundaries.csv에서 제공되는 도시 경계 파일은 이전 예제보다 가져오기가 조금 더 간단합니다. 여기에는 도시 경계를 POLYGON 으로 표현하는 WKT 필드인 city_boundary 필드와 도시 위치를 geo_point 으로 표현하는 city_location 필드가 포함되어 있습니다. 이 데이터는 공항 데이터와 비슷한 방식으로 가져올 수 있지만 몇 가지 차이점이 있습니다:

• 자동 감지되지 않았기 때문에 재정의 설정 Has header row 을 선택해야 했습니다.

• 데이터에 여분의 공백이 이미 정리되어 있었기 때문에 필드를 다듬을 필요가 없었습니다.

• 모든 유형이 문자열 또는 공간 유형이었기 때문에 수집 파이프라인을 편집할 필요가 없었습니다.

• 하지만 필드 매핑을 편집하여 city_boundary 필드를 geo_shape, city_location 필드를 다음과 같이 설정해야 했습니다. geo_point

최종 필드 매핑은 다음과 같습니다:

앞서 airports.csv 가져오기와 마찬가지로 Import 을 클릭하여 데이터를 인덱스로 가져오기만 하면 됩니다. 데이터는 우리가 편집한 매핑과 Kibana가 정의한 수집 파이프라인으로 가져옵니다.

개발 도구로 지리공간 데이터 탐색하기

Kibana에서는 일반적으로 "검색" 을 사용하여 색인된 데이터를 탐색합니다. 그러나 ES|QL 쿼리를 사용하여 직접 앱을 작성하려는 경우, 원시 Elasticsearch API에 액세스하는 것이 더 흥미로울 수 있습니다. Kibana에는 쿼리 작성을 실험해 볼 수 있는 편리한 콘솔이 있습니다. 이를 Dev Tools 콘솔이라고 하며, Kibana 사이드바에서 찾을 수 있습니다. 이 콘솔은 Elasticsearch 클러스터와 직접 통신하며 쿼리 실행, 인덱스 생성 등에 사용할 수 있습니다.

다음을 시도해 보세요:

이렇게 하면 다음과 같은 결과가 표시됩니다:

거리

abbrev

이름

장소

국가

도시

고도

273418.05776847183

HAM

함부르크

포인트 (10.005647830925 53.6320011640866)

독일

노르트슈테트

17.0

337534.653466062

TXL

베를린-테겔 국제 공항

포인트 (13.2903090925074 52.5544287044101)

독일

호헨 노이엔도르프

38.0

483713.15032266214

OSL

오슬로 가르데르멘

포인트 (11.0991032762581 60.1935783171386)

노르웨이

오슬로

208.0

522538.03148094116

BMA

브롬마

포인트 (17.9456175406145 59.3555902065112)

스웨덴

스톡홀름

15.0

522538.03148094116

ARN

Arlanda

포인트 (17.9307299016916 59.6511203397372)

스웨덴

스톡홀름

38.0

624274.8274399083

DUS

뒤셀도르프 국제 공항

POINT (6.76494446612174 51.2781820420774)

독일

뒤셀도르프

45.0

633388.6966435644

PRG

루진

포인트 (14.2674849854076 50.1076511703671)

체코

프라하

381.0

635911.1873311149

AMS

스키폴

POINT (4.76437693232812 52.3089323889822)

네덜란드

Hoofddorp

-3.0

670864.137958866

FRA

프랑크푸르트 국제

포인트 (8.57182286907608 50.0506770895207)

독일

프랑크푸르트

111.0

683239.2529970079

WAW

오케시에 국제

포인트 (20.9727263383587 52.171026749259)

폴란드

Piaseczno

111.0

Kibana Maps로 위치 기반 정보 데이터 시각화하기

Kibana Maps는 위치 기반 정보 데이터를 시각화하기 위한 강력한 도구입니다. 여러 레이어가 있는 맵을 만드는 데 사용할 수 있으며, 각 레이어는 서로 다른 데이터 집합을 나타냅니다. 데이터는 다양한 방식으로 필터링, 집계, 스타일 지정이 가능합니다. 이 섹션에서는 이전 섹션에서 가져온 데이터를 사용하여 Kibana Maps에서 지도를 만드는 방법을 보여드리겠습니다.

Kibana 메뉴에서 Analytics->Maps 으로 이동하여 새 지도 보기를 엽니다. Add Layer 을 클릭하고 Documents 을 선택하여 데이터 보기 airports 를 선택한 다음 레이어 스타일을 편집하여 elevation 필드를 사용하여 마커에 색상을 지정하면 각 공항의 높이를 쉽게 확인할 수 있습니다.

'변경 사항 유지'를 클릭하여 지도를 저장합니다:

이제 두 번째 레이어를 추가하고 이번에는 airport_city_boundaries 데이터 보기를 선택합니다. 이번에는 city_boundary 필드를 사용하여 레이어 스타일을 지정하고 채우기 색상을 하늘색으로 설정하겠습니다. 그러면 지도에 도시 경계가 표시됩니다. 공항 마커가 맨 위에 오도록 레이어를 다시 정렬해야 합니다.

공간 조인

ES|QL은 JOIN 명령을 지원하지 않지만 ENRICH 명령을 사용하여 특별한 경우의 조인을 수행할 수 있습니다. 이 명령은 SQL의 'Left 조인'과 유사하게 작동하며, 두 데이터 집합 간의 공간적 관계를 기반으로 한 인덱스의 결과를 다른 인덱스의 데이터로 보강할 수 있습니다.

예를 들어 공항 위치가 포함된 도시 경계를 찾아서 공항이 취항하는 도시에 대한 추가 정보로 공항 테이블의 결과를 보강한 다음 결과에 대한 몇 가지 통계를 수행해 보겠습니다:

색인 강화 인덱스를 먼저 준비하지 않고 이 쿼리를 실행하면 다음과 같은 오류 메시지가 표시됩니다:

앞서 언급했듯이 ES|QL은 진정한 JOIN 명령을 지원하지 않기 때문입니다. 그 중요한 이유 중 하나는 Elasticsearch가 분산 시스템이고 조인이 확장하기 어려울 수 있는 고비용 작업이라는 점입니다. 그러나 ENRICH 명령은 클러스터 전체에 복제된 특별히 준비된 강화 인덱스를 사용하여 각 노드에서 로컬 조인을 수행할 수 있기 때문에 매우 효율적일 수 있습니다.

이를 더 잘 이해하기 위해 위의 쿼리에서 ENRICH 명령에 초점을 맞춰 보겠습니다:

이 명령은 airports 인덱스에서 검색된 결과를 보강하고 원본 인덱스의 city_location 필드와 앞서 몇 가지 예제에서 사용한 airport_city_boundaries 인덱스의 city_boundary 필드 간에 intersects 조인을 수행하도록 Elasticsearch에 지시합니다. 그러나 이 정보 중 일부는 이 쿼리에서 명확하게 표시되지 않습니다. 우리가 볼 수 있는 것은 인라이크 정책의 이름 city_boundaries 이며, 누락된 정보는 해당 정책 정의에 캡슐화되어 있습니다.

여기에서 geo_match 쿼리를 수행하고(intersects 이 기본값), 일치시킬 필드는 city_boundary, enrich_fields 은 원본 문서에 추가하려는 필드임을 알 수 있습니다. 이러한 필드 중 하나인 region 은 실제로 STATS 명령의 그룹화 키로 사용되었는데, 이 '왼쪽 조인' 기능이 없었다면 불가능했을 것입니다. 인라이크 정책에 대한 자세한 내용은 인라이크 문서를 참조하세요.

Elasticsearch의 강화 인덱스와 정책은 원래 준비된 다른 강화 인덱스의 데이터를 사용하여 인덱스 시점에 데이터를 강화하도록 설계되었습니다. 그러나 ES|QL에서는 ENRICH 명령이 쿼리 시점에 작동하며 수집 파이프라인을 사용할 필요가 없습니다. 이렇게 하면 사실상 SQL LEFT JOIN 과 매우 유사하지만, 두 인덱스를 조인할 수 없고 왼쪽에는 일반 인덱스만 있고 오른쪽에는 특별히 준비된 강화 인덱스가 있다는 점이 다릅니다.

수집 파이프라인이든 ES|QL에서 사용하든 어느 경우든, 수집 인덱스와 정책을 설정하기 위해 몇 가지 준비 단계를 수행해야 합니다. 위에서 이미 airport_city_boundaries 인덱스를 가져왔지만 ENRICH 명령에서 이 인덱스를 직접 색인 강화 인덱스로 사용할 수 없습니다. 먼저 두 단계를 수행해야 합니다:

• 위에서 설명한 보강 정책을 생성하여 소스 인덱스, 일치시킬 소스 인덱스의 필드, 일치하면 반환할 필드를 정의합니다.

• 이 정책을 실행하여 보강 인덱스를 생성합니다. 이렇게 하면 원본 소스 인덱스를 보다 효율적인 데이터 구조로 읽고 클러스터 전체에 복사하여 특별한 내부 인덱스를 구축합니다.

인리치 정책은 다음 명령을 사용하여 만들 수 있습니다:

그리고 다음 명령을 사용하여 정책을 실행할 수 있습니다:

airport_city_boundaries 인덱스의 콘텐츠를 변경하는 경우 이 정책을 다시 실행해야 변경 사항이 인리치 인덱스에 반영되는지 확인할 수 있습니다. 이제 원래 ES|QL 쿼리를 다시 실행해 보겠습니다:

그러면 공항이 가장 많은 상위 5개 지역과 해당 지역과 일치하는 모든 공항의 중심점, 해당 지역 내 도시 경계를 나타내는 WKT의 길이 범위가 반환됩니다:

중심

개수

지역

포인트 (-12.139086859300733 31.024386116624648)

126

null

포인트 (-83.10398317873478 42.300230911932886)

3

디트로이트

포인트 (39.74537850357592 47.21613017376512)

3

городской округ Батайск

POINT (-156.80986787192523 20.476673701778054)

3

하와이

포인트 (-73.94515332765877 40.70366442203522)

3

뉴욕시

포인트 (-83.10398317873478 42.300230911932886)

3

디트로이트

포인트 (-76.66873019188643 24.306286952923983)

2

새로운 프로비던스

포인트 (-3.0252167768776417 51.39245774131268)

2

카디프

포인트(-115.40993484668434 32.73126147687435)

2

멕시칼리 시

포인트 (41.790108773857355 50.302146775648)

2

Центральный район

포인트 (-73.88902732171118 45.57078813901171)

2

몬트리올

또한 가장 많이 발견된 지역은 null 입니다. 이것은 무엇을 의미할까요? 이 명령을 SQL의 '왼쪽 조인'에 비유했는데, 이는 공항에 대해 일치하는 도시 경계를 찾을 수 없는 경우 공항이 여전히 반환되지만 airport_city_boundaries 인덱스의 필드에 대한 null 값이 포함된다는 의미입니다. 일치하는 항목이 없는 공항이 125개( city_boundary), 일치하는 항목이 있는 공항이 1개( region 필드 null)인 것으로 나타났습니다. 그 결과 결과에서 region 이 없는 공항이 126개로 집계되었습니다. 사용 사례에서 모든 공항을 도시 경계와 일치시켜야 하는 경우, 빈틈을 메우기 위해 추가 데이터를 소싱해야 합니다. 두 가지를 결정해야 합니다:

• airport_city_boundaries 인덱스의 레코드에 city_boundary 필드가 없는 경우

• ENRICH 명령을 사용하여 airports 인덱스의 레코드가 일치하지 않는 레코드를 확인합니다(즉. 교차하지 않음)

Kibana Maps의 위치 기반 정보 데이터에 ES|QL 사용

Kibana는 지도 애플리케이션에서 공간 ES|QL에 대한 지원을 추가했습니다. 즉, 이제 ES|QL을 사용해 Elasticsearch에서 위치 기반 정보 데이터를 검색하고 그 결과를 지도에서 시각화할 수 있습니다.

레이어 추가 메뉴에 "ES|QL" 이라는 새로운 레이어 옵션이 있습니다. 지금까지 설명한 모든 지리공간 기능과 마찬가지로 "기술 미리보기" 에서 확인할 수 있습니다. 이 옵션을 선택하면 ES|QL 쿼리 결과를 기반으로 맵에 레이어를 추가할 수 있습니다. 예를 들어 전 세계의 모든 공항을 표시하는 레이어를 지도에 추가할 수 있습니다.

또는 airport_city_boundaries 인덱스의 다각형을 표시하는 레이어를 추가하거나, 각 지역에 몇 개의 공항이 있는지 통계를 생성하는 위의 복잡한 ENRICH 쿼리를 추가하는 것이 더 좋을 수 있습니다.

그 다음은 무엇일까요?

이전 위치 기반 정보 검색 블로그에서는 8.14부터 Elasticsearch에서 사용할 수 있는 ST_INTERSECTS 같은 기능을 사용하여 검색을 수행하는 데 중점을 두었습니다. 이 블로그에서는 이러한 검색에 사용한 데이터를 가져오는 방법을 설명합니다. 하지만 Elasticsearch 8.15에는 특히 흥미로운 기능이 추가되었습니다. ST_DISTANCE 효율적인 공간 거리 검색을 수행하는 데 사용할 수 있으며, 다음 블로그의 주제는 이 기능에 관한 것입니다!