[es] 데이터 계층을 사용한 데이터 수명 주기 관리

노드 속성을 사용하여 hot-warm-cold 아키텍처를 구현하는 방식은 더 이상 권장되지 않습니다.

 

 

Elasticsearch 7.10 은 데이터 수명 주기 구성을 덜 복잡하게 만들었습니다. 이 블로그 게시물에서는 몇 가지 변경 사항, 사용 방법 및 그 과정에서 몇 가지 모범 사례를 살펴보겠습니다.

데이터 수명 주기는 많은 단계를 포함할 수 있으므로 다음을 살펴보겠습니다.

• 클러스터를 계층(핫, 웜, 콜드)으로 분할하여 새 데이터가 올바른 위치로 이동하도록 합니다.
• 계층 간에 데이터를 마이그레이션하기 위해 인덱스 수명 주기 관리(ILM) 내에서 이러한 계층을 활용합니다.
• 검색 가능한 스냅샷을 사용하여 콜드 계층 내에서 데이터 밀도를 높입니다.
• 데이터가 계층을 통해 흐르는 방식에 대한 실제 예와 함께 모든 것을 결합합니다.

 

7.10 이전

Out with attributes, in with node roles

시계열 데이터를 처리할 때 일반적인 사용 사례 중 하나는 클러스터 토폴로지를 별도의 계층으로 분리하는 것입니다. 이러한 계층에는 새로운 데이터가 수집되고 쿼리되는 hot , 중간 연령 데이터가 유지되고 쿼리되는 warm , 일반적으로 데이터가 장기간 유지되고 덜 자주 쿼리되는 cold 와 같은 이름이 지정됩니다.

사용자가 서로 다른 하드웨어로 이러한 계층을 구성하여 핫 계층에 가장 강력하고 값비싼 하드웨어를 사용하고 웜 또는 콜드 계층에 더 저렴하고 스토리지 밀도가 높은 하드웨어를 사용하는 것이 일반적입니다.

7.10 이전에는 서로 다른 노드 계층을 구성하는 가장 일반적인 방법 중 하나가 노드 속성을 사용하는 것이었 으므로 사용자는 다음과 같이 구성했습니다.

# On hot nodes 
node.attr.node_type: hot

# On warm nodes 
node.attr.node_type: warm 

# On cold nodes: 
node.attr.node_type: cold

그런 다음 클러스터 및 인덱스 수준 할당 매개변수와 함께 사용할 수 있습니다. 예를 들어 인덱스는 다음과 같이 생성됩니다.

PUT /myindex 
{ 
  "settings": { 
    "index.routing.allocation.include.node_type": "hot" 
  } 
}

이렇게 하면 핫 노드에 할당된 인덱스가 생성됩니다.

 

일을 하는 새로운 방법을 살펴봅시다.

 

 

 

 

프로세스 공식화

7.10에서는 이러한 유형의 구성이 공식화되었으며 이제 핫, 웜 및 콜드 계층에 해당하는 특정 역할을 갖게 되었습니다(또한 앞으로 다룰 다른 계층도 포함). node.attr.node_type즉, 속성 을 추가하는 대신 data_hot, data_warm또는 data_cold노드 역할 중 하나를 node.roles설정에 추가할 수 있습니다.

# On hot nodes 
node.roles: ["data_hot"] 

# On warm nodes 
node.roles: ["data_warm"] 

# On cold nodes 
node.roles: ["data_cold"]

필요할 수 있는 다른 역할을 목록에 추가하는 것을 잊지 마십시오! 예를 들어 더 작은 클러스터의 경우 데이터 노드는 다음과 같을 수 있습니다.

node.roles: ["master", "ingest", "ml", "data_hot", "data_content"]

( data_content역할은 이 포스트에서 더 자세히 설명하겠습니다.)

참고:data 기존 역할 이 어떻게 되었는지 궁금할 수 있습니다 . 음, data역할은 모든 계층이 지정된 것처럼 작동하므로 한 번에 모두 핫, 웜 및 콜드 계층의 일부입니다. 즉, 7.10 이상으로 업그레이드되었지만 해당 node.roles설정으로 사용자 지정 노드 역할을 지정하지 않은 노드는 모든 데이터 계층의 일부입니다.

계층 간 데이터 이동

이러한 역할이 설정되면 이전과 동일한 클러스터 및 인덱스 수준 할당 필터를 사용하여 클러스터 주변에서 데이터를 이동할 수 있습니다.

• cluster.routing.allocation.require._tier
• cluster.routing.allocation.include._tier
• cluster.routing.allocation.exclude._tier
• index.routing.allocation.require._tier
• index.routing.allocation.include._tier
• index.routing.allocation.exclude._tier

일반 포함, 제외 및 필수 필터링과 약간 다르게 작동하는 새 매개변수도 있습니다. 이것은 _tier_preference인덱스 수준 설정입니다: index.routing.allocation.include._tier_preference.

작동 방식을 보려면 다음 예를 살펴보겠습니다.

PUT /myindex 
{ 
  "settings": { 
    "index.routing.allocation.include._tier_preference": "data_cold,data_warm,data_hot" 
  } 
}

이 스니펫은 콜드 계층, 웜 계층, 마지막으로 핫 계층에 있는 것을 선호하는 인덱스를 생성합니다.

클러스터에 콜드 노드가 없으면 웜 노드에 할당해야 합니다. 클러스터에 웜 노드가 없으면 핫 노드에 할당해야 합니다. 이 구성을 사용하면 정책 또는 템플릿이 기본 설정을 지정할 수 있으며 각 계층이 클러스터의 일부가 되는 것에 대해 걱정할 필요가 없습니다. 대신 선호하는 계층을 지정할 수 있습니다.

이 새로운 설정이 어떻게 작동하는지 정확히 알아보려면 다음 흐름도를 확인하세요.

노드 속성과 형식화된 데이터 계층 역할 사이에는 마지막 차이점이 있습니다. 인덱스는 처음 생성될 때 할당됩니다. 다음은 색인이 처음 배치되는 위치를 결정하는 간단한 규칙입니다.

데이터 스트림의 일부인 인덱스는 생성 시 자동으로 "index.routing.allocation.include._tier_preference: data_hot" 설정이 추가됩니다.

이는 모든 데이터 스트림 지원 인덱스가 기본적으로 핫(data_hot) 노드에 할당됨을 의미합니다.

그리고 데이터 스트림의 일부가 아닌 인덱스의 경우:

데이터 스트림의 일부가 아닌 인덱스는 생성 시 자동으로 "index.routing.allocation.include._tier_preference: data_content" 설정이 추가됩니다.

이러한 설정 중 하나를 재정의할 수 있습니다. _tier_preference인덱스 설정을 로 설정 null하거나 생성 중에 다른 인덱스 수준 할당 필터링 설정을 지정 하기만 하면 됩니다.

하지만 잠깐: 이 새로운 data_content역할은 무엇입니까? 수명 주기 모델에 맞지 않는 다른 종류의 데이터, 즉 시계열 모델에 맞지 않는 데이터를 고려해 보겠습니다.

시계열에 맞지 않는 데이터

일부 데이터는 인덱싱된 다음 쿼리만 수행되지만 개념적 의미에서 나이 또는 타임스탬프가 없습니다. 여기에는 기업 검색 데이터, 전자상거래 데이터 또는 사용자 정보 데이터베이스가 포함됩니다.

이러한 종류의 데이터에는 역할이라는 특정 역할이 data_content있습니다. 이 역할은 설정을 사용하는 다른 역할과 마찬가지로 구성 node.roles됩니다.

이러한 역할 중 어느 것도 상호 배타적이지 않으므로 비시계열 데이터와 핫 데이터가 동일한 노드에 있도록 하려면 다음과 같이 노드를 구성해야 합니다.

# This node can hold either "hot" tier data, or "content" tier data 
node.roles: ["data_hot", "data_content"]

그리고 이미 짐작하셨겠지만 기존의 기본 data역할도 콘텐츠 계층의 일부입니다. 즉, 데이터 역할은 , , 및 역할을 설정에 추가 data_hot하는 data_warm것과 data_cold동일 data_content합니다 node.roles.

이전 섹션에서 언급했듯이 Elasticsearch가 시계열 데이터와 비시계열 데이터를 결정하는 방식은 해당 인덱스가 데이터 스트림에 속하는지 여부입니다.

모범 사례: 동일한 노드이더라도 클러스터에 항상 하나 이상의 data_hot노드와 하나 의 노드가 있는지 확인하십시오. data_content이러한 노드 역할이 모두 없으면 서로 다른 유형의 인덱스를 할당할 수 없습니다.

이제 다양한 계층을 모두 파악하고 몇 가지를 구성했으므로 ILM에서 이러한 계층을 활용하는 방법을 살펴보겠습니다.

데이터 계층 세계의 ILM

자체적으로 계층을 구성하는 것은 이전 속성 기반 할당과 비교하여 크게 변경되지 않습니다. 그러나 이제는 Elasticsearch 내에서 계층을 식별하는 기본 제공되고 일관된 방법이 있으므로 ILM은 이러한 설정을 사용하여 계층 간에 자동으로 데이터를 마이그레이션할 수 있습니다.

7.10 이전에는 다음과 같은 정책으로 계층화된 구성이 수행되었을 수 있습니다.

{ 
  "phases" : { 
    "hot" : { 
      "actions" : { 
        "rollover" : { 
          "max_age" : "30d", 
          "max_size" : "50gb" 
        } 
      } 
    }, 
    "warm" : { 
      "min_age" : "45d", 
      "actions" : { 
        "allocate" : { 
          "include" : { 
            "node_type" : "warm" 
          } 
        }, 
        "forcemerge" : { 
          "max_num_segments" : 1 
        } 
      } 
    }, 
    "cold" : { 
      "min_age" : "60d", 
      "actions" : { 
        "allocate" : { 
          "include" : { 
            "node_type" : "cold" 
          } 
        } 
      } 
    }, 
    "delete" : { 
      "min_age" : "90d", 
      "actions" : { 
        "delete" : { } 
      } 
    } 
  } 
}

node_type이 정책은 데이터를 핫 계층에 할당한 다음 각 ILM 단계 내에서 "할당" 작업으로 업데이트하여 데이터를 이동하는 인덱스 템플릿에 의존했습니다 .

그러나 7.10에는 더 나은 방법이 있습니다!

Elasticsearch는 이제 특정 계층을 선호할 수 있으므로 ILM은 index.routing.allocation.include._tier_preference새 단계에 들어갈 때 자동으로 설정하여 이 기본 설정을 활용할 수 있습니다. 다음은 위와 동일한 정책을 사용하지만 allocate단계를 제거한 예입니다.

{ 
  "phases" : { 
    "hot" : { 
      "actions" : { 
        "rollover" : { 
          "max_age" : "30d", 
          "max_size" : "50gb" 
        } 
      } 
    }, 
    "warm" : { 
      "min_age" : "45d", 
      "actions" : { 
        "forcemerge" : { 
          "max_num_segments" : 1 
        } 
      } 
    }, 
    "cold" : { 
      "min_age" : "60d", 
      "actions" : { } 
    }, 
    "delete" : { 
      "min_age" : "90d", 
      "actions" : { 
        "delete" : { } 
      } 
    } 
  } 
}

이 정책을 사용하는 새 데이터 스트림이 생성되면 처음에는 기본 설정이 로 설정됩니다 index.routing.allocation.include._tier_preference: data_hot.

인덱스가 웜 단계에 진입하면 설정이 로 업데이트됩니다 index.routing.allocation.include._tier_preference: data_warm,data_hot.

콜드 단계에 진입하면 로 업데이트되고 단계 index.routing.allocation.include._tier_preference: data_cold,data_warm,data_hot에서 인덱스가 최종적으로 삭제됩니다 delete.

hot이 자동 마이그레이션은 인덱스 생성 시 자동으로 관리되므로 단계 에는 적용되지 않습니다 .

이 자동 마이그레이션을 통해 클러스터 토폴로지에 해당 계층의 노드도 포함된 경우 데이터 위치가 현재 ILM 단계와 자동으로 일치할 수 있습니다.

이 동작은 다음 두 가지 주의 사항과 함께 자동으로 적용됩니다.

• "migrate": {"enabled": false}단계의 작업 목록에 작업 을 추가 하면 자동 마이그레이션이 적용되지 않습니다.
• ILM 단계 작업 allocate에 포함, 요구 또는 제외 필터를 설정하는 단계가 포함되어 있으면 자동 마이그레이션이 적용되지 않습니다.

다음 두 단계 모두 데이터를 자동으로 마이그레이션 하지 않습니다 .

"warm": { 
  "actions": { 
    "migrate": { 
      "enabled": false 
    } 
  } 
}

또는

"warm": { 
  "actions": { 
    "allocate": { 
      "include": { 
        "node_type": "warm" 
      } 
    } 
  } 
}

모범 사례: 클러스터 토폴로지에서 새 역할을 채택한 후에는 노드 특성을 사용하여 기본 데이터 계층 마이그레이션에 의존하는 ILM 정책에서 이전 할당 작업을 모두 제거해야 합니다.

검색 가능한 스냅샷으로 데이터를 더 오래 유지

데이터의 수명 주기를 만들고 유지하면 최신 데이터와 이전 데이터의 하드웨어 속성 및 성능 특성을 제어할 수 있습니다.

그러나 클러스터가 실제로 얼마나 많은 데이터를 보유할 수 있습니까?

이 질문에 대한 대답은 거의 항상 데이터의 보존 기간을 결정합니다. 디스크는 유한해지고 최신 데이터를 위한 공간을 만들기 위해 가장 오래된 데이터를 클러스터에서 삭제해야 하기 때문입니다. 이는 클러스터 디스크 리소스를 소진하거나 초과 비용을 지불하지 않고 통찰력과 규정상의 이유로 필요한 데이터 양을 유지하는 것 사이에 균형을 잘 맞추는 것입니다.

하지만 클러스터 리소스에 미치는 영향을 최소화하면서 데이터를 더 오래 보관할 수 있다면 어떨까요?

이것이 바로 검색 가능한 스냅샷이 도움이 될 수 있는 곳입니다. 7.10에 도입된 검색 가능한 스냅샷을 통해 Elasticsearch는 데이터 사본 하나를 클러스터에 로컬로 유지하고 복제본 역할을 하는 다른 사본은 스냅샷 리포지토리에 상주합니다. 즉, 로컬 복사본이 손실되면 리포지토리 스냅샷에서 자동으로 로컬로 복원할 수 있으므로 복제본이 필요하지 않습니다.

ILM 내에서도 이 기능을 사용할 수 있습니다. 콜드 단계에 도달하면 인덱스를 검색 가능한 스냅샷으로 자동 변환하여 중복성을 위해 복제본이 필요하지 않기 때문에 저장할 수 있는 데이터 밀도를 두 배로 늘릴 수 있습니다.

이 기능을 사용하는 것은 작업 으로 cold단계를 구성하는 것만큼 간단합니다 .searchable_snapshot

"cold": { 
  "min_age": "90d", 
  "actions": { 
    "searchable_snapshot": { 
      "snapshot_repository" : "backing_repo" 
    } 
  } 
}

내부적으로 이 조치에 도달하면 Elasticsearch는 다음을 수행합니다.

• 인덱스를 단일 세그먼트로 강제 병합
• backing_repo리포지토리 에서 인덱스의 새 스냅샷 생성
• 인덱스를 새 이름으로 검색 가능한 스냅샷 지원 인덱스로 마운트
• 검색 가능한 스냅샷 지원 인덱스에 대한 원본 인덱스 교체

짜잔! 이제 데이터의 기본 복사본이 손실된 경우에 사용할 수 있는 스냅샷이 있으므로 로컬 복제본이 필요하지 않습니다.

참고: Elastic Cloud 사용자인 경우 검색 가능한 스냅샷 작업 구성 내에서 이미 구성된 "found-snapshots" 리포지토리를 사용할 수도 있습니다(또는 고유한 별도 리포지토리 구성).

함께 모아서

데이터 수명 주기에 대한 데이터 계층 구성은 작업 수명 주기를 만들기 위해 다양한 이동 부분을 포함합니다. 이러한 부분을 작업 예제에 함께 넣어 보겠습니다.

시작하려면 일부 노드가 필요합니다. 이 예에서는 a, b, c 및 d로 표시된 4개의 노드를 사용합니다.

NodeA:

node.name: node-a-hot 
node.roles: ["master", "data_hot", "data_content", "ingest"]

노드 B:

node.name: node-b-hot 
node.roles: ["master", "data_hot", "data_content", "ingest"]

노드C:

node.name: node-c-cold 
node.roles: ["master", "data_cold", "ingest"]

노드D:

node.name: node-d-cold 
node.roles: ["master", "data_cold", "ingest"]

클러스터가 시작되면 스냅샷 리포지토리를 구성해 보겠습니다.

PUT /_snapshot/my-repository 
{ 
  "type": "fs", 
  "settings": { 
    "location": "my-backup-location" 
  }
}

그리고 ILM 정책을 추가하여 몇 가지 일반적인 작업과 새로운 searchable_snapshot작업을 사용합니다.

PUT /_ilm/policy/my-data-lifecycle 
{
  "policy" : { 
    "phases" : { 
      "hot" : { 
        "actions" : { 
          "rollover" : { 
            "max_size" : "50gb", 
            "max_age" : "3d" 
          } 
        } 
      }, 
      "warm" : { 
        "min_age" : "5d", 
        "actions" : { 
          "shrink" : { 
            "number_of_shards" : 1 
          } 
        } 
      }, 
      "cold" : { 
        "min_age" : "7d", 
        "actions" : { 
          "searchable_snapshot" : { 
            "snapshot_repository" : "my-repository" 
          } 
        } 
      }, 
      "delete" : { 
        "min_age" : "365d", 
        "actions" : { 
          "delete" : { } 
        } 
      } 
    } 
  } 
}

전제 조건이 하나 더 있습니다. 인덱스가 데이터 스트림이 될 수 있고 이전에 생성한 ILM 정책을 자동으로 사용할 수 있는 인덱스 템플릿입니다. 복제본을 수용할 수 있도록 각 노드가 2개 이상 있는지 확인하거나 index.number_of_replicas테스트를 위해 0으로 설정하십시오.

PUT /_index_template/my-lifecycle-template 
{ 
  "index_patterns": ["test-index"], 
  "data_stream" :{}, 
  "template": { 
    "settings": { 
      "index.lifecycle.name": "my-data-lifecycle", 
      "index.number_of_shards": 2 
    } 
  } 
}

test-index이제 문서를 데이터 스트림 에 직접 인덱싱하여 이 새 인덱스로 데이터를 보낼 수 있습니다 .

POST /test-index/_doc?op_type=create 
{ 
  "message": "test document", 
  "@timestamp": "2020-01-12" 
}

이제 더 많은 데이터가 전송되면 자동으로 클러스터의 핫 노드에서 콜드 노드로 이동하여 결국 1년 후 최종적으로 삭제되기 전에 검색 가능한 스냅샷으로 이동합니다.