Elastic Search

Ch12. 안정적인 클러스터 운영 노하우 - 안정적인 클러스터 운영을 위한 주요 체크포인트

webmaster 2025. 10. 21. 10:24
728x90

클러스터 상태 측정

GET _cluster/health
  • cluster health API를 이용하면, 클러스터의 상태를 실시간으로 확인할 수 있다.
    • green: 정상
    • yellow: 하나 이상의 레플리카 샤드가 할당되지 않았거나 누락됐을 경우
      • 대부분 시간이 지나면 green으로 변하지만 일정 기간이 지나도 변하지 않는다면 원인 분석이 필요하다.
    • red: 하나 이상의 프라이머리 샤드에 손상이 발생했을 경우
      • 데이터가 정상적이지 않은 상태로 검색 시 누락된 데이터가 결과로 제공되기에 신속히 복구가 필요하다.
      • red가 지속될 경우 색인도 정상적으로 이뤄지지 않을 가능성이 높다.
  • 모니터링 해야할 지표들
    • cluster.health.status:클러스터 상태(green/yellow/red)
    • cluster.health.number_of_nodes:노드 수
    • cluster.health.initializing_shards: 샤드 초기화 수
    • cluster.health.unassigned_shards: 할당되지 않은 샤드 수

검색 성능 측정

//노드 통계 조회
GET _nodes/stats

//특정 노드의 통계 조회
GET _nodes/{NODE_NAME)/stats

//특정 노드의 검색 항목만 조회
GET _nodes/{NODE_NAME)/stats/indices/search

//인덱스 통계 조회
GET _stats

//특정 인덱스의 통계 조회
GET {NODE_NAME}/_stats
  • 검색 성능을 측정할 지표를 모니터링 할 수 있다.
  • 모니터링 해야할 지표들
    • indiced.search.query_total: 총 쿼리 수
    • indiced.search.query_time_in_millis: 쿼리에 소요된 총 시간
    • indiced.search..query_current: 현재 진행중인 쿼리 수
    • indiced.search.fetch_total: 총 조회 수
    • indiced.search.fetch_time_in_millis: 조회에 소요된 총 시간
    • indiced.search.fetch_current: 현재 진행 중인 조회 수

색인 성능 측정

//노드 통계 조회
GET _nodes/stats 

//특정 노드의 통계 조회
GET _nodes/{NODE_NAME)/stats

//특정 노드의 indexing/refresh/flush 속성만 조회
GET _nodes/{NODE_NAME}/stats/indices/indexing,refresh,flush

//인덱스 통계 조회
GET _stats

//특정 인덱스의 통계 조회
GET {NODE_NAME}/_stats
  • 색인할 문서 크기가 크다면 색인 과정을 모니터링하고 분석하는 과정이 필요하다.
    • 새로운 문서가 색인되거나 기존 문서가 삭제,수정 될 경우 즉시 반영되지 않기 때문에 모니터링 과정이 필요하다.
  • Refresh와 Flush 작업은 많은 리소스가 필요한 작업으로 병목이 발생할 일이 많고 전체 클러스터 성능과도 연관되어 있다.
  • 모니터링 필요한 지표
    • indices.indexing.index_total: 색인된 총 문서 수
    • indices.indexing.index_time_in_millis: 색인 작업 시 소요된 총 시간
    • indices.indexing.index_current: 현재 색인 중인 문서 수
    • indices.refresh.total: Refresh 작업이 발생한 총 횟수
    • indices.refresh.total_time_in_millis: Refresh 작업에 소요된 총 시간
    • indices.flush.total: 디스크 Flush 작업이 발생한 총 횟수
    • indices.flush.total_time_in_millis: 디스크 Flush 작업에 소요된 총 시간

HTTP 성능 측정

//노드 통계 조회
GET _nodes/stats

//특정 노드의 통계 조회
GET _nodes/{NODE_NAME}/stats

//특정 노드의 HTTP 속성만 조회
GET _nodes/{NODE_NAME}/stats/http
  • HTTP 관련 지표를 이용해 현재 처리량을 모니터링 할 수 있다.
  • 모니터링 해야할 지표
    • http.current_open: 현재 열려 있는 Http 연결 수
    • http.total_opened: Http 연결의 총 갯수

GC 성능 측정

//노드 통계 조회
GET _nodes/stats

//특정 노드의 통계 조회
GET _nodes/[NODE_NAME)/stats

//특정 노드의 JVM 속성만 조회
GET _nodes/{NODE_NAME)/stats/jvm
  • JVM은 GC를 통해 지속적 메모리를 확보하기 때문에 이를 모니터링 해야한다.(ElasticSearch 또한 JVM 기반 애플리케이션)
  • 보조 지표로써만 참고하고 가급적 JMX를 지원하는 전문적인 툴을 이용하는 것을 권장한다
  • 모니터링 해야할 지표
    • jvm.gc.collectors.young.collection_count: young 영역 GC 총 갯수
    • jvm.gc.collectors.young.collection_time_in_millis: young 영역 GC에 소요된 총 시간
    • jvm.gc.collectors.old.collection_count: old 영역 GC 총 갯수
    • jvm.gc.collectors.old.collection_time_in_millis: old 영역 GC에 소요된 총 시간
    • jvm.mem.heap_used_percent: 현재 사용중인 JVM 힙 비율
    • jvm.mem.heap_committed_in_bytes: JVM 힙 커밋 크기

운영체제 성능 측정

  • 운영체제 수준의 성능 지표를 확인할 수 있다.
  • 모니터링해야할 지표
    • I/O 리소스 사용률
    • CPU 사용률
    • 송수신된 네트워크 바이트 수
    • 파일 디스크립터 사용률
    • 스왑 메모리 사용률
    • 디스크 사용률

스레드풀 상태 측정

//노드 통계 조회
GET _nodes/stats

//특정 노드의 통계 조회
GET _nodes/{NODE_NAME)/stats

//특정 노드의 스레드풀 속성만 조회
GET _nodes/{NODE_NAME}/stats/indices/thread_pool
  • 엘라스틱서치 내부에 존재하는 모듈은 스레드풀을 이용해 스레드를 관리한다.
  • 스레드 수는 CPU 코어 수에 따라 엘라스틱서치가 자동으로 설정하기에 임의로 숫자를 조정할 필요는 없으나 주기적으로 확인하는 것이 좋다.
  • 모니터링 해야할 지표
    • 스레드풀에서 생성된 스레드 수 
      • thread_pool.bulk.queue
      • thread_pool.index.queue
      • thread_pool.search.queue
      • thread_pool.merge.queue
    • 스레드풀에서 제거된 스레드 수
      • thread_pool.bulk.rejected
      • thread_pool.index.rejected
      • thread_pool.search.rejected
      • thread_pool.merge.rejected

캐시 상태 측정

//노드 통계 조회
GET _nodes/stats


//특정 노드의 통계 조회
GET _nodes/{NODE_NAME}/stats

//특정 노드의 query_cache, fielddata 속성만 조회
GET _nodes/{NODE_NAME}/stats/indices/query_cache,fielddata

 

  • 캐시 활용 여부도 주의깊게 모니터링이 필요하다.
  • 최신 엘라스틱서치에서는 캐시를 효율적으로 사용하도록 개선이 이루어졌으나 사용자가 직성 생성할 수 있는 fielddata 캐시가 있다.
    • 이를 잘못 사용하면 클러스터가 전체 장애 발생
    • fielddata 캐시는 주로 필드를 정렬하거나 집계를 수행할 때 사용되는데, 이는 빠른 처리를 위해 주로 메모리를 사용한다.
    • 잘못 활용하게 되면 힙 영역에 너무 많은 데이터가 생성되기 때문에 성능 하락으로 직결된다.
  • 모니터링해야할 지표
    • indices.query_cache.memory_size_in_bytes: 쿼리 캐시 크기
    • indices.query_cache.total_count: 생성된 쿼리 캐시 수
    • indices.query_cache.hit_count: 쿼리 캐시 적중률
    • indices.query_cache.miss_count: 쿼리 캐시 미스율
    • indices.query_cache.evitions: 쿼리 캐시 eviction 횟수
    • indices.fielddata.memory_size_in_bytes: fielddata 캐시 크기
    • indices.fielddata.evictions: fielddata 캐시의 eviction 횟수
728x90