1. 왜 이 문제에 주목했는가? (Introduction)
AWS EKS 클러스터는 지속적으로 버전이 업데이트되며, 이전 버전에 대한 지원은 일정 주기를 두고 종료됩니다. 당시 운영 중이던 프로덕션 환경은 EKS 1.27을 사용 중이었고, 이 버전은 곧 지원 종료(EOL) 예정이었습니다. 최신 버전으로의 업그레이드는 선택이 아닌 필수였고, 동시에 무중단 운영이 요구되는 서비스 특성상 다운타임 없이 안전하게 전환하는 것이 핵심 과제였습니다.
이러한 요구사항을 만족시키기 위해 Blue/Green 전략과 Route53의 트래픽 분산 기능을 활용하여, 운영 중단 없이 클러스터를 최신 버전으로 교체하는 구조를 설계하게 되었습니다. 이 글에서는 그 전체 과정을 정리해보고자 합니다.
2. 기술 스택 결정 과정 (기술 선택 이유 · Why This Technology?)
EKS 클러스터를 무중단으로 업그레이드하는 데 있어 가장 먼저 고민했던 것은 두 클러스터 간 트래픽을 어떻게 안전하게 분산하고 제어할 것인가였습니다. 단순히 새로운 클러스터를 띄우는 것만으로는 무중단 전환이 보장되지 않기 때문에, 실제 트래픽 라우팅 전략은 업그레이드 성공 여부를 좌우할 수 있는 핵심이었습니다.
당시 고려했던 아키텍처는 크게 세 가지였습니다.
- Option 1: Route 53의 Weighted Routing을 활용해 두 ALB를 DNS 레벨에서 트래픽 분산하는 구조
- Option 2: Network Load Balancer(NLB)와 EC2 Proxy를 통해 두 클러스터에 트래픽을 분산하는 구조
- Option 3: 하나의 ALB 뒤에 두 클러스터의 Ingress Controller를 붙이는 구조
Option 2는 구조적으로 복잡하고 EC2 프록시 인스턴스를 별도로 운영해야 한다는 점에서 관리 오버헤드가 크고, 트래픽 전달 지연이나 병목 발생 가능성도 배제할 수 없었습니다.
Option 3는 ALB 리스너 규칙이나 Ingress 수준에서의 세밀한 제어가 가능하다는 장점이 있었지만, ALB 하나로 두 클러스터를 동시에 연결한다는 구조가 실제 운영 중인 서비스에서 사용할 수 없는 인프라 환경이였습니다.
결국 Option 1, 즉 Route 53의 Weighted Routing 정책을 적용하는 방식이 가장 단순하고, 리스크를 최소화하면서도 롤백이 가장 빠른 구조라는 판단을 하게 되었습니다. 특히 기존에도 ALB 기반의 트래픽 분산 구조를 사용 중이었기 때문에, 별도 신규 인프라 없이도 적용 가능하다는 점이 선택의 중요한 기준이었습니다. 이 전략은 실제 전환 과정에서도 유연하게 트래픽 비율을 조절할 수 있었고, 문제 발생 시 수 분 이내에 트래픽을 기존 클러스터로 복귀시킬 수 있는 안정장치로 작동했습니다.
결론적으로, DNS 기반의 트래픽 제어는 단순하면서도 굉장히 강력한 업그레이드 전략으로 자리잡을 수 있었습니다.
3. 시스템 구성도 및 설명 (설계 및 구축 과정 · Architecture & Implementation)
초기 트래픽은 Route53을 통해 기존 클러스터에 90%, 신규 클러스터에 10% 비중으로 분산되었고, 이후 서비스 상태를 모니터링하면서 점진적으로 트래픽 비중을 조정했습니다. 문제가 발생할 경우 Route53의 가중치 값을 즉시 조정하여 롤백이 가능하도록 설정했으며, 이 과정을 수분 내에 처리할 수 있도록 사전 자동화 스크립트도 작성해 두었습니다.
업그레이드 대상은 클러스터 자체뿐만 아니라 그 위에 설치된 ArgoCD, AWS Load Balancer Controller, Cert-Manager 등 주요 서드파티 컴포넌트도 포함되었으며, 각 컴포넌트는 안정화된 최신 버전으로 맞춰 구성하였습니다.
아래의 명령어를 통해 사용중인 add-on의 안정화 버전을 확인할 수 있습니다.
aws eks describe-addon-versions --addon-name [add-on] --kubernetes-version 1.31
운영 중에는 CloudWatch와 Grafana 기반의 대시보드를 통해 클러스터 상태, 트래픽 흐름, 오류율(5xx), 응답 시간, 리소스 사용량 등을 실시간으로 모니터링했습니다.
4. 적용 결과 (결과 및 효과 · Result & Outcome)
결과적으로 이번 업그레이드는 완전한 무중단 방식으로 성공적으로 수행되었습니다. 전체 서비스의 트래픽이 신규 클러스터로 안전하게 이전되었고, 문제 없이 클러스터를 전환 완료하였습니다. 이전에는 클러스터 업그레이드 시 배포 실패나 다운타임에 대한 우려가 있었으나, 이번 전략을 통해 이러한 문제를 완전히 해소할 수 있었으며, 운영 안정성 또한 한층 높아졌습니다.
추가적으로, Route53의 DNS 기반 트래픽 분산은 단순하면서도 강력한 방식이었고, 실제 장애 발생 시 신속하게 이전 환경으로 트래픽을 되돌릴 수 있다는 점에서 높은 신뢰를 확보할 수 있었습니다. 전체 구성 요소를 최신화함으로써 보안 취약점 해결, 성능 최적화, 유지관리 편의성 향상 등의 효과도 함께 얻을 수 있었습니다.
5. 회고 및 배운 점 (Retrospective)
이번 경험을 통해 무중단 클러스터 업그레이드가 단지 기술적 전환이 아니라, 운영 안정성과 신뢰성을 확보하는 핵심 전략임을 다시금 체감했습니다. 특히 Route53의 트래픽 분산 정책은 Blue/Green 배포 전략과 궁합이 매우 좋았고, 다른 프로젝트나 신규 서비스 도입 시에도 동일한 전략을 기본 템플릿으로 삼을 수 있을 것이라 확신하게 되었습니다. 다만, 초기 클러스터 간 네트워크 연결 정책이나 IAM 권한 구성에서 일부 예상치 못한 오류가 발생했으며, 이는 문서화와 사전 테스트 프로세스를 좀 더 강화하는 방향으로 보완할 예정입니다.
향후에는 이번 전략을 Terraform 기반으로 템플릿화하여, 클러스터 업그레이드와 배포 시 동일한 흐름을 자동화된 구조로 반복 재사용할 수 있는 기반을 마련하려고 합니다.
Made by 문재승(JAESEUNG MUN)
'AWS > EKS' 카테고리의 다른 글
| Karpenter로 EKS EC2 비용 최적화하기 - 비용절감 프로젝트 #2 (1) | 2025.05.02 |
|---|---|
| EKS Graviton 마이그레이션 - 비용절감 프로젝트 #1 (1) | 2025.04.22 |
| keda 활용해서 프로매태우스 매트릭을 손쉽게 사용하기 (0) | 2025.04.18 |