Elasticsearch 톺아보기

0. 목적

Elasticsearch에 대해

1. Elasticsearch는 뭘까?

결국 인터렉티브 로그 분석, 실시간 애플리케이션 모니터링 및 웹사이트 검색 등 어떠한 데이터를 수집하고 분석하며 필요에 따라 검색할 수 있도록 해주는 것이 가장 핵심적인 기능이다.

 

거대하고 두꺼운 책 속에서 내가 원하는 정보를 찾는 게 빠른가, 완벽히 ㄱ,ㄴ,ㄷ 자음 순으로 구분된 책 속에 서 내가 원하는 정보를 찾는 게 빠른가에 대해 생각해보자.

당연히 후자의 경우가 더 빠르게 내가 원하는 정보를 찾을 수 있다. 여기에 용어를 대입해보자면

내가(user) 책(Shard)에서 정보(data)를 더 빨리 찾기(search) 위해서는 정보를 찾기 전 목차를(index) 알 수 있다면 원하는 페이지에서 정보를 빠르게 조회하는 것이 가능하다.
거기에 맨 뒤에 키워드로 찾아볼 수 있도록 정리가(Inverted index) 되어있다면 아마 정보를 찾는데 더 큰 도움이 되지 않을까?

2.Node, Shard, index의 개념

데이터 노드의 개수와 샤드의 개수에 대한 이해가 필요하다. 이는 실제 운영에 있어 최적화 즉 비용과 성능에 관련된 이슈이기도 하다.

Node는 크게 Data node와 master node로 구분된다.

데이터와 관련된 CRUD 작업과 관련 있는 노드를 data node로 이해하면 된다.
클러스터에 포함된 단일 서버로서 데이터를 저장하고 클러스터의 색인화 및 검색 기능에 참여한다.

이외 인덱스 생성, 삭제 및 클러스터 노드들의 관리, 샤드 할당 등 전반적인 클러스터 제어를 위한 노드가 Master node이다.
당연하게도 data node는 실질적으로 작업이 이뤄지는 노드이기에 computing 자원을 소모하므로 모니터링이 필요하며,
원활한 관리를 위해 master 노드와 분리하는 것이 좋다.

AWS에서는 이러한 마스터 노드들을 각 가용 영역에 배포하여 Down-time을 최소화하는 로직을 강제적으로 시행한다.

Shard는 크게 primary와 Replica로 나뉜다.

기본적인 이론은 그렇다.
primary shard는 원본 데이터를 저장하고 색인한다. 이후 replica shard는 primary shard의 데이터를 복제하여 보유한다.
replica shard는 원본 데이터를 저장하지 않기에 색인 작업에는 참여하지 않지만, 검색에는 참여한다.
또한 primary shard가 비정상적인 상태일 때, Failover 되어 primary shard로 승격된 뒤, 역할을 수행한다.

index는 도큐먼트의 집합체이다.

단일 데이터 단위를 도큐먼트(document)라고 하며 이 도큐먼트를 모아놓은 집합을 인덱스(Index)라고 한다.

3. 인덱싱 성능 개선을 위한 포인트

0. 모든 성능의 이슈는 샤드에서 발생할 가능성이 가장 높다 (그다음이 데이터 노드의 스펙)
1. 수집하려는 인덱스의 데이터 노드에 샤드가 고르게 분포되어 있는지 확인해야 한다.
   만약 인덱스의 사이즈가 크지 않다면 굳이 샤드를 나눌 필요는 없다. 샤드를 나눈다는 건 데이터를 과하게 나눠 여러 노드에 분산 저장해놓았다는 뜻이고, 이로 이한 노드 간 쿼리 및 request에 대한 네트워크 오버헤드를 초래하여 오히려 부하를 일으키게 되어 성능이 떨어질 수 있기 때문이다.
2. 반대로 인덱스의 사이즈가 어마 무시하게 큰 경우 샤드로 나눠 여러 데이터 노드에 분배하여 분포하는 것이 효율적이다. 정말 특이한 사례를 제외하고는 보통 노드의 개수보다 샤드의 개수가 더 적은 경우는 없다. 결과적으로 위 상황에서 색인 성능과 검색 성능을 향상하기 위해서는 primary 샤드를, 검색 성능만을 향상하기 원한다면 replica 샤드를 추가해주면 놀아나는 노드 없이 성능 향상을 기대할 수 있다.
3. primary에서 replica로 데이터가 복제되는 것도 워크로드이기에 index.number_of_replicas을 "0"으로 줄 경우 클러스터 자체의 성능은 향상된다. 다만 replica가 없는 상태에서 노드에 이상이 생기면 데이터가 손실될 수 있다는 점을 유의해야 한다.

4. 4. 마지막으로 오버 프로비저닝 후 Scale-in 작업 간 유의사항

   ES 구성 최적화를 위해 데이터 노드 scale in을 준비한다면 우선 현재 클러스터 내 노드의 리소스 사용량을 모니터링해야 한다.
   평시와 피크타임을 모두 모니터링하여 리소스 사용량을 분석하고 작업을 계획해야 한다.
   또한, 현재 각 노드 별 storage의 사용량을 체크해야 한다. 기존 1TB의 스토리지로 구성된 3개의 데이터 노드에 각 500GB가량의 데이터가 저장되어 있을 경우 노드가 2개로 줄어든다면, 운용 가능한 클러스터 데이터 크기는 2TB 된다는 점을 유의하자.