Amazon OpenSearch Service의 비용 최적화 기법

OpenSearch는 수집된 모든 문서를 _source 필드(원시 문서)에 한 번, 검색을 위해 인덱싱된 필드로 한 번 두 번 저장합니다.

_source 필드만으로는 총 인덱스 스토리지의 30~50%에 해당하는 상당한 스토리지 공간을 소비할 수 있습니다.

파생 소스를 사용하면 저장을 건너뛰_source고 필요한 경우(검색, 가져오기, mget, 재인덱싱 또는 업데이트 작업 중) 인덱싱된 필드에서 동적으로 재구성할 수 있습니다.

이는 옵트인으로, 복합 인덱스 설정을 사용하여 인덱스 생성 시 활성화됩니다.

OpenSearch 3.1 이상이 지원되는 모든 리전에서 사용할 수 있습니다.

OR2: OR1보다 최대 26% 더 높은 인덱싱 처리량, R7g 인스턴스보다 70% 더 높습니다.

OM2: OR1보다 최대 15% 더 높은 인덱싱 처리량, M7g 인스턴스보다 66% 더 높습니다.

둘 다 동일한 아키텍처를 사용합니다. 하나는 기본 스토리지용 로컬 EBS이고 다른 하나는 내구성을 위한 S3입니다.

복제본 스토리지 비용 제거 - 비용이 많이 드는 EBS 볼륨 대신 S3(내구성 119)에 저장된 복제본.

이전 세대 인스턴스에 비해 최대 30%의 가격 대비 성능 향상.

I/O 오버헤드 없이 거의 즉각적인 스냅샷인 얕은 스냅샷 v2를 지원합니다.

IoT/센서 데이터: 최근 기간 동안 핫 스토리지에 초당 데이터를 보관하고 이전 데이터에 대한 시간별 또는 일별 요약으로 롤업합니다.

시스템 지표: 지난 30일 동안 세부 지표를 유지하고 이전 데이터를 시간별 또는 일별 요약으로 집계합니다.

로그 데이터: 활성 문제 해결 기간(예: 1주)에 대한 전체 세부 정보를 보존하고 이전 기간에 대한 요약된 오류 패턴을 유지합니다.

ISM 정책과 결합하여 단일 수명 주기 정책에서 롤업 및 계층 마이그레이션을 자동화합니다.

몇 초에서 몇 시간으로, 몇 초에서 몇 분으로 집계할 때 절감 효과가 더 큽니다.

인덱스 자동 마이그레이션: 연령, 크기 또는 문서 수에 따라 핫 투 UltraWarm을 콜드 투 삭제로 변경합니다.

계층 전환 전에 롤업을 트리거하여 데이터 볼륨을 줄입니다.

인덱스 증가를 제어하기 위해 롤오버 정책(예: 인덱스가 50GB에 도달하거나 30일이 지난 경우)을 설정합니다.

읽기 전용 인덱스에서 강제 병합을 자동화하여 삭제된 문서에서 스토리지를 회수합니다.

롤업과 함께 사용하면 대규모 시계열 데이터 세트에서 비용을 최대한 절감할 수 있습니다.

선결제 없음, 부분 선결제 또는 전체 선결제 결제 옵션이 포함된 1년 또는 3년 약정 기간.

지속적으로 실행되는 핫 티어 데이터 노드 및 전용 마스터 노드에 가장 적합합니다.

약정하기 전에 AWS 요금 계산기를 사용하여 절감액을 추정합니다.

예약 인스턴스는 인프라 변경 없이 온디맨드 인스턴스에 적용되는 결제 할인입니다.

항상 최신 세대의 인스턴스를 사용합니다(예: Graviton3 인스턴스는 Graviton2-based 인스턴스보다 최대 25% 더 나은 성능을 제공함).

gp2 대신 gp3 EBS 볼륨을 사용하면 추가 비용 없이 저렴한 비용으로 더 나은 성능을 얻을 수 있습니다.

인스턴스 유형을 워크로드와 일치: 검색이 많은 경우 메모리 최적화, 인덱싱이 많은 경우 컴퓨팅 최적화.

전용 클러스터 관리자 노드 평가: 3개 이상의 데이터 노드에만 필요하므로 마스터 노드 크기를 과도하게 프로비저닝하지 마세요.

CloudWatch 지표를 모니터링하여 오버프로비저닝을 탐지합니다. 지속적인 CPU가 40% 미만, JVM이 50% 미만, 스토리지가 50% 미만이면 낭비의 징후입니다.

최적 범위: 지속적인 워크로드를 위한 CPU 60~80%, JVM 65~85%, 스토리지 70~85%.

권장 샤드 크기: 워크로드에 따라 샤드당 10~50GiB.

Java 힙의 GiB당 25개 이하의 샤드, 데이터 노드당 1,000개 이하의 샤드.

ISM 롤오버 정책을 사용하여 인덱스 증가를 제어하고 무제한 샤드 확산을 방지합니다.

내구성이 허용되는 복제본 수를 줄입니다(OR1/OR2 인스턴스에서는 복제본이 완전히 필요하지 않음).

읽기 전용 인덱스에서 강제 병합을 사용하여 세그먼트 수를 줄이고 스토리지를 회수합니다.

수집 비용 없음 - 데이터는 S3에 유지됩니다.

아카이브 데이터에 대한 핫 티어 스토리지 비용은 없습니다.

Pay-per-query 컴퓨팅 모델.

시각화를 위한 OpenSearch 대시보드를 지원합니다.

실시간 사용 사례가 아닌 초 또는 분 지연 시간이 허용됩니다.

샘플링: 대용량 로그 스트림의 대표적인 하위 집합만 수집합니다(예: 디버그 로그의 10%).

인덱스 압축: 최상의 압축 코덱을 활성화하여 스토리지 공간을 줄입니다.

필드 필터링: 인덱싱 전에 높은 카디널리티, 낮은 값 필드(예: 이전 로그에 대한 원시 스택 추적)를 삭제합니다.

보존 정책: 규정 준수 요구 사항에 맞게 최대 보존 기간을 정의합니다. 절대 데이터를 무기한 저장하지 마세요.

지원되지 않는 이전 버전을 유지하면 인스턴스 비용 외에 추가 요금이 발생합니다.

추가 지원 요금이 부과되지 않도록 현재 지원되는 버전으로 업그레이드합니다.

팀 또는 워크로드당 세부 비용 추적을 위해 OpenSearch 도메인에 비용 할당 태그를 적용합니다.

스토리지 사용률, JVM 압력 및 CPU에 대한 CloudWatch 경보를 설정하여 오버프로비저닝을 조기에 포착합니다.

Use AWS Cost Explorer를 사용하여 사용률이 지속적으로 낮은 도메인을 식별할 수 있습니다.

자동 조정 평가 - JVM 힙 크기 및 기타 설정을 자동으로 조정하여 성능을 개선하고 리소스 낭비를 줄입니다.

표준(in_memory) 모드에서는 전체 HNSW 그래프가 RAM에 로드되어 대규모로 엄청난 비용이 발생합니다.

on_disk 모드에서는 후보 생성을 위해 압축된(정량화된) 벡터만 메모리에 보관됩니다. 전체 정밀도 벡터는 최종 재점수 단계(2단계 검색)에 대해서만 디스크에서 검색됩니다.

이렇게 하면 높은 검색 품질을 유지하면서 RAM 요구 사항이 크게 줄어듭니다.

기본 on_disk 모드는 32x 바이너리 양자화를 사용하여 메모리 요구 사항을 인 메모리 모드에 비해 97% 줄입니다.

압축 수준 지원: 2x(FP16), 4x(바이트), 8x, 16x, 32x(바이너리).

100~200ms 범위의 P90 지연 시간 - 한 자릿수 밀리초의 응답 시간이 필요하지 않은 워크로드에 적합합니다.

1시간 이내에에서 최적화 권장 사항을 제공합니다.

벡터 수집 파이프라인과 통합됩니다.

10억 규모의 벡터 데이터베이스에 대한 GPU 가속 인덱싱과 결합할 수 있습니다.

CPU 전용 인덱싱에 비해 인덱스 빌드 시간이 6.4배~13.8배 빠릅니다.

쓰기 작업이 많은 벡터 워크로드의 경우 최대 75% 더 낮은 인덱싱 OCU 비용.

GPUs는 동적으로 연결됩니다. GPU 가속화가 활성화된 경우에만 OCUs 비용을 지불합니다.

1시간 이내에 수십억 규모의 벡터 데이터베이스를 빌드할 수 있습니다.

벡터 가속화 OCUs.

계정 수준: 최대 1,700 OCUs 모든 값(16의 배수로 제한되지 않음).

컬렉션 그룹: 1, 2, 4, 8, 16 및 16~1,696 OCUs.

인덱스 또는 인덱스 패턴당 보존 기간을 24시간에서 3,650일로 설정합니다.

Amazon OpenSearch Service Serverless는 최대한(일반적으로 보존 기간의 48시간 또는 10% 이내) 데이터를 자동으로 삭제합니다.

규칙은 컬렉션 수준, 인덱스 패턴 수준 또는 개별 인덱스 수준에서 적용할 수 있습니다. 더 구체적인 규칙이 우선합니다.

30일 보존이 포함된 1TiB/일 수집 = 약 1TiB의 핫 데이터 = 인덱싱을 위한 20OCUs + 검색을 위한 20OCUs.

7일 보존으로 축소 = 약 233GiB의 핫 데이터 = 인덱싱을 위한 약 4OCUs + 검색을 위한 4OCUs.

수집 시 필드 필터링: 파이프라인을 사용하여 컬렉션에 도달하기 전에 낮은 값 필드를 삭제합니다.

중복 또는 중복 데이터 수집 방지: 파이프라인 수준에서 중복을 제거합니다.

적절한 인덱스 매핑 사용: 저장되었지만 검색되지 않은 필드()에서 인덱싱을 비활성화합니다"index": false.

검색 컬렉션의 경우: 검색 값 없이 스토리지를 팽창시키는 큰 바이너리 BLOB 또는 원시 텍스트를 저장하지 마세요.

이전에는 각 고유 KMS 키에 전용 OCUs 필요했으므로 테넌트당 격리 비용이 매우 많이 듭니다.

컬렉션 그룹을 사용하면 별도의 암호화 키가 있는 테넌트가 OCU 용량을 공유할 수 있습니다.

많은 수의 소규모 테넌트 워크로드에 대해 최대 90%의 비용 절감.

최소 OCUs(보장된 기준, 콜드 스타트 없음)와 최대 OCUs(비용 한도)를 모두 지원합니다.

네트워크 액세스 유형이 다른 컬렉션(퍼블릭 및 VPC)은 동일한 그룹에 공존할 수 있습니다.

CloudWatch 지표는 리소스 소비 및 지연 시간에 대한 그룹별 가시성을 제공합니다.