[Elasticsearch] Elasticsearch Full GC

1. Elasticsearch에서 Full GC가 자주 발생하는 이유

Elasticsearch는 Java 기반 애플리케이션이기 때문에 JVM의 Heap 메모리 관리가 성능에 큰 영향을 미칩니다. 특히 다음과 같은 이유로 Old 영역에 많은 객체가 쌓여 Full GC가 자주 발생할 수 있습니다.

• 대량의 장기 유지 객체(캐시 데이터, Lucene 인덱스 구조 등) 누적
• 잘못된 메모리 설정(과도한 Heap 크기 설정)
• 비효율적인 인덱싱 작업이나 높은 빈도의 검색 요청으로 인한 객체 생성 증가

2. 분산 환경에서의 STW(Stop-The-World) 대응 방식

ES는 분산 환경에서 운용되므로, 한 노드에서 STW가 발생하더라도 전체 서비스 중단을 방지할 수 있습니다. 이를 가능하게 하는 주요 설계는 다음과 같습니다.

• 샤딩(Sharding): 데이터를 여러 샤드로 나누어 부하를 분산합니다.
• 복제(Replication): 주 샤드의 복제본을 다른 노드에 두어 장애 시에도 지속적인 서비스 제공이 가능합니다.
• 노드 추가(Scale-out): GC로 인한 부하가 클 경우 노드를 추가하여 분산을 강화합니다.

3. Full GC와 fielddata의 관계

fielddata는 텍스트 필드를 정렬이나 집계에 사용하기 위해 메모리에 로딩하는 데이터입니다. fielddata를 사용하면 Heap 메모리에 장기간 유지되는 객체가 생성됩니다. 이러한 객체는 Young 영역에서 쉽게 제거되지 않고 Old 영역으로 승격되어 메모리에 누적됩니다. 결과적으로 Old 영역 사용률을 급격히 높여 Full GC가 자주 발생하는 주요 원인이 됩니다.

이러한 문제를 완화하기 위한 방안은 다음과 같습니다.

• 가능한 텍스트 필드를 keyword 필드로 변경하여 fielddata 사용을 줄입니다.

• fielddata 캐시 사이즈를 제한하여 메모리 사용을 최적화합니다.

  indices.fielddata.cache.size: 20%

• 불필요한 캐시를 정기적으로 삭제하는 작업을 수행합니다.

  POST /_cache/clear?fielddata=true

  4. Full GC로 인한 장애를 줄이기 위한 색인 전략

색인 작업은 ES의 작업 중 가장 heap을 많이 사용하는 작업입니다. 따라서 GC로 인한 장애를 줄이기 위해서는 색인 작업 자체를 가볍게 만드는 것이 중요합니다.

• Bulk 요청 최적화: Bulk 요청 수를 조절하여 heap에 많은 부하를 주지 않도록 합니다.
• Refresh Interval 조정: refresh_interval 값을 조정하여 세그먼트 생성 주기를 늘립니다.
• Replica 조정: 최초 색인시 Replica 수를 0으로 설정 후 색인 완료 후 복구합니다.
• 템플릿 기반 필드 최적화: 필드 수가 많아지고 동적매핑을 사용하게 되면 GC 대상 객체가 많아집니다. 템플릿을 통해 명시적으로 필드 타입을 설정하는 것이 좋습니다.