[ElasticSearch] Logstash 와 Elasticsearch / 디스크 I/O 병목

출처: Elastic

Logstash 와 Elasticsearch 노드의 관계

1. Logstash 노드의 역할

• 데이터 수집: 다양한 소스(파일, 데이터베이스, API 등)로부터 데이터를 가져옵니다.
• 데이터 변환: 필터링, 포맷 변경, 필드 추가/삭제 등의 작업을 수행해 데이터를 Elasticsearch가 처리할 수 있는 형태로 가공합니다.
• 데이터 전송: 변환된 데이터를 Elasticsearch 클러스터에 전송합니다.

2. Elasticsearch 노드의 역할

• Logstash에서 받은 데이터를 처리:
  • Logstash에서 전송된 데이터는 Elasticsearch 클러스터로 들어옵니다.
  • Elasticsearch는 인덱스와 Shard를 기반으로 데이터를 분배합니다.
• 데이터 저장:
  • 데이터는 적절한 Primary Shard에 저장됩니다.
  • Elasticsearch는 데이터의 문서 ID와 Shard 개수를 사용해 라우팅 키를 계산하고, 데이터가 저장될 Shard를 결정합니다.

3. 전체적인 데이터 저장 구조

• Logstash → Elasticsearch 노드 → Primary Shard:
  • 데이터를 수집하고 전송하는 Logstash는 Primary Shard의 역할이나 개수에 영향을 주지 않습니다.
  • Elasticsearch가 데이터를 수신하고, 적절한 Shard에 저장하며, 이를 Replica로 복제하는 과정을 자동으로 처리합니다.

---

디스크 I/O 병목 및 해결 방안

출처: Statsig

1. 디스크 I/O와 Elasticsearch의 관계

• Elasticsearch는 **색인(indexing)**과 검색(querying) 과정에서 디스크 I/O를 사용합니다.
• 읽기 I/O(kB_read/s):
  • 데이터를 검색하거나 쿼리 결과를 가져올 때 발생.
• 쓰기 I/O(kB_wrtn/s):
  • 데이터를 색인하거나, Lucene 세그먼트 생성 및 병합 시 발생.

---

2. 병목이 발생하는 주요 상황

색인 작업

• 대량 데이터 색인 시 Translog 기록 및 Segment Merge로 쓰기 I/O 과부하 발생.
• Replica Shard로 데이터 복제 시 추가 쓰기 작업.

검색 작업

• 캐시 미스(Cache Miss)로 디스크에서 반복적인 데이터 읽기 발생.
• 집계(aggregation) 또는 정렬 작업으로 과도한 읽기 I/O 발생.

클러스터 관리 작업

• Shard 재배치: Shard가 이동하며 읽기/쓰기 I/O 증가.
• Snapshot 작업: 백업 과정에서 대량 읽기 I/O 발생.
• Recovery 작업: 노드 장애 복구 시 Primary 및 Replica Shard에서 과도한 읽기/쓰기 발생.

잘못된 설정

• Shard 크기 설계 불량: 너무 작거나 너무 큰 Shard는 I/O 병목을 초래.
• Refresh Interval이 너무 짧아 쓰기 I/O 과부하 발생.

---

3. 병목의 징후

• I/O wait 증가:
  • CPU가 디스크 작업 완료를 기다리는 시간이 길어짐.
• 색인 지연(Indexing Lag):
  • 색인 속도가 느려지고, Elasticsearch가 쓰기 작업을 처리하지 못함.
• 쿼리 응답 시간 증가:
  • 검색 속도가 느려지고 응답 시간이 길어짐.

---

4. 병목 원인

1. 디스크 속도 문제:
   • 느린 HDD 사용.
   • 디스크의 읽기/쓰기 요청이 처리량을 초과.
2. 캐시 부족:
   • JVM 힙 메모리나 파일 시스템 캐시 부족으로 디스크 접근 증가.
3. Shard 관리 문제:
   • 데이터가 특정 노드에 집중되어 부하 발생.
4. 대량 삭제 및 업데이트:
   • 대량 삭제 요청이 병합 작업을 유발해 쓰기 I/O 증가.

---

5. 해결 방안

하드웨어 최적화

• SSD 사용: 읽기/쓰기 속도 향상.
• RAID 설정: RAID 0(속도) 또는 RAID 10(속도+안정성) 적용.

Elasticsearch 설정 최적화

• Shard 크기 조정: 적정 크기(20~50GB) 유지.
• Refresh Interval 늘리기: 색인 작업 중에는 간격을 늘려 쓰기 빈도를 낮춤.
• Translog 설정: durability=async로 설정해 쓰기 I/O 감소.

작업 스케줄링

• Shard 재배치, Snapshot 생성 같은 I/O 집중 작업을 비활성 시간대에 수행.

캐시 활용

• JVM 힙 메모리를 적절히 설정해 파일 시스템 캐시를 극대화.
• Elasticsearch 노드에서 자주 사용하는 데이터를 메모리에 적재.