TSDS와 ILM의 만남: 늦게 도착하는 데이터를 거부하지 않는 시계열 데이터 스트림 설계

최근 한 고객의 메트릭 클러스터를 '모든 데이터를 hot 티어에 두는' 구조에서 hot/cold/frozen 아키텍처로 전환했습니다. 이미 수십 번은 해 본 익숙한 작업이었습니다. 그런데 몇 분 만에 Logstash에서 데이터가 더 이상 진행되지 않았습니다.

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는 메트릭 워크로드에 매우 효과적으로 작동합니다.

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