대규모 로그 처리도 OK! Elasticsearch 클러스터 개선기

하루 수십억 건의 로그를 온프레미스 Elasticsearch에서 처리하면서 인덱싱 지연과 노드 장애가 발생하자, 팀은 fielddata 사용과 비효율적인 동적 매핑 등 힙 메모리와 클러스터 상태 관리에 부담을 주는 설정을 점검했습니다. Hot-warm 아키텍처와 ILM으로 보관 기간에 따라 저장 계층을 나누고, 샤드 수·refresh 간격·translog 설정을 조정해 인덱싱 부하를 관리했습니다. JVM 기반 Logstash 파이프라인은 Rust 기반 Vector로 전환해 메모리 사용을 크게 줄이고 Prometheus exporter로 모니터링을 보강했습니다. 데이터센터 이중화를 위해 전용 회선과 투표 전용 마스터, shard awareness 및 force awareness를 적용해 하나의 클러스터를 구성했으며, 대규모 로그 환경에서는 매핑과 자원 사용을 통제하고 장애 경계를 설계하는 것이 중요하다는 점을 보여줍니다.

• Doc values를 지원하는 필드에는 fielddata를 켜지 말고, 대용량 인덱스에서 힙 메모리와 긴 GC가 발생하는지 점검하세요.
• 동적 매핑은 입력 JSON의 키가 늘면서 mapping explosion을 일으킬 수 있으므로 명시적 매핑, flattened 타입, dynamic: false를 고려하세요.
• 샤드 수는 인덱싱 처리량과 노드별 부하를 함께 고려하고, refresh 간격과 translog flush 설정으로 세그먼트 생성·머지 빈도를 조절할 수 있습니다.
• 로그 파이프라인 도구를 선택할 때 처리 성능뿐 아니라 자원 사용량과 모니터링 지원도 함께 살펴보세요.
• 데이터센터 간 클러스터링은 네트워크 지연과 단절 위험을 검토하고, 전용 회선·투표 전용 마스터·샤드 awareness로 장애 상황을 대비해야 합니다.