DevOps 지식 허브
DevOps 지식 허브

일반적인 Elasticsearch 샤드 할당 실패 문제 해결

일반적인 Elasticsearch 샤드 할당 실패를 해결하는 방법을 알아보세요. 이 가이드는 할당되지 않은 샤드 식별, 디스크 공간 오류, 노드 사용 불가 및 할당 필터링과 같은 문제 진단, 그리고 안정적인 Elasticsearch 클러스터 유지를 위한 실행 가능한 해결 방법 및 모범 사례를 다룹니다.

25 조회수

일반적인 Elasticsearch 샤드 할당 실패 문제 해결

강력한 분산 검색 및 분석 엔진인 Elasticsearch는 샤드를 사용하여 여러 노드에 데이터를 분산하는 능력에 크게 의존합니다. 이러한 샤드를 할당하지 못하면 데이터 액세스 불가, 검색 실패, 클러스터 상태 저하로 이어질 수 있습니다. 샤드 할당 실패의 일반적인 원인을 이해하고 이를 진단 및 해결하는 방법을 아는 것은 안정적이고 성능이 뛰어난 Elasticsearch 환경을 유지하는 데 중요합니다. 이 문서는 가장 빈번한 문제를 안내하고 샤드를 다시 할당 가능한 상태로 되돌리기 위한 실행 가능한 단계를 제공합니다.

이 가이드는 프로덕션 Elasticsearch 환경을 위한 실용적인 문제 해결에 중점을 둡니다. 할당되지 않은 샤드를 식별하고, 디스크 공간, 할당 규칙 및 노드 문제와 같은 일반적인 실패 원인을 이해하고, 이러한 문제를 효율적으로 해결하기 위한 명확한 단계를 제공합니다. 이러한 기술을 숙달하면 다운타임을 최소화하고 Elasticsearch 클러스터의 안정성을 보장할 수 있습니다.

할당되지 않은 샤드 식별

문제 해결의 첫 번째 단계는 어떤 샤드가 할당되지 않았는지, 그리고 그 이유를 식별하는 것입니다. Elasticsearch는 이를 위해 몇 가지 도구를 제공합니다:

클러스터 상태 API 사용

_cluster/health API는 클러스터 상태에 대한 개요를 제공합니다. 응답에서 unassigned_shards를 찾으십시오. 0이 아닌 값은 문제가 있음을 나타냅니다.

GET _cluster/health

응답 예시 스니펫:

{
  "cluster_name": "my-es-cluster",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 3,
  "number_of_data_nodes": 3,
  "active_primary_shards": 10,
  "active_shards": 20,
  "relocating_shards": 0,
  "initializing_shards": 1,
  "unassigned_shards": 1,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "max_length_search_concurrency": 1000,
  "max_length_search_size": 10000,
  "active_shards_percent_as_number": 95.45454545454545
}

이 예시에서 "status": "yellow" 및 "unassigned_shards": 1은 하나의 샤드가 할당되지 않았음을 나타냅니다. red 상태는 하나 이상의 기본 샤드가 할당되지 않았음을 의미하며, 데이터 액세스에 영향을 미칩니다. yellow 상태는 복제 샤드가 할당되지 않았음을 의미하며, 기본 샤드는 할당되었으므로 데이터는 여전히 검색 가능하지만 완전히 중복되지는 않습니다.

할당 설명 API 사용

특정 샤드가 할당되지 않은 이유에 대한 자세한 통찰력을 얻으려면 _cluster/allocation/explain API가 매우 유용합니다. 샤드 세부 정보를 제공하거나 클러스터 상태를 분석하도록 할 수 있습니다.

할당되지 않은 샤드에 대한 설명을 얻으려면:

GET _cluster/allocation/explain

특정 샤드에 대한 설명을 얻으려면 (index_name 및 shard_id를 바꾸십시오):

GET _cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}

일반적인 원인 및 해결 방법

여러 요인이 샤드 할당 실패로 이어질 수 있습니다. 가장 일반적인 원인과 이를 해결하는 방법은 다음과 같습니다:

1. 디스크 공간 부족

이는 아마도 샤드 할당 실패의 가장 빈번한 원인일 것입니다. 노드에서 디스크 공간이 부족해지면 Elasticsearch는 데이터 손상을 방지하고 안정성을 보장하기 위해 해당 노드에 새로운 샤드를 할당하지 못하도록 합니다. 기존 샤드를 제거할 수도 있습니다.

  • 증상: Allocation Explain API는 종종 "cannot allocate because disk usage [X%] exceeds the low watermark [Y%]" 또는 "cannot allocate because disk usage [X%] exceeds the high watermark [Y%]"와 같은 메시지를 보고합니다.
  • 진단: 데이터 노드의 디스크 사용량을 확인하십시오. _cat/allocation API를 사용하여 빠르게 개요를 볼 수 있습니다:
    bash GET _cat/allocation?v
    디스크 사용률이 높은 노드를 찾으십시오.
  • 해결 방법:
    • 디스크 공간 추가: 가장 간단한 해결책은 영향을 받는 노드에 저장 공간을 추가하거나 기존 디스크를 더 큰 디스크로 교체하는 것입니다.
    • 불필요한 인덱스 삭제: 디스크 공간을 차지하는 오래되거나 불필요한 인덱스를 식별하고 삭제합니다.
    • 워터마크 조정: elasticsearch.yml 구성 파일 또는 클러스터 설정 API를 통해 동적으로 디스크 사용량 워터마크(cluster.routing.allocation.disk.watermark.low, cluster.routing.allocation.disk.watermark.high, cluster.routing.allocation.disk.watermark.flood_stage)를 조정할 수 있습니다. 그러나 이러한 설정을 조정할 때는 주의가 필요합니다. 이러한 설정은 클러스터를 보호하기 위해 설계되었습니다. 용량을 추가하지 않고 낮추면 추가 문제가 발생할 수 있습니다.
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.disk.watermark.low": "85%", "cluster.routing.allocation.disk.watermark.high": "90%", "cluster.routing.allocation.disk.watermark.flood_stage": "95%" } }
    • 노드 추가: 더 많은 데이터 노드를 추가하여 클러스터를 확장합니다. 이렇게 하면 데이터가 분산되고 개별 노드의 부하가 줄어듭니다.
    • 강제 병합 또는 오래된 데이터 삭제: 시계열 데이터가 있는 경우, 오래된 인덱스에 _forcemerge API를 사용하여 세그먼트 수를 줄이거나(디스크 공간을 확보할 수 있음) 인덱스 수명 주기 관리(ILM)를 사용하여 오래된 데이터를 자동으로 삭제하는 것을 고려하십시오.

2. 노드 사용 불가 또는 재시작 중

노드가 다운되었거나, 재시작 중이거나, 네트워크 문제가 발생하는 경우 해당 노드에 있는 샤드는 할당되지 않습니다. 기본 샤드인 경우 클러스터 상태가 빨간색으로 변경됩니다.

  • 증상: Allocation Explain API는 노드를 사용할 수 없거나 다운으로 인해 (excluded)로 표시되었기 때문에 샤드를 할당할 수 없다고 나타냅니다.
  • 진단: _cat/nodes API를 사용하여 노드 상태를 확인하십시오. 예상되는 모든 노드가 나열되어 있고 건강한지 확인하십시오.
    bash GET _cat/nodes?v
    영향을 받는 노드에서 Elasticsearch 로그를 확인하여 오류나 종료 징후가 있는지 확인하십시오.
  • 해결 방법:
    • 노드 재시작: 노드가 다운된 경우 Elasticsearch 서비스를 다시 시작하십시오.
    • 네트워크 문제 해결: 노드가 클러스터의 다른 노드와 통신할 수 있는지 확인하십시오.
    • 로그 확인: 특정 노드의 Elasticsearch 로그를 검토하여 실패의 근본 원인(예: 메모리 부족, 디스크 오류, JVM 문제)을 파악하십시오.
    • index.unassigned.node_left.delayed_timeout 증가: 노드가 자주 클러스터에 참여하고 떠나는 경우(예: 롤링 재시작 중), 복제 샤드가 일시적으로 할당되지 않을 수 있습니다. index.unassigned.node_left.delayed_timeout 설정(기본값 1분)은 Elasticsearch가 노드를 벗어난 샤드를 할당되지 않은 것으로 표시하기 전에 기다리도록 하여 노드가 다시 참여할 시간을 줍니다. 필요한 경우 이 값을 늘리십시오. 복구 시간에 미치는 영향을 염두에 두십시오.

3. 할당 필터링 및 인식 규칙

Elasticsearch는 노드 속성 및 안티-어피니티와 같은 다양한 할당 규칙을 사용하여 샤드를 어디에 할당할지 제어할 수 있습니다. 이러한 규칙이 할당을 방지하면 샤드가 할당되지 않을 수 있습니다.

  • 증상: Allocation Explain API는 특정 속성에 대한 할당이 비활성화되었거나 구성된 규칙에 따라 적합한 노드를 사용할 수 없다고 보고합니다.
  • 진단:
    • 인덱스 설정에서 index.routing.allocation.require.*, index.routing.allocation.include.*, index.routing.allocation.exclude.*, index.routing.allocation.total_shards_per_node를 확인하십시오.
    • 클러스터 수준 설정에서 cluster.routing.allocation.enable(예: all, primaries, new_primaries, none)을 확인하십시오.
    • GET _cat/nodeattrs?v를 사용하여 노드 속성을 확인하십시오.
  • 해결 방법:
    • 인덱스 설정 업데이트: 제한적인 인덱스 라우팅 규칙을 제거하거나 조정합니다. 예를 들어, 모든 노드에 할당을 허용하려면:
      json PUT my-index/_settings { "index": { "routing": { "allocation": { "require": null, "include": null, "exclude": null } } } }
    • 클러스터 설정 업데이트: 비활성화된 경우 할당을 일시적으로 활성화합니다:
      json PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "all" } }
      이 설정은 일시적으로만 사용하려는 경우 원래대로 되돌리는 것을 잊지 마십시오.
    • 노드 속성 업데이트: 노드에 elasticsearch.yml에 정의된 예상 속성이 있는지 확인하고(예: node.attr.zone: us-east-1) 이러한 속성이 할당 규칙과 일치하는지 확인하십시오. elasticsearch.yml을 변경한 후에는 변경 사항이 적용되려면 노드를 다시 시작해야 합니다.

4. 손상된 샤드 데이터(드문 경우)

드문 경우 샤드 데이터가 손상되어 Elasticsearch가 시작되지 않거나 샤드를 할당하지 못할 수 있습니다. 이는 기본적인 디스크 문제로 인해 더 흔하게 발생합니다.

  • 증상: 로그에 샤드 데이터 읽기 또는 인덱스 손상과 관련된 오류가 표시될 수 있습니다. Allocation Explain API는 명확한 이유를 제공하지 않거나 읽기 오류를 가리킬 수 있습니다.
  • 진단: 샤드가 위치해야 하는 노드의 Elasticsearch 로그를 면밀히 검토하십시오. I/O 오류 또는 데이터 손상 메시지를 찾으십시오.
  • 해결 방법:
    • 스냅샷에서 복원: 가장 안정적인 해결책은 손상된 인덱스(또는 전체 클러스터)를 알려진 좋은 스냅샷에서 복원하는 것입니다. 이것이 정기적인 백업이 중요한 이유입니다.
    • 샤드 강제 삭제(최후의 수단): 스냅샷에서 복원할 수 없고 데이터가 중요하지 않거나 다시 인덱싱할 수 있는 경우, 손상된 샤드를 강제로 삭제해야 할 수 있습니다. 이것은 고급 작업이며 그 의미를 이해할 때만 수행해야 합니다. 일반적으로 영향을 받는 노드를 중지하고, 샤드 데이터 디렉토리를 수동으로 제거한 다음, 노드를 다시 시작해야 합니다. 이렇게 하면 해당 샤드의 데이터가 손실됩니다. 해당 버전에 대한 정확한 절차는 Elasticsearch 설명서를 참조하십시오.

5. 불충분한 복구 용량

노드가 클러스터를 떠나거나 디스크 공간 문제가 발생하면 Elasticsearch는 샤드를 다른 노드로 복구하려고 시도합니다. 적합한 노드가 충분하지 않거나 클러스터가 이미 과부하 상태인 경우, 샤드 복구가 지연되어 initializing_shards 또는 unassigned_shards가 발생할 수 있습니다.

  • 증상: 샤드가 장시간 initializing 또는 relocating 상태로 유지되거나 새 샤드가 할당되지 않습니다.
  • 진단: _cat/shards 및 _cat/allocation을 확인하여 샤드 상태와 디스크 사용량을 확인하십시오. 클러스터 상태 및 노드 CPU/IO 사용량을 모니터링하십시오.
  • 해결 방법:
    • 노드 추가: 더 많은 데이터 노드를 추가하여 클러스터의 용량을 늘립니다.
    • 리소스 확보: 기존 노드의 성능 병목 현상(예: 높은 CPU, 느린 디스크 I/O)을 해결합니다.
    • 샤드 할당 설정 조정: cluster.routing.allocation.node_concurrent_recoveries(노드에서 동시에 복구할 수 있는 샤드 수) 및 cluster.routing.allocation.node_concurrent_incoming_recoveries(다른 노드에서 동시에 복구할 수 있는 샤드 수)와 같은 설정을 조정할 수 있습니다. 그러나 이를 늘리면 클러스터에 더 많은 부담을 줄 수 있으므로 주의하십시오.

예방을 위한 모범 사례

  • 디스크 공간 모니터링: 모든 데이터 노드의 디스크 사용량을 사전에 모니터링하십시오. 디스크 사용량이 미리 정의된 임계값(예: 80% 또는 85%)을 초과할 때 경고를 설정하십시오.
  • 인덱스 수명 주기 관리(ILM) 구현: 오래된 인덱스의 롤오버, 축소 및 삭제를 포함하여 시계열 데이터 관리를 자동화합니다. 이렇게 하면 디스크 공간 사용량을 제어하는 데 도움이 됩니다.
  • 정기적인 스냅샷: 정기적이고 자동화된 데이터 스냅샷으로 강력한 백업 전략을 확보하십시오. 복원 프로세스를 정기적으로 테스트하십시오.
  • 할당 규칙 이해: 하드웨어, 데이터 및 가용성 요구 사항에 따라 샤드 할당 규칙을 신중하게 계획하고 구성하십시오.
  • 적절한 하드웨어: 노드가 워크로드 및 샤드 복구 프로세스를 처리할 만큼 충분한 CPU, RAM 및 I/O 기능을 갖추고 있는지 확인하십시오.
  • 클러스터 상태 모니터링: _cluster/health API를 사용하여 클러스터 상태를 정기적으로 확인하고 Kibana의 Stack Monitoring과 같은 도구로 시각화하십시오.

결론

Elasticsearch의 샤드 할당 실패는 어려운 문제가 될 수 있지만, 클러스터 상태 API 및 할당 설명 API와 같은 도구를 사용하여 체계적으로 문제를 진단하고 디스크 공간, 노드 가용성 및 할당 규칙과 같은 일반적인 원인을 이해함으로써 효과적으로 해결할 수 있습니다. 정기적인 백업 및 ILM과 같은 모범 사례를 준수하고 사전 예방적 모니터링은 이러한 문제를 방지하고 안정적이고 건강한 Elasticsearch 클러스터를 보장하는 데 중요합니다.