Amazon OpenSearch Service FAQ

예. 콘솔에서 도메인 생성 마법사를 사용해 클릭 몇 번이면 새로운 Amazon OpenSearch Service 도메인을 생성할 수 있습니다. 새로운 도메인을 생성하면서 도메인에 할당할 인스턴스 수, 인스턴스 유형 및 EBS 볼륨을 지정할 수 있습니다. 또한, 콘솔을 사용하여 기존 Amazon OpenSearch Service 도메인을 변경하거나 삭제할 수도 있습니다.

예. Amazon OpenSearch Service는 Amazon VPC와 통합됩니다. VPC 액세스를 선택할 때, VPC의 IP 주소가 Amazon OpenSearch Service 도메인에 연결되고 모든 네트워크 트래픽이 AWS 네트워크 내에 유지되며 인터넷에 액세스할 수 없습니다. 또한, 보안 그룹과 IAM 정책을 사용하여 Amazon OpenSearch Service 도메인에 대한 액세스를 제한할 수 있습니다.

예. AWS CloudFormation에서는 Amazon OpenSearch Service를 지원합니다. 자세한 내용은 CloudFormation 템플릿 참조 설명서를 확인하세요.

예. 도메인에 대해 전용 마스터 노드를 구성할 수 있습니다. 전용 마스터 구성을 선택할 때, 인스턴스 유형과 인스턴스 수를 지정할 수 있습니다.

예. 같은 Amazon OpenSearch Service 도메인 내에서 여러 개의 Elasticsearch 또는 OpenSearch 인덱스를 생성할 수 있습니다. Elasticsearch 및 OpenSearch는 인덱스 및 관련 복제본을 도메인에 할당된 인스턴스 간에 자동으로 분산합니다.

Amazon OpenSearch Service에서는 데이터를 수집할 수 있는 3가지 옵션을 지원합니다.

• 대용량 데이터의 경우, 데이터 처리량에 맞춰 자동으로 확장하며 지속적인 관리가 필요 없는 완전관리형 서비스인 Amazon Kinesis Data Firehose를 사용하는 것이 좋습니다. 또한, 이 서비스는 로드하기 전에 데이터를 변환, 일괄 처리 및 압축할 수도 있습니다.
• Amazon OpenSearch Service는 Logstash와의 통합을 지원합니다. Amazon OpenSearch Service 도메인을 Logstath 구현으로부터 수신되는 모든 로그를 위한 데이터 스토어로 구성할 수 있습니다.
• Index 및 Bulk API와 같은 기본 Elasticsearch(최신 7.10 버전까지) API를 사용하여 데이터를 도메인으로 로드할 수 있습니다.

예. Amazon OpenSearch Service는 Logstash와의 통합을 지원합니다. Logstash 구현을 통해 수신되는 모든 로그에 대한 백엔드 스토어로 Amazon OpenSearch Service 도메인을 설정할 수 있습니다. 요청 서명을 사용하여 Logstash 구현에서 수신되는 호출을 인증하거나, 리소스 기반 IAM 정책을 사용하여 Logstash 구현을 실행하는 인스턴스의 IP 주소를 포함하도록 Amazon OpenSearch Service 도메인에 대한 액세스 제어를 설정할 수 있습니다.

예. Amazon OpenSearch Service는 OpenSearch 대시보드 및 Kibana(1.5~7.10 버전)를 사용하여 시각화 기능을 제공합니다.

로컬 온인스턴스 스토리지 또는 EBS 볼륨 중에 선택할 수 있습니다. 도메인 생성 시 EBS 스토리지를 선택하면, 필요에 따라 스토리지 볼륨의 크기를 늘리고 줄일 수 있습니다.

마그네틱, 범용 및 프로비저닝된 IOPS EBS 볼륨 중에 선택할 수 있습니다.

예. Amazon OpenSearch Service는 원하는 인스턴스 또는 연결된 EBS 볼륨 크기에 기반하여 스토리지를 배포합니다. 노드당 최대 스토리지는 EBS gp3 스토리지가 포함된 R6g.12xlarge 인스턴스에서 24TB입니다. Amazon OpenSearch Service 도메인당 최대 80개의 기본 데이터 노드가 지원되므로 하나의 도메인에 약 1,920TB의 스토리지를 할당할 수 있습니다. AWS Support Center에서 케이스를 생성하여 도메인당 최대 200개의 인스턴스까지 서비스 한도 상향을 요청할 수 있습니다. 200개의 인스턴스 내에서 단일 도메인에 약 3PB의 스토리지를 할당할 수 있습니다.

데이터 인스턴스를 단일 AZ에 배포하는 경우, 전용 마스터 인스턴스도 같은 AZ에 배포됩니다. 그러나 2~3개의 AZ에 데이터 인스턴스를 배포하면 Amazon OpenSearch Service가 자동으로 3개의 AZ에 전용 마스터 인스턴스를 배포합니다. 이 규칙의 예외는 리전에 2개의 AZ만 있거나 모든 AZ에서 사용할 수 없는 마스터 인스턴스에 대해 이전 세대 인스턴스 유형을 선택한 경우 발생합니다. 자세한 내용은 설명서를 참조하세요.

프로덕션 워크로드의 경우 가용성이 향상되므로 데이터 인스턴스를 3의 AZ에 배포하는 것이 좋습니다. 또한 여러 AZ에서 균등하게 배포되도록 인스턴스를 3의 배수로 프로비저닝하는 것이 좋습니다. 3개의 AZ를 사용할 수 없는 리전에서는 짝수 개의 데이터 인스턴스가 있는 2개의 AZ 배포를 사용하는 것이 좋습니다. 모든 경우에 3개의 전용 마스터 인스턴스를 프로비저닝하는 것이 좋습니다.

AWS 콘솔, CLI 또는 SDK를 사용하여 기존 도메인과 신규 도메인 모두에 3개의 AZ 배포를 활성화할 수 있습니다. 자세한 내용은 설명서를 참조하세요.

아닙니다. Amazon OpenSearch Service는 3개의 AZ 배포를 위해 비용을 청구하지 않습니다. 도메인에 있는 인스턴스 수에 대한 비용만 지불하며 배포된 AZ 수에 대한 비용은 지불하지 않습니다.

여러 AZ에 대해 구성된 모든 도메인은 영역 인지 기능을 사용하도록 설정되어 샤드가 가용 영역에 분산되도록 합니다. 콘솔에서 이제 2~3개의 AZ 배포를 명시적으로 선택할 수 있습니다. 이전에 "영역 인지"로 구성된 도메인은 다시 구성하지 않는 한 2개의 AZ에 계속 배포됩니다. 자세한 내용은 설명서를 참조하세요.

AZ에 있는 하나 이상의 인스턴스가 도달할 수 없거나 작동하지 않는 경우, Amazon OpenSearch Service는 자동으로 영향을 받는 인스턴스를 대체하기 위해 동일한 AZ에 새 인스턴스를 가져오려고 시도합니다. 새로운 인스턴스를 AZ에서 가져올 수 없는 드문 경우로, 도메인이 여러 AZ에 인스턴스를 배포하도록 구성된 경우 Amazon OpenSearch Service는 다른 사용 가능한 AZ에서 새 인스턴스를 가져옵니다. AZ 문제가 해결되면 Amazon OpenSearch Service는 인스턴스가 도메인 용으로 구성된 AZ에 동일하게 분산되도록 인스턴스의 균형을 조정합니다. 자세한 내용은 설명서를 참조하세요.

하나의 복제본을 구성하더라도 3개의 AZ를 권장합니다. 3개의 AZ 도메인에서 AZ 장애가 발생하면 용량의 1/3만 잃게 됩니다. 그러나 2개의 AZ 도메인에서 장애가 발생하면 용량이 절반으로 줄어들어 더 많은 장애가 발생할 수 있습니다. 또한 3개의 AZ 도메인에서 AZ가 중단되면 Amazon OpenSearch Service는 나머지 두 AZ로 폴백할 수 있으며 여전히 교차 AZ 복제를 지원할 수 있습니다. 2개의 AZ 도메인에서 하나의 AZ가 중단되면 교차 AZ 복제가 손실되어 가용성을 더욱 저하시킬 수 있습니다. 자세한 내용은 설명서를 참조하세요.

도메인이 배포되는 AZ의 수는 VPC 도메인에 대해 구성한 서브넷 수에 해당합니다. 3개의 AZ 배포를 사용하려면 VPC 도메인에 3개 이상의 서브넷을 구성해야 합니다. VPC구성에 대한 자세한 내용은 설명서를 참조하세요.

예. 퍼블릭 액세스가 지원되는 프로그램은 퍼블릭 엔드포인트를 통해 Amazon OpenSearch Service 도메인에 액세스할 수 있습니다. 데이터 센터가 이미 Direct Connect 또는 SSH 터널링을 통해 Amazon VPC에 연결된 경우에는 VPC 액세스도 사용할 수 있습니다. 두 경우 모두 IAM 정책과 보안 그룹을 구성하여 AWS 외부 서버에서 실행되는 프로그램이 Amazon OpenSearch Service 도메인에 액세스하도록 허용할 수 있습니다. 서명된 요청에 대한 자세한 내용을 보려면 여기를 클릭하세요.

기존 Elasticsearch 또는 OpenSearch 클러스터에서 데이터를 마이그레이션하려면 기존 클러스터의 스냅샷을 생성하고 Amazon S3 버킷에 생성한 스냅샷을 저장해야 합니다. 그런 다음 새로운 Amazon OpenSearch Service 도메인을 생성하고, 복원 API를 사용하여 스냅샷의 데이터를 새로 생성된 Amazon OpenSearch Service 도메인으로 로드할 수 있습니다.

Amazon OpenSearch Service에서는 콘솔, API 및 CLI를 사용하여 Amazon OpenSearch Service 도메인의 크기를 조정할 수 있습니다. 애플리케이션 필요에 따라 인스턴스나 스토리지 볼륨을 추가, 제거 또는 변경하여 Amazon OpenSearch Service 도메인의 크기는 조정할 수 있습니다. Amazon OpenSearch Service는 Amazon CloudWatch와 통합되어 Amazon OpenSearch Service 도메인의 상태에 대한 지표를 제공하므로 도메인 크기 조정에 대한 적절할 의사 결정을 내릴 수 있습니다.

인스턴스와 스토리지 볼륨을 추가하거나 변경하여 Amazon OpenSearch Service 도메인의 크기를 조정하는 것은 온라인 작업이므로 가동을 중지할 필요가 없습니다.

예. OpenSearch/Elasticsearch 인덱스에 대한 복제본을 활성화하고 여러 가용 영역을 사용하는 경우, Amazon OpenSearch Service가 기본 및 복제 샤드를 다른 AZ의 인스턴스에 자동으로 분산됩니다.

예. Amazon OpenSearch Service는 Amazon CloudWatch를 통해 노드 수, 클러스터 상태, 검색 가능한 문서, EBS 지표(해당하는 경우), CPU, 데이터 및 프라이머리 노드의 메모리와 디스크 사용 등을 비롯한 여러 성능 지표를 제공합니다. 지원되는 CloudWatch 지표의 전체 목록은 서비스 설명서를 참조하십시오.

예. AWS CloudTrail은 계정에 대한 AWS API 호출을 기록하고 로그 파일을 사용자에게 전달하는 웹 서비스입니다. AWS CloudTrail에서 작성된 AWS API 호출 기록을 사용하여 보안 분석, 리소스 변경 사항 추적 및 규정 준수 감사를 수행할 수 있습니다. AWS CloudTrail 세부 정보 페이지에서 AWS CloudTrail에 대해 자세히 알아보고 CloudTrail의 AWS Management Console 홈 페이지를 통해 활성화하세요.

스냅샷은 특정 시점의 Amazon OpenSearch Service 도메인 복사본입니다.

스냅샷을 생성하면 노드 장애는 물론 하드웨어 장애와 같이 예기치 못한 상황으로 인해 데이터가 손실된 경우 유용하게 사용할 수 있습니다. 스냅샷을 사용해 사전 로드된 데이터로 Amazon OpenSearch Service 도메인을 복구하거나 새로운 Amazon OpenSearch Service 도메인을 생성할 수 있습니다. 백업을 사용하는 또 다른 일반적인 이유는 아카이빙을 위해서입니다. 스냅샷은 Amazon S3에 저장됩니다.

예. 기본적으로 Amazon OpenSearch Service에서는 각 Amazon OpenSearch Service 도메인의 시간별 스냅샷을 자동으로 생성하고 14일 동안 보관합니다.

Amazon OpenSearch Service에서는 최근 14일 동안의 시간별 자동 스냅샷을 보관합니다.

시간별 자동 스냅샷에 대한 추가 비용은 없습니다. 스냅샷은 Amazon OpenSearch Service S3 버킷에 무료로 저장되고 노드 복구가 필요할 때 사용할 수 있습니다.

예. Amazon OpenSearch Service에서 생성하는 일일 자동 스냅샷 외에도 스냅샷 API를 사용하여 추가로 수동 스냅샷을 생성할 수 있습니다. 수동 스냅샷은 S3에 버킷에 저장되며 관련된 Amazon S3 사용 요금이 발생합니다.

예. 고객은 새로운 Amazon OpenSearch Service 도메인을 생성하고, OpenSearch/Elasticsearch 복원 API를 사용하여 스냅샷의 데이터를 새로 생성된 Amazon OpenSearch Service 도메인으로 로드할 수 있습니다.

Amazon OpenSearch Service에서 보관하는 일일 스냅샷은 도메인 삭제와 함께 삭제됩니다. 도메인을 삭제하기 전에 수동 스냅샷 프로세스를 사용하여 자체 S3 버킷에 도메인 스냅샷을 생성할지를 검토해야 합니다. S3 버킷에 저장된 스냅샷은 Amazon OpenSearch Service 도메인을 삭제하더라도 그대로 유지됩니다.

Amazon OpenSearch Service에서는 Amazon CloudWatch Logs를 통해 오류 로그, 검색 느린 로그 및 인덱스 느린 로그라는 3가지 Elasticsearch 또는 OpenSearch 로그를 제공합니다. 이러한 로그는 도메인의 성능 및 안정성 문제를 해결할 때 유용합니다.

느린 로그는 작업의 다양한 단계에서 성능을 추적하는 데 도움이 되는 로그 파일입니다. OpenSearch 및 Elasticsearch에서는 두 가지 종류의 느린 로그를 표시합니다.

• 인덱스 느린 로그 – 이 로그는 인덱싱 프로세스에 대한 통찰력을 제공하며 인덱스 설정을 미세 조정하는 데 사용할 수 있습니다.
• 검색 느린 로그 – 이 로그는 쿼리 및 페치의 성능이 얼마나 빠르거나 느린지에 대한 통찰력을 제공합니다. 이러한 로그는 OpenSearch 또는 Elasticsearch에서 모든 종류의 검색 작업 성능을 미세 조정하는 데 도움이 됩니다.

느린 로그에 대한 세부 정보는 OpenSearch 설명서를 참조하세요.

느린 로그는 콘솔에서 버튼 클릭 한 번으로 또는 CLI 및 API를 통해 활성화할 수 있습니다. 자세한 내용은 설명서를 참조하세요.

예. 느린 로그를 활성화 또는 비활성화하도록 특정 인덱스의 설정을 업데이트할 수 있습니다. 자세한 내용은 설명서를 참조하세요.

Amazon OpenSearch Service에서 느린 로그를 켜면 주어진 도메인의 인덱스에 대해 생성된 로그를 Amazon CloudWatch Logs로 게시하는 옵션이 활성화됩니다. 하지만 로그를 생성하려면 로깅 프로세스를 시작하도록 하나 이상의 인덱스에 대한 설정을 업데이트해야 합니다. 느린 로그를 활성화하도록 인덱스 구성을 설정하는 방법에 대한 자세한 내용은 설명서를 참조하세요.

로그 파일 생성은 인덱스 설정에 따라 이루어집니다. 로그 파일 생성을 종료하려면 인덱스 구성을 업데이트해야 합니다. 느린 로그를 활성화하도록 인덱스 구성을 설정하는 방법에 대한 자세한 내용은 설명서를 참조하세요.

느린 로그의 경우에만 로깅의 세부 수준을 변경할 수 있습니다. OpenSearch 및 Elasticsearch에서는 느린 로그에 대해 여러 수준의 로깅을 제공합니다. 인덱스의 구성에서 적절한 수준을 설정해야 합니다. 느린 로그를 활성화하도록 인덱스 구성을 설정하는 방법에 대한 자세한 내용은 OpenSearch 설명서를 참조하세요.

느린 로그 또는 오류 로그를 활성화하면 Amazon OpenSearch Service가 생성된 로그를 Amazon CloudWatch Logs로 게시하기 시작합니다. Amazon OpenSearch Service에서는 로그 활성화에 대한 비용은 부과하지 않습니다. 그러나 표준 CloudWatch 요금이 적용됩니다.

OpenSearch에서는 Apache Log4j 2와 이에 내장된 로그 수준인 TRACE, DEBUG, INFO, WARN, ERROR, FATAL(가장 심각하지 않은 것부터 가장 심각한 순)을 사용합니다. 사용자가 오류 로그를 활성화하면 Amazon OpenSearch Service에서는 WARN, ERROR 및 FATAL의 로그 줄을 CloudWatch에 게시하고 DEBUG 수준에서 오류를 선택합니다. 자세한 내용은 설명서를 참조하세요.

오류 로그는 AWS 콘솔에서 버튼 클릭 한 번으로 또는 CLI 및 API를 통해 활성화할 수 있습니다. 자세한 내용은 설명서를 참조하세요.

아니요. 오류 로그는 전체 도메인에 대해 제공됩니다. 즉, 일단 활성화되면 도메인의 모든 인덱스에서 로그 항목이 제공됩니다.

아니요. 오류 로그는 Elasticsearch 버전 5.x 이상에서만 사용할 수 있습니다.

예. CloudWatch로 게시되는 각 로그 항목은 255,000자로 문자 수가 제한됩니다. 로그 항목이 이보다 큰 경우, 255,000자로 항목이 잘리게 됩니다.

느린 로그는 인덱스 문제를 해결하거나 성능을 미세 조정할 때만 필요합니다. 추가적인 성능 통찰력이 필요한 인덱스에 대해서만 로깅을 활성화하는 접근 방식이 권장됩니다. 또한, 조사가 완료되면 관련 비용이 계정에 추가로 발생하지 않도록 로깅을 종료해야 합니다. 자세한 내용은 설명서를 참조하세요.

CloudWatch에서는 로그를 사용할 수 있는 몇 가지 방법을 제공합니다. 로그 데이터를 보거나, S3로 내보내거나, 실시간으로 처리할 수 있습니다. 자세히 알아보려면 CloudWatch Logs 개발자 안내서를 참조하세요.

예, Amazon OpenSearch Service에서 지원하는 모든 버전의 OpenSearch 및 Elasticsearch에서 느린 로그를 활성화할 수 있습니다. 하지만 Elasticsearch 버전별로 로그 설정을 지정하는 방식이 약간 다릅니다. 자세한 내용은 설명서를 참조하세요.

아니요. 가동 중단되는 일은 없습니다. 로그 상태가 업데이트될 때마다 AWS에서는 백그라운드에 새로운 클러스터를 배포하고 기존 클러스터를 새로운 클러스터로 교체합니다. 이 프로세스로 인해 가동 중단이 발생하지 않습니다. 하지만 새로운 클러스터가 배포되므로 로그 상태가 즉시 업데이트되지는 않습니다.

Amazon OpenSearch Service는 현재 모든 OpenSearch 버전 또는 Elasticsearch 버전 5.x 이상에서 도메인에 대한 인플레이스 버전 업그레이드를 지원합니다. 업그레이드를 지원하는 대상 버전은 5.6, 6.3, 6.4, 6.5, 6.7, 6.8, 7.1, 7.4, 7.7, 7.8, 7.9 및 7.10입니다. 자세한 내용은 설명서를 참조하세요.

다양한 Elasticsearch 버전에서 마이그레이션하는 방법에 대한 자세한 내용은 설명서를 참조하세요.

아니요. 업그레이드 프로세스 내내 도메인을 사용할 수 있습니다. 하지만 업그레이드 프로세스의 일부에는 도메인 성능에 영향을 줄 수 있는 샤드 재할당이 포함됩니다. 도메인 로드가 적을 때 업그레이드를 수행하는 것이 좋습니다.

인플레이스 버전 업그레이드는 Elasticsearch 5.x 이상에서 실행되는 도메인에서만 사용할 수 있습니다. 도메인 버전이 5.x 이상인 경우, 업그레이드 자격 검사를 실행하여 도메인을 원하는 버전으로 업그레이드할 수 있는지 확인할 수 있습니다. 자세한 내용은 설명서를 참조하세요.

업그레이드 자격 확인을 위해 AWS에서 실행하는 테스트의 상세 목록은설명서를 참조하세요.

아니요. 인플레이스 버전 업그레이드가 트리거된 후에는 업그레이드가 완료되거나 실패할 때까지 도메인 구성을 변경할 수 없습니다. 업그레이드가 진행되는 동안에도 데이터 읽기 및 쓰기는 계속할 수 있습니다. 또한, 도메인을 삭제할 수 있으며 그러면 업그레이드가 종료되고 도메인이 삭제됩니다.

버전 업그레이드 프로세스가 자동으로 시스템 스냅샷을 생성하고 스냅샷이 성공해야 실제 업그레이드를 시작합니다. 자동 스냅샷의 시작 시간이 임박하여 업그레이드가 진행되는 경우, 해당 날짜에는 자동 스냅샷 생성을 건너뛰고 다음 날에 계속합니다.

Amazon OpenSearch Service는 업그레이드를 트리거하기 전에 일련의 테스트를 실행하여 업그레이드를 차단할 수 있는 알려진 문제를 확인합니다. 문제가 발생하지 않으면, 서비스에서 도메인의 스냅샷을 생성하고 스냅샷이 성공한 경우 업그레이드 프로세스를 시작합니다. 단계 중 하나에서라도 문제가 발생하면 업그레이드가 트리거되지 않습니다.

발생한 문제가 경미하고 해결할 수 있는 경우 Amazon OpenSearch Service가 자동으로 문제를 해결하고 업그레이드 차단을 해제합니다. 그러나 문제로 인해 업그레이드가 차단되면 서비스는 업그레이드 전에 생성한 스냅샷으로 되돌린 후 오류를 기록합니다. 업그레이드 프로세스의 로그를 보는 방법에 대한 자세한 내용은 설명서를 참조하세요.

예. AWS 콘솔에서 업그레이드 로그를 보거나 CLI 또는 SDK를 사용하여 이를 요청할 수 있습니다. 자세한 내용은 설명서를 참조하세요.

아니요. 업그레이드가 트리거된 후에는 업그레이드가 완료되거나 실패할 때까지 일시 중지하거나 취소할 수 없습니다.

예. 하지만 모든 도메인을 동일한 버전으로 유지하려면 업그레이드하기 전에 모든 도메인에 대해 업그레이드 자격 검사를 실행하는 것이 좋습니다. 이 추가 단계는 다른 도메인에는 없을 수도 있는 한 도메인의 문제를 파악하는 데 도움이 될 수 있습니다.

데이터 양과 클러스터 크기에 따라 업그레이드를 완료하는 데 몇 분에서 몇 시간이 걸릴 수 있습니다.

아니요. 인플레이스 버전 업그레이드를 사용하면 클러스터의 모든 데이터가 업그레이드 프로세스의 일부로 복원됩니다. 도메인만 업그레이드하려는 경우 데이터의 스냅샷을 생성하고, 도메인에서 모든 인덱스를 삭제한 다음, 인플레이스 업그레이드를 트리거할 수 있습니다. 또는 새 버전으로 별도의 도메인을 생성한 다음 해당 도메인에 데이터를 복원할 수 있습니다.

아니요. 이전 버전으로 다운그레이드하려면 자동 사전 업그레이드 스냅샷을 새 도메인에 복원하도록 AWS Support에 문의하세요. 원래 도메인의 수동 스냅샷이 있다면 이 단계를 직접 수행할 수 있습니다.

Multi-AZ with Standby는 Amazon OpenSearch Service의 새로운 배포 옵션입니다. 이 옵션은 비즈니스 크리티컬 워크로드에 고가용성의 일관된 성능을 제공합니다. Multi-AZ with Standby를 사용하는 경우 OpenSearch Service 관리형 클러스터는 노드 삭제와 같은 인프라 장애나 단일 가용 영역 장애에 복원력을 가지므로 단일 가용 영역에 장애가 발생하더라도 성능 또는 가용성이 영향을 받지 않습니다. Multi-AZ with Standby는 모범 사례를 적용하고 복잡성을 줄여 클러스터 구성 및 관리를 간소화한다는 추가 이점도 제공합니다.

Multi-AZ with Standby를 사용하려면 관리형 클러스터가 다음 조건을 충족해야 합니다.

• OpenSearch 1.3 이상의 최신 버전을 실행합니다.
• 3AZ를 사용하는 AWS 리전에 배포합니다. 현재 AWS 캘리포니아 북부 리전은 3AZ를 지원하지 않으므로 Multi-AZ with Standby에 적합하지 않습니다.
• 데이터 노드 수는 3의 배수여야 합니다.
• 데이터 복사본 수(기본+복제본)는 3의 배수여야 합니다.
• 리더의 크기 조정 지침을 따릅니다(클러스터의 노드 수, 샤드 수 및 매핑 수를 기반으로 한 권장 크기).

Multi-AZ with Standby를 사용하면 Amazon OpenSearch Service가 일부 인프라 장애를 감지하여 자동으로 복구합니다. 다음과 같은 이벤트가 발생할 경우 Amazon OpenSearch Service는 1분 이내에 자동으로 활성 노드에서 대기 노드로 장애 조치합니다.

• 활성 AZ 1개 또는 활성 AZ의 모든 노드 손실
• 활성 AZ 1개에 대한 연결 손실
• 활성 AZ의 인스턴스 하드웨어 장애
• 활성 AZ에 있는 노드의 스토리지 장애

현재 다음과 같은 이벤트에는 Multi-AZ with Standby가 적용되지 않습니다.

• 마스터 Quorum 손실(이 이벤트에서 복구하는 데 몇 분 정도 걸릴 수 있음)
• 다중 가용 영역 손실
• 리전 연결 손실
• 2개 이상의 AZ에서 50% 이상의 노드 손실
• 워크로드 특성 변화에 따른 컴퓨팅 또는 스토리지 부족으로 인한 가동 중단
• 불법 쿼리로 인한 가동 중단
• ARPS 및 ALB와 같이 Amazon OpenSearch Service에 사용되는 1개 이상의 서비스 손실
• 버전 업그레이드 중 OpenSearch 대시보드의 가동 중단

아니요. 원칙적으로 크기 조정 가이드라인은 동일합니다. Multi-AZ with Standby를 사용하려면 클러스터 크기 조정에 필요한 멘탈 모델을 간소화하는 사전 요구 사항을 충족해야 합니다. 관리형 클러스터의 크기 조정에서 고려해야 할 것은 워크로드를 처리하는 데 필요한 용량을 확인한 다음 이중화를 위해 50%를 추가해야 한다는 것입니다. 현재의 ‘영역 인지’ 옵션과 Multi-AZ with Standby 옵션의 주된 차이는 가용성 유지를 위해 중복 용량 또는 추가 용량을 처리하는 방식에 있습니다. Multi-AZ with Standby를 사용하려면 각 AZ에 1개 이상의 데이터 복사본이 있어야 합니다. 그렇게 해야 Multi-AZ with Standby가 한 AZ의 용량을 대기 용량으로 명시적으로 예약할 수 있습니다. 이 대기 용량은 AZ 중단이나 인스턴스 장애 시 장애 조치 대상 역할을 합니다. 기존 모델에서는 워크로드를 처리하기 위한 최적의 리소스 수준을 유지해야 합니다. 클러스터의 크기 조정 문제를 계속해서 모니터링하고 워크로드 특성이 변경되면 수정 조치를 취해야 합니다.

아니요. Amazon OpenSearch Service는 공동 책임 모델을 기반으로 작동합니다. 클러스터의 크기를 워크로드에 맞게 조정할 책임은 사용자에게 있습니다. Multi-AZ with Standby를 사용하면 클러스터 설정 멘탈 모델이 간소화됩니다. 스토리지, CPU 및 RAM 사용률과 함께 오류 및 지연 시간 지표를 계속 모니터링하여 클러스터가 과부하 상태이고 확장이 필요할 수 있다는 신호를 찾아야 합니다.

아니요. Multi-AZ with Standby 기능은 추가 비용 없이 제공됩니다. 워크로드를 처리하기 위해 클러스터에 배포된 리소스에 대해서는 계속해서 요금이 부과됩니다. 클러스터가 이미 모범 사례를 따르고 있고 3AZ 클러스터에서 데이터 복사본이 3개 이상 있는 경우 Multi-AZ with Standby로 전환해도 추가 비용이 발생하지 않습니다. 그러나 클러스터의 크기가 작거나 워크로드를 처리하기에 충분한 중복 용량이 없는 경우 Multi-AZ with Standby로 전환하려면 가용성과 성능을 개선하기 위해 용량을 추가해야 합니다. 대기 용량은 구성된 총 용량에서 예약됩니다.

Amazon OpenSearch Service SLA는 Amazon OpenSearch Service의 월간 가동 시간 비율을 99.9% 이상 보장합니다.

Amazon OpenSearch Service의 다중 AZ 도메인에 매월 청구 주기 중 99.9% 미만의 가동 시간 비율이 있는 경우 Amazon OpenSearch Service SLA 하에서 Amazon OpenSearch Service에 대한 SLA 크레딧을 받을 수 있습니다.

SLA 이용 약관과 요청 제출 방법에 대한 자세한 내용은 Amazon OpenSearch Service SLA 세부 정보 페이지를 참조하세요.

클러스터 간 검색은 연결된 두 클러스터 간에 쿼리 및 집계를 수행할 수 있는 Elasticsearch 및 OpenSearch 기능입니다. 이 기능은 참여 클러스터 간에 가벼운 단방향 연결을 설정하여 작동합니다.

클러스터 간 검색에 참여하는 도메인은 다음 기준을 충족해야 합니다.

• 참여 도메인은 OpenSearch 또는 Elasticsearch 버전 6.8 이상을 사용해야 합니다.
• 참여 도메인은 전송 시 암호화를 활성화해야 합니다.
• 참여 도메인은 FGAC(세분화된 액세스 제어)를 활성화해야 합니다.
• 참여 도메인 버전은 롤링 버전 업그레이드와 동일한 규칙을 준수해야 합니다.

현재 다음 인스턴스 유형에서 클러스터 간 검색이 지원됩니다.

• i2, i3 패밀리
• r3, r4, r5 패밀리
• m4, m5 패밀리
• c4, c5, 패밀리
• Graviton 패밀리

기술적 제한으로 인해 t2 및 m3 패밀리 인스턴스에서는 클러스터 간 검색이 지원되지 않습니다.

예. 참여 도메인은 두 개의 서로 다른 AWS 계정에 속할 수 있습니다.

예.

클러스터 간 검색을 시작하려면 여기에서 설명서를 참조하세요.

클러스터 간 복제는 Amazon OpenSearch Service에서 동일하거나 다른 AWS 리전에서 짧은 대기 시간으로 한 클러스터에서 다른 클러스터로 인덱스 복사 및 동기화를 자동화하는 데 사용할 수 있는 새로운 기능입니다.

클러스터 간 복제에 참여하는 도메인은 다음 기준을 충족해야 합니다.

• 참여 도메인은 Elastsearch 버전 7.10 이상을 사용해야 합니다.
• 참여 도메인은 전송 시 암호화를 활성화해야 합니다.
• 참여 도메인은 FGAC(세분화된 액세스 제어)를 활성화해야 합니다.
• 참여 도메인 버전은 롤링 버전 업그레이드와 동일한 규칙을 준수해야 합니다.

예. 서로 다른 두 AWS 리전의 도메인이 클러스터 간 복제에 참여할 수 있습니다.

아니요. 클러스터 간 복제의 현재 구현은 Ultrawarm 또는 Cold 스토리지를 지원하지 않습니다.

예. Amazon OpenSearch Service를 통해서 데이터를 전송 또는 수신할 경우 표준 AWS 데이터 전송 요금이 적용됩니다.

2021년 4월 12일에 AWS는 Elasticsearch 및 Kibana의 오픈 소스 갈래로 커뮤니티 주도의 OpenSearch 프로젝트를 발표했습니다. 당사는 사용자들이 새롭고 혁신적인 기능이 풍부한 로드맵과 함께 계속해서 안전하고 고품질에 완전한 오픈 소스 검색과 분석 제품군을 사용할 수 있도록 OpenSearch에 장기적인 투자를 감행하였습니다. 이 프로젝트에는 OpenSearch(Elasticsearch 7.10.2에서 도출됨) 및 OpenSearch 대시보드(Kibana 7.10.2에서 도출됨)가 포함됩니다. 2021년 7월 12일에 OpenSearch 버전 1.0을 출시했습니다. OpenSearch에 대한 장기적 헌신의 일환으로, 2021년 9월 7일자로 OpenSearch 1.0에 대한 관리형 서비스 지원을 추가하고 Amazon Elasticsearch Service에서 Amazon OpenSearch Service로 이름을 변경하였습니다. OpenSearch 1.0과 함께, 당사는 기존 Elasticsearch 버전에 대한 지원을 7.10이 서비스되는 동안 계속할 것입니다. 이름 변경과 별개로 AWS는 진행 중인 운영, 개발 방법론 또는 비즈니스 사용에 아무런 영향을 주는 일 없이 똑같이 훌륭한 경험을 계속 제공할 것을 여러분에게 약속합니다. OpenSearch에 대해 자세한 내용은 https://opensearch.org를 참조하세요.

이번 이름 변경이 가능한 원활하게 진행되도록 하기 위해 최선을 다하고 있습니다. 새로운 SDK/구성 API처럼 사용자가 서비스로부터 최고의 이점을 창출하도록 사용자의 작업이 필요한 부분도 있습니다. 호환성 관점에서, 기존 SDK로 계속 작업을 할 수 있는 한편, 새로운 구성 API가 필요한 모든 새로운 기능은 새로운 SDK에만 구현됩니다. 따라서 새로운 SDK로 이동하는 것이 좋습니다. 추가로, 새로운 SDK와 관계 없이 이름이 변경된 구성 API를 사용하도록 기존 IAM 정책을 이동하는 것이 좋습니다. 현재는 기존 IAM 정책으로 오래된 API 정의와 계속 작업할 수 있습니다. 그러나 새로운 API 기반 권한 검증으로 넘어가게 될 것이고 나중에는 새로운 API를 정책에 사용하게 될 것입니다(특히 CreateElasticsearchDomain에서 CreateDomain으로 바뀐 예처럼 이름 변경이 있었던 API). 자세한 내용은 설명서를 참조하세요.

아니요. 하위 호환성 관점에서 당사는 기존 설정으로도 계속해서 OpenSearch 1.0으로 작업할 수 있도록 보장할 것입니다. 그러나 위에 언급한 대로, 더 깔끔한 최신 환경을 위해 나중에는 최신 SDK로 이동하는 것이 좋습니다.

아니요. 요금은 변경되지 않습니다.

OpenSearch에는 Elasticsearch B.V. 및 다른 소스 코드의 특정 Apache 라이선스 Elasticsearch 코드가 포함됩니다. Elasticsearch B.V.는 다른 소스 코드의 소스가 아닙니다. ELASTICSEARCH는 Elasticsearch B.V.의 등록 상표입니다.

OpenSearch 1.x로 업그레이드하면 검색 인프라가 발전하고 역동적인 Apache 라이선스 오픈 소스 프로젝트를 기반으로 구축되며 OpenSearch 1.2에서 제공하는 풍부한 혁신적인 개선 사항과 기능을 활용할 수 있습니다(이 문서 작성 시점).  엔터프라이즈급 보안, 알림, 데이터 수명 주기 관리, 관측성, 기계 학습 기반 이상 감지 등과 같은 기능은 모두 OpenSearch Service의 일부이며, 추가 라이선스 비용이 들지 않습니다.

저희는 업그레이드 중에 블루/그린(BG) 배포 프로세스를 사용합니다. BG 중에 서비스는 노드를 새 구성 및 버전의 OpenSearch Service 클러스터에 추가하고, 데이터를 기존 노드에서 마이그레이션하며, 데이터 마이그레이션이 완료되면 기존 노드를 삭제합니다. BG 중에 API 검색 및 인덱싱은 사용 가능하며 정상적으로 작동합니다. BG는 요청 쿼리 및 인덱싱을 방해하지 않도록 설계되었지만, 일부 변경 사항(특히 보안 관련 설정에 수반되는 변경 사항)은 변경 기간 동안 대시보드를 사용할 수 없게 만들 수 있습니다.

AWS는 19가지 버전의 Apache-2.0 라이선스 Elasticsearch를 유지 관리합니다. 현재 이러한 버전 중 더 이상 사용하지 않거나 사용하지 않을 계획이 있는 버전은 없습니다.

예. 업그레이드하면 BG 배포 프로세스가 트리거됩니다. 여기에서 업그레이드 준비 사항과 단계를 확인하세요.

RI 관련 특정 상황에 따른 정보 얻으려면 AWS 계정 팀과 협력하세요.

OpenSearch 프로젝트 1.0은 오픈 소스 Elasticsearch 7.10.2의 분기입니다. Elasticsearch 7.10과 호환되므로 사용을 변경할 필요가 없습니다. 마이그레이션하려면 도메인을 이전 버전인 Elasticsearch 6.x 및 7.x 시리즈에서 7.10 버전으로 업그레이드하고, 스냅샷을 생성하고, 해당 스냅샷을 OpenSearch Service 1.x를 실행하는 도메인에 복원합니다. 일부 클라이언트 또는 도구에는 클라이언트 또는 도구가 OpenSearch Service와 함께 작동하지 않을 수 있는 버전 검사가 포함되어 있습니다. 업그레이드를 하면 호환 모드를 활성화하여 이러한 버전 검사를 피할 수 있습니다.

대부분의 경우 기존 클라이언트를 계속 사용할 수 있습니다. API 및 주요 검색 기능은 Elasticsearch 버전 7.10.2와 호환됩니다. 기존 클라이언트가 있거나, 클라이언트가 버전 검사를 수행하거나, 클라이언트가 기존 버전(버전 5 또는 6)의 Elasticsearch를 대상으로 하는 기능을 활용하는 경우, 원활하게 전환하기 위해 최소 표준 지원인 7.10.2로 클라이언트를 전환하는 것이 좋습니다.

OpenSearch 프로젝트는 Amazon OpenSearch Service의 OpenSearch 엔진 버전을 처리하기 위해 특별히 구축된 넓은 범위의 클라이언트를 지원합니다. 클라이언트를 최신 OpenSearch 클라이언트 및 해당 클라이언트에 대해 지원되는 프로그래밍 언어 목록과 비교하여 확인하세요.

호환 모드 기능을 활성화하여 다른 공급업체의 클라이언트와 상호 운영할 수 있지만, OpenSearch에서 보고하는 버전을 확인해야 합니다. OpenSearch Service 엔진이 도입되기 전에 개발된 클라이언트에 서비스가 버전 7.10.2로 응답하도록 하려면 이 설정을 활성화합니다.

Elasticsearch 5.x 인덱스는 Elasticsearch 7.10 또는 OpenSearch 1.x와 호환되지 않습니다. 새 인덱스를 생성하고 소스에서 데이터를 로드해야 합니다. 로그 분석 워크로드를 실행하고 있는 경우, 새 도메인에서 전체 데이터 세트를 구축하는 동안 데이터 보존 전략이 병렬 실행을 지원하는지 평가할 수 있습니다.

예. opensearchmigration-si-support@amazon.com에 연락하여 리전, 산업, 프로젝트 복잡성에 따른 파트너 목록을 요청하세요. AWS 파트너 네트워크(APN) 파트너는 교육을 받았고 업그레이드를 지원한 경험이 있습니다. 

OpenSearch 1.0은 Elasticsearch 7.10.2의 분기입니다. OpenSearch와 Elasticsearch는 호환됩니다. 호환 모드를 활성화한 경우, Elasticsearch 클라이언트는 OpenSearch 1.0과도 호환됩니다.

Amazon OpenSearch Service는 7.10.2 이후 버전의 Elasticsearch 엔진을 제공하지 않으며 앞으로도 제공하지 않을 것입니다.

AWS가 Elasticsearch를 포크했을 때 발표했듯이 OpenSearch를 중심으로 활발한 커뮤니티를 구축하려고 했고, 구축했습니다. 저희는 기능 우선 순위에 대한 커뮤니티의 조언과 합의로 완성된 OpenSearch 로드맵을 발표했습니다. Elasticsearch와의 호환성을 유지하기 위해 모든 합당한 노력을 할 것입니다. 저희 목표는 커뮤니티를 성장시키고 Amazon OpenSearch Service 고객을 늘리는 것입니다.

Elasticsearch 및 Kibana 버전 6.8.0~7.10.2, Open Distro for Elasticsearch (ODFE) 1.x에서 OpenSearch Service 1.0으로 직접 업그레이드할 수 있습니다. ODFE에서 OpenSearch로 롤링 업그레이드하는 경우, 먼저 ODFE 1.13으로 업그레이드한 다음 OpenSearch 1.0으로 업그레이드하는 것을 권장합니다.

마이그레이션 리소스:

분석 마이그레이션

Amazon OpenSearch Service로 마이그레이션

Amazon DynamoDB와의 이러한 제로 ETL 통합은 운영 데이터 저장소에서 검색 데이터 저장소로의 데이터 복제를 조율하는 데 따른 운영 복잡성을 간소화합니다. 다양한 데이터 스토어를 동기화하는 데 사용되는 데이터 파이프라인은 구축 및 관리가 어렵고 비용이 많이 들며 추적하기 어려운 오류가 간헐적으로 발생할 수 있습니다. 이러한 통합을 통해 Amazon DynamoDB 고객은 Amazon DynamoDB의 운영 데이터를 작성 후 몇 초 내에 Amazon OpenSearch Service에서 사용할 수 있도록 하는 완전관리형 솔루션을 제공함으로써 트랜잭션 데이터에서 거의 실시간에 가까운 검색 결과를 얻을 수 있습니다.

Amazon OpenSearch Service와 Amazon DynamoDB의 제로 ETL 통합은 Amazon OpenSearch 수집을 사용하여 운영 데이터를 Amazon DynamoDB에서 Amazon OpenSearch Service로 원활하게 이동합니다. 통합을 활성화하려면 고객은 먼저 데이터를 복제해야 하는 Amazon DynamoDB 테이블을 선택합니다. 제로 ETL 통합 기능은 Amazon OpenSearch Service 관리형 클러스터 또는 서버리스 컬렉션에 데이터 복제를 담당하는 Amazon OpenSearch 수집 파이프라인을 고객 계정에 설정합니다. Amazon OpenSearch 수집은 Amazon DynamoDB 테이블의 구조를 이해한 다음 DynamoDB 테이블의 기존 데이터를 사용하여 Amazon OpenSearch Service 관리형 클러스터 또는 서버리스 컬렉션을 부트스트랩합니다. 선택적으로 고객은 Amazon OpenSearch Service에서 생성될 인덱스의 스키마를 지정할 수 있습니다. 또한 DynamoDB 테이블에 대한 모든 업데이트는 고객의 수동 개입 없이 Amazon OpenSearch Service에 복제됩니다.

이 제로 ETL 기능은 Amazon OpenSearch Ingestion을 사용하여 데이터를 Amazon DynamoDB에서 Amazon OpenSearch Service로 이동하고, Amazon OpenSearch 통합 파이프라인의 기본 데이터 변환 기능을 활용하여 데이터가 이동하는 동안 데이터를 집계 및 필터링합니다. Amazon DynamoDB 테이블에서 데이터를 이동할 때 고객은 필드를 몇 개 삭제하거나 기존 필드의 집계를 기반으로 새 필드 생성을 원할 수 있습니다. 선택적으로 고객은 Amazon OpenSearch Ingestion에 대한 사용자 지정 로직을 작성하여 맞춤형 변환 기능을 구현할 수도 있습니다. 전체 데이터를 소스에서 싱크로 이동하려는 다른 사용자를 위해 Amazon OpenSearch 수집은 몇 번의 버튼 클릭만으로 통합을 수행할 수 있도록 즉시 사용 가능한 블루프린트를 제공합니다.

Amazon OpenSearch 수집이 두 시스템 모두에서 데이터를 복제하는 데 필요한 권한을 갖도록 하기 위해 제로 ETL 통합 기능은 Amazon DynamoDB 테이블에서 데이터를 읽고 Amazon OpenSearch 도메인 또는 컬렉션에 쓰는 데 필요한 권한이 있는 IAM 역할을 생성합니다. 그런 다음 Amazon OpenSearch Ingestion 파이프라인에서 해당 역할을 맡아 데이터를 소스에서 대상으로 이동할 때 항상 올바른 보안 태세를 유지하도록 합니다.

Amazon OpenSearch Ingestion에서 제공하는 대시보드에서 Amazon DynamoDB와의 Zero-ETL 통합과 관련된 모든 지표를 Amazon CloudWatch의 실시간 로그와 함께 볼 수 있습니다. 이를 통해 고객은 사용자 정의 임계값이 초과될 때 트리거되는 사용자 지정 알림을 설정할 수 있습니다.

OpenSearch Service 쿼리 엔진은 Amazon S3 및 S3 기반 데이터 레이크와 같은 클라우드 객체 스토어에 저장된 운영 데이터의 분석을 지원하도록 재설계되었습니다. 데이터를 복제하지 않고도 이 작업을 수행할 수 있습니다. 몇 초 만에 차이가 나면 고객은 새로운 통합에 내장된 쿼리 가속화 기능을 사용하여 쿼리 성능을 높이고 빠르게 로드되는 대시보드를 구축할 수 있습니다.

AWS Management Console을 시작하려면 고객은 OpenSearch Service 버전 2.11 이상을 실행하는 기존 OpenSearch Service 도메인에서 새 데이터 소스를 설정해야 합니다. 새로운 다이렉트 쿼리 데이터 소스를 설정할 때 고객은 Amazon S3 및 AWS Glue 데이터 카탈로그에 대한 읽기/쓰기 권한을 제공하여 OpenSearch Service에서 Amazon S3에 있는 데이터를 쉽게 쿼리할 수 있도록 해야 합니다. 고객은 IAM 정책을 사용자 지정하여 Amazon S3의 특정 버킷 또는 AWS Glue 데이터 카탈로그의 리소스에 대한 액세스를 제한할 수 있습니다. 콘솔에서 새 데이터 소스를 구성한 후 고객은 OpenSearch Service로 이동하여 역할 기반 액세스 제어, 쿼리 성능 향상을 위한 가속화, VPC 흐름 로그, Elastic Load Balancer Logs 및 NGINX 로그와 같은 인기 있는 로그 유형 템플릿을 위한 뛰어난 대시보드(선택 사항)를 구성합니다. 고객에게는 직접 쿼리 OpenSearch 컴퓨팅 유닛(OCU)의 형태로 소비된 컴퓨팅 리소스에 대한 요금이 청구되며, 사용률이 적용됩니다. 새 데이터 소스를 구성한 후 고객은 OpenSearch API 또는 OpenSearch 대시보드에서 직접 데이터 쿼리를 시작할 수 있습니다.

고객은 워크로드에서 사용한 리소스에 대해서만 비용을 지불합니다. OpenSearch Service는 외부 데이터를 직접 쿼리하고 OpenSearch Service에서 선택적 인덱스를 유지 관리하는 데 필요한 컴퓨팅에 대해서만 요금을 청구합니다. 컴퓨팅 용량은 Amazon OpenSearch Serverless 및 Amazon OpenSearch 수집에서 사용되는 것과 동일한 단위인 OpenSearch 컴퓨팅 단위(OCU)로 측정됩니다. OCU 수는 데이터를 기반으로 인덱스를 쿼리하거나 유지하는 데 필요한 vCPU 및 메모리에 직접적으로 해당합니다. 고객에게는 데이터 모으기 레이블이 있는 OCU 시간 단위의 컴퓨팅 항목이 하나 표시됩니다. OCU는 시간 단위(분)로 요금이 청구됩니다. 쿼리나 인덱싱 활동이 활성화되어 있지 않으면 OCU가 사용되지 않습니다. Amazon S3 또는 AWS Glue 데이터 카탈로그에 대한 비용은 고객 계정에서 별도로 청구됩니다. 자세한 요금 정보는 Amazon OpenSearch Service 요금 페이지를 참조하세요.