[AEWS4기] EKS 업그레이드 전략 비교 In-place vs Blue/Green

In-place가 합리적인 선택일까, 어쩔 수 없는 선택일까

얼마 전 AWSKRUG DevOps 소모임에서 참석자들을 대상으로 EKS 업그레이드를 어떤 방식으로 하는지 현장 설문을 한 적이 있다. 약 30명 정도의 인원이 참석했었는데 충격적인 건 In-place 업그레이드를 선택한 사람이 단 한명도 없었다.

나는 회사에서 In-place 방식을 쓰고 있었지만 손을 들 수가 없었다. 왜냐하면 나 스스로도 왜 In-place를 사용하고 있냐는 질문에 제대로 답을 해본 적이 없었기 때문이다. 그저 그렇게 해왔으니까, 그게 자연스러우니까. 그 정도였다.

 

마침 AEWS 4기 7주차 주제가 EKS 업그레이드 실습이었다. 좋은 기회다 싶어서 이번 글에서는 두 업그레이드 방식의 장·단점을 제대로 비교해보고, 마지막에는 내 현재 환경을 솔직하게 들여다보면서 -그래서 우리는 어떻게 해야 하는가- 를 정리해 보았다.

(비용 측면은 의도적으로 뺐다. Blue/Green이 비싸다는 건 누구나 안다. 진짜 흥미로운 건 위험성과 운영 가능성의 트레이드오프다.)

 

In-place와 Blue/Green, 무엇이 다른가

In-place 업그레이드는 기존 클러스터를 그대로 두고 컨트롤 플레인을 한 단계 올린 뒤, 노드 그룹을 순차적으로 교체하는 방식이다. API 엔드포인트, OIDC, ENI, 로드밸런서가 모두 그대로 유지되기 때문에 외부 의존성(CI/CD, kubectl 컨텍스트, DNS, 모니터링 등)을 건드릴 필요가 없다는 게 가장 큰 장점이다.

 

Blue/Green 업그레이드는 목표 버전으로 완전히 새로운 클러스터(green) 를 띄우고, 워크로드를 옮긴 다음 트래픽을 전환하는 방식입니다. 기존 클러스터(blue)는 검증이 끝날 때까지 그대로 두기 때문에 문제가 생기면 트래픽만 되돌리면 됩니다.

 

가장 결정적인 차이는 롤백 가능 여부이다. EKS 컨트롤 플레인은 한 번 올라가면 다운그레이드를 할 수가 없다. AWS 공식 문서에도 "Once you upgrade a cluster, you can't downgrade to a previous version" 라고 명시되어 있다. AWS가 업그레이드 도중 실패를 감지하면 자동 롤백을 시도하긴 하지만, 이건 업그레이드 프로세스 자체가 실패한 경우에만 해당된다. 일단 업그레이드가 "성공"으로 끝난 뒤에 워크로드 쪽에서 문제가 발견되면, 그때부터는 되돌릴 방법이 없다. 

 

In-place와 Blue/Green 위험성 비교

In-place 업그레이드의 위험

새 버전에서 무엇이 잘못됐을 때 롤백이 불가능하다는 점이 가장 치명적인 단점이다. 업그레이드 당시에는 괜찮은 것처럼 보이지만 이후에 발생하는 문제들이 있다.

 

시간 지연 후 드러나는 문제

업그레이드 직후 1~2시간은 멀쩡해 보이지만 며칠 지나서 드러나는 문제들이다.

• 새 kubelet 버전에서 미묘하게 달라진 메모리 회수 정책으로 인한 누적 누수
• 인증서 자동 갱신 주기와 맞물려서 터지는 webhook 인증 실패
• 주 1회 cron 스케줄에서만 호출되는 deprecated API 호출 실패
• 노드 OS 업데이트 후 며칠 뒤 발생하는 커널 모듈 호환성 이슈

검증 환경에서 트래픽 양과 패턴을 완벽히 재현하기는 거의 불가능하다.

• 피크 타임 동시 접속자 폭증으로 인한 컨트롤 플레인 throttling
• 새 스케줄러의 미묘한 동작 변화로 만들어지는 노드 핫스팟
• HPA가 새 메트릭 API와 상호작용하면서 발생하는 스케일링 oscillation
• 새 kube-proxy 버전에서 변경된 conntrack 설정으로 인한 long-lived connection 끊김

가장 치명적인건 애드온 간 상호작용이다. EKS 자체와 각 애드온의 호환성은 문서화되어 있지만, 여러 애드온이 새 버전에서 함께 만났을 때의 동작은 문서화되어 있지 않다. 

 

• Karpenter + Cluster Autoscaler가 동시에 존재하는 환경에서 새 버전의 노드 라벨 처리 변경으로 인한 충돌
• Istio sidecar injection이 새 버전의 admission webhook 순서 변경과 맞물리면서 생기는 Pod 시작 실패
• AWS Load Balancer Controller의 TargetGroupBinding이 새 CRD 검증 룰을 통과하지 못하는 케이스

 

이 모든 위험이 실제로 터졌을 때 In-place는 선택지가 거의 없다. 패치를 만들어서 앞으로 가거나, 클러스터를 새로 만들어서 워크로드를 옮기는 방법인데, 그럴거면 첨부터 blue/green을 하는 게 훨씬 낫다.

 

Blue/Green 업그레이드의 위험

blue/green 도 위험이 없는 건 아니다. 다만 종류가 조금 다르다. 

 

마이그레이션 자체의 복잡도

 

• 시크릿/ConfigMap 누락
• IRSA의 OIDC trust relationship 재구성 누락
• External-DNS가 만든 레코드의 충돌
• 인그레스 컨트롤러의 ALB 재생성에 따른 DNS 전파 지연
• PVC와 EBS 볼륨의 재연결 (특히 AZ가 다른 경우)
• 네트워크 정책, RBAC, ResourceQuota 누락

외부 시스템 연동 재구성

API 엔드포인트와 OIDC provider URL이 바뀌기 때문에 다음 항목들이 모두 영향받는다.

• CI/CD 파이프라인의 kubeconfig 갱신
• 모니터링/로깅 도구의 클러스터 등록 정보
• 보안 도구(예: Wiz, Prisma Cloud)의 RBAC 토큰 재발급
• 외부에서 클러스터 API를 호출하는 모든 시스템

 

쉽게 정리하면, In-place 업그레이드 시 발생하는 문제점은 발생확률은 낮지만 치명적이다. 반면 blue/green 업그레이드 시 발생하는 문제점은 발생확률은 높지만 통제가 가능하고, 만일 문제가 발생해도 blue 로 되돌리면 치명적인 장애는 막을 수 있다.

 

 

우리는 왜 In-place 업그레이드를 하고 있을까? 

현재 운영중인 환경의 조건은 이렇다.

• 약 30개의 EKS 클러스터, 90개 이상의 계정. (개발/검증/운영 을 계정으로 분리하고 있기 때문)
• 각 서비스마다 사용하는 애드온 조합이 전부 다르다. Karpenter를 쓰는 곳도 있고, Cluster Autoscaler를 쓰는 곳도 있다. Istio 는 쓰는 곳도 있고, 안쓰는 곳도 있다. 이유는 관리하는 부서가 전부 다르기 때문이다.
• IaC가 통일되어 있지 않다. 콘솔에서 작업해야 하고, yaml 파일 등이 Git으로 관리되고 있지 않기 때문에 수동 마이그레이션 작업이 필요하다. (이게 가장 치명적)
• 금융권이라 변경 관리가 엄격하다. 모든 변경은 변경 통제 승인을 거쳐야 하고, 작업 시간대도 정해져 있다.

이 환경에서 Blue/Green 을 한다고 가정하면, 한 사이클을 도는데 몇 달이 걸릴 것 같다.

 

사실 In-place를 선택한게 아니라, 현실적으로 불가능해서 선택할 수 밖에 없었다.

 

금융권의 변경관리와 모순

금융권에서는 변경 관리 절차가 참 번거롭다. 운영 변경은 사전 승인, 작업 윈도우 지정, 롤백 계획 명시, 사후 보고가 필수다. 변경통제 위원회는  롤백 계획이 무엇인지를 반드시 묻는다.

이게 모순적이다. In-place 업그레이드를 했는데 개발/검증 단계에서는 없었던 문제가 운영환경에서 갑자기 발생하면 롤백을 어떻게 할 것인가? 사실상 없다.

 

Blue/Green을 가능하게 하려면 무엇을 해야하는가?

지금까지 변명만 늘어놨지만 사실상 방법이 없는 건 아니다. 다만 기술의 문제가 아니라 조직의 문제다.

 

• 클러스터 표준화
  • 모든 부서가 공통으로 따라야 하는 베이스 템플릿이 있고, 그 위에 각 부서가 자신들의 애드온을 얹는 방식이다.
• IaC의 전면화
  • 콘솔작업으로는 Blue/Green은 사실상 불가능하다. 네트워크, IAM, 애드온 등 수동 생성은 말이 안된다.
  • Terraform 같은 IaC 도구를 도입해서 코드화 해야한다. 핵심은 재현가능성이다. 
• 워크로드 마이그레이션 자동화
  • 수많은 k8s 매니페스트를 Git으로 관리해야 한다.
  • ArgoCD / FluxCD 등을 활용한 자동 배포를 통해 두 클러스터의 동기화를 해야 한다.
• 트래픽 전환 메커니즘
  • Route53 가중치 라우팅, ALB의 가중치 타겟 그룹, 또는 Service mesh를 활용한 점진적 전환 구조가 필요하다.
• 이 모든 것을 책임지고 추진할 플랫폼 팀
  • 표준을 세우고, 각 부서를 설득하고 자동화를 구축할 조직이 필요하다.

 

기술은 이미 다 있다. 부족한 건 조직 차원의 합의와 투자라고 생각한다.

 

결론

In-place 업그레이드 전략은 현 상황에선 꽤나 합리적인 선택이다. 개발 / 검증 / 운영 3단계에 걸쳐서 업그레이드를 진행하며, 각 단계별로 1주일 씩 간격을 두고 진행한다. 버젼도 한 단계씩 정기적인 업그레이드를 진행한다.

따라서 대부분의 호환성 이슈는 사전에 점검이 이루어진다. 

 

다만 검증으로 잡지 못한 문제점이 운영에서 발생했을 때 되돌릴 수 없다라는 명확한 한계점을 해결할 수 없다.

다행히 현재 IaC는 전환 중에 있고, GitOps는 검토 단계에 있기 때문에 앞으로의 전망은 긍정적이다. 비용을 고려한다면 운영환경에만 Blue/Green 전략을 사용하는 것이 현실적으로 보인다.

IaC나 GitOps가 어느 정도 자리 잡은 시점에 운영을 Blue/Green으로 가자 라는 제안을 조직에 할 수 있도록 미리 준비해 두는 것이 현재 내가 할 수 있는 일일 것 같다.