[Elasticsearch] Operation

Shard 수 선택

• Write 요청은 Primary shard로 연결되고 복제된다. 따라서 주어진 시간에 쓰기 요청을 감당할 수 있게 충분한 Primary shard를 보유해야한다.
• Read 요청은 다시 Indexing하지 않고도 아무데서나 계속 Replica를 만들어 낼 수 있다.
• 새 Index를 생성할 때 몇 개의 Shard가 필요할지는 무엇으로 결정할까?
  • re-indexing 없이 primary shard를 추가할 수는 없다.
  • 하지만 Index를 복사해서 Primary shard를 추가하고 re-indexing하는 것은 가능하다.
  • Write/Read 트래픽을 위한 현재 요구사항을 생각해보고 단계적으로 확장하는 것이 좋다.

Index 추가 확장 전략

새로운 Index에 원하는 Primary와 Replicas 수를 지정하는 방법은 다음과 같다.

PUT /new_index
{
    "settings": {
        "number_of_shards": 10,
        "number_of_replicas": 1
    }
}

레플리카의 수는 각 프라이머리 샤드에 적용된다. 예를 들어 위와 같이 지정할 경우 프라이머리 샤드 하나에 레플리카 샤드 하나가 적용되기 때문에 10개의 프라이머리 샤드와 10개의 레플리카 샤드를 얻게 된다.
새로운 Index를 생성해야 하는 경우 index templates를 찾아보면 새로운 index에 mapping, analyzer, alias, settings 등을 자동으로 적용해줘 시간을 단축시켜준다.

Index alias rotation

Index 확장이 필요할 때, 기존의 Index에 shard를 추가하는 것만이 유일한 방법은 아니다. 완전히 새로운 Index를 생성하고 해당 Index에 검색 요청을 보내는 방법도 있다. 이 방법으로 기존의 Index는 건드리지 않고 새 Index를 Scaling 할 수 있다. 이 방법은 실제로 기존의 Index를 re-indexing하고 shard를 추가하는 방법보다 쉽다.

Index Lifecycle Management

Alias rotation 외에도 Elasticsearch7은 Index Lifecycle Management 기능을 추가했다. lifecycle의 각 단계에 lifecycle 정책을 지정하여 오래된 index를 어떻게 다룰지 제어할 수 있다. Index를 고정된 rotation 스케쥴에 따라 관리하는 것 대신 shard size 혹은 performance에 기반하는 것이다.
단계는 다음과 같이 나뉘어진다.

• Lifecycle
  • Hot
    • Index가 활발히 업데이트되고 쿼리되고 있음
  • Warm
    • Index가 쿼리되기는 하나 더는 업데이트되지 않아서 읽기만 하는 단계
  • Cold
    • Index가 더이상 업데이트 되지 않고 드물게 쿼리만되는 단계
    • 이 단계에서는 쿼리가 느려지기 때문에 하드웨어의 스펙을 낮춰 비용을 낮출 수 있다.
  • Delete
    • 더이상 해당 Index가 필요하지 않은 상태

다음과 같은 예시로 Lifecycle의 정책을 생성할 수 있다.

PUT _ilm/policy/datastream_policy
{
    "policy": {
        "phases": {
            "hot": {
                "actions": {
                    "rollover": {
                        "max_size": "50GB",
                        "max_age": "30d"
                    }
                }
            },
            "delete": {
                "min_age": "90d",
                "actions": {
                    "delete": {}
                }
            }
        }
    }
}

hot, delete에 대한 정책 생성에 대한 예시이다. Index의 크기가 50GB에 도달하거나 수명이 30일정도 되면 delete단계로 rollover되어 완전히 지워지기 전에 90일 정도 남아있게 설정된다. 이 정책을 실제 Index에 적용은 다음과 같이 할 수 있다.

PUT _template/datastream_template
{
    "index_patterns": ["datastream-*"],
    "settings": {
        "number_of_shards": 1,
        "number_of_replicas": 1,
        "index.lifecycle.name": "datastream_policy",
        "index.lifecycle.rollover_alias": "datastream"
    }
}

클러스터의 하드웨어 선택

• Elasticsearch에서는 RAM 최적화가 가장 주요하다. Elasticsearch에 의하면 64GB의 RAM을 가지는 것이 가장 좋은 조건이라고 한다. 32GB를 elasticsearch에 할당하고 나머지 32GB를 운영체제와 디스크 캐시에 할당해야 하기 때문이다.
  • elasticsearch 자체에 32GB 이상을 할당하지 않는 것이 좋다. 메모리에 긴 포인터를 다뤄야하기 때문에 효율이 떨어진다. 8GB 이하로는 효율이 완전히 떨어지기 때문에 사용하지 않는 것이 좋다.
• 디스크는 SSD처럼 빠를수록 좋다.
• CPU는 그렇게 중요하지 않다.
• NAS를 사용하지 말고 빠른 네트워크를 사용해야한다.
• 클라우드 서비스에서처럼 컴퓨터의 리소스를 선택해야한다면 중 혹은 대 정도를 고르는 것이 좋다. 너무 크면 속도가 느려지고, 너무 작으면 인덱스와 샤드 등을 충분히 설정할 수 없기 때문이다.

Heap size 조정

elasticsearch의 기본 힙 크기는 1GB이다. 만약 64GB RAM을 사용하는 머신에서 실행하면 Elasitcsearch는 단 1GB만 사용하고 나머지 63GB는 운영체제나 디스크 캐시를 위해서 사용하는 것이 default 설정이다. 이는 이상적인 설정은 아니다.
일반적으로 RAM의 절반 정도를 Elasticsearch 자체에 할당하고 나머지를 운영체제에 할당한다. 어떠한 집계도 하지 않는다고 한다면 머신의 RAM 절반보다 Elasticsearch에 덜 할당해도 좋다. 데이터를 캐시하는데 메모리는 많으면 좋기 때문에 더 좋은 성능을 보여줄 것이다.
힙 사이즈를 정하는데는 두 가지 방법이 있다.

• ES_HEAP_SIZE 환경변수를 사용한다.
  • export ES_HEAP_SIZE=10g
• ES_JAVA_OPTS를 사용한다.
  • ES_JAVA_OPTS="-Xms10g -Xmx10g" .bin/elasticsearch

Monitoring

모니터링은 X-Pack이라고 불리는 것의 일부다.

X-Pack

원래는 Elastic Stack의 extension으로 보안, 모니터링, 경고, 리포트, 그래프, 머신 러닝 등을 담당했다. 이를 사용하여 클러스터에 이상이 발생했는지를 확인할 수 있었고, 머신 러닝을 통해 예기치 못한 일이 발생할 경우 자동으로 경고를 띄우기도 했다. 이를 elastic에서 stack에 포함시켰고, 기본 모니터링이나 경고를 띄우는 작업처럼 간단한 작업은 무료로 사용 가능하지만 머신 러닝 등은 유료 라이센스가 필요하다.

사용

Kibana로 접속해서 Heartbeat에 들어가 모니터링을 추가하기만 간단하게 클러스터 상태를 모니터링할 수 있다.