[ElasticSearch] 데이터 처리, 검색 성능 최적화

데이터 처리에 대한 지식들

배치 크기 ( Batch Size )

배치 크기는 한 번에 처리할 데이터 묶음 크기
비유하자면, 주방장(프로세서)이 한 번에 요리할 수 있는 음식(데이터) 양이다.
만약 Logstash 가 데이터를 수집하여 Elasticsearch 에 보내는 작업에서 배치 크기가 100 으로 설정하면, 데이터를 100개씩 묶어 한 번에 처리한다.
작은 배치 : 주문이 들어올 때마다 바로 요리를 시작. 빠르게 대응할 수 있지만 효율성이 떨어질 수 있다.
큰 배치 : 여러 주문을 모아서 한 번에 요리한다. 효율적이지만 첫 음식이 나오기까지 시간이 걸린다.

 

힙 사이즈 (Heap Size)

힙 사이즈는 사용할 수 있는 최대 메모리 크기
프로그램이 사용할 수 있는 창고 공간이다.
작은 힙 : 작은 창고. 공간이 부족해 자주 정리해야 하지만, 관리는 쉽다.
큰 힙 : 큰 창고. 많은 물건을 보관할 수 있지만, 정리하는 데 시간이 더 걸릴 수 있습니다.
JVM 에서 조절하면 프로그램이 사용할 수 있는 메모리 양을 제어할 수 있다. 너무 작으면 OutofMemoryError 가 발생할 수 있고, 너무 크면 가비지 컬렉션에 시간이 많이 걸릴 수 있다.

 

가비지 컬렉션 (Garbage Collection, GC)

JVM 에서 사용하지 않는 메모리를 자동으로 정리.
메모리를 효율적으로 관리해주지만, 동작할 떄 잠시 프로그램의 실행이 멈 출 수 있음.

 

처리량과 지연시간 (Throughput / Latency)

Throughput : 프로그램이 단위 시간당 처리할 수 있는 데이터의 양.
                      배치 크기를 늘리면 처리량이 늘어지만, 메모리를 많이 소모
Latency : 특정 작업이 완료되는 데 걸리는 시간
                배치 크기가 너무 크면 지연시간이 길어짐.

 

스레드 풀 ( Thread Pool )

많은 데이터를 처리할 때 여러 작업을 동시에 실행하기 위해 사용된다.
일정 수의 스레드를 미리 생성해놓고 필요할 때 가져다 쓴다.
병렬 처리와 관련되어, 힙 메모리를 효율적으로 사용하려면 스레드 수와 메모리 사용량 간의 균형을 맞추는 것이 중요하다.

 

I/O Bound  vs  CPU Bound (입출력 대기  vs  CPU 사용 대기)

I/O Bound : 입출력 작업에 시간이 많이 소요되는 경우
CPU Bound : CPU 연산에 시간이 많이 소요되는 경우
데이터 수집이 I/O Bound 인 경우 배치 크기를 조정하여 대기 시간을 줄이는 것이 유리할 수 있음.

 

 

검색 성능 최적화

노드당 primary shard 개수가 5개일 때 검색 성능이 가장 빠르다

샤드 수와 노드 간의 자원분배가 최적화되기 때문이다.
각 샤드에서 데이터의 일부만 검색하게 되어 병목 현상이 줄어들고, cpu 와 메모리 자원이 효율적으로 사용되며, 응답 시간이 감소한다.

인덱싱 시 primary shard 개수가 많을수록 소요시간이 늘어남

각 문서를 샤드로 분산하는데 걸리는 시간이 늘어난다. 
데이터 분산이 과도해져 관리 오버헤드가 증가한다.
각 문서가 어느 샤드에 저자오딜지를 결정하고, 각각의 샤드에 대해 인덱싱 작업을 따로 수행해야 하기 때문이다.

 

인덱싱 Resource

primary shard 가 많아질수록 인덱싱할 때 CPU 사용률과 평균 kB_wrtn/s 가 낮아지는 경향을 보인다.