복세편살 개발라이프
프로그래밍 & IT › Infra

AWS GPU 운영 정리: ECS GPU 자동 복구와 CloudWatch 가속기 인사이트

· 읽는 시간 5분

목차
  1. 3줄 요약
  2. 무엇이 바뀌었나
  3. ECS Managed Instances GPU 자동 복구
  4. CloudWatch accelerated compute insights
  5. 운영 관점에서 볼 점
  6. 적용해 보려면
  7. 정리
  8. 참고 자료

3줄 요약

  • ECS Managed Instances는 NVIDIA DCGM 기반 GPU 상태 감시와 자동 복구를 기본으로 켜 둡니다. 심각한 하드웨어 장애가 나면 교체 인스턴스를 먼저 띄우고 문제 인스턴스를 종료합니다 [1].
  • 앱 재시작으로 해결되는 GPU 오류는 별도 CloudWatch 지표로 집계됩니다. 그래서 인스턴스 교체가 필요한 하드웨어 장애와 나눠 볼 수 있습니다 [1].
  • KubeCon North America 2026에서 공개된 CloudWatch accelerated compute insights는 EKS의 GPU·Trainium·Inferentia를 팀과 워크로드 단위로 보여 주고, 낭비 비용을 추정합니다 [2].

무엇이 바뀌었나

ECS Managed Instances GPU 자동 복구

지금까지 직접 관리하는 GPU 플릿에서는 여러 단계를 손수 엮어야 했습니다. NVIDIA SMI를 주기적으로 조회하는 스크립트, CloudWatch 알람, 로드 밸런서에서 인스턴스를 빼는 Lambda, 인스턴스 교체 절차가 대표적입니다 [1]. AWS는 이런 단계마다 복잡도와 지연이 늘어난다고 설명합니다 [1].

ECS Managed Instances는 모든 GPU 인스턴스에서 DCGM 호스트 엔진을 실행합니다. DCGM은 NVIDIA의 데이터센터용 GPU 관리 도구입니다. 이 엔진이 XID 오류 코드를 감시하는데, XID는 GPU 드라이버가 장애를 알리는 오류 번호입니다 [1]. 사이드카나 별도 에이전트는 필요 없습니다 [1]. 자동 복구는 GPU 인스턴스 타입을 쓰는 용량 공급자(capacity provider) 단위에서 기본으로 켜집니다 [1].

심각한 XID가 감지되면 다음 순서로 처리됩니다 [1].

  1. 인스턴스를 IMPAIRED로 표시합니다.
  2. DRAINING으로 바꿔 새 태스크가 배치되지 않게 합니다.
  3. 정상 교체 인스턴스를 프로비저닝해 클러스터에 등록합니다.
  4. 기존 태스크를 stopTimeout에 맞춰 정상 종료합니다.
  5. 모든 태스크가 멈추면 문제 인스턴스를 종료합니다.

상태가 바뀔 때마다 EventBridge 이벤트가 발행됩니다 [1]. 이벤트에는 드레이닝 사유 코드가 담겨 있어, 자동 복구로 인한 드레인인지 수동 드레인이나 예정된 교체인지 구분할 수 있습니다 [1].

앱 재시작으로 해결되는 오류(RESTART_APP 분류)도 따로 다룹니다. XID 13, XID 31 같은 오류가 여기에 속합니다 [1]. 이런 오류는 TaskGPURestartAppXidCount(태스크별)와 ContainerGPURestartAppXidCount(컨테이너별) 지표로 집계됩니다 [1].

CloudWatch accelerated compute insights

EKS 클러스터의 가속기마다 쿠버네티스 메타데이터가 붙습니다. 파드, 네임스페이스, 노드, 노드 그룹, 사용자 정의 라벨(팀, 애플리케이션)이 그 예입니다 [2]. NVIDIA GPU와 Inferentia 지표는 공통 스키마로 정규화되어 하나의 Accelerator Health 화면에 모입니다 [2].

GPU 분할 방식도 자동으로 인식합니다. MIG로 나눈 GPU는 조각별 사용률과 메모리를 보여 주고, DRA와 타임 슬라이싱은 디바이스 라벨로 알아봅니다 [2]. 낭비 비용은 세 가지로 나눠 추정합니다 [2].

  • 과한 인스턴스 사용(라이트사이징 기회)
  • 학습 효율 저하(낮은 MFU)
  • 하드웨어 용량보다 적은 추론 처리량

운영 관점에서 볼 점

  • 호환성·업그레이드: 자동 복구는 기본값이라 애플리케이션 코드를 바꾸거나 운영자가 손댈 필요가 없습니다 [1]. 끄고 싶을 때만 설정하면 됩니다 [1]. 다만 정확한 설정 키와 교체를 일으키는 XID 전체 목록은 이번 자료 발췌에 없습니다. 공식 문서에서 확인하는 것이 안전합니다.
  • 종료 시간: 기존 태스크는 stopTimeout을 지키며 멈춥니다 [1]. 추론 요청이 길다면 이 값이 처리 중인 작업을 마치기에 충분한지 점검할 필요가 있습니다.
  • 비용: 교체 인스턴스를 먼저 띄우는 start-before-stop 방식입니다 [1]. 따라서 교체 중에는 잠시 인스턴스가 하나 더 떠 있을 수 있습니다. 또 insights의 비용 수치는 운영 판단용 추정치일 뿐입니다 [2]. 정식 비용 집계는 Cost Explorer와 Cost and Usage Report를 계속 써야 합니다 [2]. insights 자체의 요금은 자료에서 확인되지 않았습니다.
  • 자동화 통제: 상태 이벤트를 AWS DevOps Agent로 보내 조사를 맡길 수 있습니다 [2]. 발표에 따르면 에이전트는 기본적으로 근거를 붙인 조치 계획을 내놓고 사람의 승인을 기다립니다 [2].

적용해 보려면

  1. GPU 인스턴스 타입으로 ECS Managed Instances 용량 공급자를 구성합니다. 자동 복구는 이때 자동으로 켜집니다 [1].
  2. 컨테이너 인스턴스 상태 변경 이벤트를 받는 EventBridge 규칙을 만듭니다. 드레이닝 사유 코드로 자동 복구 건만 걸러 온콜 채널에 알리면 됩니다 [1].
  3. RESTART_APP 지표 두 개에 알람을 걸어, 일시적인 GPU 오류를 하드웨어 장애와 나눠 추적합니다 [1].
  4. AWS 글은 DCGM 장애 주입(fault injection)으로 전체 흐름을 안전하게 검증하라고 안내합니다 [1]. 운영 전에 테스트 환경에서 확인해 두는 것이 좋습니다.
  5. EKS에서는 워크로드에 팀·애플리케이션 라벨을 일관되게 붙입니다. 그래야 insights에서 사용량을 팀별로 나눠 볼 수 있습니다 [2]. 구체적인 활성화 절차는 공식 문서를 따르면 됩니다.

정리

ECS 쪽 변화는 GPU 하드웨어 장애 대응을 플랫폼이 기본으로 맡게 됐다는 점입니다 [1]. 운영자는 이벤트를 받아 알림을 정리하고 stopTimeout을 점검하는 일에 집중하면 됩니다. EKS 쪽은 "누가, 얼마나 효율적으로 GPU를 쓰는가"를 디바이스 단위까지 볼 수 있는 길이 열렸습니다 [2]. 다만 비용 수치는 추정치이고 일부 세부 설정은 아직 확인되지 않았습니다. 도입 전에 공식 문서로 교차 확인하기를 권합니다.

참고 자료

  1. Automatically recover from GPU failures with Amazon ECS Managed Instances · AWS Containers, 2026-11-12
  2. Expensive accelerators, no workload-level visibility: Introducing Amazon CloudWatch accelerated compute insights · The New Stack, 2026-11-11

#Amazon ECS Managed Instances#Amazon CloudWatch#NVIDIA DCGM#Amazon EKS#Amazon EventBridge#GPU 운영

Infra의 다른 글