|| 당근 검색 엔진, 쿠버네티스로 쉽게 운영하기 2편 — 데이터 노드 웜업 적용
안녕하세요, 당근 검색 플랫폼팀 Ellie, Jarry예요. 검색플랫폼팀은 당근의 여러 서비스에서 발생하는 방대한 검색 트래픽을 빠르고 안정적으로 처리하고, 더 나아가 새로운 검색 경험을 가능하게 하는 플랫폼을 만드는 팀이에요. 지난 글인 1편에서는 저희가 검색 인프라를 쿠버네티스(ECK)로 이관하면서 배포 자동화와 배포 시간 단축을 이뤘던 이야기를 공유했어요. 5시간 걸리던 배포가 90분으로 줄었고, 누구나 안전하게 검색 클러스터를 배포할 수 있게 됐죠.
그리고 1편을 마무리할 때 이런 이야기를 했는데요.
“피크 타임 트래픽일 때 배포하면 CPU 사용률과 레이턴시가 튀는 현상이 발생하는 것을 확인할 수 있었어요. (…) 피크 타임을 피해서 배포하는 등의 단기적으로 쉽게 해결할 수 있는 방안도 있기 때문에, 이 문제는 논이슈로 감안하고 진행하기로 했어요.”
당시만 해도 “피크 타임만 피하면 되지”라고 생각했어요. 하지만 시간이 지나면서, “피크 타임을 피해야 한다”는 제약 자체가 문제라는 걸 깨달았어요. 운영자가 배포 시간을 계속 신경 써야 했고, 배포가 시작되면 여전히 긴장하며 지켜봐야 했으니까요. 이번 글에서는 왜 이걸 문제라고 생각하게 되었는지, 그리고 어떻게 해결했는지 이야기해 볼게요.
1. ECK 도입 후에도 남은 과제1.1. 검색 인프라, 2년 만에 얼마나 커졌을까
1편을 쓸 당시에는 검색 클러스터가 하나였고, 피크 타임 트래픽은 초당 약 1,000건(1K QPS) 정도였어요.
2년이 지난 지금은 어떨까요? 당근이 성장하면서 검색 인프라도 함께 커졌어요. 지금은 목적에 따라 네 개의 클러스터를 운영하고 있고, 각 클러스터가 받는 피크 타임 트래픽도 아래처럼 크게 달라졌어요.
1편에서 말했듯이, ECK 기반 검색 클러스터는 다음과 같은 구조로 동작하고 있어요. 쿠버네티스 환경에서 Elasticsearch Custom Resource를 정의하고, 이를 기반으로 StatefulSet으로 운영하는 구조예요.
ECK 기반 검색 클러스터 구성도
트래픽만 늘어난 게 아니에요. 클러스터가 네 개로 늘어나면서 운영 부담도 함께 커졌어요. 1편에서 다뤘던 것처럼, 한 클러스터를 배포하는 데는 대략 90분 정도가 필요했어요. 그런데 클러스터가 네 개로 늘어나면서 전체 배포에 6시간 이상이 걸리게 됐고, 그 긴 시간 동안 담당자가 계속 붙어서 모니터링해야 했죠.
1.2. “피크 타임을 피해서 배포하세요”의 한계
1편에서 우리는 ECK를 도입해 배포 자동화를 이뤘다고 말했지만, 한 가지 중요한 포인트가 있었어요. 바로 “피크 타임만 피하면” 이라는 전제 조건이에요.
처음에는 이게 큰 문제처럼 느껴지지 않았어요. 새벽이나 오전 시간대에 배포하면 되니까요. 그런데 클러스터가 네 개로 늘어나고, 배포할 일이 잦아지면서 현실적인 문제가 드러났어요.
첫째, 배포 가능한 시간이 점점 줄었어요. 피크 타임을 피하고, 점심시간도 피하고, 퇴근 전후도 피하다 보면 배포할 수 있는 시간이 하루에 몇 시간 되지 않았어요. 긴급 패치가 필요할 때 “지금은 피크 타임이라 못 해요”라고 말해야 하는 상황이 생겼어요.
둘째, 배포가 점점 “큰 이벤트”처럼 느껴지기 시작했어요. ArgoCD sync 버튼을 누르기 전에 “지금 트래픽 괜찮지?”, “이 시간에 해도 되지?”를 확인해야 했고, 배포 중에도 레이턴시 그래프를 계속 지켜봐야 했어요. 배포 자동화를 했는데도 왜 이렇게 아직도 긴장하면서 배포해야 할까?라는 의문이 들기 시작했죠.
결국, 우리가 진짜 풀어야 할 문제는 이거였어요.
“피크 타임이든 아니든, 언제든 마음 편하게 배포할 수 있는 상태를 만들자.”
그렇다면 왜 우리는 피크 타임을 그렇게 두려워했을까요?
단순히 트래픽이 많아서만은 아니었어요. 진짜 문제는 배포 과정, 그중에서도 롤링 리스타트 중에 레이턴시가 급증하는 현상 때문이었어요. 그럼, 이제 롤링 리스타트 중에 왜 레이턴시가 올라갔는지, 그 근본 원인을 하나씩 파헤쳐 볼게요.
2. 롤링 리스타