데이터 계층

원본 보기

Elasticsearch 데이터 계층: hot, warm, cold, frozen 스토리지 설명

Elasticsearch는 성능, 비용, 접근성의 균형을 맞추기 위해 데이터를 스토리지 계층으로 구성합니다. 자주 접근하는 데이터를 위한 hot 계층부터 거의 조회하지 않는 데이터셋을 위한 frozen 계층까지, 각 계층은 고유한 하드웨어 및 스토리지 특성을 가집니다. 이 가이드에서는 시계열 데이터와 일반 콘텐츠 데이터 모두에 대해 계층 간 데이터 배치를 구성, 관리, 자동화하는 방법을 설명합니다.

각 데이터 계층은 Elasticsearch 클러스터에서 동일한 데이터 노드 역할과 해당 역할에 적합한 규모의 하드웨어 프로필을 공유하는 노드의 집합입니다. Elastic은 핫 스팟을 방지하기 위해 동일한 계층의 노드가 같은 하드웨어 프로필을 공유할 것을 권장합니다.

Serverless는 데이터 스토리지를 대신 관리합니다

Elastic Cloud Serverless는 클러스터 관리 작업을 추상화하여 워크로드에 따라 데이터 스토리지와 스케일링을 조정합니다. 일부 프로젝트 설정을 통해 데이터 저장 방식을 커스터마이징하고 데이터 성능을 조정할 수 있습니다.

사용하는 데이터 계층과 그 활용 방식은 데이터의 범주에 따라 달라집니다. 각 데이터 범주에는 다음 데이터 계층을 사용할 수 있습니다:

콘텐츠 데이터:

  • Content 계층 노드는 제품 카탈로그처럼 시계열이 아닌 인덱스의 인덱싱 및 쿼리 부하를 처리합니다.

시계열 데이터:

  • Hot 계층 노드는 로그나 메트릭 같은 시계열 데이터의 인덱싱 부하를 처리합니다. 가장 최근의, 가장 자주 접근하는 데이터를 보관합니다.
  • Warm 계층 노드는 접근 빈도가 낮고 거의 업데이트할 필요가 없는 시계열 데이터를 보관합니다.
  • Cold 계층 노드는 드물게 접근하고 일반적으로 업데이트하지 않는 시계열 데이터를 보관합니다. 공간을 절약하기 위해 검색 가능한 스냅샷의 완전 마운트 인덱스를 cold 계층에 보관할 수 있습니다. 이러한 완전 마운트 인덱스는 복제본이 필요 없으므로 일반 인덱스 대비 필요한 디스크 공간을 약 50% 줄여줍니다.
  • Frozen 계층 노드는 거의 접근하지 않고 절대 업데이트하지 않는 시계열 데이터를 보관합니다. Frozen 계층은 검색 가능한 스냅샷의 부분 마운트 인덱스만 저장합니다. 이를 통해 warm 계층 대비 최대 20배까지 스토리지 용량을 더욱 확장할 수 있습니다.
팁

Elasticsearch 노드의 성능은 기반 스토리지와 하드웨어 프로필의 성능에 의해 제한되는 경우가 많습니다. 하드웨어 프로필 예시는 Elastic Cloud의 인스턴스 구성을 참고하세요. 인덱싱과 검색을 위한 스토리지 최적화 권장 사항도 확인해 보세요.

중요

Elasticsearch는 데이터 계층 내 노드들이 동일한 하드웨어 프로필(CPU, RAM, 디스크 용량 등)을 공유한다고 가정합니다. 리소스가 균등하지 않은 노드로 구성된 데이터 계층은 핫 스팟 위험이 더 높습니다.

데이터 계층을 활용하는 방식은 데이터 범주에 따라 달라지는 경우가 많습니다:

  • 콘텐츠 데이터는 전체 데이터 수명 주기 동안 content 계층에 남아 있습니다.

  • 시계열 데이터는 성능, 복원력, 데이터 보존 요구 사항에 따라 온도가 낮아지는 데이터 계층(hot, warm, cold, frozen)을 순차적으로 거칠 수 있습니다.

    데이터 스트림 수명 주기 또는 사용자 정의 인덱스 수명 주기 관리를 사용해 이러한 수명 주기 전환을 자동화할 수 있습니다.

각 데이터 계층을 언제, 어떻게 사용해야 하는지 자세히 알아보세요.

Content 계층에 저장되는 데이터는 일반적으로 제품 카탈로그나 아티클 아카이브처럼 항목의 모음입니다. 시계열 데이터와 달리 콘텐츠의 가치는 시간이 지나도 비교적 일정하게 유지되므로, 오래되었다고 해서 성능 특성이 다른 계층으로 옮기는 것은 적절하지 않습니다. 콘텐츠 데이터는 일반적으로 데이터 보존 기간이 길고, 데이터가 얼마나 오래되었든 항목을 빠르게 조회할 수 있어야 합니다.

Content 계층 노드는 대개 쿼리 성능에 최적화되어 있습니다. IO 처리량보다 처리 성능을 우선시하여 복잡한 검색과 집계를 처리하고 결과를 빠르게 반환할 수 있습니다. 인덱싱도 담당하지만, 콘텐츠 데이터는 로그나 메트릭 같은 시계열 데이터만큼 높은 속도로 수집되지는 않습니다. 복원력 관점에서 이 계층의 인덱스는 하나 이상의 복제본을 사용하도록 구성해야 합니다.

Content 계층은 필수이며, 흔히 hot 계층과 동일한 노드 그룹 내에 배포됩니다. 시스템 인덱스를 비롯해 데이터 스트림에 속하지 않는 인덱스는 자동으로 content 계층에 할당됩니다.

Hot 계층은 시계열 데이터가 Elasticsearch로 들어오는 진입점이며, 가장 최근에 가장 자주 검색되는 시계열 데이터를 보관합니다. Hot 계층의 노드는 읽기와 쓰기 모두 빨라야 하므로 더 많은 하드웨어 리소스와 더 빠른 스토리지(SSD)가 필요합니다. 복원력을 위해 hot 계층의 인덱스는 하나 이상의 복제본을 사용하도록 구성해야 합니다.

ILM 정책은 hot 단계에서 searchable_snapshot 작업을 사용할 수도 있으며, 이 경우 hot 계층은 일반 인덱스 대신 완전 마운트된 검색 가능한 스냅샷 인덱스를 보관합니다.

Hot 계층은 필수입니다. 데이터 스트림에 속하는 새 인덱스는 자동으로 hot 계층에 할당됩니다.

시계열 데이터는 hot 계층에 최근 인덱싱된 데이터보다 조회 빈도가 낮아지면 warm 계층으로 이동할 수 있습니다. Warm 계층은 일반적으로 최근 몇 주간의 데이터를 보관합니다. 업데이트는 여전히 허용되지만 빈도는 낮을 가능성이 큽니다. Warm 계층의 노드는 대체로 hot 계층만큼 빠를 필요는 없습니다. 복원력을 위해 warm 계층의 인덱스는 하나 이상의 복제본을 사용하도록 구성해야 합니다.

시계열 데이터를 정기적으로 검색할 필요가 없어지면 warm 계층에서 cold 계층으로 이동할 수 있습니다. 이 계층은 여전히 검색 가능하지만, 일반적으로 검색 속도보다 스토리지 비용 절감에 최적화되어 있습니다.

스토리지를 더 절약하려면 검색 가능한 스냅샷의 완전 마운트 인덱스를 cold 계층에 보관할 수 있습니다. 일반 인덱스와 달리 이러한 완전 마운트 인덱스는 안정성을 위한 복제본이 필요하지 않습니다. 장애가 발생하면 기반 스냅샷에서 데이터를 복구할 수 있기 때문입니다. 이를 통해 데이터에 필요한 로컬 스토리지를 절반까지 줄일 수 있습니다. Cold 계층에서 완전 마운트 인덱스를 사용하려면 스냅샷 저장소가 필요합니다. 완전 마운트 인덱스는 읽기 전용입니다.

또는 검색 가능한 스냅샷을 사용하는 대신 복제본이 있는 일반 인덱스를 cold 계층에 저장할 수도 있습니다. 이렇게 하면 오래된 데이터를 더 저렴한 하드웨어에 저장할 수 있지만, warm 계층 대비 필요한 디스크 공간이 줄어들지는 않습니다.

데이터를 더 이상 조회하지 않거나 아주 드물게만 조회하게 되면, cold 계층에서 frozen 계층으로 이동해 남은 수명 동안 그곳에 머물 수 있습니다.

Frozen 계층에는 전용 노드를 사용할 것을 권장합니다. Frozen 계층은 스냅샷 저장소가 필요하며, 부분 마운트 인덱스를 사용해 스냅샷 저장소에서 데이터를 저장하고 로드합니다. 이를 통해 frozen 데이터를 검색할 수 있으면서도 로컬 스토리지와 운영 비용을 줄일 수 있습니다. Elasticsearch가 때때로 스냅샷 저장소에서 frozen 데이터를 가져와야 하므로, frozen 계층에서의 검색은 일반적으로 cold 계층보다 느립니다.

데이터 계층을 구성하는 방법은 클러스터의 배포 유형에 따라 다릅니다. 사용 중인 배포 방식에 맞는 가이드를 참고하세요:

index.routing.allocation.include._tier_preference 설정은 인덱스를 어느 계층에 할당할지 결정합니다.

인덱스를 생성하면 Elasticsearch는 기본적으로 _tier_preference를 data_content로 설정하여 인덱스 샤드를 content 계층에 자동으로 할당합니다.

Elasticsearch가 데이터 스트림의 일부로 인덱스를 생성할 때는 기본적으로 _tier_preference를 data_hot으로 설정하여 인덱스 샤드를 hot 계층에 자동으로 할당합니다.

인덱스 생성 시점에 다음 두 가지 방법 중 하나로 선호 값을 명시적으로 지정하여 기본 설정을 재정의할 수 있습니다:

인덱스 생성 후에는 인덱스 설정을 업데이트하여 선호 값으로 이 설정을 재정의할 수 있습니다.

이 설정은 여러 계층을 선호 순서대로 지정할 수도 있습니다. 이렇게 하면 선호하는 계층에 해당하는 노드가 클러스터에 없을 때 인덱스가 할당되지 않은 상태로 남는 것을 방지할 수 있습니다. 예를 들어 인덱스 수명 주기 관리가 인덱스를 cold 단계로 마이그레이션할 때, 인덱스의 _tier_preference를 data_cold,data_warm,data_hot으로 설정합니다.

데이터 계층 선호 설정을 제거하려면 _tier_preference 값을 null로 설정하세요. 그러면 인덱스를 클러스터 내 모든 데이터 노드에 할당할 수 있습니다. _tier_preference를 null로 설정해도 기본값이 복원되지는 않습니다. 관리형 인덱스의 경우 migrate 작업이 그 자리에 새 값을 적용할 수 있습니다.

기존 인덱스의 데이터 계층 선호 설정은 index.routing.allocation.include._tier_preference에 대해 설정을 조회하여 확인할 수 있습니다:

				GET /my-index-000001/_settings?filter_path=*.settings.index.routing.allocation.include._tier_preference

_tier_preference 설정은 다른 할당 설정과 충돌할 수 있습니다. 이 충돌로 인해 샤드가 할당되지 않을 수 있습니다. 클러스터가 아직 데이터 계층으로 마이그레이션되지 않은 경우 충돌이 발생할 수 있습니다.

이 설정은 이미 할당된 샤드의 할당을 해제하지는 않지만, 현재 위치에서 지정된 데이터 계층으로 마이그레이션되는 것을 막을 수 있습니다. 문제를 해결하려면 cluster allocation explain API를 호출하고 문제가 의심되는 샤드를 지정하세요.

ILM은 migrate 작업을 사용해 관리형 인덱스를 사용 가능한 데이터 계층 간에 자동으로 전환합니다. 기본적으로 이 작업은 모든 단계에 자동으로 주입됩니다.

데이터 스트림 수명 주기는 frozen_after를 사용해 오래된 백업 인덱스를 frozen 계층으로 자동 전환할 수 있습니다. 데이터 스트림의 검색 가능한 스냅샷을 참고하세요.

다음 설정을 사용하면 ILM 정책에서 데이터 계층 마이그레이션을 위한 데이터 할당을 명시적으로 비활성화할 수 있습니다:

"migrate": {
  "enabled": false
}

예시:

"cold": {
       "min_age": "15m",
       "actions": {
         "set_priority": {
           "priority": 0
         },
         "migrate": {
           "enabled": false
         }
       }
     },

데이터 계층에 대해 migrate 작업을 "enabled": false로 정의하면 ILM 샤드 자동 마이그레이션이 비활성화됩니다. 예를 들어 allocate 작업으로 할당 규칙을 수동으로 지정할 때 유용합니다.

중요

ILM 할당 규칙을 수동으로 정의하지 않은 채 ILM 자동 마이그레이션을 비활성화하지 마세요. 할당 규칙을 정의하지 않고 데이터 마이그레이션을 비활성화하면, 데이터가 ILM 정책을 complete 상태로 정상 통과했더라도 지정된 데이터 계층으로 이동하지 못할 수 있습니다.