EKS Blue/Green 업그레이드: Stateful 서비스의 상태·쓰기·전환 기준

EKS cluster를 Blue와 Green으로 나눠 교체할 때 “Stateful 서비스는 Blue/Green이 어렵다”는 말은 반만 맞다. Stateful이라는 label보다 상태가 어디에 있고, 누가 쓸 수 있으며, 전환 순간에 어떤 일관성을 보장해야 하는지가 더 중요하다.

같은 StatefulSet이라도 외부 RDS를 쓰는 API와 EBS에 data를 저장하는 database는 migration 방법이 다르다. 반대로 Deployment라도 local file이나 in-memory session을 진실의 원천으로 쓰면 state migration이 필요하다.

상태를 네 종류로 먼저 분류한다

상태 위치	예시	Blue/Green의 핵심 질문
Pod·node ephemeral	emptyDir, local cache, node local data	버려도 되는가, warm-up은 필요한가?
Kubernetes PV	EBS·EFS 기반 PVC	두 cluster의 attach·access mode·AZ·restore 경로는?
외부 managed data	RDS, DynamoDB, ElastiCache, S3	두 version이 같은 schema·data를 동시에 안전하게 쓰는가?
third-party state	결제, 인증, webhook, SaaS queue	credential·quota·callback·idempotency를 어떻게 격리하는가?

이 표를 workload별로 채우면 “Stateful이라서 안 된다”는 막연한 말이 구체적인 cutover 조건으로 바뀐다.

StatefulSet과 stateful application은 같은 말이 아니다

StatefulSet은 Pod에 stable identity, ordered deployment와 PVC template을 제공하는 Kubernetes controller다. application의 복제 방식이나 data consistency를 자동으로 해결하지 않는다.

반대로 stateless controller를 쓰더라도 다음 data를 Pod 내부에만 보관하면 운영상 stateful하다.

• login session
• upload 중간 file
• local queue
• leader election state
• 처리 완료 marker

Blue/Green 준비에서는 Kubernetes object kind보다 application이 잃으면 안 되는 상태와 side effect를 찾는다.

PVC는 Pod-local storage가 아니다

PVC로 요청한 PersistentVolume은 Pod lifecycle과 분리된다. Pod를 삭제해도 volume이 자동으로 사라진다고 볼 수 없고, PV의 reclaim policy와 storage provisioner 동작을 확인해야 한다.

access mode도 자주 오해한다.

• ReadWriteOnce, RWO: 한 node에서 read-write로 mount
• ReadWriteMany, RWX: 여러 node에서 read-write로 mount 가능
• ReadWriteOncePod, RWOP: cluster 전체에서 한 Pod만 read-write로 mount

RWO는 “한 Pod만 쓴다”가 아니라 한 node에서 mount한다는 뜻이다. 같은 node의 여러 Pod가 접근할 가능성까지 막고 싶다면 CSI 지원 조건과 함께 RWOP를 검토한다.

EBS volume을 두 cluster가 공유한다는 말의 함정

Amazon EBS volume과 attach 대상 EC2 instance는 같은 Availability Zone에 있어야 한다. Blue와 Green node가 다른 AZ에 있으면 기존 volume을 그대로 attach할 수 없다.

같은 AZ라고 해도 두 cluster에서 하나의 writer volume을 동시에 다루는 것은 단순한 PVC manifest 복사 문제가 아니다.

• 기존 Pod의 unmount와 volume detach 완료
• old writer가 정말 종료됐다는 fencing
• Green cluster의 PV·PVC object 재생성 또는 migration
• filesystem과 application consistency
• rollback 시 다시 attach하는 절차

EBS Multi-Attach 지원 여부와 filesystem이 multi-writer를 안전하게 처리하는지는 별도 문제다. 지원된다는 이유만으로 일반 database volume의 active-active 공유에 사용하면 안 된다.

snapshot/restore는 다른 AZ에 새 EBS volume을 만들 수 있는 현실적인 경로다. 그러나 snapshot 시점 이후 변경분이 생기므로 final sync, write freeze 또는 application-level replication이 필요할 수 있다. CSI snapshot을 쓰려면 EBS CSI driver뿐 아니라 snapshot controller와 관련 CRD도 준비돼 있어야 한다.

zero downtime의 핵심은 writer와 consistency다

Stateful service라고 해서 zero-downtime cutover가 구조적으로 불가능한 것은 아니다. application replication, database replication, shared RWX storage나 external managed store를 이용할 수 있다.

다만 “두 cluster가 동시에 뜬다”와 “두 cluster가 동시에 써도 안전하다”는 다르다.

확인할 항목은 다음과 같다.

• single writer를 누가 보장하는가?
• split brain을 어떻게 감지하고 막는가?
• replication lag 허용치는 얼마인가?
• read-after-write와 transaction consistency 요구는 무엇인가?
• old writer를 fencing한 증거는 무엇인가?
• rollback 때 data를 어느 방향으로 되돌릴 수 있는가?

cutover runbook에는 traffic 전환보다 writer ownership 변경을 더 명확히 적어야 한다.

외부 database를 공유할 때 생기는 문제

Blue와 Green이 같은 RDS를 사용하면 storage migration은 줄어든다. 대신 application version compatibility가 핵심이 된다.

schema 변경은 expand·migrate·contract로 나눈다

1. Expand: old·new version이 모두 이해할 column·index를 추가한다.
2. Migrate: data backfill과 new write path를 검증한다.
3. Contract: Blue rollback window가 끝난 뒤 old schema를 제거한다.

Green 배포와 동시에 column rename·drop을 하면 Blue로 traffic을 돌려도 application이 동작하지 않을 수 있다. rollback 가능한 시간 동안 database schema도 양쪽 version과 호환돼야 한다.

traffic이 없어도 side effect는 실행될 수 있다

Green service가 public traffic을 받지 않아도 다음 component는 스스로 일을 시작할 수 있다.

• CronJob과 scheduler
• message queue consumer
• outbox publisher
• webhook dispatcher
• batch worker
• leader election participant

두 cluster에서 동시에 실행되면 duplicate payment, email, job 처리와 connection spike가 생길 수 있다. Green 검증 단계에서는 read-only mode, consumer replica 0, 별도 queue, feature flag나 leader fencing으로 side effect를 막는다.

third-party 연동은 credential까지 분리한다

Blue와 Green에 같은 API credential을 복사하는 방법은 간단하지만 좋은 기본값은 아니다. provider가 지원하면 환경·client별로 scope가 좁고 폐기 가능한 credential을 발급한다.

• Green 전용 callback URL
• 낮은 quota 또는 sandbox account
• idempotency key와 webhook deduplication
• credential owner·expiry·revocation
• provider rate limit을 합산했을 때의 여유

동일 credential을 써야 한다면 secret 복사 자체보다 중복 요청, quota와 audit에서 두 cluster를 구분할 방법을 먼저 정한다.

traffic cutover만 보면 놓치는 것

DNS나 load balancer weight로 1%, 10%, 50%, 100%처럼 traffic을 옮길 수 있다. 하지만 다음 client는 즉시 새 경로로 바뀌지 않을 수 있다.

• DNS cache와 resolver TTL
• HTTP keep-alive
• WebSocket·gRPC long-lived connection
• session affinity
• mobile application의 오래된 connection

따라서 weight가 0이 됐다는 사실과 Blue의 active connection·in-flight request가 0이 된 사실을 구분한다. drain deadline, connection age와 old endpoint traffic을 관측한다.

workload별 migration 선택

ephemeral state만 있는 API

• Green에서 cache warm-up
• session을 external store로 이전하거나 재로그인 영향 명시
• canary traffic과 drain 검증

EBS single-writer workload

• backup·restore test
• final sync 또는 maintenance write freeze
• writer fencing
• AZ와 PV·PVC recreation 절차
• data-level rollback 가능 여부

external database를 공유하는 workload

• dual-version schema compatibility
• connection limit과 query load
• background worker·CronJob fencing
• rollback window 동안 contract migration 금지

application-level replicated database

• replica bootstrap과 lag
• promotion·demotion runbook
• quorum·split-brain 조건
• failover와 failback을 각각 시험

cutover 전 검증표

단계	통과 조건
inventory	state location, owner, RPO·RTO 기록
compatibility	Blue·Green application과 schema 상호 호환
data	backup restore와 checksum·business invariant 확인
side effect	consumer·CronJob·webhook의 single-active 보장
capacity	DB connection, quota, Green node와 network 여유
traffic	canary SLI와 long-lived connection drain 확인
rollback	code뿐 아니라 writer와 schema rollback 검증
cleanup	Blue 종료 시점과 old credential·volume 처리

Blue/Green은 새 cluster를 만드는 배포 패턴이 아니라 동시에 존재하는 두 환경 사이에서 상태와 권한을 안전하게 넘기는 migration으로 봐야 한다.

Argo CD cluster bootstrap은 Green 환경을 declarative하게 재구성하는 흐름으로 이어진다. Pod drain과 Argo Rollouts는 traffic·termination 경계를, 써드파티 API 장애 격리는 외부 연동의 retry·idempotency를 보완한다.

참고 자료

• Amazon EKS cluster upgrade best practices
• Kubernetes Persistent Volumes
• Kubernetes StatefulSet
• Amazon EKS EBS CSI driver
• Amazon EKS CSI snapshot controller
• Amazon EBS snapshots