Amazon OpenSearch Service 문제 해결 - Amazon OpenSearch 서비스

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Amazon OpenSearch Service 문제 해결

이 주제에서는 일반적인 Amazon OpenSearch Service 문제를 식별하고 해결하는 방법에 대해 설명합니다. AWS Support에 문의하기 전에 이 단원의 정보를 참조하세요.

OpenSearch Dashboards에 액세스할 수 없습니다.

OpenSearch Dashboards 엔드포인트는 서명된 요청을 지원하지 않습니다. 해당 도메인의 액세스 제어 정책에서 일부 IAM 역할에만 액세스 권한을 부여하고 Amazon Cognito 인증을 구성하지 않은 경우, Dashboards에 액세스하려고 하면 다음과 같은 오류가 발생할 수 있습니다.

"User: anonymous is not authorized to perform: es:ESHttpGet"

OpenSearch Service 도메인에서 VPC 액세스를 사용하는 경우에는 이 오류가 발생하지 않지만 요청 시간이 초과될 수 있습니다. 이 문제를 바로잡는 방법과 사용 가능한 각종 구성 옵션에 대해 알아보려면 대시보드에 대한 액세스 제어 , VPC 도메인의 액세스 정책 정보Amazon OpenSearch Service의 Identity and Access Management 섹션을 참조하세요.

VPC 도메인에 액세스할 수 없습니다.

VPC 도메인의 액세스 정책 정보VPC 도메인 테스트 섹션을 참조하세요.

읽기 전용 상태의 클러스터

이전 Elasticsearch 버전에 비해, OpenSearch 및 Elasticsearch 7.x는 클러스터 조정 시 다른 시스템을 사용합니다. 이 새로운 시스템에서 클러스터가 쿼럼을 잃으면 조치를 할 때까지 클러스터를 사용할 수 없습니다. 쿼럼 손실은 두 가지 형태를 취할 수 있습니다.

  • 클러스터가 전용 프라이머리 노드를 사용하는 경우 절반 이상을 사용할 수 없으면 쿼럼 손실이 발생합니다.

  • 클러스터가 전용 프라이머리 노드를 사용하지 않는 경우 절반 이상의 데이터 노드를 사용할 수 없으면 쿼럼 손실이 발생합니다.

쿼럼 손실이 발생한 경우 클러스터에 둘 이상의 노드가 있으면 OpenSearch Service가 쿼럼을 복원하고 클러스터를 읽기 전용 상태로 설정합니다. 여기에는 두 가지 옵션이 있습니다.

클러스터를 그대로 사용하려면 다음 요청을 사용하여 클러스터 상태가 녹색인지 확인합니다.

GET _cat/health?v

클러스터 상태가 빨간색이면 스냅샷에서 클러스터를 복원하는 것이 좋습니다. 문제 해결 단계는 빨간색 클러스터 상태 섹션을 참조하세요. 클러스터 상태가 녹색이면 다음 요청을 사용하여 모든 예상 인덱스가 있는지 확인합니다.

GET _cat/indices?v

그런 다음 몇 가지 검색을 실행하여 예상 데이터가 있는지 확인합니다. 예상 데이터가 있으면 다음 요청을 사용하여 읽기 전용 상태를 제거할 수 있습니다.

PUT _cluster/settings { "persistent": { "cluster.blocks.read_only": false } }

쿼럼 손실이 발생한 경우 클러스터에 노드가 하나만 있으면 OpenSearch Service가 노드를 교체하고 클러스터를 읽기 전용 상태로 설정하지 않습니다. 그렇지 않은 경우에는 방법이 동일합니다. 클러스터를 그대로 사용하거나 스냅샷에서 복원합니다.

두 상황 모두 OpenSearch Service는 AWS Health Dashboard에 두 개의 이벤트를 전송합니다. 첫 번째 이벤트는 쿼럼의 손실을 알려줍니다. 두 번째 이벤트는 OpenSearch Service가 쿼럼을 성공적으로 복원한 후에 발생합니다. AWS Health Dashboard 사용에 대한 자세한 내용은 AWS Health 사용 설명서를 참조하세요.

빨간색 클러스터 상태

빨간색 클러스터 상태는 하나 이상의 기본 샤드와 복제본이 노드에 할당되어 있지 않음을 나타냅니다. OpenSearch Service는 상태와 관계없이 모든 인덱스의 자동 스냅샷을 만들려고 시도하지만 빨간색 클러스터 상태가 지속되는 동안에는 스냅샷이 실패합니다.

빨간색 클러스터 상태의 가장 흔한 원인은 실패한 클러스터 노드 및 OpenSearch 처리 작업 부하가 지속해서 높아서 발생한 프로세스 충돌입니다.

참고

OpenSearch Service는 클러스터 상태와 관계없이 14일 동안 자동 스냅샷을 저장합니다. 따라서, 빨간색 클러스터 상태가 2주 이상 지속되면 마지막 정상적인 자동 스냅샷이 삭제되고 클러스터의 데이터가 영구적으로 손실될 수 있습니다. OpenSearch Service 도메인이 빨간색 클러스터 상태가 되면 Support에서 연락해 문제를 직접 해결할 것인지 아니면 지원팀의 도움을 원하는지 묻는 경우도 있습니다. 빨간색 클러스터 상태가 발생할 경우 이를 알려주는 CloudWatch 경보를 설정할 수 있습니다.

빨간색 샤드는 빨간색 클러스터를 초래하고, 빨간색 인덱스는 빨간색 샤드를 초래합니다. 빨간색 클러스터 상태를 초래하는 인덱스를 식별하기 위해 OpenSearch는 몇 가지 유용한 API를 제공합니다.

  • GET /_cluster/allocation/explain은 할당되지 않은 첫 번째 샤드를 선택하고, 노드에 할당되지 못한 이유를 확인하여 보여줍니다.

    { "index": "test4", "shard": 0, "primary": true, "current_state": "unassigned", "can_allocate": "no", "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes" }
  • GET /_cat/indices?v는 각 인덱스의 상태, 문서 수, 디스크 사용량을 보여줍니다.

    health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open test1 30h1EiMvS5uAFr2t5CEVoQ 5 0 820 0 14mb 14mb green open test2 sdIxs_WDT56afFGu5KPbFQ 1 0 0 0 233b 233b green open test3 GGRZp_TBRZuSaZpAGk2pmw 1 1 2 0 14.7kb 7.3kb red open test4 BJxfAErbTtu5HBjIXJV_7A 1 0 green open test5 _8C6MIXOSxCqVYicH3jsEA 1 0 7 0 24.3kb 24.3kb

빨간색 인덱스를 삭제하는 것은 빨간색 클러스터 상태를 해결하는 가장 빠른 방법입니다. 빨간색 클러스터 상태의 이유에 따라 OpenSearch Service 도메인을 확장하여 더 큰 인스턴스 유형, 더 많은 인스턴스 또는 더 많은 EBS 기반 스토리지를 사용하도록 한 후 문제가 발생한 인덱스를 다시 생성해 볼 수 있습니다.

문제가 발생한 인덱스가 삭제되지 않으면 스냅샷을 복원하거나, 인덱스에서 문서를 삭제하거나, 인덱스 설정을 변경하거나, 복제본 수를 줄이거나, 다른 인덱스를 삭제하여 디스크 공간을 확보합니다. OpenSearch Service 도메인을 재구성하기 전에 빨간색 클러스터 상태를 해결하는 것이 중요합니다. 빨간색 클러스터가 있는 도메인을 다시 구성할 경우 문제가 심각해져서 상태를 해결할 때까지 도메인이 처리 중 구성 상태로 중단될 수 있습니다.

빨간색 클러스터의 자동 수정

클러스터의 상태가 1시간 이상 지속적으로 빨간색으로 표시되면 OpenSearch Service는 할당되지 않은 샤드를 다시 라우팅하거나 이전 스냅샷에서 복원하여 자동으로 문제를 해결하려고 시도합니다.

하나 이상의 빨간색 인덱스를 수정하지 못하고 클러스터 상태가 총 14일 동안 빨간색으로 유지되는 경우 OpenSearch Service는 클러스터가 다음 기준 중 1개 이상을 충족하는 경우에만 추가 조치를 합니다.

  • 가용 영역이 하나만 있음

  • 전용 프라이머리 노드 없음

  • 버스트 가능한 인스턴스 유형(T2 또는 T3) 포함

현재 클러스터가 이러한 기준 중 하나를 충족하면 OpenSearch Service가 이러한 인덱스를 수정하지 않으면 할당되지 않은 모든 샤드가 삭제됨을 설명하는 알림을 다음 7일 동안 매일 전송합니다. 21일 후에도 클러스터 상태가 여전히 빨간색으로 표시되면 OpenSearch Service는 모든 빨간색 인덱스에서 할당되지 않은 샤드(스토리지 및 컴퓨팅)를 삭제합니다. 이러한 각 이벤트에 대한 OpenSearch Service 콘솔의 Notifications(알림) 패널에서 알림을 수신합니다. 자세한 내용은 클러스터 상태 이벤트 단원을 참조하십시오.

지속해서 과도한 처리 로드에서 복구

빨간색 클러스터 상태의 원인이 데이터 노드의 지속해서 과도한 처리 로드인지 확인하려면 다음 클러스터 지표를 모니터링합니다.

관련 측정치 설명 복구
JVMMemoryPressure

클러스터의 모든 데이터 노드에 사용되는 Java 힙의 비율을 지정합니다. 이 지표의 Maximum(최대) 통계를 모니터링하면서 Java 가비지 수집기가 충분한 메모리를 회수하지 못하여 메모리 압력 감소가 점차 작아지는 때를 찾습니다. 복합 쿼리 또는 큰 데이터 필드가 이러한 패턴의 원인일 수 있습니다.

x86 인스턴스 유형은 일시 중지 시간을 짧게 하기 위해 애플리케이션 스레드와 함께 실행되는 Concurrent Mark Sweep(CMS) 가비지 수집기를 사용합니다. CMS가 정상 수집 중에 충분한 메모리를 회수하지 못하면 전체 가비지 수집이 트리거되어 애플리케이션이 일시 중지되므로 클러스터 안정성에 영향을 줄 수 있습니다.

ARM 기반 Graviton 인스턴스 유형은 CMS와 유사한 Garbage-First(G1) 가비지 수집기를 사용하지만 추가적인 짧은 일시 중지 및 힙 조각 모음 기능을 사용하여 전체 가비지 수집의 필요성을 더욱 줄입니다.

두 경우 모두 전체 가비지 수집 중에 가비지 수집기가 회수할 수 있는 용량 이상으로 메모리 사용량이 계속 증가하면 메모리 부족 오류가 발생하며 OpenSearch가 작동을 멈춥니다. 모든 인스턴스 유형에서 사용량을 80% 미만으로 유지하는 것이 좋습니다.

_nodes/stats/jvm API는 JVM 통계와 메모리 풀 사용량, 그리고 가비지 수집 정보를 유용하게 요약하여 제공합니다.

GET domain-endpoint/_nodes/stats/jvm?pretty

JVM에 대해 메모리 회로 차단기를 설정합니다. 자세한 내용은 JVM OutOfMemoryError 단원을 참조하십시오.

그래도 문제가 지속되면 불필요한 인덱스를 삭제하거나, 도메인에 대한 요청 수 또는 복잡성을 줄이거나, 인스턴스를 추가하거나, 더욱 큰 용량의 인스턴스 유형을 사용합니다.

CPUUtilization 클러스터의 데이터 노드에 사용되는 CPU 리소스의 비율을 지정합니다. 이 지표에 대한 Maximum(최대) 통계를 보고 지속해서 높은 사용 패턴이 있는지 찾습니다. 데이터 노드를 추가하거나 기존 데이터 노드의 인스턴스 유형 크기를 늘립니다.
Nodes(노드) 클러스터에 있는 노드 수를 지정합니다. 이 지표에 대한 Minimum(최소) 통계를 봅니다. 서비스에서 클러스터에 새 인스턴스 집합을 배포하는 경우 이 값이 변동됩니다. 데이터 노드를 추가합니다.

노란색 클러스터 상태

노란색 클러스터 상태는 모든 인덱스의 기본 샤드가 클러스터의 노드에 할당되어 있지만 하나 이상의 인덱스에 복제본 샤드가 할당되어 있지 않음을 나타냅니다. 단일 노드 클러스터는 OpenSearch Service가 복제본을 할당할 수 있는 다른 노드가 없기 때문에 항상 노란색 클러스터 상태로 초기화됩니다. 녹색 클러스터 상태가 되려면 노드 개수를 늘립니다. 자세한 내용은 Amazon OpenSearch Service 도메인 크기 조정 섹션을 참조하세요.

새 인덱스를 생성한 후 또는 노드 실패 후에 다중 노드 클러스터가 잠시 노란색 클러스터 상태가 될 수 있습니다. OpenSearch가 클러스터 전체에 데이터를 복제하면 이 상태는 자체 해결됩니다. 디스크 공간 부족이 노란색 클러스터 상태를 일으킬 수도 있습니다. 클러스터는 노드를 수용할 디스크 공간이 있는 경우에만 복제본 샤드를 배포할 수 있습니다.

ClusterBlockException

다음과 같은 이유로 ClusterBlockException 오류가 발생할 수 있습니다.

사용 가능한 스토리지 공간 부족

클러스터에 있는 하나 이상의 노드에 저장 공간이 최소값인 1) 사용 가능한 저장 공간의 20% 또는 2) 저장 공간 20GiB보다 작은 경우 문서 추가 및 인덱스 생성과 같은 기본적인 쓰기 작업이 실패하기 시작할 수 있습니다. 스토리지 요구 사항 계산에서는 OpenSearch Service가 디스크 공간을 사용하는 방법에 대한 요약을 제공합니다.

문제를 방지하려면 OpenSearch Service 콘솔의 FreeStorageSpace 지표를 모니터링하여 FreeStorageSpace가 특정 임계값 아래로 떨어지면 트리거하는 CloudWatch 경보를 생성합니다. 또한 GET /_cat/allocation?v은 샤드 할당 및 디스크 사용에 대한 유용한 요약 정보를 제공합니다. 스토리지 공간 부족과 관련된 문제를 해결하려면 더 큰 인스턴스 유형, 더 많은 인스턴스 또는 더 많은 EBS 기반 스토리지를 사용하도록 OpenSearch Service 도메인을 확장합니다.

높은 JVM 메모리 압력

JVMMemoryPressure 지표가 30분간 92%를 초과하면 OpenSearch Service는 보호 메커니즘을 트리거하고 모든 쓰기 작업을 차단하여 클러스터가 빨간색 상태가 되지 않도록 합니다. 보호가 설정되면 ClusterBlockException 오류가 뜨면서 쓰기 작업에 실패하고, 새 인덱스를 만들 수 없고, IndexCreateBlockException 오류가 발생합니다.

JVMMemoryPressure 지표가 5분간 88% 이하로 돌아가면 이 보호 조치는 비활성화되고 클러스터에 대한 쓰기 작업이 다시 허용됩니다.

높은 JVM 메모리 압력은 클러스터에 대한 요청 수가 급증하거나, 노드 간 샤드 할당이 불균형하거나, 클러스터에 샤드가 너무 많거나, 필드 데이터 또는 인덱스 매핑이 폭발적으로 증가하거나, 들어오는 부하를 처리할 수 없는 인스턴스 유형 등으로 인해 발생할 수 있습니다. 쿼리에 집계, 와일드카드 또는 광범위한 시간 범위를 사용하는 경우에도 발생할 수 있습니다.

클러스터에 대한 트래픽을 줄이고 JVM 메모리가 많이 소모되는 문제를 해결하려면, 다음 중 하나 이상을 시도해 보세요.

  • 노드당 최대 힙 크기가 32GB가 되도록 도메인을 조정하세요.

  • 오래되거나 사용되지 않는 인덱스를 삭제하여 샤드 수를 줄이세요.

  • POST index-name/_cache/clear?fielddata=true API 작업으로 데이터 캐시를 지우세요. 캐시를 지우면 진행 중인 쿼리가 중단될 수 있다는 점에 유의하시기 바랍니다.

일반적으로, 이후 높은 JVM 메모리 압력을 방지하려면 다음 모범 사례를 따르세요.

Multi-AZ with Standby로의 마이그레이션 오류

기존 도메인을 Multi-AZ with standby로 마이그레이션할 때 다음과 같은 문제가 발생할 수 있습니다.

대기 모드가 없는 도메인에서 대기 모드가 있는 도메인으로 마이그레이션하는 동안 인덱스, 인덱스 템플릿 또는 ISM 정책 생성

Multi-AZ without Standby에서 Multi-AZ with Standby로 도메인을 마이그레이션하는 동안 인덱스를 생성하고 인덱스 템플릿 또는 ISM 정책이 권장 데이터 복사 지침을 따르지 않으면 데이터 불일치가 발생하고 마이그레이션이 실패할 수 있습니다. 이러한 상황을 방지하려면 데이터 복사 횟수(프라이머리 노드와 복제본 모두 포함)가 3의 배수인 새 인덱스를 만드십시오. DescribeDomainChangeProgress API를 사용하여 마이그레이션 진행 상황을 확인할 수 있습니다. 복제본 개수 오류가 발생하는 경우 오류를 수정한 다음 AWSSupport에 문의하여 마이그레이션을 다시 시도하세요.

잘못된 데이터 복사본 수

도메인에 적절한 수의 데이터 사본이 없는 경우 Multi-AZ with Standby로 마이그레이션하는 작업이 실패합니다.

JVM OutOfMemoryError

JVM OutOfMemoryError는 일반적으로 다음 JVM 회로 차단기 중 하나에 도달했음을 의미합니다.

회로 차단기 설명 클러스터 설정 속성
상위 차단기 모든 회로 차단기에 대해 허용되는 JVM 힙 메모의 총비율입니다. 기본값은 95%입니다. indices.breaker.total.limit
필드 데이터 차단기 메모리에 단일 데이터 필드를 로드하도록 허용된 JVM 힙 메모리의 비율입니다. 기본값은 40%입니다. 큰 필드가 포함된 데이터를 업로드하는 경우에는 이 제한을 늘려야 할 수 있습니다. indices.breaker.fielddata.limit
요청 차단기 서비스 요청에 응답하는 데 사용되는 데이터 구조에 대해 허용되는 JVM 힙 메모리의 비율입니다. 기본값은 60%입니다. 서비스 요청에 집계 계산이 포함된 경우 이 제한을 늘려야 할 수 있습니다. indices.breaker.request.limit

실패한 클러스터 노드

Amazon EC2 인스턴스가 예기치 않게 종료되고 다시 시작될 수 있습니다. 일반적으로 OpenSearch Service는 노드를 자동으로 다시 시작합니다. 그러나 OpenSearch 클러스터의 노드 하나 이상에서 실패 조건이 남아 있을 수 있습니다.

이러한 조건이 있는지 확인하려면 OpenSearch Service 콘솔에서 도메인 대시보드를 엽니다. Cluster health(클러스터 상태) 탭으로 이동한 후 Total nodes(총 노드) 지표를 찾습니다. 보고된 노드 수가 클러스터에 대해 구성한 노드 수보다 적은지 확인합니다. 이 지표가 하나 이상의 노드가 하루 이상 다운되었음을 표시하면 AWS Support에 문의하세요.

이런 문제가 발생할 경우 이를 알려주는 CloudWatch 경보를 설정할 수도 있습니다.

참고

클러스터 구성 변경 중 그리고 서비스에 대한 정기 유지보수 중에는 Total nodes(총 노드) 지표가 정확하지 않습니다. 이는 예상된 동작입니다. 따라서 이 지표는 곧 정확한 클러스터 노드 개수를 보고합니다. 자세한 내용은 Amazon OpenSearch Service에서 구성 변경 섹션을 참조하세요.

예기치 않은 노드 종료 및 다시 시작으로부터 클러스터를 보호하려면 OpenSearch Service 도메인의 각 인덱스에 대해 복제본을 하나 이상 생성합니다.

최대 샤드 제한 초과

OpenSearch뿐만 아니라 Elasticsearch 7.x 버전의 기본 설정에는 노드당 1,000개 이하의 샤드가 있습니다. 새 인덱스 생성과 같은 요청으로 인해 이 제한을 초과하는 경우 OpenSearch/ElasticSearch에서 오류가 발생합니다. 이 오류가 발생한 경우 몇 가지 옵션이 있습니다.

  • 더 많은 데이터 노드를 클러스터에 추가합니다.

  • _cluster/settings/cluster.max_shards_per_node 설정을 늘립니다.

  • _shrink API를 사용하여 노드의 샤드 수를 줄입니다.

도메인이 처리 상태에 멈춤

구성 변경 중일 때 OpenSearch Service 도메인은 “처리 중(Processing)” 상태가 됩니다. 구성 변경을 시작하면 도메인 상태가 처리 중(Processing)으로 변경되며 OpenSearch Service가 새 환경을 생성합니다. 새로운 환경에서 OpenSearch Service는 새로운 적용 가능한 노드(예: 데이터, 마스터 또는 UltraWarm) 세트를 시작합니다. 마이그레이션이 완료되면 이전 노드가 종료됩니다.

다음과 같은 상황 중 하나가 발생하는 경우 클러스터가 “처리 중(Processing)” 상태로 멈출 수 있습니다.

  • 새 데이터 노드 집합이 시작되지 않습니다.

  • 새 데이터 노드 집합으로의 샤드 마이그레이션이 실패했습니다.

  • 오류가 발생하여 유효성 검사에 실패했습니다.

이러한 각 상황에 대한 자세한 해결 단계는 Amazon OpenSearch Service 도메인이 “처리 중(Processing)” 상태로 멈춘 이유는 무엇입니까?를 참조하세요.

낮은 EBS 버스트 밸런스

범용(SSD) 볼륨 중 하나의 EBS 버스트 밸런스가 70% 미만이면 OpenSearch Service에서 콘솔 알림을 보내고, 밸런스가 20% 미만으로 떨어지면 후속 알림을 보냅니다. 이 문제를 해결하려면 클러스터를 스케일 업하거나, 읽기 및 쓰기 IOPS를 줄여 버스트 밸런스가 반영되도록 할 수 있습니다. gp3 볼륨 유형이 있는 도메인과 볼륨 크기가 1000GiB를 초과하는 gp2 볼륨이 있는 도메인의 경우 버스트 균형은 0으로 유지됩니다. 자세한 정보는 범용 SSD 볼륨(gp2)을 참조하세요. BurstBalance CloudWatch 지표를 사용하여 EBS 버스트 밸런스를 모니터링할 수 있습니다.

감사 로그를 활성화할 수 없음

OpenSearch Service 콘솔을 사용하여 감사 로그 게시를 활성화하려고 하면 다음 오류가 발생할 수 있습니다.

CloudWatch Logs 로그 그룹에 대해 지정된 리소스 액세스 정책은 Amazon OpenSearch Service에서 로그 스트림을 생성할 수 있는 충분한 권한을 부여하지 않습니다. 리소스 액세스 정책을 확인하세요.

이 오류가 발생하면 정책의 resource 요소에 올바른 로그 그룹 ARN 이 포함되었는지 확인합니다. 포함되었다면 다음 단계를 수행합니다.

  1. 몇 분 정도 기다립니다.

  2. 웹 브라우저에서 페이지를 새로 고칩니다.

  3. Select existing group(기존 그룹 선택)을 선택합니다.

  4. Existing log group(기존 로그 그룹)에서 오류 메시지를 받기 전에 생성한 로그 그룹을 선택합니다.

  5. 액세스 정책 섹션에서 Select existing policy(기존 정책 선택)를 선택합니다.

  6. Existing policy(기존 정책)에서 오류 메시지를 받기 전에 생성한 정책을 선택합니다.

  7. Enable(활성화)를 선택합니다.

프로세스를 여러 번 반복한 후에도 오류가 계속되면 AWS Support에 문의하세요.

인덱스를 닫을 수 없음

OpenSearch Service는 OpenSearch 및 Elasticsearch 버전 7.4 이상에서만 _close API를 지원합니다. 이전 버전을 사용하고 있으며 스냅샷에서 인덱스를 복원하는 경우 기존 인덱스를 삭제할 수 있습니다(다시 인덱스를 만들기 전 또는 후).

클라이언트 라이선스 확인

Logstash 및 Beats의 기본 배포판에는 독점 라이선스 검사가 포함되어 있으며 오픈 소스 버전의 OpenSearch에 연결되지 않습니다. 이러한 클라이언트의 Apache 2.0(OSS) 배포판을 OpenSearch Service와 함께 사용해야 합니다.

요청 제한

지속해서 403 Request throttled due to too many requests 또는 429 Too Many Requests 오류가 발생하면 수직 확장을 고려합니다. Amazon OpenSearch Service는 페이로드로 인해 메모리 사용량이 Java 힙의 최대 크기를 초과할 경우 요청을 제한합니다.

노드에 SSH할 수 없음

SSH를 사용하여 OpenSearch 클러스터의 어떤 노드에도 액세스할 수 없고 opensearch.yml을 직접 수정할 수 없습니다. 대신, 콘솔, AWS CLI 또는 SDK를 사용해 도메인을 구성합니다. OpenSearch REST API를 사용하여 몇 가지 클러스터 수준 설정을 지정할 수도 있습니다. 자세한 내용은 Amazon OpenSearch Service API 참조Amazon OpenSearch Service에서 지원되는 작업을(를) 참조하세요.

클러스터 성능에 대한 더 자세한 통찰이 필요한 경우 CloudWatch에 오류 로그 및 느린 로그를 게시할 수 있습니다.

"객체 스토리지 클래스의 경우 유효하지 않음" 스냅샷 오류

OpenSearch Service 스냅샷은 S3 Glacier 스토리지 클래스를 지원하지 않습니다. 스냅샷을 나열하려 할 때 귀하의 S3 버킷이 객체를 S3 Glacier 스토리지 클래스로 전환하는 수명 주기를 갖고 있다면 이 에러가 발생합니다.

버킷으로부터 스냅샷을 복원하려면 S3 Glacier로부터 객체를 복원하고 새로운 버킷으로 복사한 뒤 스냅샷 리포지토리로 새로운 버킷을 등록합니다.

잘못된 호스트 헤더

OpenSearch Service에서는 클라이언트가 요청 헤드에 Host를 지정해야 합니다. 올바른 Host 값은 다음과 같이 https://가 없는 도메인 엔드포인트입니다.

Host: search-my-sample-domain-ih2lhn2ew2scurji.us-west-2.es.amazonaws.com

요청을 수행할 때 Invalid Host Header 오류가 발생하는 경우 클라이언트 또는 프록시의 Host 헤더에 OpenSearch Service 도메인 엔드포인트(예를 들어 IP 주소가 아님)가 포함되는지 확인합니다.

잘못된 M3 인스턴스 유형

OpenSearch Service에서는 OpenSearch 또는 Elasticsearch 버전 6.7 이상을 실행하는 기존 도메인에 M3 인스턴스를 추가하거나 수정할 수 없습니다. Elasticsearch 6.5 및 이전 버전에서 M3 인스턴스를 계속 사용할 수 있습니다.

최신 인스턴스 유형을 선택하는 것이 좋습니다. OpenSearch 또는 Elasticsearch 6.7 이상을 실행하는 도메인의 경우 다음 제한 사항이 적용됩니다.

  • 기존 도메인에서 M3 인스턴스를 사용하지 않는 경우 더 이상 인스턴스로 변경할 수 없습니다.

  • 기존 도메인을 M3 인스턴스 유형에서 다른 인스턴스 유형으로 변경하는 경우 다시 전환할 수 없습니다.

UltraWarm 활성화 후 핫 쿼리의 작동이 중지됨

도메인에 UltraWarm을 활성화할 때 search.max_buckets 설정에 기존 재정의가 없는 경우 OpenSearch Service는 값을 자동으로 10000으로 설정하여 메모리를 많이 사용하는 쿼리가 웜 노드를 포화시키는 것을 방지합니다. 핫 쿼리에서 10,000개 이상의 버킷을 사용하는 경우 UltraWarm을 활성화하면 핫 쿼리의 작동이 중지될 수 있습니다.

Amazon OpenSearch Service의 관리 특성으로 인해 이 설정을 수정할 수 없으므로 지원 사례를 열어 제한을 늘려야 합니다. 한도 증가에는 Premium Support 구독이 필요하지 않습니다.

업그레이드 후 다운그레이드할 수 없음

현재 위치 업그레이드는 되돌릴 수 없지만, AWS Support에 문의하면 새 도메인에서 자동 업그레이드 전 스냅샷을 복원하는 데 도움을 줄 수 있습니다. 예를 들어 Elasticsearch 5.6에서 6.4로 도메인을 업그레이드하는 경우, AWS Support는 새 Elasticsearch 5.6 도메인에서 업그레이드 전 스냅샷을 복원하는 데 도움을 줄 수 있습니다. 원래 도메인의 수동 스냅샷을 생성한 경우, 해당 단계를 직접 수행할 수 있습니다.

모든 AWS 리전에 대한 도메인의 요약 필요

다음 스크립트는 Amazon EC2 describe-regions AWS CLI 명령을 사용하여 OpenSearch Service를 사용할 수 있는 모든 리전 목록을 생성합니다. 그런 다음 각 리전에 대해 list-domain-names를 호출합니다.

for region in `aws ec2 describe-regions --output text | cut -f4` do echo "\nListing domains in region '$region':" aws opensearch list-domain-names --region $region --query 'DomainNames' done

각 리전에 대해 다음 출력을 수신합니다.

Listing domains in region:'us-west-2'... [ { "DomainName": "sample-domain" } ]

OpenSearch Service를 사용할 수 없는 리전은 "엔드포인트 URL에 연결할 수 없음"을 반환합니다.

OpenSearch Dashboards를 사용할 때 브라우저 오류

Dashboards를 사용하여 OpenSearch Service 도메인에서 데이터를 보려고 하면 브라우저가 HTTP 응답 객체에서 서비스 오류 메시지를 래핑합니다. 웹 브라우저에서 일반적으로 사용할 수 있는 개발자 도구(예: Chrome의 개발자 도구)를 사용하여 기본 서비스 오류를 확인하고 디버그 작업을 지원할 수 있습니다.

Chrome에서 서비스 오류를 보려면
  1. Chrome 메뉴 모음에서 View(보기), Developer(개발자), Developer Tools(개발자 도구)를 차례로 선택합니다.

  2. Network(네트워크) 탭을 선택합니다.

  3. Status(상태) 열에서 상태가 500인 HTTP 세션을 선택합니다.

Firefox에서 서비스 오류를 보려면
  1. 메뉴에서 Tools(도구), Web Developer(웹 개발자), Network(네트워크)를 차례로 선택합니다.

  2. 상태가 500인 HTTP 세션을 선택합니다.

  3. Response(응답) 탭을 선택하여 서비스 응답을 봅니다.

노드 샤드 및 스토리지 스큐

노드 샤드 스큐는 클러스터 내의 하나 이상의 노드에 다른 노드보다 훨씬 많은 샤드가 있는 경우입니다. 노드스토리지 스큐는 클러스터 내의 하나 이상의 노드에 다른 노드보다 훨씬 많은 스토리지(disk.indices)가 있는 경우입니다. 도메인에서 노드 하나를 교체했고 여전히 샤드를 노드에 할당 중인 경우처럼 이 두 조건 모두가 일시적으로 발생할 수 있습니다. 그러나 이러한 조건이 지속되는 경우 해결이 필요합니다.

두 가지 유형의 스큐를 모두 식별하려면 _cat/allocation API 작업을 실행하고 응답의 shardsdisk.indices 항목을 비교합니다.

shards | disk.indices | disk.used | disk.avail | disk.total | disk.percent | host | ip | node 264 | 465.3mb | 229.9mb | 1.4tb | 1.5tb | 0 | x.x.x.x | x.x.x.x | node1 115 | 7.9mb | 83.7mb | 49.1gb | 49.2gb | 0 | x.x.x.x | x.x.x.x | node2 264 | 465.3mb | 235.3mb | 1.4tb | 1.5tb | 0 | x.x.x.x | x.x.x.x | node3 116 | 7.9mb | 82.8mb | 49.1gb | 49.2gb | 0 | x.x.x.x | x.x.x.x | node4 115 | 8.4mb | 85mb | 49.1gb | 49.2gb | 0 | x.x.x.x | x.x.x.x | node5

약간의 스토리지 스큐는 정상이지만 평균에서 10%를 초과하는 경우에는 주의해야 합니다. 샤드 배포가 왜곡되면 CPU, 네트워크 및 디스크 대역폭 사용량도 왜곡될 수 있습니다. 일반적으로 데이터가 많을수록 인덱싱 및 검색 작업이 늘어나기 때문에 가장 무거운 노드는 리소스가 가장 많이 사용되는 노드인 반면, 가벼운 노드는 리소스 활용도가 낮음을 나타냅니다.

해결 방법: 데이터 노드 수의 배수인 샤드 수를 사용하여 각 인덱스가 데이터 노드 간에 균등하게 분산되도록 합니다.

인덱스 샤드 및 스토리지 스큐

인덱스 샤드 스큐는 하나 이상의 노드가 다른 노드보다 인덱스의 샤드를 더 많이 보유하는 경우입니다. 인덱스 스토리지 스큐는 하나 이상의 노드가 인덱스의 총 스토리지 중 균형이 안 맞게 많은 양을 보유하는 경우입니다.

인덱스 스큐는 _cat/shards API 출력을 약간 조작해야 하기 때문에 노드 스큐보다 식별하기 어렵습니다. 클러스터 또는 노드 지표에 스큐 징후가 있는 경우 인덱스 스큐를 조사합니다. 인덱스 스큐의 일반 징후는 다음과 같습니다.

  • 데이터 노드의 하위 집합에서 HTTP 429 오류 발생

  • 데이터 노드 전체에서 고르지 않은 인덱스 또는 검색 작업 대기열

  • 데이터 노드 전반에 걸쳐 균일한 JVM 힙 또는 CPU 사용률

해결 방법: 데이터 노드 수의 배수인 샤드 수를 사용하여 각 인덱스가 데이터 노드 간에 균등하게 분산되도록 합니다. 인덱스 저장소 또는 샤드 스큐가 계속 표시되는 경우, OpenSearch Service 도메인의 모든 블루/그린 배포에서 발생하는 샤드 재할당을 강제 실행해야 할 수 있습니다.

VPC 액세스를 선택한 후 허용되지 않은 작업

OpenSearch Service 콘솔을 사용하여 새 도메인을 만들 때 VPC 또는 공용 액세스를 선택하는 옵션이 있습니다. VPC access(VPC 액세스)를 선택할 경우, OpenSearch Service가 VPC 정보를 쿼리하는데, 올바른 정책이 없을 경우 쿼리가 실패합니다.

You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation

이 쿼리를 활성화하려면 ec2:DescribeVpcs, ec2:DescribeSubnetsec2:DescribeSecurityGroups 작업에 대한 액세스 권한이 있어야 합니다. 이 요구 사항은 콘솔에만 해당됩니다. AWS CLI를 사용하여 VPC 엔드포인트를 사용하는 도메인을 만들고 구성하는 경우, 이러한 작업에 액세스할 필요가 없습니다.

VPC 도메인 생성 후 로딩 단계에서 멈춤

VPC 액세스를 사용하는 새 도메인을 만든 후, 도메인의 Configuration state(구성 상태)가 Loading(로드 중)에서 더 이상 진행되지 않을 수 있습니다. 이 문제가 발생할 경우 리전에서 AWS Security Token Service(AWS STS)가 비활성화된 것일 수 있습니다.

VPC 엔드포인트를 VPC에 추가하려면 OpenSearch Service가 AWSServiceRoleForAmazonOpenSearchService 역할을 수임해야 합니다. 따라서 지정된 리전에서 VPC 액세스를 사용하는 새 도메인을 생성하려면 AWS STS가 활성화되어야 합니다. AWS STS 활성화 및 비활성화에 대한 자세한 내용은 IAM 사용 설명서를 참조하세요.

OpenSearch API에 대한 요청 거부됨

OpenSearch API에 태그 기반 액세스 제어를 도입하면서 이전에 없었던 액세스 거부 오류가 나타날 수 있습니다. 하나 이상의 액세스 정책에 ResourceTag 조건을 사용하는 Deny이(가) 포함되어 있고, 이러한 조건이 현재 적용되고 있어서 발생하는 것일 수 있습니다.

예를 들어 다음 정책은 도메인에 environment=production 태그가 있는 경우 구성 API의 CreateDomain 작업 액세스만 거부하는 데 사용되었습니다. ESHttpPut이(가) 작업 목록에도 포함되어 있었지만 해당 작업이나 다른 ESHttp* 작업에는 거부 문이 적용되지 않았습니다.

{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:CreateDomain", "es:ESHttpPut" ], "Effect": "Deny", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] }

OpenSearch HTTP 메서드에 대한 태그 지원이 추가되면서 위와 같은 IAM 자격 증명 기반 정책을 사용하면 연결된 사용자의 ESHttpPut 작업에 대한 액세스가 거부됩니다. 이전에는 태그 유효성 검사가 없어도 연결된 사용자가 PUT 요청을 계속 보낼 수 있었습니다.

도메인을 서비스 소프트웨어 R20220323 이상으로 업데이트한 후 액세스 거부 오류가 표시되기 시작하면 자격 증명 기반 액세스 정책을 확인하여 이러한 경우인지 확인하고 필요하다면 업데이트해 액세스를 부여합니다.

Alpine Linux에서 연결할 수 없음

Alpine Linux는 DNS 응답 크기를 512바이트로 제한합니다. Alpine Linux 버전 3.18.0 이하에서 OpenSearch Service 도메인에 연결하려고 할 때 도메인이 VPC에 있으며 20개가 넘는 노드가 있는 경우 DNS 확인이 실패할 수 있습니다. 3.18.0 이상의 Alpine Linux 버전을 사용하는 경우 20개 이상의 호스트를 해결할 수 있어야 합니다. 자세한 내용은 Alpine Linux 3.18.0 릴리스 정보를 참조하세요.

도메인이 VPC에 있는 경우 Debian, Ubuntu, CentOS, Red Hat Enterprise Linux 또는 Amazon Linux 2 등의 다른 Linux 배포를 사용하여 연결하는 것이 좋습니다.

Search Backpressure에 대한 요청이 너무 많음

CPU 기반 승인 제어는 트래픽의 유기적 증가와 급증 모두에 대해 현재 용량을 기준으로 노드에 대한 요청 수를 사전에 제한하는 게이트키핑 메커니즘입니다. 요청이 너무 많으면 거부 시 HTTP 429 “Too Many Requests” 상태 코드가 반환됩니다. 이 오류는 클러스터 리소스가 부족하거나, 리소스를 많이 사용하는 검색 요청 또는 의도하지 않은 워크로드 급증을 나타냅니다.

Search Backpression은 거부 사유를 제공하므로 리소스를 많이 사용하는 검색 요청을 세밀하게 조정하는 데 도움이 될 수 있습니다. 트래픽이 급증하는 경우 지수 백오프 및 지터를 사용하여 클라이언트측 재시도를 하는 것이 좋습니다.

SDK를 사용할 때 인증서 오류

AWS SDK는 컴퓨터의 CA 인증서를 사용하기 때문에, AWS 서버의 인증서가 변경되면 SDK를 사용하려고 할 때 연결 장애가 발생할 수 있습니다. 오류 메시지는 다양하지만 일반적으로 다음 텍스트가 포함되어 있습니다.

Failed to query OpenSearch ... SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

컴퓨터의 CA 인증서와 운영 체제를 최신 상태로 유지하여 이러한 장애를 피할 수 있습니다. 본인 컴퓨터를 직접 관리하지 않는 기업 환경에서 이 문제가 발생하는 경우, 관리자에게 업데이트 프로세스를 문의해야 할 수 있습니다.

아래 목록에 최소한의 운영 체제 및 Java 버전이 나와 있습니다.

  • 2005년 1월 이후 업데이트가 설치된 Microsoft Windows 버전의 경우, 신뢰할 수 있는 연결 목록에 필요한 CA가 하나 이상 들어 있습니다.

  • Mac OS X 10.4 릴리스 5(2007년 2월), Mac OS X 10.5(2007년 10월) 및 그 이후 버전의 Java가 설치된 Mac OS X 10.4의 경우, 신뢰할 수 있는 연결 목록에 필요한 CA가 하나 이상 들어 있습니다.

  • Red Hat Enterprise Linux 5(2007년 3월), 6, 7과 CentOS 5, 6, 7은 모두 신뢰할 수 있는 기본 CA 목록에 필요한 CA가 하나 이상 들어 있습니다.

  • Java 1.4.2_12(2006년 5월), 5 업데이트 2(2005년 3월), 그리고 Java 6(2006년 12월), 7, 8을 포함한 이후의 모든 버전은 신뢰할 수 있는 기본 CA 목록에 필요한 CA가 하나 이상 들어 있습니다.

인증 기관은 다음 세 곳입니다.

  • Amazon Root CA 1

  • Starfield Services Root Certificate Authority - G2

  • Starfield Class 2 Certification Authority

처음 두 기관의 루트 인증서는 Amazon Trust Services에서 구할 수 있지만, 컴퓨터를 최신 상태로 유지하는 것이 더욱 직접적인 해결책입니다. ACM 제공 인증서에 대한 자세한 내용은 AWS Certificate Manager FAQ 섹션을 참조하세요.

참고

현재 us-east-1 리전의 OpenSearch Service 도메인은 다른 기관의 인증서를 사용합니다. 가까운 시일 안에 이 리전에서도 새 인증 기관을 사용하도록 업데이트할 예정입니다.