EKS Blue/Green 업그레이드에서 Stateful 서비스를 바라보는 올바른 기준

EKS 버전을 Blue/Green 방식으로 업그레이드할 때, 가장 먼저 던져야 할 질문은 이것이다.

“이 서비스의 상태(state)는 어디에 존재하는가?”

Stateful 여부는 단순히 StatefulSet을 쓰느냐의 문제가 아니다.
데이터가 어디에 있고, 누가 진실(Source of Truth)을 가지고 있느냐에 따라 난이도와 전략이 완전히 달라진다.

실무에서는 stateful 서비스를 아래 세 가지로 나누는 것이 가장 명확하다.

---

1. Pod 내부에 상태가 존재하는 서비스 (Pod-local state)

개념

상태가 컨테이너 또는 Pod에 연결된 파일 시스템에만 존재하는 경우다.

대표적인 예는 다음과 같다.

• 로컬 디스크(EBS RWO)에 직접 데이터 저장
• StatefulSet + PVC
• 자체 DB, embedded DB
• 단일 노드 Elasticsearch / Redis
• 파일 기반 큐, 캐시

이 구조의 핵심 특징은 Pod가 사라지면 상태도 함께 사라지거나, 다른 노드에서 바로 이어받을 수 없다는 점이다.

---

특징 정리

• Kubernetes 관점에서 가장 다루기 어려운 유형
• Blue/Green 구조와 근본적으로 충돌
• 동일 데이터를 두 클러스터가 동시에 접근 불가 (EBS RWO 제약)
• 완전한 무중단 전환은 구조적으로 거의 불가능

즉, 이 유형에서 “무중단”을 목표로 하면 설계가 꼬이기 쉽다.

---

현실적인 판단

무중단 가능 여부는 다음과 같이 보는 게 맞다.

• 완전 무중단: 사실상 불가능
• 현실적인 목표: 쓰기 중단을 포함한 짧은 다운타임

그래서 이 경우에는 “Blue/Green”이라기보다
통제된 중단 절차를 가진 전환 시나리오를 만드는 쪽이 훨씬 안정적이다.

---

권장 운영 절차 (중단 허용 모델)

1단계: 쓰기 중단 진입

• API write 차단
• background worker / consumer 중지
• 큐 처리 중단
• 가능하면 read-only 모드 제공

2단계: 데이터 안정화

• flush / fsync / checkpoint 수행
• 애플리케이션 정상 종료
• Pod scale down → 볼륨 detach

3단계: Green 클러스터 기동

• 동일 PV attach
• StatefulSet 재기동
• 데이터 무결성 확인

4단계: 트래픽 전환

• Ingress 또는 DNS 변경
• health check 통과 여부 확인

5단계: write 재개

---

핵심 정리

• Pod 내부 상태 기반 시스템은 “인프라 교체”와 “무중단”이 구조적으로 충돌한다
• Blue/Green보다는 짧고 예측 가능한 중단 절차가 더 안전하다
• 장기적으로는 상태 외부화가 필요하다

---

2. 데이터 레이어에 상태가 있는 서비스 (External Data Layer)

개념

애플리케이션은 stateless이고, 상태는 외부 데이터 저장소가 관리한다.

대표적인 예:

• RDS / Aurora / Cloud SQL
• DynamoDB
• Redis (ElastiCache)
• Kafka / MSK
• S3
• 외부 Elasticsearch / NoSQL

---

특징

• Blue/Green 전환에 가장 적합
• 애플리케이션은 단순한 클라이언트 역할
• 데이터는 단일 Source of Truth
• 여러 클러스터에서 동시에 접근 가능

이 구조가 사실상 무중단 배포의 정석이다.

---

무중단 전략의 핵심 원칙

• Blue와 Green은 동일한 데이터 레이어를 바라본다
• 애플리케이션은 stateless하다
• 스키마 변경은 항상 하위 호환(backward compatible)으로 진행한다

---

전형적인 Blue/Green 절차

1단계: Green 클러스터 준비

• 신규 EKS 클러스터 생성
• 애플리케이션 배포
• 트래픽은 받지 않음
• DB 연결 테스트만 수행

---

2단계: 스키마 확장 (Expand 단계)

기존 코드가 깨지지 않도록 먼저 확장한다.

예:

• 컬럼 추가
• 테이블 추가
• nullable 컬럼 추가
• backward-compatible migration

---

3단계: 트래픽 점진 전환

ALB 또는 Route53 가중치 기반 전환:

• 5% → 25% → 50% → 100%

---

4단계: 모니터링

전환 중 반드시 확인해야 할 지표:

• error rate
• latency
• DB load
• connection 수
• replication lag

---

5단계: 정리 (Contract 단계)

Blue 완전 종료 이후에만 수행한다.

• 불필요한 컬럼 제거
• NOT NULL 적용
• 타입 변경
• 인덱스 정리

이 단계 이후에는 롤백이 사실상 어렵다.

---

핵심 정리

• state를 외부로 분리한 구조는 Blue/Green과 궁합이 가장 좋다
• 무중단 업그레이드의 전제 조건이다
• 스키마 설계가 곧 배포 전략이다

---

3. 3rd-party 서비스가 상태를 가지는 경우

개념

상태를 직접 저장하지 않고, 외부 SaaS 또는 관리형 서비스가 상태를 소유한다.

예:

• Auth0, Cognito
• Stripe, Toss Payments
• Firebase
• 외부 검색 SaaS
• 외부 메시징 서비스
• 외부 API 기반 워크플로

---

특징

• 애플리케이션은 사실상 완전한 stateless
• Blue/Green 난이도가 가장 낮음
• 상태 관리 책임이 외부에 있음

---

무중단 전략

핵심

• 두 클러스터가 동일한 외부 설정 사용
• 동일한 API Key / Secret / Endpoint 사용

절차

1. Green 배포
2. Secret / Config 동일하게 주입
3. health check
4. 트래픽 점진 전환
5. 문제 없으면 Blue 종료

---

주의할 점

• rate limit
• API key 쿼터
• webhook 중복 수신
• callback URL 다중 등록 여부
• idempotency 미지원 API

---

핵심 요약

3rd-party 기반 구조는 배포 난이도는 낮지만,
장애 제어권 역시 외부에 있다는 점을 항상 고려해야 한다.

계약, 쿼터, 콜백 설계가 사실상 “상태 설계”가 된다.

---

전체 요약 표

구분상태 위치무중단 가능성주요 리스크권장 전략

Pod 내부	컨테이너 / PV	낮음	볼륨 공유 불가	짧은 중단 + 재기동
데이터 레이어	외부 DB / 큐	높음	스키마 호환성	expand / contract
3rd-party	외부 SaaS	매우 높음	rate limit / 중복 호출	idempotency

---

마무리

EKS Blue/Green 업그레이드에서 “stateful 서비스”는 하나의 개념이 아니다.
상태가 어디에 존재하느냐에 따라 완전히 다른 문제가 된다.

• Pod 안에 상태가 있으면 운영 절차의 문제이고
• 데이터 레이어에 있으면 설계의 문제이며
• 3rd-party라면 계약과 인터페이스의 문제다

결국 무중단 배포는 Kubernetes 기술 문제가 아니라,
데이터 소유권과 변경 흐름을 어떻게 설계했는가의 문제다.