ElasticSearch - “Hot-Warm” Architecture in Elasticsearch 5.x

원문 - https://www.elastic.co/blog/hot-warm-architecture-in-elasticsearch-5-x

Master Nodes

• 안정적으로 운영하기 위해서 3개의 dedicated master nodes를 권장함
• 따라서 split-brain이 발생하지 않으려면 discovery.zen.minimum_master_nodes를 2로 세팅해야함
• dedicated master node는 데이터를 가지고 있지도 않고 색인과 검색에 참여하지 않으므로 JVM GC에 의한 PAUSE가 훨씬 적다.
• CPU, RAM, DISK 설정을 데이터 노드에 비해서 적게 설정할 수 있다.

Hot Nodes

• 클러스터에서 데이터 인덱싱을 수행하는 특별한 노드이다.
• time-based indices에서 가장 최근에 인덱싱된 데이터들이 쿼리되는 경향이 있다.
• 인덱싱은 CPU와 I/O 집중적인 작업이고, 이러한 노드를 가진 서버들은 좀 더 강력한 CPU를 요구하고 SSD 같은 저장 장치를 필요로 한다.
• 고가용성을 위해서 최소 3개의 Hot Nodes가 권장된다.
• 수집 및 쿼리 성능은 데이터의 양에 의존하므로, 더 나은 성능을 위해서는 더 많은 서버를 필요로 한다.

Warm Nodes

• 자주 쿼리 되지 않는 대량의 읽기 전용의 인덱스를 처리하기 위해서 설계된 타입의 노드이다.
• 이러한 인덱스들은 읽기 전용이므로, SSD대신에 (대개 spinning disk) 큰 디스크를 활용할 수 있다.
• hot nodes와 같이 고가용성을 위해서 3개의 노드를 권장한다. 그리고 앞에서와 같이, 더 큰 양의 데이터를 위해서 성능을 만족하기 위해서 추가적인 노드가 요구된다.
• CPU와 메모리 설정은 hot nodes와 동일하게 맞추준다. 이러한 설정값들은 운영 환경에서와 유사한 쿼리를 테스팅하면서 결정된다.
• Elasticsearch 클러스터는 어떤 서버가 hot nodes를 포함하는지, warm nodes를 포함하는지 알 필요가 있다. 이것은 각 노드에 속성을 부여하여 구분할 수 있다.

설정 및 명령 실행

• hot, warm이라는 용어는 임의적이다. 태깅은 임의로 규칙을 정하면 된다.

• hot 이라는 tag를 가진 노드의 디스크는 SSD로 하고, warm이라는 tag를 가진 노드의 디스크는 spinning disk(일반 HDD)로 태깅한다.

• 특정 인덱스 생성시 (index template에서 지정가능) hot으로 태깅하고, 일정 시간이 지나면 태깅을 warm으로 변경하여 HDD를 사용하고 있는 노드로 데이터를 옮겨가는 방식이다.

• 노드 설정

  • 실행시

    ./bin/elasticsearch -Enode.attr.box_type=hot ./bin/elasticsearch -Enode.attr.box_type=warm

  • elasticsearch.yml에서도 설정 가능하다.

    node.attr.box_type: hot node.attr.box_type: warm

• indices type 태깅

  • "hot" type 태깅

    `PUT /indices-20181025/_settings { "settings": { "index.routing.allocation.require.box_type": "hot" } }`

  • 며칠이 지난 인덱스는 "warm" 으로 태깅을 변경한다.

    `PUT /indices-20181018/_settings { "settings": { "index.routing.allocation.require.box_type": "warm" } }`

  • 현재 box_type 확인 - box_type이 hot인것을 확인할 수 있다.

    curl -s -XGET 'localhost:9200/connectome-20200401/_settings' | jq
    {
      "indices-20200401": {
        "settings": {
          "index": {
            "routing": {
              "allocation": {
                "require": {
                  "box_type": "hot"
                }
              }
            },
            "number_of_shards": "5",
            "provided_name": "indices-20200401",
            "max_result_window": "100000",
            "creation_date": "1585666814539",
            "analysis": {
              "analyzer": {
                "comma": {
                  "type": "custom",
                  "tokenizer": "comma"
                }
              },
              "tokenizer": {
                "comma": {
                  "pattern": ",",
                  "type": "pattern"
                }
              }
            },
            "number_of_replicas": "1",
            "uuid": "ZdCmkwJLRYONlhVvntc0xw",
            "version": {
              "created": "5061699"
            }
          }
        }
      }
    }

테스트

• hot node로 2개를 실행하고, warm node로 2개를 실행하였다.

• hot node는 data path로 /data로 설정하고, warm node는 /data2로 설정하였다.

• 다음 템플릿으로 신규로 생성된는 인덱스 패턴(indices-*)은 hot type을 부여 받고 box_type이 hot인 노드의 데이터 디렉터리에 저장된다.

  { "template": "indices-*", "settings": { "index.routing.allocation.require.box_type": "hot" } }

• 2018년 10월 29일자 신규 인덱스의 경우 최초 생성시에는 /data 아래에 인덱스가 생성되는것이 확인되었고, 아래의 명령으로 인덱스의 type을 warm으로 변경 가능하다.

  PUT /indices-20181029/_settings { "settings": { "index.routing.allocation.require.box_type": "warm" } }

• 명령 수행 후 어느정도 시간이 지난 후 확인해 보면 /data에 존재했던 indices-20181029 인덱스의 샤드는 모두 /data2로 이동된것을 확인할 수 있다.

  • elasticsearch 5.X에서는 인덱스 이름을 실제 이름이 아닌 UUID로 관리한다. (indices-20181029 Kksen_nHSZ2Lgj_g-q5jzg).

    curl -s -XGET 'localhost:9200/_cat/indices?v&h=health,status,index,uuid,pri,rep,docs.count,docs.deleted,store.size,pri.store.size,tm' | awk 'NR == 1; NR > 1 {print $0 | "sort -k 2"}' 
    health status index uuid pri rep docs.count docs.deleted store.size pri.store.size tm green open batch 2XUz-Pw0S9u038DImRdHgw 5 1 2 0 95.2kb 47.6kb 39.6kb 
    green open indices-20181028 jhNOlD66R0ql0Gd7nZ5Isw 5 1 1 0 37kb 18.5kb 23.8kb 
    green open indices-20181029 Kksen_nHSZ2Lgj_g-q5jzg 5 1 75471 0 57.2mb 28.6mb 777.9kb 
    green open indices-20181030 amdyw69-RQ-TfLQ4rPidkw 5 1 877755 0 812.8mb 407.9mb 43.2mb

  • 인덱스 디렉터리는 남아 있지만 데이터는 모두 /data2로 이동한 상태이다.

    /data/nodes/1/indices/Kksen_nHSZ2Lgj_g-q5jzg$ ls -al 
    total 12 drwxrwxr-x 3 conse conse 4096 Oct 30 09:17 . 
    drwxrwxr-x 7 conse conse 4096 Oct 30 09:10 .. 
    drwxrwxr-x 2 conse conse 4096 Oct 30 09:17 _state 
    /data/nodes/1/indices/Kksen_nHSZ2Lgj_g-q5jzg$

Rollover Pattern

• time-based index 운영는 이해하기 쉽고, 운영하기 쉽다는 장점이 있다.
• 그러나 가장 문제가 되는것은 같은 날짜의 데이터가 여러개의 노드(서버)에 분산되어 있다는 것이다.
• old data를 삭제하기에는 쉬운 구조이지만, 검색에 있어서만은 많은 서버에서 수행하는것 보다 최소한의 샤드를 대상으로 하는 것이 효율적이다.
• Rollover Pattern은 다음과 같이 동작한다.
  1. 하나의 alias는 현재 인덱싱에 사용되고 active index를 가리킨다.
  2. 또 다른 alias는 active, inactive index를 가리키고 검색에 사용된다.
  3. active index는 hot-node의 수만큼이나 많은 샤드를 가지고 있고, 고비용의 하드웨어 자원을 인덱싱하는데 이용한다.
  4. active index가 꽉차고 너무 오래 되면, roll over된다. 새로운 인덱스가 생성되고 자동적으로 alias는 새로운 인덱스로 전환된다.
  5. old index는 cold node로 이동되고 하나의 샤드로 축소(shrink)된다. 샤드는 force-merge되거나 압축될 수 있다.

Shrink API

• time-based index에서 과거 데이터는 잘 사용하지 않는데 많은 샤드를 차지하고 있어야 하므로, shink api를 이용하여 샤드의 수를 축소할 수 있다.