Elastic Search : Complete Guide to ElasticSearch - 클러스터링과 샤딩

[샤딩]

• 인덱스를 여러 개로 나눔. 인덱스 수준(RDB의 테이블 수준)에서 이뤄짐. 
• 수평적 확장을 위해서 사용. 
• ex) 하나의 인덱스가 600기가 / 하나의 노드 최대 용량이 500이면 어느 노드에도 담을 수 없음
• 이 때 샤드로 나눔. 샤드는 어떤 노드에도 배치할 수 있다. 다섯 개의 샤드가 있다고 해서 다섯 개의 개별 노드에 배치해야 하는 것은 아님. 
• 각 샤드는 하나의 루씬 인덱스다. 즉, 5개의 샤드를 가진 일라스틱 서치 인덱스 한 개는 실제로 다섯 개의 루씬 인덱스로 이루어졌다. 
• 샤딩의 장점 : 하나의 인덱스에 더 많은 문서를 담을 수 있으면서 노드에 더 적합하게 담길 수 있다. 
• 7.0 전까지는 5개의 샤딩이 기본. -> 오버 샤딩이 문제가 되어서 + 인덱스 생성 이후에는 샤딩의 수를 바꿀 수 없어서 새 인덱스를 생성하고 데이터를 옮기는 수고로움이 필요했다. 
• 이제는 1개의 샤딩이 기본이다.
  • Split API로 샤딩을 추가할 수 있음 (새 인덱스 생성은 동일하지만 일라스틱 서치가 이걸 좀 간결화해줌)
  • Shrink Api로 샤딩을 줄일 수 있음. 

 

* elastic search 내에서 볼 수 있는 용어 Pri : primary shards

 

[샤드 수를 정해야 할 때 고려해야 할 지점]

• 클러스터 내 노드, 노드마다의 capacity, 사이즈, 쿼리의 수 등에 따라 다름
• 하나의 인덱스에 수십만 도큐먼트가 추가된다면 5개로 일단 시작해봐라. 아니면 1개로 시작해도 충분할 것이다.

 

[복제 (replication)]

• 하드웨어의 다운타임이 발생하면 데이터는 유실된다. 
  • 샤드의 레플리카를 생성함으로써 이를 해결한다. 
• Primary + replica  =  replication group
• 레플리카는 프라이머리랑 같은 노드에 저장되지 않는다. 하나의 노드만 동작하는 경우에는 레플리카가 의미가 없다. (할당 X)
• 보통 하나, 두개의 레플리카면 단일 장애 포인트는 피했겠지만, 두개 이상의 노드가 죽은 경우에는 여전히 데이터가 유실될 수 있다. 
• 따라서 중요한 시스템인 경우 두 개 이상의 레플리카를 두는 것이 좋다.
• 레플리카를 여럿 둠으로써 쿼리 처리량을 늘릴 수 있음. (레플리카를 통한 병렬 처리가 가능하기 때문. 노드가 두개 뿐이더라도 두개의 레플리카를 두면 총 세 개가 존재 -> 세 개의 쿼리를 동시에 처리할 수 있음. ∵ CPU에는 여러 코어가 있으므로)

 

[스냅샷]

• 백업용으로 제공하고 있음. 
• 전체 클러스터나 지정된 인덱스들을 선택할 수 있음. 
• 레플리카는 라이브 데이터를 위한 백업, 쿼리가 잘못되면 스냅샷으로 롤백. 
• 데이터에 변화를 적용하기 전에 롤백용 스냅샷을 찍어두는 경우가 많음. 

 

index의 샤드가 여러 개로 지정되었지만 노드가 하나라서 레플리카 샤드가 할당되지 않은 상황이라면 인덱스의 health = yellow 일 수 있다. -> 각 샤드에 대한 정보를 알 수 있는 명령어 GET /_cat/shards?v

 

 

[노드의 역할 분리]

1. 클러스터의 마스터 노드

• Voting system을 통해 마스터가 선발됨
• 마스터 노드가 CPU, memory, IO에서 높은 사용률을 보인다면(보통 서치 쿼리는 많은 동작을 요구하므로) 다른 마스터 노드를 추가하는 편이 좋을 수 있다.

2. 데이터 역할

• 데이터를 저장하는 역할
• 작은 클러스터에 대해서 이 역할은 항상 활성화되어 있다. (활성화되어 있지 않다면 노드는 어떤 샤드도 저장하지 않는다)
• 서치 쿼리나 데이터 변경과 같은 역할을 수행한다.

3. ingest 역할

• 노드가 ingest pipeline을 실행하도록 한다. 
• Ingest pipeline : 문서를 인덱싱할 때 수행하는 몇 가지 단계들을 의미 / Ingest : 도큐먼트를 인덱스에 추가하는 것
• 단순화된 Logstash pipeline으로 생각해도 된다. (전처리 작업을 많이 할 수 있지만 완전한 기능 전체를 사용하려면 LogStash를 사용해야 한다)
• 각 노드에서 ingest pipeline을 켜거나 끄도록 설정할 수 있다. > 데이터양이 많다면 하나의 노드에서 Ingest pipeline만 처리하도록 설정할 수도 있다. 

4. 머신 러닝

• 설정을 통해서 머신러닝만을 돌리는 노드를 둘 수도 있음. 

5. Coordination

• 요청을 라우팅 및 분배 하는 노드 (로드 밸런서 역할)
• 보통 큰 클러스터에서 coordination-only 코드들을 사용함. 
• 한 노드에서 모든 다른 역할들을 비활성화하는 방법으로 역할을 활성화할 수 있음. 

6. Voting-only

• 거의 사용할 일이 없음. 
• 새로운 마스터 노드를 선택할 때 투표권이 있는 노드지만, 직접 마스터가 될 수는 없음.
• 엄청 큰 클러스터에서 주로 사용

* elastic search 내에서 볼 수 있는 용어 dim : data, ingest, master
GET /_cat/nodes?v  >> node.role 에서 확인할 수 있다.

 

[언제 노드의 역할을 바꿔야 하는가]

• 큰 클러스터인 경우에만 보통 변경이 발생한다. 
• 요청의 수에 따라서 클러스터를 최적화할 때 필요할 수 있다.
• 노드나 샤드의 수 등등이 변화할 때 바뀔 수 있다. 
• 하드웨어 리소스 사용에 대해서 좀 더 잘 이해하기 위해서 변경할 수도 있다.