Kubernetes 환경에서의 Elasticsearch 운영 고도화: Data Node Warm-Up 전략

1. ECK 도입 후 잔존 과제

• Kubernetes(ECK) 환경으로 Elasticsearch 인프라 전환 후에도 피크 타임 배포 시 CPU, Latency 스파이크 문제 발생
• 4개의 클러스터 운영으로 배포 시간 증가 및 운영 부담 가중
• '피크 타임 회피' 배포 전략의 한계점 및 스트레스 요인 분석

2. Rolling Restart의 근본적인 문제점 분석

• Kubernetes StatefulSet Rolling Restart 방식의 한계: Pod 단위 재시작 시 캐시 미반영으로 인한 성능 저하
• 실제 장애 사례 공유: Elastic Operator 버전 이슈로 인한 전체 Elasticsearch StatefulSets Rolling Restart 시 발생한 대규모 장애
• Data Node 재시작 시 캐시 미반영 및 복제본 샤드 부하 집중 현상 분석

3. 목표 설정 및 해결 전략 수립

• 목표: "언제든 Elasticsearch 배포 버튼을 눌러도 검색 서비스가 다운되지 않는 상태 구축"
• 핵심 요구사항: 운영자 모니터링/타이밍 조절 불필요, P99 Latency 1s 유지, 비정상 노드 재시작 자동 처리
• 해결 전략: "노드는 자유롭게 재시작하되, Warm-up 완료 전까지는 검색 트래픽을 받지 않도록 제어"

4. search-coordinator Proxy 아키텍처 설계

• search-coordinator를 Elasticsearch와 서비스 사이에 배치하여 트래픽 제어
• HTTP Proxy 역할: 요청 전달 및 Warm-up 상태에 따른 노드 필터링
• Central Dogma의 prefer_nodes 활용: Warm-up 완료 노드만 검색 타겟으로 등록 관리
• Single Source of Truth: 노드 라우팅 상태 관리를 search-coordinator에서 통합 관리

5. search-coordinator Warm-Up Orchestration 상세

• preStop Hook 및 Kubernetes Informer 연동: 노드 종료 시 prefer_nodes에서 제외 및 Warm-up 큐 등록
• Redis Distributed Lock 활용: 단일 search-coordinator Pod의 Warm-up 책임 할당 및 중복 부하 방지
• Production Traffic 기반 Warm-up Query Pool 구축 및 재사용
• Warm-up 성공 조건 정의(요청 수, 실행 시간, Latency 기준) 및 통과/실패 처리
• Safeguards: 동시 Warm-up 노드 수 제한(최대 2개)으로 샤드 가용성 확보

6. 운영 결과 및 성과

• 배포 시간 단축 (4개 클러스터 동시 배포 1~2시간) 및 심리적 부담 감소
• Rolling Restart 시 P99 Latency 1s 이하 유지 및 정상 범위 내 안정화
• 비정상 노드 재시작 자동 처리로 서비스 다운타임 방지 및 안정성 확보

7. 향후 계획

• 전체 클러스터 장애, 네트워크 이슈 등 대응 범위 확장
• ECK 환경에서의 Warm-up 시스템 외부 패키징 및 확장성 확보
• Search Query DSL 변경 등 Warm-up 효과성 최적화

결론

search-coordinator 도입을 통해 Elasticsearch Rolling Restart 시 발생하는 Latency 스파이크 문제를 해결하고, 피크 타임에도 안정적인 배포가 가능한 시스템을 구축하여 운영 효율성과 서비스 안정성을 크게 향상시켰습니다.