2. 공감세미나발표자
김흥래 (Naver Business Platform)
자바카페 커뮤니티의 운영진이다.
심심할 틈 없이 신기술이 쏟아지는 IT와 사랑에 빠진 개발자로,
개발자간의 소통과 교류를 즐긴다.
현재 네이버 비즈니스 플랫폼에서 다양한 서비스를 개발하고 있다.
hrkim3468@gmail.com
17. 공감세미나Cerebro가 노란색으로 바뀐다면 …
고민 할 포인트
• 복구 메커니즘에 따른 적절한 데이터 분산 (Node 수 or Shard 수)
• 하나의 Index 사이즈 (데이터 건수 or 데이터 사이즈)
• 하나의 Shard 사이즈 (데이터 건수 or 데이터 사이즈)
• Replica Set의 개수
• 내부네트워크도 가급적이면 10G로
• IDC 분산이 필요하다면?
29. 공감세미나헤비 유저에게 Kibana를 열어주면 일어나는일
• Coordinating Node가 매일 죽는다면?
• 과부하를 막기 위해서는 Kibana의 권한제어가 필요하다
고민 할 포인트
원천적인 해결책은?
(1) X-Pack 도입
(2) Proxy 도입
30. 공감세미나Approximate Aggregation과 돈이 만난다면
분산환경과 집계연산
Avg Aggregation
1. 코디네이터 노드가 Avg 집계 요청을 받는다.
2. 코디데이터 노드는 클러스터에 존재하는 모든 Shard로 Avg 집계 요청을 보낸다.
3. 각각의 Shard는 자신이 가지고 있는 데이터를 기준으로 평균값을 계산한다.
4. 코디네이터 노드는 모든 Shard들의 결과를 받을때까지 기다린다.
5. 모든 결과가 도착하면 도착한 값들을 가지고 다시 평균값을 계산한다.
6. 사용자에게 정확한 평균값을 결과로 제공한다.
값을 주고 받는다.
31. 공감세미나Approximate Aggregation과 돈이 만난다면
분산환경과 집계연산
Cardinality Aggregation ( = Distinct )
1. 코디네이터 노드가 Cardinality 집계 요청을 받는다.
2. 코디데이터 노드는 클러스터에 존재하는 모든 Shard로 Cardinality 집계 요청을 보낸다.
3. 각각의 Shard는 자신이 가지고 있는 데이터를 기준으로 중복을 제거하고 결과 데이터를
리스트로 작성한다.
4. 코디네이터 노드는 모든 Shard들의 결과를 받을때까지 기다린다.
5. 모든 Shard로 부터 리스트가 도착하면 결과를 하나로 합쳐서 다시 한번 중복을 제거한다.
6. 사용자에게 정확한 중복 제거된 결과를 제공한다.
데이터 리스트를
주고 받는다.
32. 공감세미나Approximate Aggregation과 돈이 만난다면
분산환경과 집계연산
특정 금액
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하여
전체를 대상으로 한번 더 중복 제거하여 리턴
33. 공감세미나Approximate Aggregation과 돈이 만난다면
HyperLogLog++
• 확률 기반의 자료구조
• 정확한 값이 아닌 근사치 값을 제공한다.
• 일부 데이터를 샘플링하여 결과를 확률적으로 예측한다.
• 버킷 사이즈가 크면 클수록 정확도가 올라간다.
34. 공감세미나Approximate Aggregation과 돈이 만난다면
Approximate Cardinality Aggregation
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-cardinality-aggregation.html
35. 공감세미나Approximate Aggregation과 돈이 만난다면
Approximate Cardinality Aggregation
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-cardinality-aggregation.html
36. 공감세미나Approximate Aggregation과 돈이 만난다면
UV, PV
• UV를 뽑기 위해서는 반드시 Cardinality 연산이 필요하다.
• 대충 비슷하게 나오면 되는거 아닌가?
• 만약 UV, PV를 이용하여 과금을 한다면?
72. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자
• elasticsearch.yml에서 설정한 내역들이 나의 의도대로 실질적으로 클러스터에 반
영되었는지 확인하는 과정이 반드시 필요하다.
• Elasticsearch에서는 물리적 설정과 논리적 설정을 모두 지원하기 때문에 우선 순
위에 따라서 나의 의도와는 다르게 동작할 수 있다.
• 해당 물리 노드에만 적용하길 원할 경우 물리적 설정을 한다.
(Node명, Node타입, 네트워크 설정)
• 일반적으로는 클라우드 전체에 동일하게 적용하기 때문에 논리적 설정을 한다.
78. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자
_cluster/settings?include_defaults=true [Cluster] 논리적 설정정보
79. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자
_cluster/settings?include_defaults=true [Cluster] 논리적 설정정보
80. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자
_cluster/settings?include_defaults=true [Cluster] 논리적 설정정보
81. 공감세미나환경설정 값들을 Runtime에 반드시 확인하자
_cluster/settings?include_defaults=true [Cluster] 논리적 설정정보
82. 공감세미나Runtime에는 환경설정을 신중하게 변경하자
indices.recovery.max_bytes_per_sec 항목의 설정을 변경해보자.
이 항목은 Index Recovery 상황에서
초당 복구될 사이즈를 설정하는 항목이다.
83. 공감세미나Runtime에는 환경설정을 신중하게 변경하자
./config/elasticsarch.yml 파일을 열어본다.
indices.recovery.max_bytes_per_sec : 40mb
초당 40MB의 속도로 Recovery를 수행하도록 물리적으로
설정되어 있다.
84. 공감세미나Runtime에는 환경설정을 신중하게 변경하자
클러스터가 실제 동작하고 있는
설정값을 확인해보자.
_cluster/settings?include_defaults=true
마찬가지로 초당 40MB의 속도로
Recovery를 수행하도록 설정되어 있다.
85. 공감세미나Runtime에는 환경설정을 신중하게 변경하자
PUT _cluster/settings
{
"transient" : {
"indices.recovery.max_bytes_per_sec" : "512mb"
}
}
Runtime 중에 복구속도를 빠르게 조정하기로 결정했다면
아래 API를 이용할 수 있다.
_cluster/settings
초당 512MB의 속도로 Recovery를 수행하도록 논리적으로 변경한다.
90. 공감세미나Master Node를 반드시 분리하자
Shard 수가 수백개라면 Config 정보는 어디에?
Master Node와 Data Node가 같은 JVM에서 동작할때 문제점은?
분산시스템에서 Data Node가 죽을 경우에 Master Node도 죽는다면?
골치 아픈 Split Brain 문제?
Master 전용 Node는 낮은 사양의 장비로도 충분하다.
안정적인 클러스터를 운영하려면 Master Node가 안정적이어야 한다.
91. 공감세미나장비는 64GB의 물리메모리를 가지는 장비가 좋다.
Elasticsearch를 VM장비로 운영한다면 그 많은 I/O는?
Lucene은 mmap()을 통한 System Call을 공격적으로 사용한다.
물리 장비당 하나의 인스턴스가 적합하다.
물리메모리의 반은 Elasticsearch에게 나머지 반은 Lucene에게 할당하자.
분산 클러스터 특성상 고사양 서버보다는 저사양 서버 다수로 구성하는 것이 좋다.
92. 공감세미나Elasticsearch 힙사이즈는 31GB가 좋다.
Java는 객체를 표현하기 위해 Ordinary Object Pointer (OOP)를 사용한다.
64bit 시스템이라도 힙메모리가 32GB 이하일 경우에는
Compressed OOP를 사용하여 32bit 포인터 사용이 가능하므로
성능향상에 큰 도움이 된다.
93. 공감세미나디스크는 가급적이면 SSD를 사용하자.
루씬이 디스크 기반이기 때문에 SSD 사용시 효율이 매우 좋아진다.
이제는 SSD 가격이 매우 저렴해졌다. ^^;;;
94. 공감세미나최대한 메모리 스와핑이 발생하지 않도록 하자.
Elasticsearch가 사용하지 않는 메모리가 OS에 의해 강제적으로 스와핑이 될 경우
성능에 치명적인 문제가 생길 가능성이 있다.
$ sudo sysctl -w vm.swappiness=1
95. 공감세미나가상메모리 mmap 카운트를 변경하자.
Lucene의 경우 내부적으로 mmap을 많이 활용한다.
기본으로 제공되는 mmap 카운트를 262,144로 늘려야 한다.
최신버전의 Elasticsearch에서는 mmap 카운트가 부족할 경우
실행시 부트스트랩 과정에서 강제적으로 오류를 발생시킨다.
$ sudo sysctl -w vm.max_map_count = 262144
96. 공감세미나생성 가능한 최대 파일 개수를 변경하자.
Lucene은 불변 방식으로 데이터의 정합성을 제공한다.
이 과정에서 무수히 많은 Segment가 생성될 수 있기 때문에
응용프로그램에서 생성 가능한 최대 파일 개수가 변경되어야 한다.
$ sudo sysctl -w fs.file-max=518144
97. 공감세미나연결 가능한 최대 Connection 개수를 변경한다.
Elasticsearch는 복구과정에서 대량의 데이터를 Tcp/Ip로 주고받는다.
좀더 빠른 네트워크 처리를 위해서
연결 가능한 최대 Connection 개수를 변경해야 한다.
$ sudo sysctl -w net.core.somaxconn=65535
98. 공감세미나대용량 클러스터를 위한 제안
결론
• Master Node를 반드시 분리하자.
• 장비는 64GB의 물리메모리를 가지는 장비가 좋다.
• Elasticsearch 힙사이즈는 31GB가 좋다.
• 디스크는 가급적이면 SSD를 사용하자.
• 최대한 메모리 스와핑이 발생하지 않도록 하자.
• 가상메모리 mmap 카운트를 변경하자.
• 생성 가능한 최대 파일 개수를 변경하자.
• 연결 가능한 최대 Connection 개수를 변경한다.
111. 공감세미나은탄환은 없다.
서버의 Spec, 데이터의 종류, 사이즈, 검색패턴 등에 따라 결과가 달라진다.
지금 최적화 했다고 해서 앞으로도 계속 최적화 상태를 유지하지 않는다.
시간이 지날수록, 데이터가 자랄수록 정답이 달라진다.
자신의 데이터를 이용하여 항상 밴치마크를 해야 한다.
클러스터의 성능을 최대한 끌어내려면?