Blog

EKS에서 EBS 볼륨의 AZ 종속성으로 인해 발생하는 파드 장애 사례

Tags: , , , ,

Amazon EKS에서 Stateful 워크로드를 운영하다 보면, “파드는 떴는데 볼륨이 안 붙는다”는 전형적인 장애를 경험할 때가 있습니다. 특히 멀티 AZ 구성 + EBS(gp3) 기반 PVC 조합에서 한 번쯤 반드시 맞닥뜨리게 되는 문제입니다.

이번 글에서는 실제로 경험했던 RabbitMQ 멀티 AZ 장애 사례를 기반으로,
왜 이런 문제가 발생하는지, 그리고 어떤 방식으로 설계해야 안정적으로 운영할 수 있는지 정리했습니다.

1. 문제 상황 요약: 파드는 살아있는데 왜 볼륨은 안 붙지?

고객사 RabbitMQ 구성은 다음과 같았습니다.

AZ-A
 └─ Node1: RabbitMQ Pod + EBS(gp3) 볼륨(AZ-A 고정)

AZ-B
 ├─ Node1: RabbitMQ Pod
 └─ Node2: RabbitMQ Pod

초기 배포 당시 파드는 정상 동작했지만, 노드 재시작 이후 문제는 나타났습니다.

  • RabbitMQ Pod가 AZ-B 노드에 스케줄됨
  • 하지만 PVC는 AZ-A에 생성된 EBS 볼륨을 사용
  • 결과적으로 파드는 Pending 상태에서 어태치 실패 반복

이때 나타나는 대표적인 이벤트 메시지는 다음과 같습니다.

AttachVolume.Attach failed :
volume is in a different availability zone

멀티 AZ 클러스터인데 왜 이런 문제가 생길까요?

2. 원인: EBS는 “애초에 단일 AZ 리소스”이다

AWS Support에서도 명확하게 정리해준 부분입니다.

✔ EBS 볼륨은 특정 AZ에 존재

  • gp3 / io1 / io2 타입 상관없이
  • 볼륨이 생성된 AZ의 노드에만 Attach 가능

즉,

“멀티 AZ 클러스터”라고 해서
“스토리지도 멀티 AZ”가 되는 건 아니다.

이 구조적 차이를 이해하지 못하면 멀티 AZ 환경에서 Stateful 파드가 쉽게 장애를 일으킵니다.

3. Multi-Attach는 멀티 AZ 기능이 아니다

AWS 문서를 보면 io1/io2 일부 타입에 Multi-Attach라는 기능이 있습니다.

하지만 이것은
→ 동일 AZ 내 여러 EC2 인스턴스에 동시에 Attach 가능한 기능이며,
→ AZ를 넘는 Attach 기능이 아닙니다.

고객사도 여기서 잘못된 기대를 가지고 있었고,
AWS Support가 아래처럼 정확하게 정리했습니다.

“EBS의 단일 AZ 종속성을 완화할 방법은 없습니다.”

즉, io2로 타입을 바꾸어도 AZ cross-attach는 여전히 불가능합니다.

4. 그렇다면 어떻게 설계해야 할까? (현실적인 해결책 2가지)

해결책 1) 파드를 특정 AZ에 고정하기 (Pod Affinity 사용)

가장 현실적인 대응 방법은
파드가 EBS 볼륨이 존재하는 AZ에서만 실행되도록 고정하는 것입니다.

예를 들어 PVC가 AZ-A에 있다면 Pod도 AZ-A의 노드에만 스케줄되도록 설정합니다.

기본적으로 노드에는 아래와 같은 라벨이 있습니다.

topology.kubernetes.io/zone=ap-northeast-2a

Pod 스펙에 Node Affinity를 추가하면 다음과 같이 적용할 수 있습니다.

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values:
                - ap-northeast-2a

이런 경우 적합합니다

  • 해당 Stateful 워크로드가 반드시 특정 EBS 볼륨 하나만 사용해야 할 때
  • 파드를 특정 AZ에서만 운영해도 가용성 측면에서 문제가 없을 때

반대로, RabbitMQ처럼 “멀티 AZ 고가용성이 필수지만 볼륨은 하나만 써야 하는 구조”라면 근본적인 충돌이 생기므로 완전한 해법이 되지는 않습니다.

해결책 2) 멀티 AZ 스토리지가 필요하다면 EFS를 사용하기

만약 서비스 요구사항이 다음과 같다면?

  • 멀티 AZ 분산 운영 필수
  • 노드가 어느 AZ로 스케줄되든 정상적으로 파일을 읽고 써야 함

이 경우 EBS는 구조적으로 맞지 않습니다.

이런 환경에는 EFS가 더 적합합니다.

  • EFS는 멀티 AZ에서 동시에 접근 가능
  • PVC → EFS CSI Driver 연동
  • 파일 시스템 특성이라 EBS처럼 AZ 제한 없음

StorageClass 예시는 아래와 같습니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-XXXXXX
volumeBindingMode: Immediate

단, 주의할 점도 있습니다

  • EBS보다 지연시간(latency)이 높음
  • 초고성능 I/O가 필요한 워크로드(DB 계열)에는 부적합할 수 있음

그래도 “AZ 간 자유로운 스케줄링”이 가장 중요한 요구라면 현재로서는 EFS가 가장 안전한 선택입니다.

5. 교훈

이 사례를 통해 가장 크게 느낀 점은 아래 한 줄로 요약됩니다.

멀티 AZ 클러스터에서 Stateful 워크로드를 운영할 때는
스토리지 특성을 반드시 먼저 확인해야 한다.

  • EBS는 단일 AZ 리소스
  • 멀티 AZ 스캐줄링과 충돌할 수밖에 없음
  • Affinity로 고정하거나, 멀티 AZ 스토리지(EFS)로 전환하는 것 외에는 근본적 해법이 없다

또한 StorageClass volumeBindingMode가 Immediate인 경우
→ 파드 스케줄보다 먼저 볼륨이 AZ에 고정되기 때문에
이러한 문제가 더 쉽게 발생합니다.

6. 마무리

이번 사례는 RabbitMQ였지만,
사실 어떤 Stateful 워크로드라도 동일한 문제를 겪을 수 있습니다.

EKS에서 PVC를 사용하는 모든 서비스는 다음 질문을 먼저 던져야 합니다.

  • “이 볼륨은 어느 AZ에 생성되는가?”
  • “이 파드는 어느 AZ에서 실행 가능한가?”
  • “두 조건이 충돌하지 않는가?”

그 구조적 충돌을 해결하는 방법은 결국 두 가지뿐입니다.

✔ 단일 AZ로 고정 → AZ Affinity

✔ 멀티 AZ가 필수 → EFS로 전환

이 두 가지 원칙만 알고 있어도
멀티 AZ 환경의 스토리지 문제를 훨씬 빠르게 진단하고 대응할 수 있습니다.

Post Views: 26