기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
아마존 OpenSearch 서비스 문제 해결
이 주제에서는 일반적인 Amazon OpenSearch Service 문제를 식별하고 해결하는 방법을 설명합니다. AWS Support
OpenSearch 대시보드에 액세스할 수 없습니다.
OpenSearch 대시보드 엔드포인트는 서명된 요청을 지원하지 않습니다. 해당 도메인의 액세스 제어 정책에서 일부 IAM 역할에만 액세스 권한을 부여하고 Amazon Cognito 인증을 구성하지 않은 경우, Dashboards에 액세스하려고 하면 다음과 같은 오류가 발생할 수 있습니다.
"User: anonymous is not authorized to perform: es:ESHttpGet"OpenSearch 서비스 도메인이 VPC 액세스를 사용하는 경우 이 오류는 수신되지 않을 수 있지만 요청 시간이 초과될 수 있습니다. 이 문제를 바로잡는 방법과 사용 가능한 각종 구성 옵션에 대해 알아보려면 대시보드 액세스 OpenSearch 제어, VPC 도메인 액세스 정책에 대하여 및 아마존 OpenSearch 서비스의 ID 및 액세스 관리 섹션을 참조하세요.
VPC 도메인에 액세스할 수 없습니다.
VPC 도메인 액세스 정책에 대하여 및 VPC 도메인 테스트 섹션을 참조하세요.
읽기 전용 상태의 클러스터
이전 엘라스틱서치 버전 및 엘라스틱서치 OpenSearch 7과 비교한 결과입니다. x 클러스터 조정을 위해 다른 시스템을 사용합니다. 이 새로운 시스템에서 클러스터가 쿼럼을 잃으면 조치를 할 때까지 클러스터를 사용할 수 없습니다. 쿼럼 손실은 두 가지 형태를 취할 수 있습니다.
-
클러스터가 전용 프라이머리 노드를 사용하는 경우 절반 이상을 사용할 수 없으면 쿼럼 손실이 발생합니다.
-
클러스터가 전용 프라이머리 노드를 사용하지 않는 경우 절반 이상의 데이터 노드를 사용할 수 없으면 쿼럼 손실이 발생합니다.
쿼럼 손실이 발생하고 클러스터에 두 개 이상의 노드가 있는 경우 OpenSearch 서비스는 쿼럼을 복원하고 클러스터를 읽기 전용 상태로 전환합니다. 여기에는 두 가지 옵션이 있습니다.
-
읽기 전용 상태를 제거하고 클러스터를 그대로 사용합니다.
클러스터를 그대로 사용하려면 다음 요청을 사용하여 클러스터 상태가 녹색인지 확인합니다.
GET _cat/health?v
클러스터 상태가 빨간색이면 스냅샷에서 클러스터를 복원하는 것이 좋습니다. 문제 해결 단계는 빨간색 클러스터 상태 섹션을 참조하세요. 클러스터 상태가 녹색이면 다음 요청을 사용하여 모든 예상 인덱스가 있는지 확인합니다.
GET _cat/indices?v
그런 다음 몇 가지 검색을 실행하여 예상 데이터가 있는지 확인합니다. 예상 데이터가 있으면 다음 요청을 사용하여 읽기 전용 상태를 제거할 수 있습니다.
PUT _cluster/settings { "persistent": { "cluster.blocks.read_only": false } }
쿼럼 손실이 발생하고 클러스터에 노드가 하나뿐인 경우 OpenSearch 서비스는 노드를 대체하고 클러스터를 읽기 전용 상태로 전환하지 않습니다. 그렇지 않은 경우에는 방법이 동일합니다. 클러스터를 그대로 사용하거나 스냅샷에서 복원합니다.
두 경우 모두 OpenSearch 서비스는 사용자에게 두 개의 이벤트를 전송합니다. AWS Health Dashboard
빨간색 클러스터 상태
빨간색 클러스터 상태는 하나 이상의 기본 샤드와 해당 복제본이 노드에 할당되지 않았음을 의미합니다. OpenSearch 서비스는 상태에 관계없이 모든 인덱스의 자동 스냅샷을 만들려고 계속 시도하지만 빨간색 클러스터 상태가 지속되는 동안에는 스냅샷이 실패합니다.
빨간색 클러스터 상태가 나타나는 가장 일반적인 원인은 클러스터 노드에 장애가 발생하거나 지속적인 과도한 처리 부하로 인한 OpenSearch 프로세스 충돌입니다.
참고
OpenSearch 서비스는 클러스터 상태에 관계없이 14일 동안 자동 스냅샷을 저장합니다. 따라서, 빨간색 클러스터 상태가 2주 이상 지속되면 마지막 정상적인 자동 스냅샷이 삭제되고 클러스터의 데이터가 영구적으로 손실될 수 있습니다. OpenSearch 서비스 도메인이 빨간색 클러스터 상태가 되면 AWS 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
빨간색 인덱스를 삭제하는 것은 빨간색 클러스터 상태를 해결하는 가장 빠른 방법입니다. 빨간색 클러스터 상태의 이유에 따라 더 큰 인스턴스 유형, 더 많은 인스턴스 또는 더 많은 EBS 기반 스토리지를 사용하도록 OpenSearch 서비스 도메인을 확장하고 문제가 되는 인덱스를 다시 생성해 볼 수 있습니다.
문제가 발생한 인덱스가 삭제되지 않으면 스냅샷을 복원하거나, 인덱스에서 문서를 삭제하거나, 인덱스 설정을 변경하거나, 복제본 수를 줄이거나, 다른 인덱스를 삭제하여 디스크 공간을 확보합니다. 중요한 단계는 서비스 도메인을 재구성하기 전에 빨간색 클러스터 상태를 해결하는 것입니다. OpenSearch 빨간색 클러스터가 있는 도메인을 다시 구성할 경우 문제가 심각해져서 상태를 해결할 때까지 도메인이 처리 중 구성 상태로 중단될 수 있습니다.
빨간색 클러스터의 자동 수정
클러스터의 상태가 1시간 이상 계속 빨간색으로 표시되면 OpenSearch 서비스는 할당되지 않은 샤드를 다시 라우팅하거나 이전 스냅샷에서 복원하여 자동으로 문제를 해결하려고 시도합니다.
빨간색 인덱스를 하나 이상 수정하지 못하고 클러스터 상태가 총 14일 동안 빨간색으로 유지되는 경우 OpenSearch 서비스는 클러스터가 다음 기준 중 하나 이상을 충족하는 경우에만 추가 조치를 취합니다.
-
가용 영역이 하나만 있음
-
전용 프라이머리 노드 없음
-
버스트 가능한 인스턴스 유형(T2 또는 T3) 포함
현재 클러스터가 이러한 기준 중 하나를 충족하는 경우 OpenSearch 서비스는 향후 7일 동안 이러한 인덱스를 수정하지 않으면 할당되지 않은 샤드가 모두 삭제된다는 내용을 설명하는 일일 알림을 보냅니다. 21일 후에도 클러스터 상태가 여전히 빨간색으로 표시되면 OpenSearch 서비스는 모든 빨간색 인덱스에서 할당되지 않은 샤드 (스토리지 및 컴퓨팅) 를 삭제합니다. 이러한 각 이벤트에 대해 OpenSearch 서비스 콘솔의 알림 패널에서 알림을 받게 됩니다. 자세한 정보는 클러스터 상태 이벤트을 참조하세요.
지속해서 과도한 처리 로드에서 복구
빨간색 클러스터 상태의 원인이 데이터 노드의 지속해서 과도한 처리 로드인지 확인하려면 다음 클러스터 지표를 모니터링합니다.
| 관련 측정치 | 설명 | 복구 |
|---|---|---|
| JVM MemoryPressure |
클러스터의 모든 데이터 노드에 사용되는 Java 힙의 비율을 지정합니다. 이 지표의 Maximum(최대) 통계를 모니터링하면서 Java 가비지 수집기가 충분한 메모리를 회수하지 못하여 메모리 압력 감소가 점차 작아지는 때를 찾습니다. 복합 쿼리 또는 큰 데이터 필드가 이러한 패턴의 원인일 수 있습니다. x86 인스턴스 유형은 일시 중지 시간을 짧게 하기 위해 애플리케이션 스레드와 함께 실행되는 Concurrent Mark Sweep(CMS) 가비지 수집기를 사용합니다. CMS가 정상 수집 중에 충분한 메모리를 회수하지 못하면 전체 가비지 수집이 트리거되어 애플리케이션이 일시 중지되므로 클러스터 안정성에 영향을 줄 수 있습니다. ARM 기반 Graviton 인스턴스 유형은 CMS와 유사한 Garbage-First(G1) 가비지 수집기를 사용하지만 추가적인 짧은 일시 중지 및 힙 조각 모음 기능을 사용하여 전체 가비지 수집의 필요성을 더욱 줄입니다. 어느 경우든 전체 가비지 컬렉션 중에 가비지 컬렉터가 회수할 수 있는 양보다 메모리 사용량이 계속 증가하면 메모리 부족 오류와 함께 OpenSearch 충돌이 발생합니다. 모든 인스턴스 유형에서 사용량을 80% 미만으로 유지하는 것이 좋습니다.
|
JVM에 대해 메모리 회로 차단기를 설정합니다. 자세한 정보는 JVM OutOfMemoryError을 참조하세요. 그래도 문제가 지속되면 불필요한 인덱스를 삭제하거나, 도메인에 대한 요청 수 또는 복잡성을 줄이거나, 인스턴스를 추가하거나, 더욱 큰 용량의 인스턴스 유형을 사용합니다. |
| CPUUtilization | 클러스터의 데이터 노드에 사용되는 CPU 리소스의 비율을 지정합니다. 이 지표에 대한 Maximum(최대) 통계를 보고 지속해서 높은 사용 패턴이 있는지 찾습니다. | 데이터 노드를 추가하거나 기존 데이터 노드의 인스턴스 유형 크기를 늘립니다. |
| Nodes(노드) | 클러스터에 있는 노드 수를 지정합니다. 이 지표에 대한 Minimum(최소) 통계를 봅니다. 서비스에서 클러스터에 새 인스턴스 집합을 배포하는 경우 이 값이 변동됩니다. | 데이터 노드를 추가합니다. |
노란색 클러스터 상태
노란색 클러스터 상태는 모든 인덱스의 기본 샤드가 클러스터의 노드에 할당되어 있지만 하나 이상의 인덱스에 복제본 샤드가 할당되어 있지 않음을 나타냅니다. OpenSearch 서비스가 복제본을 할당할 수 있는 다른 노드가 없기 때문에 단일 노드 클러스터는 항상 노란색 클러스터 상태로 초기화됩니다. 녹색 클러스터 상태가 되려면 노드 개수를 늘립니다. 자세한 내용은 아마존 OpenSearch 서비스 도메인 크기 조정 섹션을 참조하세요.
새 인덱스를 생성한 후 또는 노드 실패 후에 다중 노드 클러스터가 잠시 노란색 클러스터 상태가 될 수 있습니다. 이 상태는 클러스터 전체에 OpenSearch 데이터를 복제할 때 자체 확인됩니다. 디스크 공간 부족이 노란색 클러스터 상태를 일으킬 수도 있습니다. 클러스터는 노드를 수용할 디스크 공간이 있는 경우에만 복제본 샤드를 배포할 수 있습니다.
ClusterBlockException
다음과 같은 이유로 ClusterBlockException 오류가 발생할 수 있습니다.
사용 가능한 스토리지 공간 부족
클러스터에 있는 하나 이상의 노드에 스토리지 공간이 최소 값인 1) 사용 가능한 스토리지 공간의 20% 또는 2) 20GiB 미만의 스토리지 공간을 가지고 있는 경우, 문서 추가 및 인덱스 생성과 같은 기본 쓰기 작업이 실패할 수 있습니다. 스토리지 요구 사항 계산 OpenSearch 서비스가 디스크 공간을 사용하는 방법에 대한 요약을 제공합니다.
문제를 방지하려면 OpenSearch 서비스 콘솔에서 FreeStorageSpace 메트릭을 모니터링하고 특정 임계값 아래로 FreeStorageSpace 떨어질 때 트리거되는 CloudWatch 경보를 생성하세요. GET
/_cat/allocation?v또한 샤드 할당 및 디스크 사용에 대한 유용한 요약을 제공합니다. 스토리지 공간 부족과 관련된 문제를 해결하려면 더 큰 인스턴스 유형, 더 많은 인스턴스 또는 더 많은 EBS 기반 스토리지를 사용하도록 OpenSearch 서비스 도메인을 확장하세요.
높은 JVM 메모리 압력
JVM MemoryPressure 지표가 30분 동안 92% 를 초과하면 OpenSearch Service는 보호 메커니즘을 트리거하고 클러스터가 빨간색 상태에 도달하지 않도록 모든 쓰기 작업을 차단합니다. 보호가 설정되면 ClusterBlockException 오류가 뜨면서 쓰기 작업에 실패하고, 새 인덱스를 만들 수 없고, IndexCreateBlockException 오류가 발생합니다.
JVM MemoryPressure 지표가 5분 동안 88% 이하로 돌아오면 보호 기능이 비활성화되고 클러스터에 대한 쓰기 작업이 차단 해제됩니다.
높은 JVM 메모리 압력은 클러스터에 대한 요청 수가 급증하거나, 노드 간 샤드 할당이 불균형하거나, 클러스터에 샤드가 너무 많거나, 필드 데이터 또는 인덱스 매핑이 폭발적으로 증가하거나, 들어오는 부하를 처리할 수 없는 인스턴스 유형 등으로 인해 발생할 수 있습니다. 쿼리에 집계, 와일드카드 또는 광범위한 시간 범위를 사용하는 경우에도 발생할 수 있습니다.
클러스터에 대한 트래픽을 줄이고 JVM 메모리가 많이 소모되는 문제를 해결하려면, 다음 중 하나 이상을 시도해 보세요.
-
노드당 최대 힙 크기가 32GB가 되도록 도메인을 조정하세요.
-
오래되거나 사용되지 않는 인덱스를 삭제하여 샤드 수를 줄이세요.
-
POSTAPI 작업으로 데이터 캐시를 지우세요. 캐시를 지우면 진행 중인 쿼리가 중단될 수 있다는 점에 유의하시기 바랍니다.index-name/_cache/clear?fielddata=true
일반적으로, 이후 높은 JVM 메모리 압력을 방지하려면 다음 모범 사례를 따르세요.
-
텍스트 필드를 집계하거나
keyword에 대한 인덱스의 매핑 형식을 변경하지 않도록 하세요. -
올바른 샤드 수 선택으로 검색 및 인덱싱 요청을 최적화하세요.
-
정기적으로 사용되지 않는 인덱스를 삭제하도록 인덱스 상태 관리(ISM) 정책을 설정하세요.
Multi-AZ with Standby로의 마이그레이션 오류
기존 도메인을 Multi-AZ with standby로 마이그레이션할 때 다음과 같은 문제가 발생할 수 있습니다.
대기 모드가 없는 도메인에서 대기 모드가 있는 도메인으로 마이그레이션하는 동안 인덱스, 인덱스 템플릿 또는 ISM 정책 생성
Multi-AZ without Standby에서 Multi-AZ with Standby로 도메인을 마이그레이션하는 동안 인덱스를 생성하고 인덱스 템플릿 또는 ISM 정책이 권장 데이터 복사 지침을 따르지 않으면 데이터 불일치가 발생하고 마이그레이션이 실패할 수 있습니다. 이러한 상황을 방지하려면 데이터 복사 횟수(프라이머리 노드와 복제본 모두 포함)가 3의 배수인 새 인덱스를 만드십시오. DescribeDomainChangeProgress API를 사용하여 마이그레이션 진행 상황을 확인할 수 있습니다. 복제본 개수 오류가 발생하는 경우 오류를 수정한 다음 AWS Support
잘못된 데이터 복사본 수
도메인에 적절한 수의 데이터 사본이 없는 경우 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 서비스가 자동으로 노드를 재시작합니다. 하지만 OpenSearch 클러스터에 있는 하나 이상의 노드가 장애 상태로 남아 있을 수 있습니다.
이 상태를 확인하려면 OpenSearch 서비스 콘솔에서 도메인 대시보드를 여십시오. Cluster health(클러스터 상태) 탭으로 이동한 후 Total nodes(총 노드) 지표를 찾습니다. 보고된 노드 수가 클러스터에 대해 구성한 노드 수보다 적은지 확인합니다. 이 지표가 하나 이상의 노드가 하루 이상 다운되었음을 표시하면 AWS Support
이 문제가 발생할 때 알리도록 CloudWatch 경보를 설정할 수도 있습니다.
참고
클러스터 구성 변경 중 그리고 서비스에 대한 정기 유지보수 중에는 Total nodes(총 노드) 지표가 정확하지 않습니다. 이는 예상된 동작입니다. 따라서 이 지표는 곧 정확한 클러스터 노드 개수를 보고합니다. 자세한 내용은 Amazon OpenSearch 서비스에서 구성 변경 섹션을 참조하세요.
예기치 않은 노드 종료 및 재시작으로부터 클러스터를 보호하려면 서비스 도메인의 각 인덱스에 대해 하나 이상의 복제본을 생성하십시오 OpenSearch .
최대 샤드 제한 초과
OpenSearch 뿐만 아니라 7. x 버전의 Elasticsearch에는 노드당 1,000개 이하의 샤드가 기본 설정되어 있습니다. OpenSearch/Elasticsearch는 새 인덱스 생성과 같은 요청으로 인해 이 한도를 초과하는 경우 오류가 발생합니다. 이 오류가 발생한 경우 몇 가지 옵션이 있습니다.
-
더 많은 데이터 노드를 클러스터에 추가합니다.
-
_cluster/settings/cluster.max_shards_per_node설정을 늘립니다. -
_shrink API를 사용하여 노드의 샤드 수를 줄입니다.
도메인이 처리 상태에 멈춤
구성 변경 도중에는 OpenSearch 서비스 도메인이 “처리 중” 상태가 됩니다. 구성 변경을 시작하면 OpenSearch 서비스가 새 환경을 생성하는 동안 도메인 상태가 “처리 중”으로 변경됩니다. 새 환경에서 OpenSearch 서비스는 적용 가능한 새 노드 세트 (예: 데이터, 마스터 또는 UltraWarm) 를 시작합니다. 마이그레이션이 완료되면 이전 노드가 종료됩니다.
다음과 같은 상황 중 하나가 발생하는 경우 클러스터가 “처리 중(Processing)” 상태로 멈출 수 있습니다.
-
새 데이터 노드 집합이 시작되지 않습니다.
-
새 데이터 노드 집합으로의 샤드 마이그레이션이 실패했습니다.
-
오류가 발생하여 유효성 검사에 실패했습니다.
각 상황의 자세한 해결 단계는 Amazon OpenSearch Service 도메인이 “처리 중” 상태에서 멈춘 이유를
낮은 EBS 버스트 밸런스
OpenSearch 범용 (SSD) 볼륨 중 하나의 EBS 버스트 밸런스가 70% 미만이면 서비스에서 콘솔 알림을 보내고 밸런스가 20% 미만으로 떨어지면 후속 알림을 보냅니다. 이 문제를 해결하려면 클러스터를 스케일 업하거나, 읽기 및 쓰기 IOPS를 줄여 버스트 밸런스가 반영되도록 할 수 있습니다. gp3 볼륨 유형이 있는 도메인과 볼륨 크기가 1000GiB를 초과하는 gp2 볼륨이 있는 도메인의 경우 버스트 균형은 0으로 유지됩니다. 자세한 정보는 범용 SSD 볼륨(gp2)을 참조하세요. 지표로 EBS 버스트 밸런스를 모니터링할 수 있습니다. BurstBalance CloudWatch
감사 로그를 활성화할 수 없음
OpenSearch 서비스 콘솔을 사용하여 감사 로그 게시를 활성화하려고 할 때 다음 오류가 발생할 수 있습니다.
로그 로그 그룹에 지정된 리소스 액세스 정책은 Amazon OpenSearch Service에서 CloudWatch 로그 스트림을 생성할 수 있는 충분한 권한을 부여하지 않습니다. 리소스 액세스 정책을 확인하세요.
이 오류가 발생하면 정책의 resource 요소에 올바른 로그 그룹 ARN 이 포함되었는지 확인합니다. 포함되었다면 다음 단계를 수행합니다.
-
몇 분 정도 기다립니다.
-
웹 브라우저에서 페이지를 새로 고칩니다.
-
Select existing group(기존 그룹 선택)을 선택합니다.
-
Existing log group(기존 로그 그룹)에서 오류 메시지를 받기 전에 생성한 로그 그룹을 선택합니다.
-
액세스 정책 섹션에서 Select existing policy(기존 정책 선택)를 선택합니다.
-
Existing policy(기존 정책)에서 오류 메시지를 받기 전에 생성한 정책을 선택합니다.
-
Enable(활성화)를 선택합니다.
프로세스를 여러 번 반복한 후에도 오류가 계속되면 AWS Support
인덱스를 닫을 수 없음
OpenSearch 이 서비스는 Elasticsearch 버전 7.4 이상에서만 _close
클라이언트 라이선스 확인
Logstash와 Beats의 기본 배포에는 독점 라이선스 검사가 포함되어 있으며 의 오픈 소스 버전에 연결할 수 없습니다. OpenSearch 서비스와 함께 이러한 클라이언트의 Apache 2.0 (OSS) 배포판을 사용해야 합니다. OpenSearch
요청 제한
지속해서 403 Request throttled due to too many requests 또는 429 Too Many Requests 오류가 발생하면 수직 확장을 고려합니다. Amazon OpenSearch Service는 페이로드로 인해 메모리 사용량이 Java 힙의 최대 크기를 초과하는 경우 요청을 제한합니다.
노드에 SSH할 수 없음
SSH를 사용하여 OpenSearch 클러스터의 어떤 노드에도 액세스할 수 없으며 직접 수정할 수도 없습니다. opensearch.yml 대신 콘솔 또는 SDK를 사용하여 도메인을 구성하세요. AWS CLI OpenSearchREST API를 사용하여 몇 가지 클러스터 수준 설정을 지정할 수도 있습니다. 자세한 내용은 Amazon OpenSearch 서비스 API 참조 및 을 참조하십시오Amazon OpenSearch 서비스에서 지원되는 작업.
클러스터 성능에 대한 더 자세한 정보가 필요한 경우 오류 로그와 슬로우 로그를 에 게시할 수 CloudWatch 있습니다.
"객체 스토리지 클래스의 경우 유효하지 않음" 스냅샷 오류
OpenSearch 서비스 스냅샷은 S3 Glacier 스토리지 클래스를 지원하지 않습니다. 스냅샷을 나열하려 할 때 귀하의 S3 버킷이 객체를 S3 Glacier 스토리지 클래스로 전환하는 수명 주기를 갖고 있다면 이 에러가 발생합니다.
버킷으로부터 스냅샷을 복원하려면 S3 Glacier로부터 객체를 복원하고 새로운 버킷으로 복사한 뒤 스냅샷 리포지토리로 새로운 버킷을 등록합니다.
잘못된 호스트 헤더
OpenSearch 서비스를 사용하려면 클라이언트가 요청 Host 헤더에 지정해야 합니다. 올바른 Host 값은 다음과 같이 https://가 없는 도메인 엔드포인트입니다.
Host: search-my-sample-domain-ih2lhn2ew2scurji.us-west-2.es.amazonaws.com
요청할 때 Invalid Host Header 오류가 발생하는 경우 클라이언트 또는 프록시가 Host 헤더에 OpenSearch 서비스 도메인 엔드포인트 (예: IP 주소 제외) 를 포함하는지 확인하세요.
잘못된 M3 인스턴스 유형
OpenSearch 서비스는 Elasticsearch 버전 6.7 이상을 실행하는 기존 도메인이나 Elasticsearch 버전 6.7 이상을 실행하는 OpenSearch 기존 도메인에 M3 인스턴스를 추가하거나 수정하는 것을 지원하지 않습니다. Elasticsearch 6.5 및 이전 버전에서 M3 인스턴스를 계속 사용할 수 있습니다.
최신 인스턴스 유형을 선택하는 것이 좋습니다. OpenSearch 또는 Elasticsearch 6.7 이상을 실행하는 도메인의 경우 다음 제한 사항이 적용됩니다.
-
기존 도메인에서 M3 인스턴스를 사용하지 않는 경우 더 이상 인스턴스로 변경할 수 없습니다.
-
기존 도메인을 M3 인스턴스 유형에서 다른 인스턴스 유형으로 변경하는 경우 다시 전환할 수 없습니다.
핫 쿼리는 활성화 후 작동이 중지됩니다. UltraWarm
UltraWarm 도메인에서 활성화할 때 설정에 대한 기존 재정의가 없는 경우 OpenSearch Service는 자동으로 값을 1로 search.max_buckets 설정하여 메모리를 많이 사용하는 쿼리가 웜 노드를 가득 채우는 것을 방지합니다. 10000 핫 쿼리가 10,000개 이상의 버킷을 사용하는 경우 활성화하면 작동이 중지될 수 있습니다. UltraWarm
Amazon OpenSearch Service의 관리형 특성으로 인해 이 설정을 수정할 수 없으므로 지원 사례를 열어 한도를 늘려야 합니다. 한도 증가에는 Premium Support 구독이 필요하지 않습니다.
업그레이드 후 다운그레이드할 수 없음
현재 위치 업그레이드는 되돌릴 수 없지만, AWS Support
모든 AWS 리전에 대한 도메인의 요약 필요
다음 스크립트는 Amazon EC2 describe-region AWS CLI 명령을 사용하여 서비스를 사용할 수 있는 모든 지역의 목록을 생성합니다. OpenSearch 그런 다음 각 지역을 호출합니다 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 서비스를 사용할 수 없는 지역은 “엔드포인트 URL에 연결할 수 없음”을 반환합니다.
OpenSearch 대시보드 사용 시 브라우저 오류가 발생했습니다.
대시보드를 사용하여 서비스 도메인의 데이터를 볼 때 브라우저가 HTTP 응답 개체로 서비스 오류 메시지를 래핑합니다 OpenSearch . 웹 브라우저에서 일반적으로 사용할 수 있는 개발자 도구(예: Chrome의 개발자 도구)를 사용하여 기본 서비스 오류를 확인하고 디버그 작업을 지원할 수 있습니다.
Chrome에서 서비스 오류를 보려면
-
Chrome 메뉴 모음에서 View(보기), Developer(개발자), Developer Tools(개발자 도구)를 차례로 선택합니다.
-
Network(네트워크) 탭을 선택합니다.
-
Status(상태) 열에서 상태가 500인 HTTP 세션을 선택합니다.
Firefox에서 서비스 오류를 보려면
-
메뉴에서 Tools(도구), Web Developer(웹 개발자), Network(네트워크)를 차례로 선택합니다.
-
상태가 500인 HTTP 세션을 선택합니다.
-
Response(응답) 탭을 선택하여 서비스 응답을 봅니다.
노드 샤드 및 스토리지 스큐
노드 샤드 스큐는 클러스터 내의 하나 이상의 노드에 다른 노드보다 훨씬 많은 샤드가 있는 경우입니다. 노드스토리지 스큐는 클러스터 내의 하나 이상의 노드에 다른 노드보다 훨씬 많은 스토리지(disk.indices)가 있는 경우입니다. 도메인에서 노드 하나를 교체했고 여전히 샤드를 노드에 할당 중인 경우처럼 이 두 조건 모두가 일시적으로 발생할 수 있습니다. 그러나 이러한 조건이 지속되는 경우 해결이 필요합니다.
두 가지 유형의 스큐를 모두 식별하려면 _cat/allocationshards 및 disk.indices 항목을 비교합니다.
shards | disk.indices | disk.used | disk.avail | disk.total | disk.percent | host | ip | node264|465.3mb|229.9mb|1.4tb|1.5tb|0|x.x.x.x|x.x.x.x|node1115 | 7.9mb | 83.7mb | 49.1gb | 49.2gb | 0 | x.x.x.x | x.x.x.x | node2264|465.3mb|235.3mb|1.4tb|1.5tb|0|x.x.x.x|x.x.x.x|node3116 | 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
-
데이터 노드의 하위 집합에서 HTTP 429 오류 발생
-
데이터 노드 전체에서 고르지 않은 인덱스 또는 검색 작업 대기열
-
데이터 노드 전반에 걸쳐 균일한 JVM 힙 또는 CPU 사용률
해결 방법: 데이터 노드 수의 배수인 샤드 수를 사용하여 각 인덱스가 데이터 노드 간에 균등하게 분산되도록 합니다. 인덱스 스토리지 또는 샤드 스큐가 여전히 나타나는 경우 샤드 재할당을 강제 적용해야 할 수 있습니다. 이 재할당은 서비스 도메인을 블루/그린으로 배포할 때마다 발생합니다. OpenSearch
VPC 액세스를 선택한 후 허용되지 않은 작업
OpenSearch 서비스 콘솔을 사용하여 새 도메인을 생성할 때 VPC 또는 퍼블릭 액세스를 선택할 수 있습니다. VPC 액세스를 선택하면 OpenSearch 서비스가 VPC 정보를 쿼리하고 적절한 권한이 없으면 실패합니다.
You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation이 쿼리를 활성화하려면 ec2:DescribeVpcs, ec2:DescribeSubnets 및 ec2:DescribeSecurityGroups 작업에 대한 액세스 권한이 있어야 합니다. 이 요구 사항은 콘솔에만 해당됩니다. AWS CLI를 사용하여 VPC 엔드포인트가 있는 도메인을 만들고 구성하는 경우 이러한 작업에 액세스할 필요가 없습니다.
VPC 도메인 생성 후 로딩 단계에서 멈춤
VPC 액세스를 사용하는 새 도메인을 만든 후, 도메인의 Configuration state(구성 상태)가 Loading(로드 중)에서 더 이상 진행되지 않을 수 있습니다. 이 문제가 발생하면 해당 지역에서 AWS Security Token Service (AWS STS) 를 비활성화했을 수 있습니다.
VPC에 VPC 엔드포인트를 추가하려면 OpenSearch 서비스가 역할을 맡아야 합니다. AWSServiceRoleForAmazonOpenSearchService 따라서 특정 지역에서 VPC 액세스를 사용하는 새 도메인을 생성할 수 AWS STS 있어야 합니다. 활성화 및 AWS STS비활성화에 대한 자세한 내용은 IAM 사용 설명서를 참조하십시오.
API에 대한 요청 거부됨 OpenSearch
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 서비스 도메인에 연결하려고 하면 도메인이 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 인증서와 운영 체제를 보관하면 이러한 오류를 방지할 수 있습니다. up-to-date 본인 컴퓨터를 직접 관리하지 않는 기업 환경에서 이 문제가 발생하는 경우, 관리자에게 업데이트 프로세스를 문의해야 할 수 있습니다.
아래 목록에 최소한의 운영 체제 및 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에서
참고
현재 us-east-1 지역의 OpenSearch 서비스 도메인은 다른 기관의 인증서를 사용합니다. 가까운 시일 안에 이 리전에서도 새 인증 기관을 사용하도록 업데이트할 예정입니다.
