본문으로 건너뛰기

Advanced Managed Search 문제 해결

본 문서는 Advanced Managed Search 서비스와 관련된 주요 문제와 해결 방법을 정리한 문서입니다.

안내

이 문서에서 사용하는 provisioningStatus / detailedStatus 값은 API 응답 기준 표기이며, 콘솔 UI의 표시명과 다음과 같은 차이가 있습니다.

  • 공백 제거: ScalingUp → Scaling Up, RelocatingNodes → Relocating Nodes
  • 공백 제거 + 축약: ProvisioningErr → Provisioning Error

전체 상태·표시명 대응 관계는 클러스터 상태 및 세부 상태 문서를 참고해 주세요.

1. 클러스터 상태가 오랫동안 Provisioning 상태로 유지될 때​

증상​

클러스터 provisioningStatus가 Provisioning에서 Initializing / Running으로 전환되지 않습니다.

확인 방법​

클러스터 상태 확인

provisioningStatus: Provisioning

노드 상태 확인

해당 클러스터의 OpenSearch data/manager 노드 목록에서 각 노드의 status를 확인합니다.

상태값설명
ProvisioningOpenStack 리소스 생성 중 (정상 대기)
InitializingOpenSearch 설치/설정 중 (정상 진행)
ProvisioningErr프로비저닝 실패 (복구 불가)

조치​

노드 중 하나라도 status가 ProvisioningErr이면, 자동으로 재시도되지 않습니다. 이 경우 서비스데스크에 문의해 주세요.

ProvisioningErr 발생 원인 예시

  • 노드 리소스 생성 과정에서 오류가 발생한 경우
참고

ProvisioningErr 상태에서는 클러스터가 Provisioning에 머물며, scale up/out과 달리 자동 rollback이 수행되지 않습니다.

2. 클러스터 상태가 오랫동안 ScalingUp 상태로 유지되고, 세부 상태가 RelocatingNodes로 오랫동안 유지될 때​

증상​

provisioningStatus: ScalingUp
detailedStatus: RelocatingNodes

배경 (정상 동작)​

Scale up 과정에서 기존 노드의 데이터를 신규 노드로 옮기는 단계입니다. 클러스터에 저장된 데이터가 많을수록 이 작업에 수 시간 이상 걸릴 수 있습니다.
RelocatingNodes 상태가 오래 유지되는 것만으로는 반드시 오류는 아닙니다. 아래 케이스를 참고해 정상 진행 중인지, 문의가 필요한지 구분해 주세요.

2-1. 내부 데이터가 많아 relocation이 오래 걸리는 경우​

판단 기준

  • 클러스터에 인덱스나 데이터가 많은 상태
  • Scale up 시작 후 시간이 지났지만, 데이터 이동이 느리게 진행 중인 상태

정상 진행 여부

기존 노드의 데이터가 점차 줄어들고 신규 노드로 옮겨지고 있다면 정상 진행 중일 가능성이 높습니다. Dev Tools 등에서 아래 API로 확인할 수 있습니다.

확인 예시 (OpenSearch API)

클러스터 전체 이동 현황:

GET /_cluster/health?pretty
  • relocating_shards가 0보다 크면 shard 이동이 진행 중입니다.
  • initializing_shards가 함께 보이면 새 노드에서 shard 초기화가 진행 중일 수 있습니다.

shard별 배치 및 이동 상태:

GET /_cat/shards?v
  • state가 RELOCATING / INITIALIZING인 shard가 보이면 이동 작업이 진행 중입니다.
  • 기존 노드의 shard 수가 시간이 지남에 따라 줄어들면 정상 진행으로 볼 수 있습니다.

현재 진행 중인 recovery 목록:

GET /_cat/recovery?v&active_only=true
  • recovery 항목이 표시되고 진행률(bytes_percent 등)이 변하면 느리더라도 진행 중일 가능성이 높습니다.

이동 속도 높이기 (선택)

이동이 진행 중이지만 너무 느릴 때, 아래 cluster settings를 일시적으로 조정해 속도를 높일 수 있습니다. Dev Tools에서 실행합니다.

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.node_concurrent_recoveries": "4",
    "cluster.routing.allocation.cluster_concurrent_rebalance": "4",
    "indices.recovery.max_bytes_per_sec": "200mb"
  }
}
설정설명
cluster.routing.allocation.node_concurrent_recoveries노드당 동시 recovery 수 (기본 2)
cluster.routing.allocation.cluster_concurrent_rebalance클러스터 전체 동시 rebalance 수 (기본 2)
indices.recovery.max_bytes_per_secrecovery 전송 속도 상한 (기본 40mb)

적용 후 GET /_cat/recovery?v&active_only=true로 진행 속도 변화를 확인할 수 있습니다.

Scale up 완료 후에는 아래처럼 설정을 원복하는 것을 권장합니다.

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.node_concurrent_recoveries": null,
    "cluster.routing.allocation.cluster_concurrent_rebalance": null,
    "indices.recovery.max_bytes_per_sec": null
  }
}
주의
  • 위 설정은 관리자 권한이 필요하며, 클러스터 부하에 따라 값 조정이 필요할 수 있습니다.
  • Scale up 중 allocation exclude 등 기타 클러스터 설정은 변경하지 마세요. 데이터 손실 위험이 있을 수 있습니다.
  • 2-2(이동 정체) 케이스에서는 이 방법만으로 해결되지 않을 수 있습니다. 진행이 멈춘 경우 서비스데스크에 문의해 주세요.

조치

  • 정상 진행 중이라면 완료까지 기다리는 것을 권장합니다.
  • 예상보다 훨씬 오래 걸리거나, 진행 여부 확인이 필요하면 서비스데스크에 문의해 주세요.

2-2. Scale up 중 데이터 이동이 멈춘 경우​

판단 기준

  • RelocatingNodes 상태가 오랫동안 유지되지만, 데이터 이동이 전혀 진행되지 않는 상태
  • Scale up 이후에도 기존 노드에 데이터가 남아 있는 것처럼 보이고, 상태가 다음 단계로 넘어가지 않는 상태

확인 예시 (OpenSearch API)

이동 중인 shard가 있는지 확인:

GET /_cluster/health?pretty
  • relocating_shards와 initializing_shards가 오랫동안 0이면 이동이 진행되지 않을 수 있습니다.

기존 노드에 shard가 남아 있는지 확인:

GET /_cat/shards?v
  • 기존(legacy) 노드 이름으로 shard가 계속 남아 있고, RELOCATING 상태가 거의 보이지 않으면 정체 상태를 의심할 수 있습니다.
  • 동일 index/shard에 primary(p)는 기존 노드, replica(r)는 신규 노드에 있는 패턴이 보이면 이동이 막힌 경우일 수 있습니다.

진행 중인 recovery가 없는지 확인:

GET /_cat/recovery?v&active_only=true
  • 결과가 비어 있거나, 오랫동안 진행률 변화가 없으면 이동이 멈춘 상태일 수 있습니다.

특정 shard가 왜 이동되지 않는지 확인 (index/shard는 실제 값으로 변경):

GET /_cluster/allocation/explain
{
  "index": "my-index",
  "shard": 0,
  "primary": true
}
  • explanation에 이동 불가 사유가 표시됩니다.

원인 1: data node 수 대비 replica 설정 불일치

data node가 1대인데 인덱스의 number_of_replicas가 1 이상으로 설정된 경우, replica shard가 영구적으로 할당되지 못해 클러스터 상태가 yellow로 유지되고 relocation이 다음 단계로 넘어가지 못할 수 있습니다.

조치

  • 해당 인덱스의 number_of_replicas를 data node 수에 맞게 조정하면 진행이 재개될 수 있습니다.
PUT /<index명>/_settings
{
  "index": {
    "number_of_replicas": 0
  }
}

원인 2: 기타 데이터 배치 불일치 (원인 특정이 어려운 경우)

원인 1에 해당하지 않으면서 데이터 이동이 정체된 경우, 기존 노드와 신규 노드 간 데이터 배치가 맞지 않아 이동이 지연되거나 멈췄을 가능성이 있습니다.

조치

  • 서비스데스크에 문의해 주세요.
  • 클러스터 설정을 직접 변경하거나 데이터 이동을 수동으로 조작하지 마세요. 데이터 손실 위험이 있을 수 있습니다.