티스토리 뷰

반응형

EasticSearch에 가장 기본이 된다고 생각하는 3가지에 대해서 한번 정리해보려고 합니다.

본 포스팅은 7.x 버전 이후의 EasticSearch를 기준으로 하고 있습니다.

읽기 쉽게 지금부터는 한글로 일라스틱 서치로 작성하겠습니다.

 

0. 정리

 

3가지 요소를 간단히 이야기하자면 아래와 같습니다.

 

Index ( 인덱스 ) : Table

Shard ( 샤드 ) : 분산 저장소

Replica ( 복제본 ) : Shard의 복제본

 

1. 개념 정리

 

1-1 Index 란?

 

인덱스(Index)는 테이블 입니다.

 

6.X 이하 버전에서 인덱스는 데이터베이스로 타입(Type)은 테이블로 설명되었습니다.

하지만 타입을 관리하는 구조에 문제가 있어 7.X 이상부터 인덱스당 타입을 1개로 고정시켰습니다.

또한 이후 버전에서는 Type의 개념을 삭제할 예정으로 이제 Type이란 개념이 없어진 상태입니다.

 

7.X 버전 이후부터는 인덱스를 테이블 개념으로 생각해야 합니다.

인덱스가 테이블 개념이지만 RDB의 테이블과 성격이 다릅니다.

예를 들면 RDB에서 하위 정보를 다른 테이블로 관리하고 데이터를 읽을 때 Join을 사용했다면

일라스틱 서치는 도큐먼트(Document) 개념을 사용하여 모든 데이터를 하나의 도큐먼트에서 사용합니다.

이러한 점은 NOSQL과 유사합니다. 그렇기 때문에 NOSQL을 사용했던 분들이라면 쉽게 이해할 수 있습니다.

 

※ 도큐먼트 샘플


{
    "상품" : "사과",
    "가격" : "10000",
    # 하위 개념을 하나의 doc로 관리합니다.
    "배송업체" : {
      "업체이름" : "빠르게배달",
      "전화번호" : "010-0000-0000"
    }
}

 

1-2 Shard 란?

 

샤드(Shard)는 인덱스의 도큐먼트를 분산 저장하는 저장소입니다.

인덱스는 도큐먼트를 모아 높은 집합인데 샤드에 개수에 따라 도큐먼트를 분산 저장합니다.

인덱스에 샤드를 설정하면 설정한 개수만큼 노드에 분산하여 저장소를 만듭니다.

이때 도큐먼트는 생성된 샤드에 순차적으로 저장하게 됩니다.

 

만약, 노드 1개에 샤드의 개수를 2로 설정하고 6개의 도큐먼트를 저장하게 되면 아래와 같이 저장됩니다.

 

샤드 기본 설정은 7 버전 이상부터 디폴트가 1로 변경되었고 6 버전 이하는 디폴트가 5입니다.

샤드 개수는 데이터의 크기가 작다면 디폴트로 유지하는 것이 좋고

데이터 크기가 크다면 목표한 응답 속도 부합하게 증가시키는 것이 좋습니다.

주의해야 할 점은 샤드의 개수는 인덱스를 생성할 때만 설정할 수 있습니다.

 

만약, 인덱스 생성 후 샤드를 변경하려면 리인덱스를 수행해야 합니다.

샤드는 데이터를 분산 저장하는 역할도 있지만 분산하여 검색도 합니다.

샤드의 개수가 증가될수록 쿼리의 속도가 증가됩니다.

데이터가 분산되어 있는 만큼 각각의 샤드에서 검색하여 결과를 리턴해 주기 때문입니다.

 

하지만, 무조건 샤드가 많다고 좋은 것은 아닙니다.

작은 데이터를 가진 인덱스는 하나의 샤드를 유지하는 것이 검색 속도가 빠를 수 있습니다.

샤드의 개수가 2개로 설정된 인덱스의 응답속도와 샤드의 개수가 1개로 설정된 인덱스의 응답속도가 동일하거나 거의 비슷하다면 1개로 유지하는 것이 좋습니다.

 

쿼리를 수행하면 샤드의 개수만큼 CPU의 스레드를 사용하기 때문에 샤드의 개수가 많아질수록 비례하여 자원을 사용하기 때문입니다.

 

대략적으로 20G의 데이터를 검색하는데 100ms 이하의 응답속도를 준다는 결과가 있었습니다.

이점 참고해서 샤드의 개수를 정해진 응답속도에 맞춰 늘리면 좋을 것 같습니다.

 

성능 측정 참조 블로그

 

클러스터 설계하기 - #1 검색 성능과 샤드 개수

ElasticSearch | 이번 글에서는 ElasticSearch (이하 ES)의 클러스터를 설계하기 위해 필요한 요소들 중 샤드의 개수가 검색 성능에 미치는 영향을 바탕으로 적정한 샤드의 개수와 데이터 노드의 개수를 산정하는 방법에 대해 이야기해 보려고 합니다. ES는 대부분의 경우 기본 설정 만으로도 충분한 성능을 보여 주지만 서비스에 투입하기 위한 검색 엔진으로 사용하거나 대용

brunch.co.kr

 

1-3 Replica 란?

 

복제본(Replica)은 프라이머리 샤드(Shard)를 복제하여 다른 노드(Node)에 저장하는 개념입니다.

프라이머리 샤드(Shard)의 복제본으로 프라이머리 샤드의 개수만큼 생성되게 됩니다.

샤드와 마찬가지로 복제본은 인덱스 생성 시 개수를 설정할 수 있습니다.

 

만약, 샤드 2개, 복제본 1개로 설정하여 인덱스를 생성하면 {샤드 개수} X {복제본 개수} 만큼 생성되어 총 2개의 복제본이 생성됩니다.

 

조금 더 자세한 예를 들어보겠습니다.

노드 3개, 샤드 3개, 복제본 2개를 예를 들어 보겠습니다.

샤드의 개수가 3개로 설정되어 있기 때문에 3개의 노드에 각각 분산되어 생성됩니다.

 

복제본의 개수는 2개로 프리미어 샤드가 없는 노드에 각각 1개씩 총 2개가 생성됩니다.

샤드와 복제본은 각각 다른 노드에 분산되어 생성되어 저장됩니다.

 

 

분산되는 이유는 노드 한 개가 시스템 다운 또는 네트워크 단절 등으로 사라지게 되면

다른 노드의 복제본이 프리미어 샤드가 되어 문제없이 서비스가 중단이 되지 않도록 합니다.

하지만 샤드와 복제본이 많을수록 좋은 것은 아닙니다.

 

샤드에 데이터가 저장될 때 모든 복제본에 같이 저장하게 됩니다.

복제본이 2개가 생성된다면 프리미어 샤드가 1개일 때보다 2배의 쓰기가 발생한다는 의미입니다.

복제본이 많아지면 I/O 자원이 많이 쓰이게 되고 서버의 속도가 느려질 수 있습니다.

그래서 복제본의 개수는 데이터의 용도와 운영 방식에 따라 설정할 필요가 있습니다.

 

2. 설정 방법

인덱스를 생성하기 전 샤드의 개수와 인덱스 개수를 설정할 수 있습니다.

샤드 개수는 생성 이후 변경이 불가능하고 복제본 개수는 변경이 가능합니다.

때문에 샤드 개수는 초반에 데이터의 성격에 맞게 설정하는 것이 중요합니다.

 

하지만 샤드 개수를 잘못 설정할 것 같다는 걱정을 하지 않으셔도 됩니다.

샤드 개수의 변경이 필요하면 리인덱스(Reindex) 작업으로 변경이 가능합니다.

리인덱스 작업이란 인덱스를 다른 인덱스로 변경하는 작업으로 복사라고 생각하면 됩니다.

 

※ < Shard & Replica 설정 법 >


PUT test_fruit_shop
{
  "settings": {
    "number_of_shards": 2,
    "number_of_replicas": 1
  }
}
 
 
# 생성된 설정 확인
GET test_fruit_shop
 
 
# Replica 설정 변경
PUT test_fruit_shop/_settings
{
    "number_of_replicas": 2
}

설정 방법은 간단하죠?

설정 이후 프라이머리 샤드와 복제본이 어떻게 생성되었는지 API 호출하여 확인이 가능합니다.

 


GET _cat/shards/{index}?pretty&v
 
 
# 샤드 2개, 복제본 2개로 설정한 샤드의 모습.
index           shard prirep state   docs store ip             node
test_fruit_shop 1     p      STARTED    0  283b 192.121.225.1 node01
test_fruit_shop 1     r      STARTED    0  283b 192.121.225.1 node03
test_fruit_shop 1     r      STARTED    0  283b 192.121.225.1 node02
test_fruit_shop 0     r      STARTED    0  283b 192.121.225.1 node01
test_fruit_shop 0     r      STARTED    0  283b 192.121.225.1 node03
test_fruit_shop 0     p      STARTED    0  283b 192.121.225.1 node02

생성된 샤드를 확인해 보면 두 개의 노드에 프라이머리 샤드 2개가 생성되었고 프라이머리 샤드가 없는 노드에 복제본이 각각 2개 생성된 것을 확인할 수 있습니다.

 

복제본은 생성 이후에도 변경이 가능하다고 했으니 복제본을 변경 후에 shard가 어떻게 변경되는지 볼까요.

 


PUT test_fruit_shop/_settings
{
    "number_of_replicas": 1
}
 
 
GET _cat/shards/test_fruit_shop?pretty&v
 
 
  
index           shard prirep state   docs store ip             node
test_fruit_shop 1     p      STARTED    0  283b 192.121.225.1 node01
test_fruit_shop 1     r      STARTED    0  283b 192.121.225.1 node02
test_fruit_shop 0     r      STARTED    0  283b 192.121.225.1 node03
test_fruit_shop 0     p      STARTED    0  283b 192.121.225.1 node02

복제본이 1개가 되면서 기존에 각각의 서버에 있던 복제본이 한 개씩 줄어든 것을 확인할 수 있습니다.

 

이번 포스팅에서는 간단하게 인덱스, 샤드, 복제본에 대해 정리했습니다.

그리고 간단하게 설정하는 방법도 정리하였습니다.

 

다음에는 elasticSearch node에 대해 정리해보겠습니다.

반응형
댓글