엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기

공감세미나
엘라스틱서치 클러스터로
수십억 건의 데이터 운영하기
JAVACAFE
김흥래

공감세미나발표자
김흥래 (Naver Business Platform)
자바카페 커뮤니티의 운영진이다.
심심할 틈 없이 신기술이 쏟아지는 IT와 사랑에 빠진 개발자로,
개발자간의 소통과 교류를 즐긴다.
현재 네이버 비즈니스 플랫폼에서 다양한 서비스를 개발하고 있다.
hrkim3468@gmail.com

공감세미나Overview
장애경험 공유
장애방지를 위한 제안
대용량 클러스터를 위한 제안
클러스터 최적화를 위한 밴치마크

공감세미나
1. 장애경험 공유
2. 장애방지를 위한 제안
3. 대용량 클러스터를 위한 제안
4. 클러스터 최적화를 위한 밴치마크

공감세미나Cerebro가 노란색으로 바뀐다면 …
_cluster/health

Recovery Step1
정상상태

Recovery Step2
2번 Node 장애
Replica 샤드 Master 샤드로 전환
서비스는 문제없음

Recovery Step3
로드 걸리기 시작함 ㅠㅠ

Recovery Step4
열심히 Replica 샤드 생성

Recovery Step5
Replica 샤드 복제 끝나고
클러스터 안정화라고 생각했는데…

Recovery Step6
CPU 치기 시작함
2번 Node 다시 올라왔나 봄.

Recovery Step7
역시…..
곧 또 로드 걸리겠군 ㅠㅠ

Recovery Step8
2번 Node로 샤드 분산해야지….

Recovery Step9
열심히 샤드 분산중

Recovery Step10
Master 샤드도 분산되고
Replica 샤드도 분산되고

Recovery Step11
다시 평화 ^^

고민 할 포인트
• 복구 메커니즘에 따른 적절한 데이터 분산 (Node 수 or Shard 수)
• 하나의 Index 사이즈 (데이터 건수 or 데이터 사이즈)
• 하나의 Shard 사이즈 (데이터 건수 or 데이터 사이즈)
• Replica Set의 개수
• 내부네트워크도 가급적이면 10G로
• IDC 분산이 필요하다면?

공감세미나엘라스틱서치는 트랜잭션을 지원하지 않는다.
Spring Batch

_bulk
Index Queue
Index
Thread Pool
Index Request

Scroll Search

refresh=wait_for
https://www.elastic.co/guide/en/elasticsearch/reference/master/docs-refresh.html
어떤 옵션을 사용할 것인가?
refresh=false (Default) // 0.1초
refresh=true // 1.5초
refresh=wait_for // 흠…….

• wait_for 옵션을 이용하여 속도를 희생 할 것인가?
• Replica Set의 수가 많아지면 많아질수록…
• 만약 IDC 이중화가 되어있다면…

공감세미나헤비 유저에게 Kibana를 열어주면 일어나는일
Dashboard

Chart 추가

조회기간 변경

결국은 …

Coordinating Node

• Coordinating Node가 매일 죽는다면?
• 과부하를 막기 위해서는 Kibana의 권한제어가 필요하다
원천적인 해결책은?
(1) X-Pack 도입
(2) Proxy 도입

공감세미나Approximate Aggregation과 돈이 만난다면
분산환경과 집계연산
Avg Aggregation
1. 코디네이터 노드가 Avg 집계 요청을 받는다.
2. 코디데이터 노드는 클러스터에 존재하는 모든 Shard로 Avg 집계 요청을 보낸다.
3. 각각의 Shard는 자신이 가지고 있는 데이터를 기준으로 평균값을 계산한다.
4. 코디네이터 노드는 모든 Shard들의 결과를 받을때까지 기다린다.
5. 모든 결과가 도착하면 도착한 값들을 가지고 다시 평균값을 계산한다.
6. 사용자에게 정확한 평균값을 결과로 제공한다.
값을 주고 받는다.

Cardinality Aggregation ( = Distinct )
1. 코디네이터 노드가 Cardinality 집계 요청을 받는다.
2. 코디데이터 노드는 클러스터에 존재하는 모든 Shard로 Cardinality 집계 요청을 보낸다.
3. 각각의 Shard는 자신이 가지고 있는 데이터를 기준으로 중복을 제거하고 결과 데이터를
리스트로 작성한다.
4. 코디네이터 노드는 모든 Shard들의 결과를 받을때까지 기다린다.
5. 모든 Shard로 부터 리스트가 도착하면 결과를 하나로 합쳐서 다시 한번 중복을 제거한다.
6. 사용자에게 정확한 중복 제거된 결과를 제공한다.
데이터 리스트를
주고 받는다.

특정 금액
Avg Aggregation
CN
DN1 DN2 DN3
평균값 1KB
평균값 1KB
평균값 1KB
총 3KB 데이터를 평균하여 리턴
각각의 DN에 1억건의 데이터씩 총 3억건의 데이터가 분산 저장되어 있고
특정 금액의 종류가 1만건 존재할 경우
특정 금액
Cardinality Aggregation
CN
DN1 DN2 DN3
중복제거 500MB
중복제거 500MB
중복제거 500MB
총 1.5GB 데이터를 Merge하여
전체를 대상으로 한번 더 중복 제거하여 리턴

HyperLogLog++
• 확률 기반의 자료구조
• 정확한 값이 아닌 근사치 값을 제공한다.
• 일부 데이터를 샘플링하여 결과를 확률적으로 예측한다.
• 버킷 사이즈가 크면 클수록 정확도가 올라간다.

Approximate Cardinality Aggregation
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-cardinality-aggregation.html

UV, PV
• UV를 뽑기 위해서는 반드시 Cardinality 연산이 필요하다.
• 대충 비슷하게 나오면 되는거 아닌가?
• 만약 UV, PV를 이용하여 과금을 한다면?

• Unique 처리한 데이터를 별도의 인덱스로 생성한다면?
• 실시간 처리와 배치 처리를 나눠서 보여준다면?

공감세미나클러스터의 상태를 실시간으로 모니터링하자
[1단계] Cluster 레벨 모니터링
[2단계] Node 레벨 모니터링
[3단계] Index 레벨 모니터링

_cluster/stats [1단계] Cluster 레벨 모니터링

_nodes/stats [2단계] Node 레벨 모니터링

_stats [3단계] Index 레벨 모니터링

공감세미나환경설정 값들을 Runtime에 반드시 확인하자
• elasticsearch.yml에서 설정한 내역들이 나의 의도대로 실질적으로 클러스터에 반
영되었는지 확인하는 과정이 반드시 필요하다.
• Elasticsearch에서는 물리적 설정과 논리적 설정을 모두 지원하기 때문에 우선 순
위에 따라서 나의 의도와는 다르게 동작할 수 있다.
• 해당 물리 노드에만 적용하길 원할 경우 물리적 설정을 한다.
(Node명, Node타입, 네트워크 설정)
• 일반적으로는 클라우드 전체에 동일하게 적용하기 때문에 논리적 설정을 한다.

./config/elasticsearch.yml [Node] 물리적 설정정보

_nodes/노드ID [Node] 물리적 설정정보

_cluster/settings?include_defaults=true [Cluster] 논리적 설정정보

공감세미나Runtime에는 환경설정을 신중하게 변경하자
indices.recovery.max_bytes_per_sec 항목의 설정을 변경해보자.
이 항목은 Index Recovery 상황에서
초당 복구될 사이즈를 설정하는 항목이다.

./config/elasticsarch.yml 파일을 열어본다.
indices.recovery.max_bytes_per_sec : 40mb
초당 40MB의 속도로 Recovery를 수행하도록 물리적으로
설정되어 있다.

클러스터가 실제 동작하고 있는
설정값을 확인해보자.
_cluster/settings?include_defaults=true
마찬가지로 초당 40MB의 속도로
Recovery를 수행하도록 설정되어 있다.

PUT _cluster/settings
{
"transient" : {
"indices.recovery.max_bytes_per_sec" : "512mb"
}
}
Runtime 중에 복구속도를 빠르게 조정하기로 결정했다면
아래 API를 이용할 수 있다.
_cluster/settings
초당 512MB의 속도로 Recovery를 수행하도록 논리적으로 변경한다.

_cluster/settings

공감세미나장애방지를 위한 제안
• 클러스터의 상태를 실시간으로 모니터링하자
• 환경설정 값들을 Runtime에 반드시 확인하자
• Runtime에는 환경설정을 신중하게 변경하자
결론

공감세미나Master Node를 반드시 분리하자
Shard 수가 수백개라면 Config 정보는 어디에?
Master Node와 Data Node가 같은 JVM에서 동작할때 문제점은?
분산시스템에서 Data Node가 죽을 경우에 Master Node도 죽는다면?
골치 아픈 Split Brain 문제?
Master 전용 Node는 낮은 사양의 장비로도 충분하다.
안정적인 클러스터를 운영하려면 Master Node가 안정적이어야 한다.

공감세미나장비는 64GB의 물리메모리를 가지는 장비가 좋다.
Elasticsearch를 VM장비로 운영한다면 그 많은 I/O는?
Lucene은 mmap()을 통한 System Call을 공격적으로 사용한다.
물리 장비당 하나의 인스턴스가 적합하다.
물리메모리의 반은 Elasticsearch에게 나머지 반은 Lucene에게 할당하자.
분산 클러스터 특성상 고사양 서버보다는 저사양 서버 다수로 구성하는 것이 좋다.

공감세미나Elasticsearch 힙사이즈는 31GB가 좋다.
Java는 객체를 표현하기 위해 Ordinary Object Pointer (OOP)를 사용한다.
64bit 시스템이라도 힙메모리가 32GB 이하일 경우에는
Compressed OOP를 사용하여 32bit 포인터 사용이 가능하므로
성능향상에 큰 도움이 된다.

공감세미나디스크는 가급적이면 SSD를 사용하자.
루씬이 디스크 기반이기 때문에 SSD 사용시 효율이 매우 좋아진다.
이제는 SSD 가격이 매우 저렴해졌다. ^^;;;

공감세미나최대한 메모리 스와핑이 발생하지 않도록 하자.
Elasticsearch가 사용하지 않는 메모리가 OS에 의해 강제적으로 스와핑이 될 경우
성능에 치명적인 문제가 생길 가능성이 있다.
$ sudo sysctl -w vm.swappiness=1

공감세미나가상메모리 mmap 카운트를 변경하자.
Lucene의 경우 내부적으로 mmap을 많이 활용한다.
기본으로 제공되는 mmap 카운트를 262,144로 늘려야 한다.
최신버전의 Elasticsearch에서는 mmap 카운트가 부족할 경우
실행시 부트스트랩 과정에서 강제적으로 오류를 발생시킨다.
$ sudo sysctl -w vm.max_map_count = 262144

공감세미나생성 가능한 최대 파일 개수를 변경하자.
Lucene은 불변 방식으로 데이터의 정합성을 제공한다.
이 과정에서 무수히 많은 Segment가 생성될 수 있기 때문에
응용프로그램에서 생성 가능한 최대 파일 개수가 변경되어야 한다.
$ sudo sysctl -w fs.file-max=518144

공감세미나연결 가능한 최대 Connection 개수를 변경한다.
Elasticsearch는 복구과정에서 대량의 데이터를 Tcp/Ip로 주고받는다.
좀더 빠른 네트워크 처리를 위해서
연결 가능한 최대 Connection 개수를 변경해야 한다.
$ sudo sysctl -w net.core.somaxconn=65535

공감세미나대용량 클러스터를 위한 제안
결론
• Master Node를 반드시 분리하자.
• 장비는 64GB의 물리메모리를 가지는 장비가 좋다.
• Elasticsearch 힙사이즈는 31GB가 좋다.
• 디스크는 가급적이면 SSD를 사용하자.
• 최대한 메모리 스와핑이 발생하지 않도록 하자.
• 가상메모리 mmap 카운트를 변경하자.
• 생성 가능한 최대 파일 개수를 변경하자.
• 연결 가능한 최대 Connection 개수를 변경한다.

공감세미나기본개념
Search Rate
Primary Shard 및 Replica Shard에
서 실행되는 초당 검색 요청수

Search Latency
검색요청을 처리하기 위한
평균 대기시간

Indexing Rate
샤드에서 인덱싱 처리가 되고 있는
초당 문서수

Indexing Latency
인덱싱 처리를 위한
평균 대기시간

Node 모니터링

Index 모니터링

공감세미나은탄환은 없다.
서버의 Spec, 데이터의 종류, 사이즈, 검색패턴 등에 따라 결과가 달라진다.
지금 최적화 했다고 해서 앞으로도 계속 최적화 상태를 유지하지 않는다.
시간이 지날수록, 데이터가 자랄수록 정답이 달라진다.
자신의 데이터를 이용하여 항상 밴치마크를 해야 한다.
클러스터의 성능을 최대한 끌어내려면?

공감세미나밴치마크
시나리오
1. JSON 데이터 4500만건 (2.28GB) 색인
2. 검색 테스트
3. 업데이트 테스트

공감세미나밴치마크
동일한 클러스터에서 3가지 경우 밴치마크 테스트
Case1)
힙사이즈 1G, CMS GC
Case2)
힙사이즈 4G, CMS GC
Case3)
힙사이즈 4G, G1GC

엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기

Similar to 엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기 (20)

More from 흥래 김

More from 흥래 김 (20)

엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기