당근 검색 엔진을 쿠버네티스로 운영하며 데이터 노드 웜업을 적용한 방법

이 게시물은 쿠버네티스(ECK) 기반 Elasticsearch 운영에서 롤링 리스타트 시 레이턴시가 급증하는 문제를 ‘데이터 노드 웜업’으로 해결한 과정을 설명합니다.

ECK 도입 이후에도 남은 운영 과제

• 클러스터가 1개에서 4개로 늘며 전체 배포 시간이 6시간 이상으로 증가하고, 운영자가 장시간 모니터링해야 했습니다.
• 피크 타임을 피해서만 배포 가능한 제약이 커지며, 긴급 패치 대응과 심리적 부담이 문제로 드러났습니다.

롤링 리스타트가 위험했던 근본 원인

• 데이터 노드 재시작 시 page/query/request cache 등이 비어 cold cache 상태가 되어 디스크 I/O가 증가하고 레이턴시가 튑니다.
• 노드 다운 동안 replica unassigned로 클러스터가 yellow가 되며 남은 샤드로 부하가 집중되고, 연쇄 영향 시 가용성 저하가 발생합니다.

해결 전략: search-coordinator 프록시로 ‘웜업 완료 노드만’ 서빙

• 서비스와 Elasticsearch 사이에 search-coordinator를 두고, 웜업이 끝난 데이터 노드만 검색 대상에 포함시키는 구조를 만들었습니다.
• Central Dogma의 prefer_nodes로 검색 대상 노드 목록을 관리하고, 단일 상태 관리자로서 search-coordinator만 읽기/쓰기를 수행합니다.

웜업 오케스트레이션 동작

• 노드 종료 시 preStop으로 노드 정보를 전달받아 prefer_nodes에서 제외(exclude)하고, Redis Sorted Set 웜업 대기열에 넣습니다(Informer 기반 fallback 포함).
• 노드 기동 후 Redis 분산 락으로 단일 워커만 웜업을 수행하며, Kafka의 실제 검색 로그를 consume해 쿼리를 만들고 동일 쿼리를 최대 5회 재사용해 캐시 생성을 유도합니다.
• Central Dogma에 정의된 QPS와 p50/p90 latency 임계값, 최소 요청 수/시간 조건을 만족하면 웜업 통과로 판정하고 prefer_nodes에 포함(include)해 트래픽을 받게 합니다.