개요
Amazon OpenSearch Service Docs를 도메인 구성 시나리오 관점에서 정리해보았습니다.
1. Document
: 데이터 기본 단위
2. Index : 데이터 범주 단위
- Rolling Index VS Long-Term Retention Index
- 사이즈기반 로테이션 VS 기간(시계열) 기반 로테이션
1) Rolling Index
- 인덱싱 기간 또는 보존 기간이 있고 계속적으로 흘러들어오는 경우
- 오래된 Index는 보유 기간에 따라 Warm/Cold 계층으로 마이그레이션하거나 삭제 가능
2) Long-Term Retention Index
- 같은 Index에 소스 데이터를 저장
- 문서를 업데이트하거나 삭제가 필요한 경우
3) 사이즈 기반 로테이션
- 크기 추정불가
- 삭제 요구사항 없음
- 동일한 shard 크기 유지
4) 기간(시계열) 기반 로테이션
- 크기 추정 가능
- 삭제 요구사항 있음
- 기간 기준 검색 요구사항 있
3. Shard
: Index별로 데이터를 저장하는 저장공간, 1개의 Index에 여러개의 Shard가 있을 수 있고 그만큼 동시에 검색가능
- 고려사항
- Shard를 고르게 배포하려면 Node의 배수로 구성하는 것이 좋다.
- 가용성을 높이려면 AZ의 배수로 Replica 수를 구성하면 좋다.
4. Domain 구성 시나리오
- 스토리지 크기
- Index 디자인/전략에 기반한 Shard 수
- Shard와 스토리지에 기반한 vCPU/Memory
- vCPU/Memory에 기반한 Data nodes (instance type)
- Data nodes에 기반한 Master nodes (instance type)
1) Storage Tier별 크기 예측
- Hot Source data size
x (1 + Overhead) - Index overhead : 약 10%
x (1 + Replicas) - Replica 수 : 1, 2, 3 …
/ (1 - OS 예약공간 %) - 약 5%
/ (1 - Amazon OpenSearch Service Overhead %) - 약 20%
- UltraWarm Source data size
x (1 + OverHead)
x (1 + 0)
- Cold Source data size
x (1 + OverHead)
x (1 + 0)
2) Shard의 개수와 사이즈
- 작고 많은 Shard : 검색성능 저하, 높은 Heap 사용률
- 크고 적은 Shard : 검색성능 저하
- 일반적으로 Shard는 50GB 이하로 설정하는 것이 좋다
- Long-Term Retention Index: 10~30GB
- Rolling Index: 10~50GB
- Index 생성 후에는 Shard 수를 수정할 수 없음
- Long-Term Retention Index : 향후 데이터 증가 고려 필요
- Rolling Index: 향후 데이터 증가 고려 불필요
- Primary Shard의 수 = (source data + room for growth) x (1 + Indexing overhead) / size per Shard ex) 매일마다 200GB씩 들어오는 로그성 데이터 각 Shard 크기는 30GB 롤링빈도 : 50GB를 초과하므로 매일마다 롤링 3 AZ에 3개의 데이터노드가 분산되어 배포 = (200 + 0) x (1 + 0.1) / 30 GB x 1day = 7 → 6 (or 9)
3) vCPU/Memory 예측
- vCPU
- 일반적인 워크로드 : 클러스터에 할당할 vCPU 수는 Active Shard 수를 기반 1.5 vCPU per Active Shard 할당
- 고부하 워크로드 (빈도가 높은 인덱싱 및 검색이 있는 데이터 분석 환경) : 2 vCPU per 스토리지 100GB 할당 (shard크기가 50GB에 가까워야함)
- Active Shard : 인덱싱요청과 빈번한 검색 요청을 처리하는 Shard
- 일반적인 워크로드 : 클러스터에 할당할 vCPU 수는 Active Shard 수를 기반 1.5 vCPU per Active Shard 할당
- Memory
- 일반적인 워크로드 : (Heap 영역에) 1GB per 20개 Shard
- 고부하 워크로드 : (Heap 영역에) 8GB per 스토리지 100GB (shard크기가 50GB에 가까워야함)
- 노드에 실제 부여하는 메모리 : 필요한 Heap size * 2
- Amazon OpenSearch Service는 노드에 할당된 메모리의 절반을 Heap 영역으로 할당
- 기본 Heap size 제한은 32GB
- Amazon OpenSearch Service는 Heap size를 최대 128GB까지 늘릴 수 있는 Auto-Tune을 제공하지만 사용자가 제어할 수는 없다.
4) Data nodes
- Hot node
- intance type : 일반적인 버전 - M6g
- Storage (EBS) : 일반적인 버전 - gp3
- UltraWarm node : 워크로드에 맞게 사용
5) Master node
- 전체 instance 노드와 개수에 따라 결정
- Master 후보 노드에서 하나의 node가 선택되는 방식,
- master node에 문제가 생기면 다른 master node 들이 투표 → 절반이상의 master node를 사용할 수 있어야함 → 따라 3개 이상으로 권장
5. API 요청 핸들링
1) Queue와 Thread Pool
- Queue의 요청을 처리하는 Tread는 shard별로 할당됨 → 1개의 queue에 여러개의 thread가 할당
- API 유형에 개별적으로 할당
- Write (for index, update, delete, bulk)
- Queue size : 10000
- Thread pool size : the number of vCPUs
- Search (for count, search, suggest)
- Queue size : 1000
- Thread pool size : int ((the number of vCPUs x 3) / 2) + 1
- Write (for index, update, delete, bulk)
6. 검색 성능 최적화
1) 자주 검색되는 Shard의 경우 File system cache에 메로리 할당 늘리기
2) Node Query Cache 활용
- filter 사용시에 응답속도 향상을 위한 캐시
- LRU정책을 사용해서 가장 오래사용되지않은 내용이 제거되고 새로운 내용이 입력
3) 많은 양의 데이터를 검색하거나 집계할 때 높은 I/O 성능이 필요시 인스턴스 스토어 사용
- EBS 보다 지연시간 낮음
4) 검색할 필드 수 줄이기 (최대한 간단하게)
- 중첩된 필드 사용 줄이기 (copy_to 이용하기)
- 1-N 과 같은 부모-자식 관계 피하기
- source data에서 숫자값을 저장하고 검색할 때 filter나 range로 검색하는것보다 term 형태로 필드를 추가해서 미리 저장해놓으면 훨씬 빠르다
- 목적에 따라 수치 데이터의 종류 선택
- 가능한 Script 피하기
- Index sorting (쓰기 성능은 저하)
- 큰 결과 값에는 페이징과 비동기 검색 활용
- 단일 검색 요청에 반환되는 문서 수 제한 : 10000개
- index.max_result_window 업데이트 → 큰 heap 메모리가 필요하고 vCPU 사용률 증가
- search_after, size & from 과 함께 페이징을 사용하여 API 실행당 문서 수 줄이기
- 비동기 검색 : 배치 프로세싱과 같이 오랫동한 실행되는 쿼리
- Index 롤업 : 집계형 데이터 수집시 이용
7. 인덱싱 최적화
1) _bulk API
단일 Shard인경우 3~5MB payload
2) 새로고침 간격 (Refresh interval) 조절
실시간 요구사항이 적을수록 새로고침 간격을 늘여서 인덱싱 성능을 증가시킬 수 있음
3) Replica 비활성화
replica가 증가하면 검색 효율을 높아지지만 쓰기 성능은 낮아짐
replica를 사용하지않으면 인덱싱 성능이 증가
4) 자동으로 생성되는 ID 사용
id 충돌 검사을 생략해서 인덱싱 성능 증가
5) 인덱싱과 검색 워크로드 분리
8. 기타 팁
1) 자동 튜닝(Auto-tune) 사용
2) 워크로드에 따른 클러스터 분리
- 로그 : 지속적인 I/O 성능 요구
3) 운영환경에서는 T2, T3 인스턴스 피하기
4) data streams 활용
- 인덱스가 너무 커지면 자동으로 인덱스 분리
- 쓰기 → 마지막 인덱스에 요청
- 검색 → 모든 인덱스에 요청
9. Scaling
1) scale up
- 일반적으로는 scale out 보다 scale up이 더 효과적, 노드가 너무 많아지면 노드끼리 통신하는 것만으로도 병목현상이 발생
- but 단일 노드가 커지면 노드 장애 시 복구 시간이 증가
2) scale out
- 단일 노드의 기능제한 대응에 효과적
- Storage 제한, Heap size 제한, Queue size 제한, 총 대역폭, 최대요청 페이로드 크기, Shard 수에대한 소프트 제한 등
kimphysicsman