당근 검색 엔진, 쿠버네티스(ECK) 기반 운영 고도화: 데이터 노드 웜업 시스템 적용

💡 ECK 도입 후에도 지속된 과제

• 검색 인프라 확장: 2년 만에 클러스터 수가 1개에서 4개로 증가하며 운영 부담 가중.
• 배포 시간 증가: 클러스터당 90분 소요 → 전체 배포 6시간 이상 소요.
• '피크 타임 회피' 제약: 배포 가능한 시간이 줄고, 긴급 패치 시 어려움 발생.
• 롤링 리스타트 시 레이턴시 급증: 배포 자동화에도 불구하고 운영자의 지속적인 모니터링 필요.

💥 롤링 리스타트 시 레이턴시 증가의 근본 원인

• 캐시 미활용: 쿠버네티스 롤링 리스타트 시 Pod Ready 상태 직후 Elasticsearch 노드는 캐시가 비어 있어 디스크 I/O 발생 및 성능 저하.
• 샤드 부하 집중: 노드 다운 시 남은 노드로 부하가 집중되고, Replica 부족 시 가용성 저하 발생.
• Elasticsearch 자체 동작 방식: 쿠버네티스 readinessProbe나 postStart hook과 무관하게 클러스터 합류 시점부터 트래픽 수신.

🎯 목표 및 해결 전략

• 목표: 피크 타임과 무관하게 언제든 안전하게 배포 가능한 상태 구현.
• 핵심 전략: "노드는 마음껏 재시작하되, 웜업이 끝나기 전까지는 검색 트래픽을 받지 않게 하자."
• 솔루션: search-coordinator 프록시 도입 및 웜업 시스템 구축.

🏗️ search-coordinator Proxy 아키텍처

• 역할: HTTP 프록시 기능 및 웜업 오케스트레이션 (트래픽 제어권 확보).
• prefer_nodes 활용: Central Dogma에서 관리하는 데이터 노드 목록을 통해 검색 참여 노드 제어 (웜업 완료 노드만 포함).
• Single Source of Truth: search-coordinator가 노드 라우팅 상태 관리 및 라우팅 정책 캡슐화.

⚙️ 웜업 오케스트레이션 상세 과정

1. 노드 종료 (prestop & exclude)

• Pod 종료 시 preStop hook으로 정보 전달 → search-coordinator가 Central Dogma에서 노드 제거(exclude) 및 웜업 대기열 추가.
• preStop hook 실패 대비: search-coordinator-controller가 Pod 이벤트 구독하여 안전망 역할 수행.

2. 실 트래픽 기반 웜업 (warmup)

• Redis 분산 락으로 웜업 담당 Pod 결정 (단일 Pod만 웜업 진행).
• Kafka 토픽에서 실 운영 트래픽 패턴 Consume → 웜업 대상 노드로 집중 전송 (최대 5회 재사용하여 캐시 생성 유도).

3. 웜업 완료 및 트래픽 서빙 (warmup pass, include, serve traffic)

• QPS, Latency (p50, p90) 기준 충족 시 웜업 성공 판정.
• 성공 시 Central Dogma prefer_nodes에 노드 추가 및 검색 트래픽 수신 시작.
• 최대 실행 시간 초과 시 웜업 실패, 락 해제 후 다른 Pod가 재시도.

4. 샤드 부족 방지 안전장치

• 동시에 검색 대상에서 제외되는 노드 수를 최대 2개로 제한 (샤드 복제본 정책 기반).
• 웜업 대기열 주기적 확인 및 필요시 웜업 중단 후 검색 대상 복귀.

📈 운영 결과

• 배포 시간 단축: 전체 배포 6시간 이상 → 1~2시간으로 감소.
• 심리적 부담 감소: 언제든 안전하게 배포 가능한 환경 구축.
• 레이턴시 안정화: 롤링 리스타트 중 p99 latency 1s 이내 유지.
• 예기치 못한 재시작 대응: 노드 재시작 시 자동 exclude → warmup → include 과정으로 장애 영향 최소화.

📚 한계 및 다음 스텝

• 한계: 클러스터 전체 장애, 네트워크 장애 시 대응 범위 제한. 쿼리 DSL 변경 시 웜업 효과 감소 가능성.
• 다음 스텝: 클러스터 전체 장애 대응 범위 확장, ECK 외 환경 적용 가능한 패키징 방안 모색.