Amazon Elasticsearch Service 문제 해결 - Amazon Elasticsearch Service

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

Amazon Elasticsearch Service 문제 해결

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

Kibana에 액세스할 수 없습니다.

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

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

Amazon ES 도메인에서 VPC 액세스를 사용하는 경우에는 이 오류가 발생하지 않습니다. 그 대신 요청이 시간 초과됩니다. 이 문제를 바로잡는 방법과 사용 가능한 각종 구성 옵션에 대해 알아보려면 Kibana에 대한 액세스 제어, VPC 도메인 액세스 정책에 대하여Amazon Elasticsearch Service의 자격 증명 및 액세스 관리. 단원을 참조하십시오.

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

VPC 도메인 액세스 정책에 대하여VPC 도메인 테스트. 단원을 참조하십시오.

읽기 전용 상태의 클러스터

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

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

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

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

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

GET _cat/health?v

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

GET _cat/indices?v

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

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

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

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

빨간색 클러스터 상태

빨간색 클러스터 상태는 하나 이상의 기본 샤드 및 복제본이 노드에 할당되지 않았음을 나타냅니다. 빨간색 클러스터 상태가 지속되면 인덱스의 상태가 양호하더라도 Amazon ES가 스냅샷 자동 생성을 중지합니다.

빨간색 클러스터 상태의 가장 일반적인 원인은 실패한 클러스터 노드 및 처리 부하가 지속적으로 높아서 Elasticsearch 프로세스가 충돌하는 것입니다.

참고

Amazon ES는 자동 스냅샷을 14일 동안 저장하므로, 빨간색 클러스터 상태가 2주 이상 지속되면 클러스터의 데이터가 영구적으로 손실될 수 있습니다. Amazon ES 도메인이 빨간색 클러스터 상태가 되면 AWS Support에서 연락해 문제를 직접 해결할 것인지 아니면 지원 팀의 도움을 원하는지 묻는 경우도 있습니다. 빨간색 클러스터 상태가 발생할 때 알림을 받도록 경보를 설정CloudWatch할 수 있습니다.

적색 샤드는 적색 클러스터를 초래하고, 적색 인덱스는 적색 샤드를 초래합니다. 빨간색 클러스터 상태를 초래하는 인덱스를 식별하기 위해 Elasticsearch에는 몇 가지 유용한 APIs가 있습니다.

  • 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

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

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

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

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

관련 지표 설명 복구
JVMMemoryPressure

클러스터의 모든 데이터 노드에 사용되는 Java 힙의 비율을 지정합니다. 이 지표에 대한 최대 통계를 보고 Java 가비지 수집기가 충분한 메모리를 회수하지 못하여 메모리 압력 하락이 더 작고 작은지 찾습니다. 복합 쿼리 또는 큰 데이터 필드가 이러한 패턴의 원인일 수 있습니다.

Concurrent Mark Sweep(CMS) 가비지 수집기는 "구세대" 객체 공간의 75%가 차면 트리거됩니다. 이 수집기는 다른 스레드와 함께 실행되면서 일시 정지를 최소한으로 유지합니다. CMS가 이러한 정상 수집 중에 충분한 메모리를 회수하지 못하면, Elasticsearch가 모든 스레드를 중지하는 다른 가비지 수집 알고리즘을 트리거합니다. 노드는 클러스터 안정성에 영향을 미칠 수 있는 이러한 stop-the-world 수집 중에는 응답하지 않습니다.

메모리 사용량이 계속 증가하면 Elasticsearch가 메모리 부족 오류로 인해 결국 충돌합니다. 경험상 사용량을 80% 미만으로 유지하는 것이 좋습니다.

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

GET elasticsearch_domain/_nodes/stats/jvm?pretty

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

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

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

노란색 클러스터 상태

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

다중 노드 클러스터는 새 인덱스를 생성하거나 노드에 장애가 발생한 후 잠시 노란색 클러스터 상태가 될 수 있습니다. 이 상태는 Elasticsearch가 클러스터 간에 데이터를 복제할 때 자체 확인됩니다. 디스크 공간 부족으로 인해 노란색 클러스터 상태가 발생할 수도 있습니다. 노드에 디스크 공간이 있는 경우에만 클러스터가 복제본 샤드를 분산시켜 수용할 수 있습니다.

ClusterBlockException

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

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

샤드 재할당을 받아들일 만큼 스토리지 공간이 넉넉한 노드가 없으면 문서 추가 및 인덱스 생성과 같은 기본적인 쓰기 작업이 실패하기 시작합니다. 스토리지 요구 사항 계산는 Amazon ES의 디스크 공간 사용에 대한 요약 정보를 제공합니다.

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

메모리 부족으로 인한 디스크 차단

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

5분 동안 JVMMemoryPressure 지표가 88% 이하로 돌아가면 보호가 비활성화되고 클러스터에 대한 쓰기 작업이 차단 해제됩니다.

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

이러한 조건이 있는지 확인하려면 Amazon ES 콘솔에서 도메인 대시보드를 엽니다. Cluster health(클러스터 상태) 탭을 선택한 다음 노드 지표를 선택합니다. 보고된 노드 수가 클러스터에 대해 구성한 노드 수보다 적은지 확인합니다. 이 지표가 하나 이상의 노드가 하루 이상 다운되었음을 표시하면 AWS Support.에 문의하십시오.

또한 이 문제가 발생할 때 알림을 받도록 경보를 설정CloudWatch할 수도 있습니다.

참고

클러스터 구성을 변경하는 동안과 서비스에 대한 정기 유지 관리 중에는 노드 지표가 정확하지 않습니다. 이는 예상된 동작입니다. 따라서 이 지표는 곧 정확한 클러스터 노드 개수를 보고합니다. 자세한 내용은 단원을 참조하십시오.구성 변경.

예기치 않은 노드 종료 및 다시 시작으로부터 클러스터를 보호하려면 Amazon ES 도메인의 각 인덱스에 대해 복제본을 하나 이상 만드십시오.

최대 샤드 제한

의 7.x 버전에서 기본 설정된 노드당 샤드 수는 1,000개 이하입니다. 새 인덱스 생성과 같은 요청으로 인해 이 한도를 초과하는 경우 Elasticsearch에서 오류가 발생합니다.Elasticsearch 이 오류가 발생한 경우 몇 가지 옵션이 있습니다.

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

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

The Resource Access Policy specified for the CloudWatch Logs log group does not grant sufficient permissions for Amazon Elasticsearch Service to create a log stream. Please check the Resource Access Policy.

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

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

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

  3. Use existing log group(기존 로그 그룹 사용)을 선택합니다.

  4. 기존 로그 그룹에서 오류 메시지를 수신하기 전에 생성한 로그 그룹을 선택합니다.

  5. [Select an existing policy]를 선택합니다.

  6. 기존 정책에서 오류 메시지를 수신하기 전에 생성한 정책을 선택합니다.

  7. Enable.]을 선택합니다.

1–7단계를 여러 번 반복한 후에도 오류가 지속될 경우 AWS Support에 문의하십시오.

인덱스를 닫을 수 없습니다.

Amazon ES는 _close 버전 7.4 이상에서만 Elasticsearch API를 지원합니다. 이전 버전을 사용하고 스냅샷에서 인덱스를 복원하는 경우 기존 인덱스를 삭제할 수 있습니다(다시 인덱싱하기 전 또는 후). 다른 옵션은 인덱스를 복원할 때 rename_patternrename_replacement 필드를 사용하여 인덱스 이름을 변경하는 것입니다.

POST /_snapshot/my-repository/my-snapshot/_restore { "indices": "my-index-1,myindex-2", "include_global_state": true, "rename_pattern": "my-index-(\\d)", "rename_replacement": "restored-my-index-$1" }

인덱스를 다시 만들거나, 수축하거나, 분할하려는 경우 작업을 수행하기 전에 쓰기를 중단하는 것이 좋습니다.

클라이언트 라이선스 검사

Logstash 및 Beats의 기본 배포에는 독점 라이선스 검사가 포함되어 있으며 Elasticsearch의 오픈 소스 버전에 연결하지 못합니다. 에서 이러한 클라이언트의 Apache 2.0(OSS) 배포를 사용해야 합니다.Amazon ES

조절 요청

지속적인 403 Request throttled due to too many requests 오류가 발생하면 수직 확장을 고려하십시오. 페이로드로 인해 메모리 사용량이 Java 힙의 최대 크기를 초과하는 경우 Amazon Elasticsearch Service가 요청을 조절합니다.

노드에 SSH할 수 없습니다.

SSH를 사용하여 Elasticsearch 클러스터의 어떤 노드에도 액세스할 수 없으며 elasticsearch.yml를 직접 수정할 수 없습니다. 대신 콘솔, AWS CLI 또는 SDKs를 사용하여 도메인을 구성합니다. REST Elasticsearch를 사용하여 몇 가지 클러스터 수준 설정을 지정할 수도 있습니다.APIs 자세한 내용은 Amazon Elasticsearch Service 구성 API 참조지원되는 Elasticsearch 작업. 단원을 참조하십시오.

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

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

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

버킷에서 스냅샷을 복원해야 하는 경우 S3 Glacier에서 객체를 복원하고 객체를 새 버킷에 복사한 다음 새 버킷을 스냅샷 리포지토리로 등록합니다.

잘못된 호스트 헤더

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

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

요청 시 Invalid Host Header 오류가 표시되는 경우 클라이언트 또는 프록시가 Amazon ES 헤더에 Host 도메인 엔드포인트(예를 들어 IP 주소가 아님)를 포함하는지 확인합니다.

잘못된 M3 인스턴스 유형

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

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

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

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

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

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

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

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

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

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

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

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

Kibana를 사용하려 할 때 브라우저 오류

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

Chrome에서 서비스 오류를 보려면

  1. 메뉴에서 보기, 개발자, 개발자 도구.를 차례로 선택합니다.

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

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

Firefox에서 서비스 오류를 보려면

  1. 메뉴에서 도구, 웹 개발 도구, 네트워크.를 차례로 선택합니다.

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

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

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

Amazon ES 콘솔을 사용하여 새 도메인을 만들 때 VPC 또는 공용 액세스를 선택하는 옵션이 있습니다. VPC 액세스를 선택하면 가 VPC 정보를 쿼리하고 적절한 권한이 없는 경우 실패합니다.Amazon ES

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(구성 상태)로드 중.에서 더 이상 진행되지 않을 수 있습니다. 이 문제가 발생하면 리전에 대해 AWS Security Token Service(AWS STS)가 비활성화된 것일 수 있습니다.

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

Alpine Linux에서 연결할 수 없음

Alpine Linux는 DNS 응답 크기를 512바이트로 제한합니다. Alpine Linux에서 Amazon ES 도메인에 연결하려고 할 때 도메인이 VPC에 있으며 20개가 넘는 노드가 있는 경우 DNS 확인이 실패할 수 있습니다. 도메인이 VPC에 있는 경우 Debian, Ubuntu, CentOS, Red Hat Enterprise Linux 또는 Amazon Linux 2와 같은 다른 Linux 배포를 사용하여 연결하는 것이 좋습니다.

SDK를 사용할 때 인증서 오류

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

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

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

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

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

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

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

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

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

  • Amazon Root CA 1

  • Starfield Services Root Certificate Authority - G2

  • Starfield Class 2 Certification Authority

처음 두 기관의 루트 인증서는 Amazon Trust Services에서 구할 수 있지만 컴퓨터를 최신 상태로 유지하는 것이 보다 간단한 해결 방법입니다. ACM 제공 인증서에 대한 자세한 내용은 AWS Certificate Manager FAQs 단원을 참조하십시오.

참고

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