Elastic Workflows란?
Elastic Workflows는 Elasticsearch 플랫폼 환경 내에서 직접 실행되는 네이티브 자동화 엔진(Native Automation Engine)입니다.
기존의 로그 수집, 이상 탐지(Alerting), 사후 대응에 필요했던 외부 파이프라인(SOAR, n8n, Tines, 외부 스크립트 등)에 대한 의존도를 최소화하고, 데이터가 존재하는 스토리지 레이어에서 즉각적인 연산과 대응 조치를 수행할 수 있도록 설계되었습니다.
특히 정형화된 규칙 기반(Rule-based) 자동화와 최신 Agentic AI(에이전트 기반 자율 추론) 역량을 단일 워크플로우 파이프라인 안에서 결합할 수 있어, Observability 및 보안 Security 운영 효율을 극대화합니다.
기존 방식 vs Elastic workflows 비교
기존 방식 : 전통적인 자동화 아키텍처는 데이터 저장소와 실행 엔진이 분리되어 있어 발생하는 '데이터 이동(Data Gravity)' 비용과 보안 위협이 가장 큰 걸림돌이었습니다.
•
문제점 : 자동화를 위해 데이터를 밖으로 빼내야 하므로 네트워크 비용이 발생하고, 자격 증명(Credentials) 노출 위험이 크며, API 속도 제한(Rate-limiting) 및 동기화 지연 문제가 발생합니다.
Elastic Workflows : 네이티브 인데이터(In-Data) 아키텍처 (Co-located)
•
워크플로우 엔진이 Elasticsearch 클러스터 내부 프로세스로 동작합니다. 데이터가 보관된 물리적/논리적 영역 내에서 연산이 일어나기 때문에, 데이터 이동이 불필요하며 극도로 안전하고 빠른 실행이 가능합니다.
항목 | 기존 외부 자동화 방식 (외부 SOAR / 서드파티 파이프라인) | Elastic Workflows (Native 방식) |
데이터 처리 위치 | 외부 시스템으로 데이터 Export/ETL 필요 | Elasticsearch 내부에서 Native 인-플레이스 처리 |
네트워크 & 지연시간 | API Polling 및 대용량 전송으로 인한 레이턴시 발생 | 데이터 로컬리티(Data Locality) 확보로 실시간 처리 가능 |
보안 및 규정 준수 | 시스템 간 API 토큰 관리 및 데이터 외부 반출 위험 | 클러스터 내부 보안 컨텍스트(RBAC/Document-level security) 공유 |
운영 복잡도 | 복수의 플랫폼 모니터링, 버전 호환성 관리 부담 | 선언형(YAML) 기반 단일 플랫폼 관리 |
AI 결합성 | 단순 챗봇 호출 또는 별도 LLM 게이트웨이 파이프라인 구축 필요 | Elastic Agent Builder와의 직접 상호작용 및 양방향 Tool 연동 |
핵심 아키텍처 및 메커니즘
① 네이티브 인데이터 컨텍스트 (In-Data Contextualization)
•
메커니즘: 워크플로우가 실행될 때, 별도의 쿼리 파이프라인을 구축할 필요 없이 클러스터 내부 메모리 상에서 데이터 및 보안 컨텍스트를 즉시 공유합니다.
•
아키텍처적 이점: 외부 자동화 도구는 인증 정보(API Key)를 저장소와 엔진 양쪽에 설정해야 하지만, Elastic Workflows는 Elasticsearch의 기존 역할 기반 액세스 제어(RBAC) 및 보안 모델을 그대로 상속받습니다. 즉, 별도의 권한 동기화 설계가 필요 없습니다.
② YAML 기반 선언적 상태 머신 (Declarative State Machine)
•
워크플로우는 절차형 코드가 아닌 선언적(Declarative) YAML로 정의되며, 이는 내부적으로 안정적인 상태 머신(State Machine)으로 변환되어 실행됩니다.
# 워크플로우 선언 예시 (콘셉트 구조)
id: "auto-remediation-flow"
trigger:
event: "elasticsearch.alert"
query: "error.class: 'OutOfMemoryError'"
steps:
- id: "analyze_logs"
action: "elasticsearch.search"
params:
indices: "logs-*"
- id: "notify_slack"
action: "connectors.slack.send"
params:
message: "OOM 경고 발생! 분석 데이터와 함께 담당자 전송"
JavaScript
복사
•
메커니즘:
◦
상태 보존(Durability): 각 단계(Step)의 실행 결과와 중간 상태가 클러스터 내부에 분산 저장되어, 노드 장애가 발생하더라도 작업이 손실되지 않고 중단된 지점부터 다시 시작(Failover)됩니다.
◦
컴포지빌리티(Composability): 하나의 워크플로우가 다른 워크플로우를 서브루틴으로 호출하거나, 외부에서 호출 가능한 '도구(Callable Tool)' 인터페이스로 추상화될 수 있습니다.
③ 이벤트 구동형 리액티브 루프 (Event-Driven Reactive Loop)
•
메커니즘: 실시간 인덱싱되는 데이터 변경 감지(Data Watchers), 클러스터 내부 경보(Alerting Engine), 그리고 외부 웹훅(Webhook) 인입을 단일 이벤트 버스(Event Bus)에서 처리합니다.
•
동작 순서:
1.
Event Capture: 특정 인덱스에 장애 패턴 로그가 인덱싱됩니다.
2.
Evaluation: 실시간 룰 엔진이 해당 이벤트를 트리거 조건과 매칭합니다.
3.
Execution: 가장 적합한 노드에 워크플로우 실행 스레드가 할당되어 비동기(Asynchronous)로 단계를 수행합니다.
AI Agent와의 오케스트레이션 메커니즘
Elastic Workflows 아키텍처의 진가는 Elastic Agent Builder(AI 에이전트)와 결합할 때 발휘됩니다.
•
하이브리드 자동화 아키텍처:
◦
AI 에이전트 (비결정론적 추론): 상황을 파악하고 대안을 구상하는 '뇌' 역할을 수행합니다.
◦
Workflows (결정론적 실행): 정해진 시퀀스대로 완벽하고 일관되게 행동하는 '손과 발' 역할을 수행합니다.
•
AI 에이전트가 예상치 못한 행동을 함부로 하지 못하도록, 실제 인프라 제어나 위험한 액션은 엄격한 승인 루프 및 규칙이 정의된 Workflows를 거쳐서만 실행되도록 설계할 수 있습니다.
다양한 Workflow Connector 및 Template Library 제공
•
•
직무별 주요 활용 사례
보안 분석가 (Security Analysts)
•
반복적인 수동 분석 작업을 줄이고 경보 피로(Alert Fatigue)를 해결합니다.
•
경보가 발생하면 네이티브 워크플로우가 자동으로 데이터를 수집하고 호스트 격리, 티켓 생성 등의 표준 대응 프로세스를 실행합니다.
•
분석가는 데이터가 보관된 플랫폼을 벗어나지 않고도 AI 에이전트를 호출해 정밀 조사를 가속화할 수 있습니다
서비스 신뢰성 엔지니어 (SREs)
•
인프라 장애나 성능 저하가 발생했을 때 자동 복구(Autoremediation) 시나리오를 가동할 수 있습니다
•
예를 들어, 특정 서비스에서 에러율이 급증하면 관련 로그를 분석하고 자동으로 백업 인스턴스를 기동하거나 서비스를 재시작한 뒤 Slack/Jira 등으로 결과를 공유하는 흐름을 무중단으로 자동화합니다
️상세 활용 시나리오 (Use Cases)
시나리오 : Elastic Security Defend에서 탐지된 이벤트에서 의심스러운 file이 발견 됨.Elastic Security Alert 생성 시, VirusTotal에서 SHA256 대조 후 Elastic case 생성까지 자동으로 진행하는 Workflow
name: Alert Triage Playbook
description: Enriches alerts, checks threat intel, creates a case, and notifies the team.
enabled: true
tags:
- security
- triage
triggers:
- type: alert
steps:
- name: check_virustotal
type: virustotal.scanFileHash
connector-id: "my-virustotal"
with:
hash: "{{ event.alerts[0].file.hash.sha256 }}"
on-failure:
retry:
max-attempts: 2
delay: 3s
continue: true
- name: related_alerts
type: elasticsearch.esql.query
with:
query: |
FROM .alerts-security*
| WHERE host.name == "{{ event.alerts[0].host.name }}"
| WHERE @timestamp > NOW() - 24 hours
| STATS
alert_count = COUNT(*),
rules_triggered = VALUES(kibana.alert.rule.name),
users_involved = VALUES(user.name)
format: json
- name: check_malicious
type: if
condition: steps.check_virustotal.output.stats.malicious > 5
steps:
- name: create_case
type: kibana.createCase
with:
title: "Malware Detected: {{ event.alerts[0].file.hash.sha256 }}"
description: |
Confirmed malicious file detected on {{ event.alerts[0].host.name }}.
**Detection:** {{ event.rule.name }}
**User:** {{ event.alerts[0].user.name }}
**VirusTotal:** {{ steps.check_virustotal.output.stats.malicious }} engines flagged this file
**Related alerts (24h):** {{ steps.related_alerts.output.values[0][0] }}
alerts from {{ steps.related_alerts.output.values[0][1] | size }} rules
owner: securitySolution
severity: high
tags:
- automation
- malware
settings:
syncAlerts: false
connector:
id: none
name: none
type: ".none"
fields: null
JavaScript
복사
Workflow 실행 결과
•
file.hash.sha256 값 입력
•
check_virustotal step에서 alert에서 탐지된 sha256 값을 사용하여 connector로 연동된 virustotal api를 사용하여 값 대조
•
탐지된 event의 sha256값을 대조한 결과를 Case에 자동으로 생성
참고 자료
황하라 프로
안녕하세요 반갑습니다. Elasticsearch&Opensearch 기술지원 업무를 담당하고 있어요 