[ELK] Elasticsearch 클러스터 트러블 슈팅 및 모니터링

---

 

1. Elasticsearch 트러블슈팅을 위한 cat API

0) _cat API

• 사람이 읽기 편하게 만든 api (상황을 빠르게 판단하는데 도움)
  
  
• 20개 이상의 API 제공 (아래 4가지가 제일 많이 사용)

 

1) _cat health

• GET _cat/health?v (v: verbose를 붙여주면 header까지 보임)
  
  
• cluster 이름, 상태, shard 개수 (primary, reload, init, unassign)
  
  
• status 확인 용

 

2) _cat nodes

• GET _cat/nodes?v
  e.g. GET _cat/nodes?h=ip,heap.percent,disk.avail,name&v
  
  
• jvm, node 메모리 사용률, cpu, load average, node.role, master(* 붙은게 master)
  
  
• 노드 디스크 사용량 확인 / 노드 역할 / 마스터 노드 / 메모리 사용량 확인

 

3) _cat indices

• GET _cat/indices?v
• 인덱스 status(open/close), shard 종류, docs.count, store.size
• 클러스터의 상태는 곧 인덱스의 상태이므로 cat health 이후 트러블슈팅에 cat indices 이용
• 인덱스들의 프라이머리/레플리카 샤드 개수 확인 또는 인덱스 상태 확인

 

4) _cat shards

• GET _cat/shards?v
  e.g. GET _cat/shards?h=index,shard,state,docs,unassigned.reason&v
  
  
• index의 몇 번 shard가 어떤 상태인지(ASSIG, UNASSIG) 확인 -> yellow, red
  
• 이상 상태인 샤드 확인 및 원인 분석 

 

---

2. Elasticsearch 클러스터 모니터링

 

0) 모니터링 시스템 종류

• Elastic Cloud나 Self-Hosted Elasticsearch에는 Kibana의 Stack Monitoring
  
  
• AWS OpenSearch Service 이용 시에는 AWS CloudWatch
  
  
• Prometheus나 Exporter는 어떤 시스템에도 다 이용 가능.

 

1) 임계치를 걸어 알람 받아야 하는 지표

• (1) CPU Usage
  • 노드에 얼마나 많은 요청이 들어오는가
  • 50% 이상
    

• (2) Disk Usage
  • 노드가 얼마나 많은 문서를 저장하는가 -> 80%, 90% 이상 차면 yellow, red
  • 70% 이상
    
    
• (3) Load
  • 노드가 얼마나 많은 CPU/Disk 연산을 처리하고 있는가 (프로세스 개수)
  • CPU 개수에 따라 상이 (CPU 개수 2라면 2 이상)
    
    
• (4) JVM Heap
  • 노드의 JVM이 얼마나 많은 메모리를 사용하는가 (GC 방식에 따라 의미가 달라지긴 함) OOM 발생 전에 JVM Heap에 임계치 걸어 알람
  • Elasticsearch에는 CircuitBreaker가 있어서 jvm Heap 외의 일반 Memory는 신경쓰지 않아도 됨.
  • 85% 이상 (Old GC에 유의)
    
    
• (5) Threads
  • 처리량을 넘어서는 색인/검색 요청이 있는가 (queue, reject)
  • Rejected Threads가 1 이상

 

2) 문제 원인 분석 용도를 찾아내는 지표

• (1) Memory Usage
  • 노드에 설치되어 있는 물리적 메모리의 사용량 (JVM Heap과는 다름)
  • JVM Heap을 늘릴 수 있을지 없을지 판단할 때 지표
    
    
• (2) GC Rate
  • 노드에서 발생하는 GC의 발생주기
  • Disk I/O에 문제가 없을 때 Old GC, Young GC 횟수를 통해 GC가 너무 자주 일어나는지 확인
    
    
• (3) GC Duration
  • 노드에서 발생하는 GC의 소요 시간
  • 0.3ms가 아니라 3s 정도 걸린다면 문제가 있음
    
    
• (4) Disk I/O
  • 노드에서 발생하는 디스크 연산의 지연 시간 (물리적인 작업이므로 CPU에 영향을 주기 때문)
  • NVME와 같은 더 좋은 디스크로의 교체도 고려해볼 수 있음.
    
    
• (5) Latency
  • 노드에서 색인/검색에 소요되는 시간
  • Disk I/O, GC, Heap 등을 연상해볼 수 있는 지표
    
    
• (6) Rate
  • 노드에 색인/검색 요청이 인입되는 양
  • Rejected Thread를 연상해볼 수 있는 지표

 

---

 

3. Elasticsearch 클러스터의 OOM(Out Of Memory) 상황 대처

 

0) 쿠버네티스 환경에서의 OOM

• Kubernetes는 Pod의 상태를 감시하고, 만약 Pod의 상태가 불안정하거나 비정상적인 상태가 감지될 경우 Pod를 재생성합니다. 이때, Pod의 상태를 판단하는 기준은 Kubernetes에서 제공하는 Liveness Probe, Readiness Probe, Startup Probe 등의 설정 값들에 따라 달라질 수 있습니다.
  
  
• 일반적으로 Elasticsearch는 JVM Heap 메모리가 부족해지면 더 이상 데이터를 처리할 수 없는 상태가 됩니다. 이때, Elasticsearch는 OutOfMemoryError와 같은 예외를 발생시키고, 자체적으로 프로세스를 종료합니다. 따라서 Kubernetes에서는 이러한 상황을 Pod의 비정상적인 상태로 감지하고, 자동으로 Pod를 재생성할 수 있습니다.
  
  
• 하지만, 이 경우에도 Pod의 재생성 여부는 Kubernetes 설정에 따라 달라질 수 있습니다. 예를 들어, Kubernetes에서는 Pod의 재생성 여부를 결정하기 위해 Liveness Probe와 Readiness Probe 등의 설정 값을 사용합니다. 이들 설정 값은 사용자가 직접 지정할 수 있으며, Elasticsearch의 Heap 메모리 사용량이 높아져도 이 값들이 충분히 설정되어 있지 않다면 Pod가 재생성되지 않을 수도 있습니다.
  
  
• 따라서, Elasticsearch의 Heap 메모리 사용량이 높아져서 Pod가 재생성되는지 여부는 Kubernetes의 설정과 Elasticsearch의 설정 값에 따라 달라질 수 있습니다. 일반적으로는 Pod의 재생성이 이루어질 것으로 예상되지만, 환경에 따라 다를 수 있으므로 유의해야 합니다.

 

 

1) JVM Heap의 Memory 상태 확인

• Elasticsearch 클러스터에서 OutOfMemoryError가 발생하면, 메모리를 더욱 효율적으로 사용하기 위해 Heap Dump 파일을 생성하는 것이 좋습니다. Heap Dump 파일은 현재 JVM의 Heap 메모리 상태를 스냅샷으로 저장한 것으로, OutOfMemoryError가 발생한 시점의 JVM 상태를 확인하는 데 도움이 됩니다.
  
  
• Heap Dump 파일은 JVM의 HotSpot Diagnostics Tool인 jmap 명령어를 사용하여 생성할 수 있습니다. jmap 명령어는 JDK에 포함된 유틸리티이므로, Elasticsearch가 실행 중인 서버에서 JDK가 설치되어 있어야 합니다. Heap Dump 파일을 생성하기 위해서는 다음과 같은 명령어를 실행합니다.
  
  

jmap -dump:format=b,file=<heap_dump_file> <pid>

 

• 위 명령어에서 <heap_dump_file>은 생성할 Heap Dump 파일의 경로와 이름을 지정하며, <pid>는 Elasticsearch 프로세스 ID입니다. 이 명령어를 실행하면 지정된 경로에 Heap Dump 파일이 생성됩니다. 이후, Heap Dump Analyzer 도구를 사용하여 메모리 누수나 비정상적인 메모리 사용 패턴을 분석할 수 있습니다. Heap Dump Analyzer 도구는 Eclipse Memory Analyzer와 IBM HeapAnalyzer 등이 있으며, 이 도구들은 Heap Dump 파일을 열어 메모리 사용 패턴을 분석하는 기능을 제공합니다.
  
  
• Heap Dump Analyzer 도구를 사용하여 메모리 누수나 비정상적인 메모리 사용 패턴을 찾아내면, 이에 대한 대처 방안을 검토할 수 있습니다. 예를 들어, Elasticsearch의 Heap 메모리 설정 값을 조정하거나, 사용하지 않는 인덱스나 필드를 삭제하는 등의 작업을 수행할 수 있습니다.

 

 

2) JVM Heap 메모리 외 원인들

• 클러스터에서 OOM(Out of Memory) 발생 시, Heap 메모리의 사용량을 체크하는 것은 중요한 부분이지만, 모든 문제의 원인이 되는 것은 아닙니다. OOM은 다양한 원인으로 인해 발생할 수 있으므로, 클러스터에서 문제를 진단하려면 Heap 메모리 뿐 아니라 다른 요소들도 고려해야 합니다.
  
  
  • (1) File Descriptor : Elasticsearch는 파일 입출력에 대한 File Descriptor를 사용합니다. 너무 많은 File Descriptor 사용 시 OOM이 발생할 수 있습니다.
    
    
  • (2) Thread : Elasticsearch는 다양한 Thread를 사용합니다. Thread Pool이 제대로 동작하지 않아 Thread Leak이 발생하면 OOM이 발생할 수 있습니다.
    
    
  • (3) Circuit Breaker : Circuit Breaker는 Elasticsearch가 더 이상 요청을 받지 않도록 하기 위한 장치입니다. Circuit Breaker를 사용하지 않거나, 잘못된 Circuit Breaker 설정으로 인해 OOM이 발생할 수 있습니다.
    
    
• 이 외에도 클러스터의 문제 진단을 위해 다양한 도구와 명령어를 사용할 수 있습니다. 예를 들어, top 명령어를 사용하여 클러스터의 CPU 및 메모리 사용량을 확인하거나, iostat 명령어를 사용하여 디스크 사용량을 확인할 수 있습니다. 또한, Elasticsearch가 제공하는 다양한 API를 사용하여 클러스터의 상태를 확인하고, 문제를 진단할 수도 있습니다.

 

 

3) Elasticsearch의 Circuit Breaker 기능

• Circuit Breaker는 Elasticsearch가 Out Of Memory(OOM) 상황에서도 정상적으로 동작할 수 있도록 해주는 중요한 요소입니다. OOM을 예방하기 위해 일정량의 메모리를 미리 예약하고, 예약된 메모리를 초과하여 사용하는 작업이 발생하면 해당 작업을 중단시키는 역할을 합니다. 일반적인 Application에서 Circuit Breaker가 작동하면 Client에게는 503 Service Unavailable 오류가 반환됩니다. 하지만 Elasticsearch는 429 Too Many Requests 오류를 전달하므로 무작정 503 에러를 받는 케이스에 비해 Client 단에서 Request를 줄이거나 지연시키는 등 UX 친화적인 개발이 가능합니다. Circuit Breaker에는 세 가지 종류가 존재합니다.
  
  
  
• (1) Request Circuit Breaker
  
  Request Circuit Breaker는 검색 및 색인 요청 처리에 사용되는 메모리를 제한합니다. Request Circuit Breaker는 인덱스마다 별도로 적용됩니다. 기본적으로 Request Circuit Breaker는 인덱스당 60%의 JVM Heap을 사용합니다.
  
  
  • 각 인덱스의 요청을 처리하기 위해 일정량의 메모리를 예약합니다.
    
    
  • 인덱스별 예약된 메모리를 초과하여 사용하면, 해당 인덱스의 요청 처리를 중단시킵니다.
    
    
  • Request Circuit Breaker가 동작하면, 해당 인덱스의 상태를 CIRCUIT_BREAKER로 설정합니다.

 

• (2) Field Data Circuit Breaker
  
  Field Data Circuit Breaker는 필드 데이터를 캐싱하기 위해 사용되는 메모리를 제한합니다. Field Data Circuit Breaker는 인덱스마다 별도로 적용됩니다. 기본적으로 Field Data Circuit Breaker는 Request Circuit Breaker 크기의 40%를 사용합니다. Field Data Circuit Breaker는 다음과 같은 방식으로 동작합니다.
  
  
  • 필드 데이터를 캐시하기 위해 일정량의 메모리를 예약합니다.
    
    
  • 캐시된 필드 데이터를 사용하여 검색을 수행할 때, 사용한 메모리를 추적합니다.
    
    
  • Field Data Circuit Breaker가 동작하면, 필드 데이터의 캐시를 제한하거나, 해당 필드를 캐시하지 않습니다.

 

• (3) Parent/Child Circuit Breaker
  
  Parent/Child Circuit Breaker는 Parent/Child Join 관련 메모리 사용을 제한합니다. Parent/Child Circuit Breaker는 인덱스마다 별도로 적용됩니다. 기본적으로 Parent/Child Circuit Breaker는 Request Circuit Breaker와 동일한 크기를 사용합니다.
  
  
  • Parent/Child Join 작업을 수행할 때, 일정량의 메모리를 예약합니다.
    
    
  • Parent/Child Join 작업을 수행하면서 사용한 메모리를 추적합니다.
    
    
  • Parent/Child Circuit Breaker가 동작하면, Parent/Child Join 작업을 중단시킵니다.
    

 

Parent/Child Join은 Elasticsearch에서의 데이터 모델링 패턴 중 하나로, 관계형 데이터베이스에서 사용되는 외래키 관계를 대신하여 사용됩니다. Elasticsearch에서는 문서를 인덱싱할 때, Parent 문서와 Child 문서를 별도의 인덱스에 저장합니다. 이때 Parent 문서와 Child 문서는 join 필드를 공유하며, join 필드를 사용하여 관계를 맺습니다.

Parent/Child Join은 다음과 같은 장점을 제공합니다.

1. 유연한 데이터 모델링 Parent/Child Join을 사용하면, 관계형 데이터를 유연하게 모델링할 수 있습니다. Elasticsearch는 Parent/Child Join을 지원하기 때문에, 관계형 데이터를 인덱싱하고 검색하는 것이 가능합니다.
   
   
2. 다양한 쿼리 지원 Parent/Child Join을 사용하면, 관계형 데이터에 대한 다양한 쿼리를 지원할 수 있습니다. 예를 들어, Parent 문서와 Child 문서를 동시에 검색하는 쿼리나, Parent 문서와 Child 문서를 함께 반환하는 쿼리를 사용할 수 있습니다.
   
   

하지만 Parent/Child Join은 추가적인 메모리를 필요로 하기 때문에, 메모리 사용량을 늘리는 요인 중 하나입니다. Parent/Child Join을 사용할 때는, 메모리 사용량을 고려하여 적절한 설정값을 조정해야 합니다.

 

 

---

 

[ELK] Container 환경의 Elasticsearch에 대해 알아두면 좋은 것들

[Data Analyst] Prometheus & Grafana 이해와 활용 (오픈소스 모니터링 시스템)

 

[Kubernetes] 쿠버네티스 환경에서의 JVM 동작/배포/성능 최적화