[elastic search] 엘라스틱 서치 shard와 replica

이번 게시글에서는 엘라스틱서치 샤드와 레플리카에 대해 정리합니다.

1. 샤드란

elastic search는 인덱스에 데이터를 저장하며, 인덱스의 인스턴스를 샤드라고 합니다.
즉 인덱스에 데이터를 저장하면 데이터는 샤드에 기록되며 디스크에 저장됩니다.

샤드는 일반적으로 20~40gb 의 데이터가 저장되도록 하는게 좋습니다.
(ex index에 저장되는 데이터의 양이 60gb라면 샤드를 2개로 설정해주는게 좋습니다, 샤드에 데이터는 50gb를 넘기지 않아는게 좋습니다.)

인덱스를 정의할때 setting필드에 정의를 해주거나(setting이란 인덱스의 샤드, 레플리카의 매핑 등의 정보를 설정할때 사용되는 필드입니다.)

아래의 코드와 같이 템플릿을 만들어 놓으면 index가 생성(my- , your-로 시작되는)될때 자동으로 샤드갯수가 정해집니다.

PUT _template/2_shard
{
    "order" : 0,
    "index_patterns" : [
       "my-*",
       "your-*"
    ],
    "settings" : {
      "index" : {
        "number_of_shards" : "3",
        "number_of_replicas" : "2"
      }
    },
    "mappings" : { },
    "aliases" : { }
}

샤드가 3개인 경우 이런식으로 저장됩니다.

샤드의 갯수를 조절하지 않게되면 아래와 같은 문제를 야기합니다.

샤드의 갯수가 너무 적어 샤드당 너무 많은 데이터가 저장되게되면 노드당 데이터가 균등하지 않게 저장됩니다.
elastic search는 샤드를 배치할때 노드의 남은 디스크 사이즈를 확인하여 가장 남은 양이 많은 노드에 샤드를 배치합니다. 일시적으로 남은 용량이 많은 노드에 너무 큰 샤드들이 배치된다면 전체 클러스터의 용량은 넉넉하지만, 일부 노드의 디스크사이즈가 부족해져 적재에 장애를 유발 할 수 있습니다.
elastic search는 일부노드의 남은 용량이 부족하더라도 자동으로 재분배 해주지 않으니 클러스터의 total size보다는 가장 free size가 작은 노드를 모니터링 해줘야 합니다

그러나 너무 많은 샤드가 있으면 노드간 통신에 의해 컴퓨팅 리소스가 낭비되므로 적절히 조절해 줍니다.

 

2. 레플리카란

es는 분산저장소이므로 여러개의 노드(서버)를 사용하는 경우가 많습니다.
마스터노드(여러 노드와 통신하여 어떤 노드가 어떤일을 할지만 지정하는 노드이며 지정하지 않으면 상황에 맞게 돌아가면서 마스터 노드 역할을 수행)는 따로 지정하지 않은 기준으로 작성하겠습니다.

레플리카란 데이터의 복제본입니다.
레플리카는 하나의 노드에 장애가 발생하더라도 데이터를 보존하자는 용도로 주로 사용됩니다.
샤드 3개, 레플리카 2개로 데이터를 저장하면 이런식으로 저장됩니다(푸른색 primary, 붉은색 replica) 
원본은 primary, 복제본은 replica라고 칭하며 아래와 같이 저장됩니다.
아래와 같이 저장되므로 어떤 노드에서 장애가 발생하던지간에 데이터를 복구할수 있게 됩니다.
대신 컴퓨팅 리소스를 많이 사용하게 되므로 특히 disk 공간이 넉넉한지를 잘 확인하고 사용해야 됩니다.

레플리카를 늘리면 저장성능은 떨어지지만, 읽기 성능이 좋아지고,
레플리카를 줄이면 저장성능은 좋아지지만 읽기 성능이 줄어든다는 특징이 있습니다.