트위터에서 공유하기
링크드인에서 공유하기
페이스북에서 공유하기
이메일로 공유하기
인쇄하기
Elastic Platform은 오랫동안 검색 사용 사례 및 머신 생성 데이터를 위한 분석 시스템으로 잘 알려져 있습니다. 분석은 데이터를 수집된 대로 처리하는 데 초점을 맞추고 있으며, 이 지점에서 Elasticsearch에서 색인되는 데이터를 최적으로 구조화하는 방법에 중요한 생각을 하게 됩니다. Kibana는 Elasticsearch 집계를 공개하고 이를 사용하여 대화형 대시보드, 시각화 및 경보를 생성합니다.
그러나 Elastic Platform이 검색, 보안, Observability 및 일반 분석 플랫폼으로 널리 채택됨에 따라, 분석가 사용자는 데이터를 수집한 대로 가져와, 수집 후 조사 필요에 맞게 변환하고, 기본 Elasticsearch 인덱스 데이터에서 인사이트를 얻을 수 있는 기능이 필요합니다. 분석가 사용자는 간결하고 통합적이며 효율적인 워크플로우가 필요합니다. 이러한 워크플로우는 UI 컨텍스트 전환이 거의 또는 전혀 없는 단일 쿼리 식을 통해 검색, 필터링, 집계 및 변환을 수행하는 풍부하고 표현적인 쿼리에 의해 가능합니다.
이러한 과제를 해결하기 위해 Elastic 팀은 현재 Elasticsearch Query Language(ESQL)를 개발하고 있습니다. ESQL은 Elastic 사용자에게 데이터를 조회할 수 있는 유연하고 강력하며 강력한 쿼리 식 언어를 제공합니다. 또한 ESQL은 Elasticsearch의 분석 및 데이터 처리 기능을 근본적으로 변환하고 확장하는 수집 후 처리 기능을 갖춘 우수한 쿼리 UX를 제공합니다.
새로운 쿼리 및 집계 컴퓨팅 아키텍처
ESQL은 언어 그 이상입니다. Elasticsearch 내의 새로운 컴퓨팅 기능에 대한 상당한 투자를 의미합니다. ESQL의 기능 및 성능 요건을 모두 충족하려면 완전히 새로운 컴퓨팅 아키텍처를 구축해야 합니다. ESQL 검색, 집계 및 변환 기능은 Elasticsearch 자체 내에서 직접 실행됩니다. 쿼리 식은 실행을 위해 QueryDSL로 변환 컴파일되지 않습니다. 오히려, Elastic은 Elasticsearch 내에서 ESQL 기능에 대한 기본 지원을 구축했습니다.
ESQL은 서로 다른 역할과 다양한 기술 수준을 가진 사용자들에게 분산 컴퓨팅 기능을 도입합니다. 이러한 컴퓨팅 기능을 통해 ESQL은 몇 가지 주요 방법으로 사용자 워크플로우를 단순화할 수 있습니다.
ESQL을 사용하면 다음과 같은 이점이 있습니다.
- 우수한 쿼리 UX 활용: ESQL 쿼리 식은 복잡한 분석 및 데이터 처리를 지원합니다. 그리고 쉽게 배우고, 읽고, 공유할 수 있습니다.
- Elasticsearch의 필터링, 집계 및 변환 기능을 하위 쿼리 및 조회 기능과 함께 사용할 수 있으며, 새로운 Elasticsearch 컴퓨팅 및 데이터 처리 기능을 사용할 수 있습니다.
- Discover, Kibana Lens 및 Elastic Solutions에서 Kibana 전반에 걸쳐 ESQL을 사용하여 원활한 워크플로우를 제공합니다. ESQL 쿼리를 시각화하고 대시보드 또는 쿼리로 팀과 공유하며 쿼리를 사용하여 사용자 정의 경보를 생성할 수 있습니다.
ESQL 사용 방법
ESQL은 파이프로 구분된 일련의 명령을 통해 사용자가 Elasticsearch 데이터를 처리하는 파이프 쿼리 언어입니다. 한 명령의 출력은 다음 명령이 논리적 데이터 파이프라인을 정의하기 위한 입력이 됩니다. ESQL 식은 선형적이고 논리적이며 쉽게 읽을 수 있습니다. 모든 경험 수준의 분석가가 작성, 사용 및 수정할 수 있을 정도로 간단합니다. 간단한 예는 다음과 같습니다.
search index_name
| eval field_c = (field_a + field_b)
| sort field_c desc위의 식은 인덱스에서 모든 데이터를 검색하여 각 레코드에 대해 필드 A와 필드 B의 합인 새 필드 C를 만듭니다. 마지막으로 결과는 필드 C에 정렬됩니다.
보안을 위해 ESQL 사용
ESQL은 보안 분석가가 임시 위협 헌팅을 할 때 특히 유용합니다. 분석가는 로그 데이터를 쿼리하여 “powershell.exe”에 의해 생성된 고유한 프로세스를 보여주고 명령줄 인수의 스트링 길이를 기준으로 정렬하는 것으로 시작할 수 있습니다.
from winlog
| where host.os.family == ‘windows’
| where process.name == "powershell.exe"
| unique process.command_line
| sort len(process.command_lin) desc
| limit 3host.os.family | process.name | process.command_line |
windows | powershell.exe | (get-acl \\smb_file\share).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags -auto |
windows | powershell.exe | Get-ADComputer -property * -filter { ipv4address -eq ‘172.16.0.3’} |
| windows | powershell.exe | Get-ADGroupMember -identity Helpdesk |
결과에 따르면 파일 시스템 정보와 Active Directory에 대한 정보를 검색하는 데 PowerShell이 사용되고 있습니다. 이는 정상적인 시스템 동작일 수 있지만 악의적인 활동을 나타낼 수도 있습니다.
추가 조사를 위해, 쿼리가 Active Directory 및 파일 시스템 관련 명령줄 인수를 필터링하도록 수정되었습니다. 그런 다음 process.command_line 및 그룹의 고유 값을 hostname별로 카운트합니다.
from winlog
| where host.os.family == ‘windows’
| where process.name == "powershell.exe"
| where process.command_line in (‘*get-acl*’, ‘*Get-AD*’)
| stats count(unique process.command_line) as cl_count by hostname
| sort cl_count desc
| limit 3cl_count | hostname |
155 | host2 |
74 | host1 |
| 67 | host3 |
결과는 host2가 다른 호스트보다 파일 및 AD 관련 명령줄 인수를 호출하는 powershell 프로세스가 훨씬 더 많다는 것을 보여줍니다. 분석가는 ESQL 쿼리 식을 계속 수정하고 확장하여 host2에 의한 악의적인 활동이 있는지 확인할 수 있습니다. 이 조사는 궁극적으로 위협 벡터에 대한 이해로 이어지며, 이를 통해 개선 조치를 취할 수 있고 향후 이 위협을 예방할 수 있는 방법을 파악할 수 있습니다.
검색을 위해 ESQL 사용
Elasticsearch는, 아시다시피, 검색을 위한 것이고 앞으로도 그럴 것입니다. 따라서 ESQL은 오랫동안 Elasticsearch의 일부였던 검색, 정확도 및 순위 지정 기능을 지원합니다. ESQL을 사용하면 이러한 검색 기능의 모든 역량을 아주 손쉽게 이용할 수 있습니다.
문서 수에 따라 정렬된 장르 필드의 상위 3개 용어로 버킷을 생성하려는 단순 용어 집계를 고려해 보세요.
from music
| stats terms((genre), 3, doc_count, unwind)
| sort doc_count descdoc_count | term |
6 | electronic |
3 | rock |
| 2 | jazz |
날짜 히스토그램과 같은 버킷 집계도 지원됩니다. 이 쿼리에서는, 가격 필드를 기준으로 50개의 간격을 사용하여 판매 지수에서 히스토그램을 만듭니다.
from sales
| stats histogram(price, 50)
| sort bucket descdoc_count | bucket |
3 | 200 |
2 | 150 |
| 0 | 100 |
| 1 | 50 |
| 1 | 0 |
또한 ESQL을 사용하면 현재 파이프라인 집계와 유사한 방식으로 데이터를 매우 간편하게 처리할 수 있습니다. 예를 들어, 도함수의 도함수를 계산하려 한다고 가정해 봅시다. 그 가장 간단한 형태는 다음과 같습니다.
from sales
| eval (stats derivative(sales)) as fist_der
| eval (stats derivative(first_der)) as second_derObservability를 위해 ESQL 사용
사이트 안정성 엔지니어(SRE)는 방대한 양의 데이터를 처리하는 데 어려움을 겪고 있습니다. SRE는 이 데이터를 사용하여 시스템 가동 중단 시간 및 기타 관련 문제를 예방하고 해결할 책임이 있습니다. SRE는 중요한 추적, 로그 및 메트릭 데이터를 생성하는 수천 개의 시스템을 모니터링합니다. 그런 다음 이 데이터는 SRE가 문제를 식별하고 향후 시스템 또는 애플리케이션 중단을 방지하기 위한 조치를 구현하는 데 사용됩니다. 따라서 SRE의 경우, 여러 데이터 세트의 결합된 이해를 통해 시스템 동작을 분석하는 기능이 필수적입니다.
Observability 수집 데이터는 본질적으로 예측할 수 없습니다. ESQL은 데이터를 상호 연관시키고 재구성하여 시스템 및 애플리케이션 동작에 대한 더 깊은 인사이트를 얻을 수 있는 수단을 SRE에게 제공합니다. 문제가 발견된 후 사후 분석을 수행할 수 있는 능력을 확장하며, 이 귀중한 인사이트는 향후 유사한 문제를 방지하는 데 직접적으로 사용됩니다.
아래의 데이터 처리 섹션에서는 Observability 예를 사용해 보겠습니다.
새로운 Elasticsearch 컴퓨팅 기능을 통해 완전히 새로운 데이터 처리 방법 탐색
ESQL 식은 인덱스 데이터에서 인사이트를 끌어내는 데 유연하고 강력합니다. 그러나 이러한 식 이면에 있는 대부분의 작업은 Elasticsearch 자체에서 발생합니다. Elastic은 ESQL에 노출된 데이터 프로세스 기능을 지원하기 위해 새로운 컴퓨팅 엔진을 구축했습니다. 가장 주목할 만한 것은 향상된 수집 후 데이터 처리, 중간 데이터 상태, 조회 기능 및 하위 쿼리입니다.
ESQL은 Elasticsearch의 새로운 컴퓨팅 및 처리 기능에 전적으로 의존합니다. ESQL은 변환 컴파일을 통해 해석 및 실행되지 않습니다. 오히려, ESQL은 Elasticsearch 자체 내에서 전체적으로 처리됩니다.
수집 후 처리
Kibana 전역에 통합된 ESQL은 가장 일반적이고 유용한 집계 및 예상에 빠르고 쉽게 액세스할 수 있도록 합니다. 메트릭 데이터의 인덱스를 가지고 작업하는 것을 상상해 보세요. 분석가는 수집된 데이터에 대해 비율을 계산하거나 집계를 수행하려고 할 수 있습니다. ESQL을 사용하면 기본 인덱스에서 이를 쉽게 추출할 수 있습니다.
from network_flow
| stats count(*) filter (where transport == ‘udp’) as udp_count
| stats count(*) filter (where transport == ‘tcp’) as tcp_count
| eval total_transport_events = udp_count + tcp_count
| eval udp_per_total = udp_count / total_transport_eventsESQL은 기본 인덱스를 쉽고 빠르게 집계 및 변환할 수 있도록 함으로써 분석가들이 데이터의 형태를 만들고 데이터를 탐색할 때 중요한 새로운 인사이트를 제공합니다. 분석가들은 ESQL을 통해 광범위한 기본 인덱스에서 새로운 구조와 인사이트를 도출할 수 있기 때문에 이를 통해 데이터 수집을 단순화할 수 있습니다.
데이터 파이프라인 및 중간 데이터
ESQL 식을 지원하는 또 다른 핵심적인 부분은 중간 상태에서 데이터를 처리하는 것입니다. 서로 다른 파이프라인 단계를 통과할 때 데이터를 처리하고 수정할 수 있는 능력은 ESQL에 의해 노출되는 처리 능력의 핵심입니다.
다음 쿼리를 고려하여, 메트릭 인덱스를 검색하여 CPU 사용률이 가장 높은 5개의 호스트 이름을 찾아보세요.
from metrics
| stats max(system.process.cpu.total.pct) as max_cpu by hostname
| where max_cpu > .800 and hostname == '*web*'
| sort max_cpu desc
| limit 5이 데이터 파이프라인의 각 단계는 표 형식 출력을 생성합니다. 처음 from metrics 명령은 모든 인덱스 데이터를 검색합니다. 그런 다음 이 표는 system.process.cpu.total.pct에서 집계되고 hostname별로 그룹화되어, 결과적으로 고유한 표가 생성됩니다. 그 후에 이러한 표 형식 결과를 필터링하고 정렬하여 원하는 출력을 생성합니다.
max_cpu | hostname |
.989 | 1webapache |
.978 | 1websftp |
| .964 | nfsweb |
| .955 | 2webredis |
| .943 | web_staging_primary |
그런 다음 이 출력을 시각화 또는 경보의 기준으로 사용할 수 있습니다.
조회 기능 및 하위 쿼리
또한 ESQL은 Elasticsearch에 조회 및 하위 쿼리 기능을 도입합니다.
ESQL은 별도의 조회 인덱스에서 값을 조회할 수 있습니다. 이것은 쿼리 시 결과를 강화하는 데 가장 일반적으로 사용됩니다. 조회는 지정된 키를 사용하여 외부 인덱스에서 필드를 반환한다는 점에서 SQL 왼쪽 조인과 유사합니다.
예를 들어, 조회 인덱스에는 고유한 키로 식별된 시스템 사용자에 대한 정보가 들어 있습니다. ESQL 식은 이러한 인덱스의 데이터를 검색하여 이 외부 데이터를 결과로 반환할 수 있습니다. 이 쿼리는 access_logs 인덱스의 결과를 user_info_lookup 인덱스의 사용자 데이터로 강화해 줍니다. 특히, 조회 인덱스의 이메일 및 상태 필드가 반환됩니다.
from access_logs where user != 'root'
| lookup user_info_lookup['email', 'state'] on useriduserid | [ … access_logs … ] | state | userid | |
3455 | … | bob | NY | 3455 |
하위 쿼리를 사용하면 다른 쿼리 내의 인수로 고유한 쿼리를 포함할 수 있습니다. 예를 들어, SRE는 동일한 인덱스에 대한 쿼리에서 인수로 집계를 사용하려고 할 수 있습니다. 여기서 SRE는 총 로그인 수를 사용하여 특정 사용자의 로그인 비율(%)을 계산합니다.
from user_login where userid = 1234
| eval stats count(*) as 1234_logins
| eval total_logins = [from logs where userid = *| stats count(*) as total_logins]
| eval round((1234_logins / total_logins), 2) as 1234_pct조회 기능 및 하위 쿼리를 사용함으로써 분석가와 SRE는 Elasticsearch를 모두 활용하여 엄청나게 풍부한 데이터 구조를 생성하고 Elasticsearch의 데이터에서 새로운 인사이트를 얻을 수 있습니다.
ESQL은 Elastic Search Platform에서 데이터와 상호 작용하는 방식을 근본적으로 변경하고 개선합니다. ESQL은 대용량 데이터 세트를 신속하게 변환 및 결합하고, 방대한 양의 데이터를 검색, 필터링 및 처리하며, 궁극적으로 응답 및 해결 시간을 단축하는 강력한 기능을 통해 데이터의 가치를 극대화합니다. 이를 실제 작업에서 활용하시는 걸 보고 싶네요!
이 분석적인 여정에 참여해 주세요
ESQL, 변환 및 조인, 다단계 쿼리 사용에 관심과 기대가 크신가요? 저희도 그렇습니다. Elastic 팀은 계속해서 이러한 기능을 개발하고 출시를 위해 준비하고 있습니다. 더 많은 뉴스를 눈여겨 봐주시기 바랍니다.
다른 사람들보다 먼저 이 솔루션을 사용해 보는 것에 관심이 있으신가요? 토론 포럼이나 Elastic 커뮤니티 Slack 채널을 통해 Elastic에 연락하실 수 있습니다. Elastic의 새로운 쿼리 언어, 컴퓨팅 엔진 및 쿼리 기반 조사 워크플로우의 방향을 구체화하는 데 도움이 될 수 있도록 여러분의 피드백을 부탁드립니다.
이 포스팅에 설명된 기능의 릴리즈 및 시기는 Elastic의 단독 재량에 따릅니다. 현재 이용할 수 없는 기능은 정시에 또는 전혀 제공되지 않을 수 있습니다.
공유하기
트위터에서 공유하기
링크드인에서 공유하기
페이스북에서 공유하기
이메일로 공유하기
인쇄하기