Elasticsearch 운영과 트러블슈팅 — 클러스터 구성부터 장애 복구까지

관리형 서비스가 아니라 Elasticsearch 클러스터를 직접 운영하기 시작하면, 검색 품질과 무관한 문제들이 먼저 찾아온다. 노드가 아예 뜨지 않고(vm.max_map_count), 어느 날 갑자기 쓰기가 막히고(디스크 flood_stage), 네트워크가 잠깐 끊겼는데 데이터가 갈라진다(split brain).

이 글은 그런 문제들의 원리와 처방을 정리한다. 클러스터 토폴로지·OS 커널 튜닝·샤드 할당·장애복구·배포·모니터링·성능튜닝을 도식과 표 중심으로 다룬다. ES를 자체 인프라에 올려 운영하거나 운영 인계를 앞둔 엔지니어를 위한 글이다. 내부 동작의 배경은 Elasticsearch 아키텍처, 검색 기능은 한글 검색 구현에서 다룬다.

용어 정리

클러스터 토폴로지 — 노드 역할과 마스터 구성

노드 역할

Elasticsearch 클러스터는 역할이 다른 노드들의 모임이다. _cat/nodes?v의 node.role 컬럼이 한 글자씩 역할을 표시한다.

마스터 후보 노드 — Quorum과 Split Brain

• Quorum(정족수) = (마스터후보 수 / 2) + 1. 이 표수 이상이 모여야 마스터를 선출한다.
• Split Brain: 짝수 구성에서 네트워크가 분단되면 양쪽이 각각 마스터를 뽑아 데이터가 갈라진다. 홀수 구성 + quorum으로 막는다.

운영 3원칙은 이렇게 정리된다. ① 마스터 후보는 3·5 홀수로 둔다. ② 한 번에 절반 이상 노드를 빼지 않는다(quorum 미달 시 클러스터 unavailable). ③ 최초 구성 시 cluster.initial_master_nodes에 후보를 모두 넣고, 구성 완료 후 제거한다.

OS·커널 튜닝 — 운영 모드의 첫 관문

ES는 특정 주소로 바인딩(network.host)하는 순간 운영 모드가 되어 부트스트랩 체크가 엄격해진다. 아래 커널 설정을 통과하지 못하면 노드가 뜨지 않는다.

• 왜 스왑을 막나: ES 힙 페이지가 디스크 스왑으로 내려가면 Thrashing(연속 페이지폴트)으로 검색 지연이 급증한다. 확인은 GET _nodes?filter_path=**.mlockall → mlockall: true.
• 왜 FD를 올리나: Lucene은 세그먼트 파일을 다수 연다. 부족하면 샤드가 ALLOCATION_FAILED로 떨어진다(Windows는 JVM이 관리해 무관, Linux/macOS만 해당).
• 힙 설정 3원칙: Xms = Xmx 동일 / 32GB 초과 금지(compressed oops 상실) / 총 메모리의 50% 이하(나머지는 파일시스템 캐시가 써야 검색이 빠르다).

샤드 할당·디스크 Watermark·서킷브레이커

디스크 Watermark — 용량이 차면 벌어지는 일

실무에서 "갑자기 인덱스에 쓰기가 안 된다"는 장애의 흔한 원인이 flood_stage(95%) 도달이다. 디스크를 비우고 index.blocks.read_only_allow_delete를 해제해야 풀린다.

샤드 배치 인지(Awareness)

• allocation.awareness.attributes: zone — rack/AZ 속성을 인지해 primary와 replica를 다른 AZ에 분산한다.
• Force Awareness(awareness.force.zone.values: KR,JP): 지정 AZ가 없으면 복제본을 아예 할당하지 않아, 한 AZ가 다운돼도 잔여 AZ가 과적재되지 않게 한다.

서킷 브레이커 — OOM 방어선

과부하를 감지해 요청을 끊어 노드 전체가 OOM으로 죽는 것을 막는다.

Hot-Warm-Cold 아키텍처와 ILM

시계열 데이터(로그·주문 등)를 접근 빈도에 따라 다른 스토리지 계층에 나눠 담아 성능·비용을 동시에 잡는다.

• 티어 라우팅: index.routing.allocation.include._tier_preference: data_hot. 폴백은 cold→warm→hot 순으로 노드 존재를 검사한다.
• 라이선스 주의: Searchable snapshot·cold/frozen은 Enterprise, CCR·ML은 Platinum부터다.

장애복구 — Green/Yellow/Red와 복구 절차

클러스터 상태의 의미

상태를 결정짓는 것은 대부분 샤드다.

• Red 복구 순서: ① 문제 인덱스 확인 → ② 노드 종료가 원인이면 노드 재시작 → ③ 스냅샷 복구 → ④ 재색인(reindex).

노드 유실 시 샤드 복구

핵심 설정은 index.unassigned.node_left.delayed_timeout(기본 1m)이다.

• 왜 delayed_timeout이 중요한가: 롤링 재기동처럼 잠깐 빠졌다 돌아오는 노드 때문에 매번 대량 샤드를 재할당하면 낭비다. 5m로 늘리면 순간 재기동에서 불필요한 재할당을 억제한다.

스냅샷과 SLM

• 스냅샷은 ES의 유일한 백업 수단이다. 외부 저장소(S3·GCS·Azure·HDFS)에 저장한다.
• 스냅샷 T1→T2→T3는 증분·독립이다. T1을 지워도 T1 전용 데이터만 삭제되고 T2가 참조하는 데이터는 남는다.
• One Writer, Many Readers: 한 저장소에 쓰는 클러스터는 하나여야 한다.
• gotcha: 스냅샷 생성 중에는 샤드 할당·리밸런싱이 막혀 인덱스 생성이 실패한다. 생성 완료 후 재개된다.
• SLM: 주기적 자동 생성 + retention으로 자동 삭제. 버전 호환은 하위 버전 미지원이라 복구 대상 클러스터 버전을 맞춰야 한다.

배포와 버전 업그레이드

• 버전 업그레이드: 마이너는 하위호환이 되므로 롤링과 짝이다. 메이저는 하위호환이 없어 중단 배포와 짝이고, 비호환 인덱스는 Archive Functionality로 대응한다.
• 롤링 시에는 앞 절의 delayed_timeout을 함께 조정해 노드 재기동마다 샤드가 대량 재할당되지 않게 한다.

ECK — 쿠버네티스 위의 Elasticsearch

• ECK = Elastic Cloud on Kubernetes: 오퍼레이터 패턴으로 K8s 위에서 Elastic Stack을 선언적으로 운영한다.
• 동작(reconcile): 사용자가 CRD(YAML)로 원하는 상태를 선언 → API Server → ECK Operator가 감시·조정 → Kubelet이 Pod(ES/Kibana)를 생성·수렴한다.

• 왜 StatefulSet인가: ES 데이터 노드는 상태(Stateful)를 가지므로 Pod 이름이 -0, -1, -2처럼 고정(Ordinal)돼야 PV와 안정적으로 연결된다. Deployment(랜덤 ID)는 Stateless용이다.
• 운영 주의(gotcha): cluster-autoscaler.kubernetes.io/safe-to-evict: false 애노테이션으로 K8s Scale In이 ES 데이터 노드를 임의 축출하는 것을 막는다. 그러지 않으면 스케일 인 때 샤드가 유실된다.

모니터링 — 무엇이 죽었는지 어떻게 아는가

• 모니터링 전용 클러스터 분리: 운영 클러스터가 장애로 죽어도 모니터링 데이터는 별도 클러스터에 남아 조회할 수 있다.
• Prometheus는 Pull 방식: exporter를 주기적으로 스크레이핑한다. 구성은 Prometheus server(Retrieval+TSDB) / Alertmanager(→PagerDuty·email) / PromQL / Grafana다.
• Slow Log: index.search.slowlog.threshold.query.warn 등으로 임계를 설정하고, X-Opaque-ID 헤더로 느린 쿼리를 추적한다.

성능·색인 튜닝 핵심

검색 성능

색인(대량 적재) 성능

대량 색인의 정석은 **"색인 중엔 refresh를 늦추고 replica를 끄고, 끝나면 되돌린다"**이다. Elasticsearch 아키텍처의 색인 내부동작(버퍼→refresh→segment→merge)을 이해하면 자연스럽게 나오는 결론이다.

운영에서 실제로 겪는 어려움 (종합)