Amazon EKS에서 탄력성의 기본: 프로덕션에서 장애에 강인한 워크로드 설계 방법

Source: Dev.to

🎯 1. 쿠버네티스와 EKS 컨텍스트에서의 복원력(Resilience)이란?

복원력은 시스템이 다음을 수행할 수 있는 능력입니다:

• 장애가 발생해도 계속 운영
• 자동으로 복구
• 제어된 방식으로 성능 저하
• 신뢰성 및 가용성 유지

쿠버네티스/EKS에서는 다음과 같이 구현됩니다:

• 멀티 AZ
• 자동 스케일링
• readiness 및 liveness 프로브
• 리소스 제한
• 안전한 롤아웃
• 인프라 자동 스케일링

복원력은 절대 실패하지 않는 것이 아니라, 우아하게 실패하는 것을 의미합니다.

🏗️ 2. 멀티 AZ 아키텍처와 자동 복구(Auto‑Healing)

EKS는 여러 가용 영역에 걸쳐 클러스터를 쉽게 배포하도록 하여 중단 위험을 크게 줄여줍니다.

왜 중요한가요?

• 하나의 AZ가 장애가 나도 → 파드가 다른 AZ에서 계속 실행됩니다.

노드 장애는 자동으로 다음을 통해 처리됩니다:

• Managed Node Groups 자동 복구
• 쿠버네티스 자동 복구(Auto‑healing)

모범 사례

• 클러스터에 2~3개의 AZ 사용
• Managed Node Groups 또는 EKS Auto Mode 사용 권장.
  (EKS Auto Mode에 대한 자세한 글)
• Pod Anti‑Affinity를 설정해 파드를 노드/AZ에 고르게 분산

🔧 3. 프로브: 애플리케이션 상태 보장

Liveness Probe

정지 상태를 감지합니다. 실패 시 → 쿠버네티스가 파드를 재시작합니다.

Readiness Probe

파드가 트래픽을 받을 준비가 되었는지를 정의합니다.

Startup Probe

시작이 오래 걸리는 애플리케이션에서 liveness의 false positive를 방지합니다.

모범 사례

• 항상 적절한 healthcheck를 정의
• readiness와 liveness에 동일한 URL을 사용하지 않음
• initialDelay, timeout, period 등 타이밍을 조정

📦 4. Requests, Limits 및 QoS

클러스터에서 발생하는 대부분의 사고는 리소스 사용 오류에서 비롯됩니다:

• 메모리 과다 사용
• CPU 과다 사용
• OOMKill
• 스로틀링

Requests

필요한 최소 리소스 양.

Limits

파드가 사용할 수 있는 최대 리소스 양.

QoS

• Guaranteed
• Burstable
• BestEffort

모범 사례

• requests와 limits를 항상 설정
• OOMKill 및 스로틀링을 모니터링
• 성숙한 클러스터에서는 Vertical Pod Autoscaler 검토

📈 5. 자동 스케일링: HPA, Karpenter 및 EKS Auto Mode

복원력은 자동 적응도 포함합니다.

HPA (Horizontal Pod Autoscaler)

다음 기준으로 파드를 스케일링:

• CPU
• 메모리
• 레이턴시
• 사용자 정의 메트릭(Prometheus 등)

인프라: Karpenter 또는 EKS Auto Mode

• Karpenter는 스마트한 노드 프로비저닝을 제공
• EKS Auto Mode는 이를 한 단계 끌어올림:
  • 파드 기반 자동 프로비저닝
  • 멀티 AZ 지원
  • 노드 그룹 설정 불필요
  • 높은 복원력 + 비용 절감

모범 사례

• HPA와 Auto Mode/Karpenter 조합 사용
• Pod Disruption Budgets 설정
• 트래픽을 받기 전에 readiness 확인 보장

🔄 6. 복원력 있는 배포: Rolling, Blue/Green 및 Canary

Rolling Update

점진적 업데이트로 다운타임 없이 배포.

Blue/Green

새 버전은 검증 후에만 트래픽을 받음.

Canary

메트릭 기반으로 새 버전에 트래픽을 점진적으로 전환.

추천 도구

• Argo Rollouts
• AWS App Mesh
• NGINX Ingress Controller

모범 사례

• 파괴적인 변경( breaking changes) 피하기
• Feature Flag 활용
• 롤아웃 각 단계마다 모니터링

🧪 7. 복원력 테스트: 혼돈(Chaos), 부하 및 기능 테스트

Chaos Engineering

도구: ChaosMesh, LitmusChaos, AWS Fault Injection Simulator

주요 시나리오: 노드 장애, 파드 장애, 네트워크 손실, 인위적 레이턴시.

부하 테스트

K6, Locust, Artillery

기능 테스트

Robot Framework, Postman/Newman, Cypress(프론트엔드)

왜 중요한가?
병목, 예상치 못한 동작, 장애 내성 부족을 드러냄.

📊 8. 복원력을 위한 관측성(Observability)

가시성이 없으면 복원력도 없습니다.

메트릭

Prometheus, CloudWatch, OpenTelemetry

로그

Fluent Bit, CloudWatch Logs, OpenSearch

트레이스

X‑Ray, Jaeger, Tempo(Grafana)

모범 사례

• SLO 메트릭(레 이턴시, 오류) 정의
• 파드, 노드, 디플로이먼트 전용 대시보드 구축
• CloudWatch 또는 Alertmanager를 이용한 자동 알림 설정

🛣️ 9. 쿠버네티스 복원력 기본 패턴

• Pod Disruption Budget (PDB)
• Pod Affinity/Anti‑Affinity
• Topology Spread Constraints
• Retry + Exponential Backoff
• Circuit Breaker
• Idempotency
• 명확한 Timeout

이 패턴들은 다음을 방지합니다:

• 장애 연쇄(cascade)
• 리소스 포화
• 서비스 전체 성능 저하

🎯 10. 결론

EKS는 견고한 기반을 제공하지만, 복원력은 다음에 달려 있습니다:

• 아키텍처 패턴
• 운영 관행
• 관측성
• 지속적인 테스트
• DevOps 문화
• 스마트 자동화

이 기본 원칙을 적용하면 다음과 같은 애플리케이션을 만들 수 있습니다:

• 장애를 견디고
• 자동으로 스케일링되며
• 인간 개입 없이 복구되고
• 프로덕션에서 신뢰성을 제공

복원력은 설정이 아니라 지속적인 훈련과 같은 분야입니다.