AWS 오픈서치 관련 내역 정리

IT/EKS

AWS 오픈서치 관련 내역 정리

클라우드 개발자 앙몬드 2023. 5. 31. 14:26

혹시라도 읽으시는 분들은,

이거 그냥 개인 메모니까 굳이 이 글 말고 다른거 찾아보시면 됨 ㅇㅇ

인덱스

> 샤드

> 루신 인덱스

> 세그먼트(다큐먼트들) .. 세그먼트가 실제 디스크

바로 세그먼트까지 들어가진 않고, 1초동안 버퍼에 있다가 세그먼트로 감. (디폴트 1초임. 이건 보통 좀 크게 리프레시 인터벌을 지정해서..)

검색 기준은 무조건 스토리지 세그먼트에 들어가있어야 함.

> 샤드 개수 & 레플리카 개수

.. 샤드 = 프라이머니 샤드 (최소 3개 이상을 권장함. 아니면 데이터 노드 개수에 맞추어서 배수로. 즉 노드 3개면 3개 마스터 샤드.)

.. 레플리카 = 복제본 샤드 (최소 1개 이상은 무조건 있어야 함)

> 오픈서치는 마스터 샤드 최초 설정 이후 변경 불가. 그래서 엘사는 스케일아웃. 오서는 스케일업 을 권장함

> 샤드 고르게 배포하려면, 샤드 수를 데이터 노드 (혹 az) 배수로 구성하면 좋음.

> 가용성 높이려면 az배수 고려해서 레플리카 구성하면 좋음.

마스터 샤드 3개. 1개의 마스터에 1개 레플리카 혹은 2개 레플리카. 대다수는 1개의 레플리카만 한다. 그리고 무조건 마스터 샤드랑은 다른 곳에 저장된다.

좀 더 레플리카 읽기 히트를 높이고 성능 올리려면 레플리카 올려주면 좋긴 함. 근데 대다수는 1개만 씀 ㅇㅇ

> 오픈서치 검색

(인덱스 패턴)

---롤링 인덱스

-인덱싱 기간 / 보존 기간 있고, 계속 흘러 들어오는경우.

-올드 인덱스는 보유 기간 따라, 웜/콜드 계층으로 마이그레이션 혹은 삭제 가능.

ex) ks-log-2022-07

---롱텀 retention 인덱스.

같은 인덱스에 소스 데이터 저장. 문서 업뎃/삭제 필요한 경우가 많을때

ex) movies, websites, (날짜별 인덱스가 없음)

(오픈서치 인덱스 사이즈 관리)

---사이즈 기반 로테이션

크기 추정 불가.

삭제 요구사항 없음.

동일 샤드 크기 유지.

ex) index-a-000, index-a-001

---기간(시계열) 기반 로테이션

크기 추정 가능

삭제 요구사항 있음.

기간 기준 검색 요구사항 있음.

ex) index-a-2022-09-01, index-b-2022-09-02

(인덱스 로테이션 빈도 따른 주의사항)

매일마다 일정 데이터 흐름 속도/양 으로 들어오더라도, 빈도에 따라 샤드 구성 달라진다.

일 데이터량 30기가, 샤드 사이즈 50기가로 가정한다면,

daily rotate

마스터 샤드 : 30기가 * 1.1/50기가 = 0.66 > 1샤드

weekly rorate

마스터샤드 수 : 30기가 * 1.1 * 7일 / 50기가 = 4.62 > 5개 샤드

monthly rotate

마스터샤드 수 : 30기가 * 1.1 * 31일 / 50기가 = 20.46 → 21개 샤드

>>> 이거 왜 1.1을 곱하지?

>>> 스파이크 / 에러 로그 대량 발생으로 달라지게 된다면, 샤드를 따로 만드는가?

-----------

(도메인 구성)

마스터 노드 역할 = 인덱싱 / 헬스 / 보존기간 등 (3개 최소 무조건임)

데이터 노드 = 검색 전용 (캐싱 가능). ec2 사이즈마다 스토리지 크기 제한.

울트라 웜 노드 = 저장 노드. 이거 ec2 사이즈마다 스토리지 크기도 제한됨.

콜드 스토리지 = 아카이브

ALB = 내부적으로 통신 시 내장됨.

opensearch 내부적으로 유저 생성 / 권한 가능. (iam) .. 쿠버랑 비슷.

---------

(도메인 구성 예측)

스토리지 계층

(핫 / 울트라 웜 / 콜드 스토리지)

핫 (데이터노드) : 인스턴스 + 데이터볼륨 (비쌈, 래이턴시 낮음)

울트라 웜 : 인스턴스 + 캐시 + s3

콜드 : 울트라 웜에서 액세스 할 수 있는 인덱스 저장영역. 콜드에서 인덱스 검색 불가.

--스토리지 크기 예측하기

핫 = 소스 데이터 크기 * (1 + 오버헤드 0.1 10%) * (1 + 레플리카 샤드) / (1 - os예약공간% 0.05) / (1- 아마존 어픈서치 서비스의 오버헤드% 0.2)

울트라 웜 = 소스 데이터 크기 * (1 + 오버헤드)

콜드 = 소스 데이터 크기 * (1 + 오버헤드)

--샤드 개수 맞추기

작은 크기의 샤드가 너무 많으면, 검색 성능 저하. 높은 힙 사용률 문제 발생.

큰 크기 샤드도 검색 성능 저하.

롱 텀 리텐션 인덱스 : 10~30기가

롤링 인덱스 : 10~50 기가

인덱스 생성 후 샤드 수 수정 불가.

롱 텀 리텐션 인덱스 : 향후 데이터 증설 고려 필요

롤링 인덱스 : 향후 데이터 증가 고려 불필요.

샤드당 검색 메모리를 할당. 그래서 작으면 메모리 성능 저하.

샤드 크면 볼륨 하나에서만 스루풋 왔다갔다. 볼륨쪽에서 성능 저하.

(예제)

매일마다 200기가 씩 들어오는 로그 데이터

각 샤드 크기는 30기가 설정했음.

롤링빈도 = 50기가 초과이므로 매일 롤링

3az에 3개의 데이터 노드가 분산되어 배포.

프라이머리 샤드 수 = (소스데이터크기 + room for growth) * (1 + 오버헤드 0.1) / 30기가 샤드크기 * 1일 = 7

7이니까 데이터노드 개수 배수로. 6 아니면 9로 마스터 샤드 개수 설정.

레플리카 = 6*2 (6은 마스터 샤드 개수)

-------------

샤드/스토리지 기반 스펙 예상하기

(일반) 액티브 샤드 당 1.5 vcpu 할당.
(고부하) 2v cpu. 스토리지 100기가 당. 이 경우 샤드 크기가 50기가 정도 되어야함

> 액티브 샤드?

-인덱싱 요청과 빈번한 검색 요청 처리하는 샤드

-인덱싱 요청 : 직접 인덱싱 하는데 사용하는 마스터 샤드 + 레플리카 샤드 수

-검색 요청 : 마스터 샤드 수만 포함

r타입 = 메모리타입. 데이터 내리는거보다 실시간 조회에 좀 더 힘을 실을 때

gp3 스토리지를 추천함.

---------

검색 성능 최적화

..인스턴스 스토어..

많은 양 데이터 검색/집계 시, 높은 io가 필요함

!!!중첩 필드 유형은 가능한 피해야함. (nested json)

nested json을 오픈서치가 다 풀어서 인덱싱하기때문에..

!!!조인 필드 피하셈.

1:N 관계 구조.

--------

인덱싱 최적화

.. 벌크 api 이용해서 한방에 저장하자 ㅇㅇ (3~5메가 정도 될거임)

------

리프레시 인터벌.

jvm heap : 인덱싱 버퍼 (48메가 < 10% 힙)

> (리프레시) >파일시스템 캐시 (페이지 캐시임) : 세그먼트데이터.

> (플러시) > 디스크 (세그먼트 저장)

-------

(오토 튜닝)

..유지 관리 기간 중 블루.그린 배포로 반영됨.

jvm 셋팅 (힙 크기 최대 128기가까지)

-------

엘사 analyzer , 형태소분석기(은전한닢) 설치해보기 ㅇㅇ

저작자표시