아마존 EKS 무중단 업그레이드 (SRE 밋업 1회)

주요 구간

• 00:00 EKS 소개와 지원 종료 일정
• 02:00 업그레이드가 고통스러운 이유
• 03:00 싱글 클러스터 업그레이드
• 06:30 멀티 클러스터 업그레이드와 트래픽 전환
• 12:00 여러 단계 건너뛰기와 주의할 점
• 15:00 질의응답

반복되는 업그레이드의 부담

당근은 서비스 대부분을 EKS에서 운영하며, 서울, 영국, 북미, 일본의 클러스터를 3, 4개월마다 업그레이드하는 데 부담을 느꼈습니다. 발표자 입사 당시 모든 클러스터는 1.14였습니다. 지원 종료에 맞춰 1.15로 올리자 1.15의 지원 종료일인 2021년 5월 3일도 곧 다가왔습니다. 당시 슬라이드 표에는 리전별 서비스용, 개발 테스트용, 운영과 배포용을 합쳐 10개 클러스터가 있었고 모두 1.15였습니다.

이번에는 지원 종료 직전까지 기다리지 않고 최신 버전에 가깝게 올려, 다음 업그레이드까지 시간을 벌기로 했습니다.

새 클러스터로 트래픽 옮기기

당근은 새 버전 클러스터를 만들고 트래픽을 옮기는 멀티 클러스터 방식을 골랐습니다. 트래픽을 세밀하게 조절하려고 ALB는 AWS Load Balancer Controller의 제어권을 빼고 Terraform으로 관리하기로 했습니다. 컨트롤러가 의도하지 않은 작업까지 하면서 타깃 그룹을 지운 사고가 있었기 때문입니다. ALB와 타깃 그룹은 TargetGroupBinding으로 연결해 파드 IP 변경을 대상 그룹에 자동 반영합니다.

NLB는 가중치 조절이 어려워 앞에 HAProxy를 두었습니다. 새 클러스터로 보내는 트래픽은 1%, 20%, 50%, 100% 순으로 늘리며 에러가 없는지 확인했습니다.

비교한 싱글 클러스터 방식은 EKS 마스터를 한 버전씩 올립니다. 버전당 약 40분이 걸려 1.15에서 1.18까지 3단계에는 두 시간쯤 필요합니다. 이어 CoreDNS, kube-proxy, VPC CNI 플러그인을 올리는데, 공식 문서 절차가 복잡해 eksctl의 업데이트 명령을 썼습니다. 워커는 새 버전 노드 그룹을 만든 뒤 이전 그룹을 cordon하고 drain해 파드를 옮기고, 이전 그룹을 삭제합니다. 노드 그룹에는 v1, v2 같은 라벨을 달아 대상 노드를 쉽게 골랐습니다.

업그레이드 결과

1.15에서 1.18까지 한 번에 올리면서 지원 종료를 2022년 2월 18일까지 늦췄습니다. 멀티 클러스터 방식으로 버전을 여러 단계 건너뛰며 내부 시스템도 함께 올렸습니다. Istio는 1.5에서 1.8로, ALB 컨트롤러는 AWS Load Balancer Controller로 올렸고 EBS CSI 드라이버도 업그레이드했습니다.

발표자는 두 클러스터를 유지하므로 언제든 이전 상태로 되돌릴 수 있고, 트래픽을 잘 조절하면 두 클러스터를 상시 운영할 수도 있다고 설명했습니다.

적용할 때 확인할 점

멀티 클러스터 방식에는 앞단에서 트래픽을 조절할 ALB나 HAProxy가 필요합니다. Job 같은 배치는 두 클러스터에서 실행 시간이 겹쳐도 문제없도록 바꿔야 합니다.

싱글 클러스터 방식은 한 번에 한 버전만 올릴 수 있고 롤백이 불가능합니다. 발표에서 예로 든 Ingress API처럼 버전에 따라 바뀌는 API가 있어, 배포된 리소스를 함께 바꾸지 않으면 문제가 생길 수 있습니다.

질의응답에서는 1.22에서 삭제되는 API가 많아 다음 업그레이드는 2021년 말쯤 1.21까지만 진행할 계획이라고 답했습니다. Route 53 가중치 라우팅으로 HAProxy를 대체하는 방안은 DNS 캐싱 때문에 앱이 잘 따라올지 확인해 봐야 한다고 했습니다. 멀티 클러스터 업그레이드를 고른 이유는 당근 SRE 밋업 2회 배포 시스템 발표에서도 언급됩니다.