당근마켓 검색 엔진, 쿠버네티스로 쉽게 운영하기 (2023-05)

평균 5시간이 걸리던 수동 배포

당근 검색 플랫폼팀은 플러그인·버전·사이드카 업데이트로 배포가 잦았는데, 한 번에 평균 5시간이 걸렸습니다. ES 특성을 알아야 하는 수동 작업이라 진입장벽도 높았습니다. 팀의 목표는 배포를 자동화해 누구나 안전하게 수행하고, 시간을 30분 이내로 줄이는 것이었습니다.

당근 검색은 Elasticsearch로 피크 때 초당 약 1K 요청과 중고 거래 기준 2.7억 건 이상의 문서를 서빙합니다. 기존에는 AWS ASG의 EC2에서 노드마다 Docker 컨테이너를 실행했습니다. 메인 클러스터와 로그·메트릭을 받는 모니터링 클러스터로 구성했습니다. 이 구성(메인 + 모니터링)을 한국, 일본, 영국, 캐나다 네 지역에 두 환경씩 두어 모두 8개 검색 클러스터를 운영했습니다.

배포하려면 ASG desired count를 2배로 늘리고, 데이터 노드 18대의 샤드를 한 대씩 옮긴 뒤 다시 줄여야 했습니다. 샤드를 옮기는 동안에는 요청을 받을 수 없어 한꺼번에 이동하면 장애가 나는 작업이었습니다.

ECK 검증과 클러스터 이관

팀은 쿠버네티스 위에서 ECK(Elastic Cloud on Kubernetes)를 쓰기로 했습니다. ECK의 롤링 배포에서는 새 Pod가 기존 샤드가 있던 디스크에 붙으므로 샤드를 옮길 필요가 없습니다. SRE팀의 도움을 받아 Helm으로 설치한 뒤 약 3개월 동안 PoC를 진행했습니다.

약 100 QPS로 개념을 검증하고, 운영과 같은 노드 수와 스냅샷, 피크 트래픽으로 규모를 검증했습니다. 확인 대상은 롤링 배포 중 서빙 중단 여부, 노드 강제 종료 시 동작, ArgoCD History & Rollback을 사용한 롤백이었습니다.

데이터 노드가 내려가자 ES가 곧바로 다른 노드에 레플리카를 만들기 시작해, 이 동작을 지연시키는 설정을 추가했습니다. Istio sidecar가 idle 연결을 끊어 데이터 노드 연결이 풀리는 문제도 발견했습니다. SRE팀과 디버깅한 끝에 sidecar injection을 끄자 증상이 사라졌습니다. 저자는 이 일로 ES 앞에 Istio sidecar 같은 프록시를 두면 안 된다는 것을 배웠다고 적었습니다.

8개 클러스터 모두 같은 순서로 옮겼습니다. 새 클러스터를 만들고 색인을 일시 정지한 뒤 스냅샷을 복원했습니다. Route53 라우터를 전환하고 색인을 재개했으며, 하루 지켜본 뒤 기존 클러스터를 종료했습니다. 이관 후에는 GitHub Action에서 이미지를 빌드하고 Kustomize로 태그를 갱신한 뒤, 상태를 확인하고 ArgoCD Sync를 수행하는 배포 파이프라인을 만들었습니다.

이관 결과

문제 정의부터 이관까지 약 5개월이 걸렸으며, 큰 이슈 없이 마쳤습니다. 저자는 배포 시간 단축과 자동화라는 OKR을 100% 달성하지는 못했고, 달성률은 70~80% 안팎이라고 평가했습니다.

이 시리즈의 2편은 이 글에 남은 피크 시간 배포 문제를 다룹니다.

레플리카 요건과 남은 과제

ECK는 데이터 노드를 지운 뒤 새로 띄웁니다. 샤드마다 레플리카가 있어야 하며, 없으면 클러스터가 red가 됩니다.

PoC에서는 피크 트래픽 중 배포하면 CPU와 지연이 튀었습니다. 저자는 피크를 피해 배포하면 되는 문제로 보고 넘어갔습니다. 이후 과제로 꼽은 항목은 HPA 기반 오토스케일링, 데이터 노드 웜업, Graviton, ES 8.7.0 업그레이드입니다.