Amazon OpenSearch Deep dive - 내부구조, 성능최적화 그리고 스케일링

AWS DATA SPECIAL WEBINAR
© 2022, Amazon Web Services, Inc. or its affiliates.
Amazon OpenSearch Service Deep Dive
내부구조, 성능최적화 그리고 스케일링
김성일
Sr Analytics Specialist Solutions Architect
AWS

Agenda
2
• Amazon OpenSearch Service
• Document, Index, Shard
• Index 디자인
• 적합한 Domain 구성 예측
• API 요청 핸들링
• 검색성능 최적화
• 인덱싱 최적화
• 기타 유용한 팁
• 스케일링

Amazon OpenSearch Service
3

© 2022, Amazon Web Services, Inc. or its affiliates. 4
Amazon OpenSearch Service
• 대화형 로그 분석
• 실시간 애플리케이션 모니터링
• 웹사이트 검색
• 최신 버전의 OpenSearch와 19가지 버전의 Elasticsearch(1.5 ~ 7.10 버전)에 대한 지원
• OpenSearch Dashboards 및 Kibana 기반 시각화 기능(1.5 ~ 7.10 버전)을 제공합니다.
• 오픈소스
• Elasticsearch에서 파생된 분산 검색, 분석 제품군
https://opensearch.org/

Document, Index, Shard
5

Field
Document
{
"name": "John Smith",
"age": 42,
"confirmed": true,
"join_date": "2014-06-01",
"home": { "lat": 51.5, "lon": 0.1 },
"accounts": [
{ "type": "facebook", "id": "johnsmith" },
{ "type": "twitter", "id": "johnsmith" }
]
}

Index
=
Index
document
ID ID ID ID ID
ID ID ID ID ID

OpenSearch 구조
Index
Shard Shard Shard
Lucene
Index
Lucene
Index
Lucene
Index
Segment Segment Segment Segment Segment Segment
Document

Shard - 배포
1
2 3
Primary Shard
여러 document가 들어있음 데이터 노드
Index
Shard Shard Shard

Shard - 배포
1
2 3
Primary Shard
데이터 노드
Replica Shard
3
2
1
3
1
2
Replica Shard
PUT more-movies
{
“settings” : {
“Index” : {
“number_of_shards” : 3,
"number_of_replicas" : 2
}
}
}

Shard - 고려사항
Shard를 고르게 배포하려면 Shard 수를 데이터 노드(또는 AZ)의 배수로 구성하면 좋습니다.
1 2 3 1 2
vs
number_of_shards : 3 number_of_shards : 2
가용성을 높이려면 AZ의 배수를 고려해서 Replica 수를 구성하면 좋습니다.
Availability
Zone
1
Availability
Zone
1
Availability
Zone
1
number_of_replicas : 2
vs
Availability
Zone
1
Availability
Zone
1
Availability
Zone
number_of_replicas : 1

Index 디자인
12

Index - 패턴
Long-Term Retention Index
• 같은 Index에 소스 데이터를 저장
• 문서의 업데이트하거나 삭제가
필요한 경우가 많음
• movies
• website-contents
• Internal-docs
Rolling Index
• 인덱싱 기간 또는 보존 기간이 있고
계속적으로 흘러 들어오는 경우
• 오래된 Index는 보유 기간에 따라
Warm/Cold 계층으로
마이그레이션하거나 삭제 가능
• search-logs-2022
• iot-sensor-logs-2022-07
• weblogs-2022-07-30

Index - 사이즈 관리
사이즈 기반 로테이션
• 크기 추정 불가
• 삭제 요구사항 없음
• 동일한 Shard 크기 유지
• index-A-000000
• Index-A-000001
기간(시계열) 기반 로테이션
• 크기 추정 가능
• 삭제 요구사항 있음
• 기간 기준 검색 요구사항 있음
• index-A-2022-09-01
• Index-A-2022-09-02

Index – 로테이션 빈도에 따른 주의사항
매일마다 일정한 데이터 흐름 속도(양)으로 들어오더라도, 빈도에 따라 Shard 구성이 달라짐
만약, 일일 데이터 양이 30GB이고, Shard 사이즈를 50GB라 가정하면,
Daily rotate
• Primary Shard 수: 30GB* 1.1/50GB = 0.66 -> 1 Shard
Weekly rotate
• Primary Shard 수: 30GB* 1.1* 7일/50GB = 4.62 -> 5개 Shard
Monthly rotate
• Primary Shard 수: 30GB* 1.1 * 31일/50GB = 20.46 -> 21개 Shard

적합한 Domain 구성 예측
16

Amazon OpenSearch Service Architecture

Domain 구성 예측
스토리지 크기
Index 디자인/전략에 기반한 Shard 수
Shard와 스토리지에 기반한 vCPU/Memory
vCPU/Memory에 기반한 Data nodes (instanace type)
Data nodes에 기반한 Master nodes (instanace type)

Storage - Tiers
Data
Volume
Hot
Instance
＋
Cache
Volume
Instance
＋
S3 Bucket
＋
S3 Bucket
UltraWarm Cold Storage
Cost: high
Low latency
Cost: low
Latency: high

UltraWarm 노드 Amazon Elasticsearch Service domain
Dashboard
Application Load
Balancer
Queries
Active
Master
Node
Backup
Master
Node
Backup
Master
Node
Hot Data
Node
Hot Data
Node
Hot Data
Node
Hot Data
Node
UltraWarm
Node
UltraWarm
Node
UltraWarm
Node
Amazon S3
POST _ultrawarm/migration/my-Index/_warm
POST _ultrawarm/migration/my-Index/_hot

Cold Storage
• UltraWarm에서 액세스할 수 있는 Index 저장 영역
• 콜드 스토리지의 Index는 검색이 불가능
• 오랜 기간 동안 저렴하게 Index를 저장할 수 있음
• UltraWarm 노드에서 떼어내서 도메인의 스토리지 크기 제한에 관계없이 사용
• Index는 언제든지 UltraWarm 노드에 연결할 수 있음

Storage 크기 예측
Data Volume
Hot
Instance
＋
Cache Volume
Instance
＋
Bucket
＋
Bucket
UltraWarm Cold Storage
Source data size
x (1+ Overhead)
x (1+ Replicas)
÷ (1- OS 예약공간%)
÷ (1- Amazon
OpenSearch
Service
Overhead%)
Source data size
x (1+ Overhead)
× (1 + 0)
Source data size
x (1+ Overhead)
× (1 + 0)
OS 예약공간
• 노드 별 Storage 용량의 5% 확보
Amazon OpenSearch Service Overhead
• 노드 별 Storage 용량의 20% 확보 (최대 20GB)
• 500GB/3개 노드: MIN(20GB, 500GB x 0.2) x 3 = 60GB
• 50GB/30개 노드: MIN(20GB, 50GB x 0.2) x 30 = 300GB
0.1
2
0.05
0.2

Index overhead
일반적으로 오버헤드는 10% 정도
_cat/indices API

Shard - 개수와 사이즈
Magic number?
• 작은 Shard가 너무 많으면 검색 성능 저하, 높은 Heap 사용률 등의 문제가 발생합니다.
• Shard 사이즈가 너무 커도 검색 성능이 저하됩니다.
• Long-Term Retention Index : 10GB - 30GB
• Rolling Index : 10GB - 50GB
• Index 생성 후에는 Shard 수를 수정할 수 없습니다.
• Long-Term Retention Index : 향후 데이터 증가 고려 필요
• Rolling Index : 향후 데이터 증가 고려 불필요

Shard - 예측
Primary Shard의 수
= (source data + room for growth) x (1 + Indexing overhead) / size per Shard
<참고>
• 노드/AZ 수의 균형을 맞추면서 최종 Shard 수를 조정하는 것이 좋습니다.
• Primary Shard의 개수가 7과 같이 2나 3으로 나누어지지 않는 경우
• 배포할 가용 영역의 수에 맞춰서
• 8 (2AZ의 배수) 또는 9 (3AZ의 배수) 로 고르게 분산 시키는 것이 좋습니다.
PUT more-movies
{
“settings” : {
“Index” : {
“number_of_shards” : 3,
"number_of_replicas" : 2
}
}
}

Shard - Primary Shard 수 계산
가정
• 매일마다 200 GB 씩 들어오는 로그성 데이터
• 각 Shard 크기는 30 GB 로 하려고 함
• 롤링 빈도
• 50GB를 초과하므로 매일마다 롤링
• 3 AZ에 3개의 데이터 노드가 분산되어 배포
계산 결과
• Primary Shard의 수: (200 GB + 0) x (1 + 0.1) / 30 GB x 1 day = 7
• 7 -> 6 (또는 9)
• Replica Shards
• 6 x 2 = 12 Shards per day (또는 9 x 2 = 18 Shards per day)

vCPU 예측
• 일반적인 워크로드
• 클러스터에 할당할 vCPU 수는 Active Shard 수를 기반으로 합니다.
• 1.5 vCPU per Active Shard 할당
• 고부하 워크로드 (빈도가 높은 인덱싱 및 검색이 있는 데이터 분석 환경)
• 2 vCPU per 스토리지 100GB 할당
• 이 경우 Shard 크기는 50GB에 가까워야 합니다.
<참고> Active Shard?
• 인덱싱 요청과 빈번한 검색 요청을 처리하는 Shard
• 인덱싱 요청 : 직접 인덱싱하는데 사용하는 Primary Shard + Replica Shard 수
• 검색 요청 : Primary Shard 수만 포함
• 실제 필요한 vCPU는 쿼리 병렬도(QPS = Queries Per Second)에도 영향을 받음

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을 제공하지만
사용자가 제어할 수는 없습니다.

Hot node 인스턴스 타입 선택
Generic
1:4 vCPU:memory
vCPU: 2 – 48
Memory: 8 – 192 GB
Disk: 10GB – 9TB
Networking: up to 20 Gbps
R6gd
Compute-optimized
1:2 vCPU:memory
vCPU: 2 - 48
Memory: 4 – 96 GB
Disk: 10 GB - 4.5 TB
Memory optimization
1:8 vCPU:memory
vCPU: 2 – 48
Disk: 10 GB – 12 TB
Memory optimization
1:8 vCPU:memory
vCPU: 2 – 64
Disk: 118 – 3800 GB
I/O optimization
vCPU: 2 – 64
Memory: 15.25 – 488 GB
Disk: 475 – 15200 GB
https://docs.aws.amazon.com/opensearch-service/latest/developerguide/limits.html
SSD-Backed EBS(gp3, gp2, io1) NVMe SSD

Hot node 스토리지 선택
General Purpose
SSD
gp2 / gp3(recommended)
Provisioned IOPS
SSD
io1
Previous Generation
HDD
(not recommended)
magnetic
NVMe SSD
Instance store
EBS Instance Store

UltraWarm node 선택
-
Can
manage
up
to
20
TB
of
data
per
node
-
16
vCPU,
122
GiB
memory,
3.8
TiB
local
storage
-
Use
1,000
shards
per
node
as
a
guide
• 노드당 1.5 TB 까지 관리 가능
• 2 vCPU, 16 GB memory,
475 GB local storage
• 노드당 약 400 개 shard 가능
ultrawarm1.large.search
ultrawarm1.medium.search
• 노드당 20 TB 까지 관리 가능
• 16 vCPU, 122 GB memory,
3.8 TB local storage
• 노드당 약 1000 개 shard 가능

Master node 선택
Instance Count Recommended minimum instance type
1 – 10 m5.large.search or m6g.large.search
10 – 30 c5.xlarge.search or c6g.xlarge.search
30 – 75 c5.2xlarge.search or c6g.2xlarge.search
75 - 200 r5.4xlarge.search or r6g.4xlarge.search
<참고>
• T2 인스턴스 유형 및 t3.small.search는 프로덕션 환경에서 권장되지 않습니다.
• 소모되는 리소스도 Index와 Shard의 수에 따라 달라지므로 CloudWatch 메트릭에서 실제 부하 상황을 확인하고
필요에 따라 도메인 크기를 확장합니다.
• 마스터 노드의 관리 작업은 분산되지 않으므로, "스케일 아웃"이 작동하지 않습니다.
• 다만, 가용성을 위해 3노드 구성을 권장합니다.

Master node
Master
Eligible
Node-1
Master
Eligible
Node-2
Master
Eligible
Node-3
Master
Node
Master
Eligible
Node-2
Master
Eligible
Node-3

Master node
Master
Node
Master
Eligible
Node-2
Master
Eligible
Node-3
Master
Eligible
Node-1
Master
Node
Master
Eligible
Node-3

API 요청 핸들링
40

Request Thread
Thread
Thread
Thread
Queue Thread Pool

Queue
Request
Thread Pool
Thread
Thread
Thread
Thread
Request
Request
Request
Request
Request
429(Too Many Requests)

Queue, Thread Pool, vCPU 상관관계
Queue와 Thread Pool은 각 API 유형에 개별적으로 할당
• Write (for Index, update, delete, bulk)
- Queue size: 10000 (Elasticsearch 7.8 or later. Previous size is 200)
- 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
Thread Pool size는 노드에 할당된 vCPU에 따라 다릅니다.
• (vCPU를 추가하기 위해) 인스턴스 유형을 변경하면 API 동시성이 증가합니다.

검색성능 최적화
44

File system cache에 메모리 할당 늘리기
File System Cache
(Page Cache)
JVM Heap
(50% memory < 32 GB)
Indexing Buffer
(10% heap)
Shard Request Cache
(1% heap)
Node Query Cache
(10% heap)
Field Data Cache
(unbounded)
Disk
Segment
Segment
Segment

Node Query Cache 활용
GET logs/_search
{
"query": {
"bool": {
"must": [
(…)
],
"filter": [
{
"range": {
"timestamp": {
"gte": "now-1d/m",
"lte": "now/m"
}
}
(…)

필요한 경우 인스턴스 스토어 사용
Physical host
• 많은 양의 데이터를 검색하거나 집계할 때 높은 I/O 성능이 필요
• 인스턴스 스토어는 EBS보다 지연시간이 낮습니다.
• 높은 I/O 성능이 필요한 경우, 인스턴스 스토어가 있는 인스턴스 유형 사용
• EC2 공식 문서에서 각 인스턴스 유형에 대한 인스턴스 스토어의 성능을 확인
• 충분한 I/O 성능을 제공하는 적절한 인스턴스 유형을 선택

복잡한 Document 구조 피하기
• 중첩 필드 유형은 가능한 한 사용하지 마십시오
• 일반 필드 유형보다 검색 요청을 처리하는 데 몇 배 더 오래 걸릴 수 있습니다.
• 중첩 유형 아래에 여러 필드가 있고 해당 필드의 조합으로 검색해야 하는 경우
• copy_to를 사용하여 여러 필드를 결합하고 단일 필드로 복사합니다.
• 조인 필드 유형으로 부모-자식 관계를 최대한 사용하지 마십시오
• 일반 필드 유형보다 검색 요청을 처리하는 데 수백 배 더 오래 걸릴 수 있습니다.
• 1:N 부모-자식 관계 외에는 사용하지 않는 것을 권장합니다.

검색할 필드 수 줄이기
PUT users
{
"mappings": {
"properties": {
"full_name": {
"type": "text"
},
"first_name": {
"type": "keyword",
"copy_to": "full_name"
},
"last_name": {
"type": "keyword",
"copy_to": "full_name"
(…)

Term을 이용해서 범위 만들기
PUT index/_doc/1
{
"item": ”banana",
"price_krw": 4980
}
GET index/_search
{
"aggs": {
"price_ranges": {
"range": {
"field": "price_krw",
"ranges": [
{ "to": 10 },
{ "from": 10, "to": 100 },
{ "from": 100, "to": 1000 },
{ "from": 1000, "to": 5000 },
{ "from": 5000, "to": 10000 },
{ "from": 10000 }
]
(…)
GET index/_search
{
"aggs": {
"price_ranges": {
"terms": {
"field": "price_krw_range"
}
(…)
fast
slow
PUT index/_doc/1
{
"item": ”banana",
"price_krw": 4980,
"price_krw_range": "1000-5000"
}

목적에 따라 수치 데이터의 종류 선택
PUT index
{
"mappings": {
"properties": {
"product_id": {
"type": "keyword",
"fields": {
"numeric": {
"type": "integer"
}
}
}
}
}
}
(…)

가능한 Script 피하기
Shard
Primary
Shard
Replica
node.master:false
node.data:true
node.ingest:true
Data node
Pipeline
Transformation and Transfer
Kinesis
Data Firehose

Index sorting
GET scores/_doc/_search
{
"track_total_hits": false,
"size": 3,
"sort": [
{ "Score": "desc" }
]
}
“Name”: “Player000001”, “Score”:10
・・・
・・・
Skipping

큰 결과 값에는 페이징과 비동기 검색 활용
• OpenSearch는 단일 검색 요청에서 반환되는 문서 수에 제한이 있습니다.
• 기본 limit : 10,000개 문서
• index.max_result_window 업데이트
• 큰 Heap 메모리가 필요하고 vCPU 사용률 증가
• search_after, size & from과 함께 페이징을 사용하여
• API 실행당 검색되는 문서 수를 줄이기
• 비동기 검색 사용 고려
• 배치 프로세싱과 같이 오랫동안 실행되는 쿼리

Index 롤업

인덱싱 최적화
56

_bulk API
POST _bulk
{ "index" : { "_index" : "more-movies", "_id" : "1" } }
{ "title" : "Back to the Future" }
{ "delete" : { "_index" : "more-movies", "_id" : "2" } }
{ "create" : { "_index" : "more-movies", "_id" : "3" } }
{ "title" : "Back to the Future Part III" }
{ "update" : {"_id" : "1", "_index" : "more-movies"} }
{ "doc" : {“director" : "Robert Lee Zemeckis"} }
"

새로고침 간격(Refresh interval) 조절
File System
Cache
(Page Cache)
JVM Heap
Indexing Buffer
(48 MB < 10% heap)
Disk
Segment Segment
refresh flush

Replica 비활성화
1
1
Coordinating Stage
Primary Stage
Replica Stage

자동으로 생성되는 ID 사용
Formula:
• routing_factor = num_routing_shards / num_primary_shards
• shard_num = (hash(_routing) % num_routing_shards) / routing_factor
1
3
2
1
3
2 3
2
1

인덱싱과 검색 워크로드 분리
Domain 1
Domain 2
IndexA
IndexA
Replication
Indexing
Request
Search
Request

기타 유용한 팁
62

자동 튜닝(Auto-tune) 사용
Per-node
Evaluation
Cluster-
level
Evaluation
Decision
framework
Apply
optimizati
on
Deep
Telemetry
JVM Settings
• Heap size (up to 128 GiB)
• GC (change from CMS to G1GC*1)
• The size of the Young region
Cache
• Clear cache
• Field data cache size
• Shard request cache size
유지 관리 기간 중 블루/그린 배포로 반영
온라인으로 즉시 반영

워크로드에 따른 클러스터 분리

운영환경에서는 T2, T3 인스턴스를 피하십시오
• T2 및 T3의 경우 bootstrap.memory_lock이 false로 설정
• JVM에 할당된 메모리를 Swap-out 할 수 있음
• Full GC에서 Swap-out이 발생하면 Tread가 오랫동안 응답하지 않을 수 있음
• OOM을 막기위한 CircuitBreakerException 증가
• 다른 인스턴스에 비해 낮은 메모리 할당
• 지속적인 워크로드가 있는 환경에서는 T2 인스턴스 유형을 사용하지 않는 것이 좋습니다.
• CPUCreditBalance가 고갈되면 크레딧 보충이 유지되지 않음
• CPU 처리 성능이 항상 기준 성능으로 고정
• 속도 저하 및 오류와 같은 문제가 발생

Data Stream 활용
Data streams
applog
.ds-applog-
000001
.ds-applog-
000002
.ds-applog-
000003
Indexing
Request
Search
Request
POST applog/_doc
{“message”: “hello”}
POST applog/_search

스케일링
67

Scaling 전략
일반적으로 수직적 스케일링이 더 효과적
• 단일 노드가 커질수록 노드 장애 시 복구 시간이 증가
• 복구 비용과 성능 간의 Trade off
수평적 스케일링은 노드당 기능제한 대응에 효과적
• Storage 제한 (용량, IOPS, 처리량)
• Heap size 제한 (노드당 최대 32GB)
• Queue size 제한 (노드당 고정 값이 할당됨)
• 총 대역폭 - 최대 요청 페이로드 크기 (10MiB 또는
100MiB)
• Shard 수에 대한 소프트 제한 (노드당 Shard 1000개)

Thank you!

Amazon OpenSearch Deep dive - 내부구조, 성능최적화 그리고 스케일링

More Related Content

What's hot

Similar to Amazon OpenSearch Deep dive - 내부구조, 성능최적화 그리고 스케일링

More from Amazon Web Services Korea

Amazon OpenSearch Deep dive - 내부구조, 성능최적화 그리고 스케일링