[opensearch]Anomaly detection(이상감지)

startingfindmistake·2025년 12월 17일
  1. Detector details
    • Name
    • Description
  2. Data Source
    • Clusters
    • Index
    • Data filter
  3. Timestamp
    • Timestamp field
  4. Operation settings
    • Enable custom result index
  5. Custom result index
  6. Features
    • Feature name
    • Feature state
    • Find anomalies based on
    • Aggregation method
    • Field
    • Anomaly criteria
  7. Categorical fields
    • Enable categorical fields
  8. Advanced settings
  9. Sample anomalies
  10. Real-time-detection
  11. Historical analysis detection


  1. Detector details
    • Name
    • Description
  2. Data Source
    • Clusters
    • Index
    • Data filter
  3. Timestamp
    • Timestamp field
  4. Operation settings
    • Enable custom result index
  5. Custom result index
  6. Features
    • Feature name
    • Feature state
    • Find anomalies based on
    • Aggregation method
    • Field
    • Anomaly criteria
  7. Categorical fields
    • Enable categorical fields
  8. Operation settings
    • Interval
    • Frequency
    • Window delay
    • History
  9. Advanced settings
    • Shingle size
    • Sparse data handling
  10. Real-time-detection
    • start real-time detector automatically
  11. Historical analysis detection
    • Run historical analysis detection

OpenSearch에서 이상치란 시계열 데이터에서 발생하는 비정상적인 동작 변화를 의미한다.

시각화 및 대시보드와 같은 기존 방법으로는 이상 징후를 파악하기 어려울 수 있다.

고정된 임계값을 기반으로 알림을 설정하는 것도 가능하지만, 이 접근 방식은 해당 분야에 대한 사전 지식이 필요하며, 자연스러운 성장이나 계절적 추세를 보이는 데이터에는 적응하지 못할 수 있다.



이상 탐지 기능은 랜덤 컷 포레스트(RCF)알고리즘을 사용하여 OpenSearch 데이터의 이상 징후를 거의 실시간으로 자동 감지합니다.

RCF는 비지도 학습 알고리즘으로, 입력 데이터 스트림의 개략적인 형태를 모델링하여 각 데이터 포인트에 대한 이상 등급 과 신뢰도 점수를 계산합니다.

이러한 값은 이상 징후를 정상적인 변동과 구분하는 데 사용된다.

OpenSearch 대시보드에서 이상탐지 시작하기

1단계: 검출기 정의

  • 탐지기는 각각 개별적인 이상 탐지 작업입니다.
  • 여러 개의 탐지기를 정의할 수 있다
  • 모든 탐지기는 동시에 실행될 수 있고
  • 각각 다른 소스의 데이터를 분석할 수 있다.

2단계: 데이터 소스

데이터 선택창 에서 인덱스 드롭다운 메뉴 에서 하나 이상의 소스를 선택하여 데이터 소스를 지정합니다.

  1. 데이터 소스 및 인덱스(Data Source & Index)
    이 단계는 OpenSearch가 분석하거나 시각화할 데이터의 범위를 지정하는 가장 기초적인 단계이다.
  • 인덱스(Index)
    - OpenSearch에서 데이터가 저장되는 논리적인 단위 입니다. 관계형 데이터베이스(RDBMS)의 '테이블'과 유사합니다.
    -ex) web-logs-2023-10-01(특정 날짜의 로그가 담긴 인덱스)
  • 인덱스 패턴(Index Pattern)
    - 여러 개의 인덱스를 하나로 묶어서 검색하거나 분석하기 위한 규칙 입니다.
    • 시계열 데이터(로그 등)는 보통 날짜별로 인덱스가 생성되므로, 이를 한꺼번에 조회하기 위해 사용합니다.

인덱스 패턴에 와일드카드(*)를 사용할 수 있습니다.
공식문서에 따르면, 와일드 카드(*) 는 여러 문자를 대체하는 기호 입니다.
이를 사용하여 이름이 유사한 여러 인덱스를 하나의 그룹으로 묶을 수 있습니다.

  • 설정 예시
    - 보유한 인덱스들
    server-log-2025.01.01, server-log-2025.01.02, server-log-2025.01.03,....
    • 입력해야 할 패턴: server-log-*
    • 결과: server-log-로 시작하는 모든 날짜의 인덱스가 이 데이터 소스에 포함되어 분석 대상이 됩니다.

참조:OpenSearch는 Multi-target syntax를 지원하여, 쉼표,로 구분된 목록이나 와일드카드*를 통해 여러 인덱스로 요청을 라우팅 합니다.

데이터 필터

이 기능은 선택한 인덱스(또는 패턴)안에 있는 데이터 중,
분석에 불필요한 데이터를 미리 걸러내는(Filtering)역활을 한다.

  1. 노이즈 감소(Accuracy): 분석 목적과 상관없는 데이터가 섞여 있으면 이상 탐지나 보안 분석의 정확도가 떨어집니다.
  2. 성능 최적화(Performance): 불필요한 데이터를 미리 제외하면 OpenSearch가 처리해야 할 데이터 양이 줄어들어 검색 및 분석 속도가 빨라진다.

이 부분은 보통 OpenSearch Query DSL (Domain Specific Language) 형태나 간단한 KQL(Kibana Query Language) 필터를 사용한다.

  • 상황 예시: 웹 서버 로그 web-logs-*를 분석하여 공격 시도를 찾고 싶습니다. 하지만 로그에는 정상적인 접속 기록에 200ok가 99% 입니다.
  • 필터 적용:
    - 정상 응답 코드는 제외하고 싶다면: response_code가 200이 아닌 것만 필터링.
    • 특정 에러만 보고 싶다면: tags 필드에 error또는 failure가 포함된 것만 필터링.

Query DSL

{
  "bool": {
    "filter": [
      {
        "term": {
          "status": "error"
        }
      }
    ]
  }
}

위와 같이 설정하면, 전체 로그 중 status가 error인 데이터만 쓱 뽑아서 이 "데이터 소스"로 정의하겠다는 의미 입니다.



  • 인덱스, 인덱스 패턴 또는 별칭을 선택할 수 있다.<
    - 탐지기는 원격 인덱스를 사용할 수 있으며, cluster-name:index-name패턴을 사용하여 해당 인덱스에 액세스할 수 있습니다.
    • 클러스터와 인덱스를 직접 선택할 수 있다.


Feature란 무엇인가?

피처는 이상 탐지 모델(Random Cut Forest 알고리즘)이 학습하고 감시해야 할 핵심 지표입니다. 쉽게 말해, 인공지능에게 "이 데이터의 흐름을 지켜보고 이상하면 알려줘"라고 지정하는 대상입니다.

  • 최대 5개 제한
  • 공식 문서에 따르면, 피처가 너무 많으면 모델의 정확도가 떨어지는 Curse of Dimensionality 현상이 발생하고, 계산 부하가 급증합니다.
  • 따라서 서로 상관관계가 적고 비즈니스에 치명적인 핵심 지표 1 ~ 3개를 선정하는 것이 가장 성능이 좋습니다.


집계 방법(Aggregation Method)
이상 탐지기는 실시간으로 들어오는 로그 하나하나를 분석하는 것이 아니라,
설정한 탐지 주기(Detector Interval, 예 1분, 5분) 동안의 데이터를 모아서 하나의 값으로 요약(집계)한 뒤 분석합니다.

메서드영문 표기설명추천 사용 사례
개수count()해당 주기 동안 발생한 로그의 총 개수를 셉니다
(필드 선택 불필요)		- 트래픽 폭주(DDoS)탐지
- 로그 유실 감지(0에 가까워질 때)
평균average()선택한 필드 값들의 평균을 계산합니다.
전반적인 추세를 보는 데 가장 안정적 입니다.		- 평균 응답 속도(Latency)
- CPU/메모리 평균 사용률
합계sum()선택한 필드 값들을 모두 더합니다- 총 데이터 전송량(Bytes)
주문총액(이커머스 등)
최소/최대min()/max()해당 주기 내의 최솟값 또는 최댓값을 찾습니다.
노이즈(뒤는 값)에 민감할 수 있습니다.		- 디스크 여유 공간(min)(갑자기 0이 될 때)
- 최대 지연 시간(Max) (대부분 정산인데 하나가 엄청 느릴때)


이상 징후 기준(Find anomalies based on)
데이터를 가져오는 방식을 선택한다.

  • Field value(필드 값)
    • 가장 일반적인 방식이다. 인덱스에 저장된 숫자형(Numeric) 필드를 그대로 가져와서 집계합니다.
    • ex) cpu_usage, bytes_sent
  • Custom expression(사용자 지정 표현식):
    - 인덱스에 있는 필드를 그대로 쓰지 않고, 가공하거나 계산해서 쓰고 싶을 때 사용한다.
    - Painless Script 문법을 사용하여 JSON 쿼리를 작성합니다.
    - ex) 인덱스에는 total_memory와 free_memory만 있을 때,
    (total - freee) / total 계산식을 넣어 메모리 사용률 이라는 새로운 지표를 만들어 분석할 수 있습니다.

필드(Field)
집계할 대상이 되는 구체적인 데이터 항목을 선택한다.

  • 여기서는 반드시 숫자(Integer,Float,Long 등) 타입의 필드만 선택 가능합니다.
  • 문자열(Keyword)데이터(ex: ip주소, User ID)는 여기서 선택하는 것이 아니라, 나중에 설정할 Category Field에서 사용합니다.
  1. 범주형 필드 (Categorical Fields)란?
  • 개념:SQL의 GROUP BY와 유사합니다.
    전체 로그를 하나의 시계열로 보는 것이 아니라,
    선택한 필드의 값(Entity)마다 별도의 시계열을 생성하여 분석합니다.
  • Split a single time series into multiple time series의 의미
    • ex) 기능을 ON: "특정 IP 192.168.0.1에서만 에러가 늘었나요?(개별분석)
    • 기능을 OFF: "웹 서버 전체의 에러가 늘었나요?" (전체 합계 분석)
  • 효과: 전체 트래픽에 묻혀서 보이지 않던 특정 사용자의 이상 행동 이나 특정 서버 1대의 고장 을 정밀하게 잡아낼 수 있습니다.

제약 조건 및 필수 확인 사항
시스템 성능과 모델의 구조적 한계 때문에 제약 사항이 존재한다.

  • 범주형 필드를 늘릴수록 관리해야 할 모델의 수가 기하급수적으로 늘어납니다.
    • Region10개 x OS5개 = 50개의 모델 생성
  • 공식 문서는 성능 최적화를 위해 이 필드를 최대 2개로 제한하고 있다.


Only ip and keyword OpenSearch data types

  • 가능한 데이터 타입
    • ip: ip주소 (192.168.1.1)
    • keyword: 텍스트지만 분석되지 않은 완전 일치 문자열 (예) user_id, host_name, error_code)
  • 불가능한 데이터 타입: text(분석된 긴 문장), integer/float(연속된 숫자)등은 범주(Category)로 나누기에 적합하지 않아 사용할 수 없습니다.


생성 후 변경 불가

  • 한번 감지기(Detector)를 만들면, 내부적으로 각 카테고리(Entity)별로 모델을 생성하고 학습을 시작합니다.
  • 그래서 중간에 수정이 불가능 합니다.
상황범주형 필드 설정 예시분석 결과
DDoS 공격 감지client_ip전체 트래픽은 정상이지만,
특정 해커 ip 하나가 접속을 시도하는 것을 탐지
마이크로서비스 모니터링service_name전체 시스템은 괜찮은데, 결제 서비스(Payment)만 응답이 느려지는 것을 탐지
서버 하드웨어 장애host_name웹 서버 100대 중 web-03번 서버만 CPU가 튀는 것을 탐지

요약: 이 단계는 "전체를 뭉뜽그려 볼 것인가?(OFF) 아니면 "개별 타겟별로 쪼개서 볼 것인가?(ON) 결정 하는 단계




Advanced settings

이 설정은 이상 탐지 알고리즘(Random Cut Forest)가 과거의 데이터를 얼마나 참고해서 현재를 판단할지 를 결정하는 매우 중요한 파라미터 입니다.

Shingle Size란 무엇인가요?

  • 정의: 모델이 이상 여부를 판단하기 위해 한 번에 바라보는 과거 데이터 포인트(interval)의 개수
  • 비유: 영화를 볼 때, 정지 화면 1장만 보고 상황을 판단할지,아니면 연속된 8장의 필름 을 보고 흐름을 파악할지 정하는 것

기본값: 8개

  • 대부분의 시계열 데이터에서 가장 균형 잡힌 성능을 보입니다
  • 과거 8개의 데이터를 하나의 패턴으로 묶어서 인식하므로, 일시적인 노이즈는 무시하고 실질적인 패턴 변화를 감지하는 데 효과적이다.

작은값: 1 ~ 4개

  • 작은 값은 재현율을 높이지만 오탐도 늘어날 수 있습니다.
  • 특징: 과거 흐름을 거의 보지 않고, 현재 값 자체에 집중한다.
  • 장점:반응 속도가 매우 빠릅니다. 데이터가 갑자기 튀는 스파이크(Spike)형태의 이상 징후를 즉각 잡아냅니다.
  • 단점:(오탐 증가) 정사적인 작은 변동(노이즈)도 이상 징후로 차각하여 알람을 울릴 확률이 높습니다

큰 값은 신호의 노이즈를 무시하는 데 유용할 수 있습니다.

  • 특정: 긴 시간의 흐름을 봅니다
  • 장점: 단순한 값의 등락보다는 패턴의 깨짐을 감시합니다.
  • ex: 심장박동처럼 주기적으로 오르내리던 데이터가 갑자기 일직선이 될 때, 값 자체는 정상 범위라도 패턴이 깨졌으므로 이상으로 탐지합니다.
  • 단점:계산량이 많아지고, 반응이 다소 느려 질 수 있습니다.

요약
일반적인 경우 기본값 8을 그대로 두세요
즉각적인 스파이크 감지가 중요할때, 값을 조금 줄여 볼 수 있지만 4 오탐이 늘어날 각오를 해야 한다
복잡한 패턴 변화를 감지해야 할때: 값을 늘립니다.
하지만 60을 초과 할 수 없습니다.

Real-time detection

설정한 이상 탐지기(Detector)를 즉시 가동할지, 아니면 나중에 수동으로 켤지를 결정하는 마지막 단계이다.

실시간 탐지란 무엇인가?

  • OpenSearch가 설정된 간격(예:1분)마다 새로 들어오는 데이터를 지속적으로 읽어와서, 방금 설정한 알고리즘(RCF)을 통해 점수를 매기는 백그라운드 작업 입니다.
  1. 충분한 데이터를 수집해야 합니다.
    "To receive accurate... collect sufficient data" 문구는 콜드 스타트(Cold start) 과정을 설명합니다
  • 초기화 단계
    이상 탐지기를 처음 만들면, 이 모델은 '빈 뇌' 상태 입니다
  • 모델의 정확한 판단을 내리기 위해서는, 먼저 일정량의 데이터 (초기 샘플)를 관찰하여 평소 패턴(Baseline)을 학습하는 시간이 필요합니다.
  • 공식 문서에 따르면 데이터가 초기화되는 데 필요한 데이터 수는 설정(Shingle size 등)에 따라 다르지만,
    보통 수백 개에서 1000개 정도의 데이터 포인트가 지나가야 안정적인 탐지 결과를 내놓는다.
  1. 체크박스 설정 가이드
    ☑ Start real-time detector automatically (권장)
    동작: [Create] 버튼을 누르는 즉시 탐지 작업이 시작됩니다.

장점: 별도의 조작 없이 바로 초기 학습(Cold Start)에 들어가므로, 가장 빠르게 탐지 결과를 받아볼 수 있습니다.

대부분의 경우 이 옵션을 체크한 상태로 두시면 됩니다.

☐ 체크 해제 (수동 시작)
동작: 탐지기 '설정'만 저장되고, 실제로 데이터 분석은 시작하지 않습니다. 상태가 Disabled나 Stopped로 생성됩니다.

언제 사용하나요?

과거 데이터 분석(Historical Analysis)만 필요할 때: 실시간 감시는 필요 없고, 지난달 로그만 분석해보고 싶을 때 리소스 낭비를 막기 위해 끕니다.

유지보수 시간일 때: 지금 당장은 서버 점검 중이라 데이터가 엉망진창일 것이 예상되어, 점검이 끝난 후 깨끗한 데이터부터 학습시키고 싶을 때.

리소스 관리: 클러스터 부하가 심해 나중에 트래픽이 적을 때 켜고 싶을 때.



profile
startingfindmistake
도움이되었다면 그것으로 충분 합니다.
이전 포스트

mongodb

다음 포스트

AWS CLI 설치& 등록

0개의 댓글