YAML과 kubectl 없는 Ray 클러스터 생성 및 관리

SageMaker Studio 콘솔에서 Kubernetes 매니페스트 작성이나 `kubectl` 명령 없이 Ray 클러스터를 직접 생성하고 관리할 수 있다. 기존에는 Ray를 Kubernetes 환경에서 실행하려면 YAML 매니페스트 작성과 포트 포워딩 설정이 필수였으나, 이번 업데이트로 인프라 설정 시간을 단축하고 개발 환경 구축 과정을 단순화했다.

구체적인 생성 과정은 SageMaker Studio 내 HyperPod 메뉴의 Tasks 탭에서 RayCluster 타입을 선택하는 것으로 시작한다. 생성 양식에서 클러스터 이름, 헤드 및 워커 노드의 인스턴스 유형, 워커 수, 컨테이너 이미지를 입력하여 클러스터를 구성한다. 콘솔 화면에서는 운영 중인 Ray 클러스터의 상태와 인스턴스 유형, 제어 동작을 실시간으로 확인할 수 있어 모델 학습과 튜닝에 더 많은 시간을 할애할 수 있다.

기본 컨테이너 이미지로는 Ray가 사전 설치된 SageMaker Distribution이 제공된다. AWS가 취약점 패치와 소프트웨어 업그레이드를 주기적으로 관리하므로 사용자는 이미지 유지보수 부담 없이 보안 환경을 유지할 수 있다. 특정 라이브러리나 추가 의존성이 필요한 경우 사용자가 정의한 커스텀 컨테이너 이미지를 지정해 전용 환경을 구축할 수도 있다.

고급 설정이 필요한 사용자를 위해 Studio 내에 인라인 YAML 에디터가 제공되어 전체 Kubernetes 매니페스트를 직접 수정할 수 있다. 클러스터의 생명주기 관리는 Kubernetes용 Ray 오퍼레이터인 KubeRay를 기반으로 수행된다. KubeRay는 HyperPod의 태스크 거버넌스와 통합되어 관리자가 Ray 워크로드의 컴퓨팅 쿼터와 스케줄링 우선순위를 설정할 수 있도록 돕는다. 또한 로컬 환경의 `kubectl` 포트 포워딩 없이도 접근 가능한 보안 원격 엔드포인트 설정 기능을 지원해 네트워크 설정의 복잡함을 제거했다.

JupyterLab과 Code Editor의 네이티브 Ray 연결 방식

데이터 사이언티스트는 SageMaker Studio의 JupyterLab이나 Code Editor 공간을 HyperPod Ray 클러스터에 연결해 제로 컴퓨팅 워커 노드로 참여시킬 수 있다. 이 방식은 IDE 워크스페이스가 클러스터의 일부로 편입되어 노트북 환경에서 네이티브 Ray 드라이버 접근 권한을 직접 확보하는 구조다. 공간 생성 단계에서 대상 클러스터를 선택하고 공간을 재시작한 뒤, 아래 코드를 호출하여 클러스터에 접속한다.

ray.init(address="auto")

연결이 완료되면 사용자는 헤드 노드에서 작업하는 것과 동일하게 분산 워크로드를 실행하고 제어할 수 있다.

런타임 시점에 Python 의존성을 주입하는 `runtime_env` 파라미터를 활용하면 컨테이너 이미지를 매번 다시 빌드하지 않고도 필요한 라이브러리를 즉시 반영할 수 있다. 또한 `ScalingConfig` 설정을 통해 노트북 내에서 GPU 워커 수를 실시간으로 조정할 수 있다. 예를 들어 단일 워커로 프로토타이핑을 수행하다가 설정 파일 수정만으로 4개의 GPU 워커로 확장해 대규모 학습을 시작할 수 있다. 분산 학습 중에도 노트북은 인터랙티브한 상태를 유지하므로, 학습 진척도 모니터링과 하이퍼파라미터 수정, 결과물 검토를 노트북 하나로 수행한다.

운영 환경의 워크로드는 `toolkit-for-ray-on-sagemaker-ai` 파이썬 패키지를 이용해 Studio, 개인 노트북, 또는 CI/CD 파이프라인에서 원격으로 제출한다.

from sagemaker_ray import RayJobSubmitter

toolkit-for-ray-on-sagemaker-ai를 통한 원격 작업 제출

submitter = RayJobSubmitter(cluster_id="your-cluster-id")

submitter.submit(entrypoint="train.py")

이 패키지는 IAM 인증을 기반으로 EKS API 자격 증명을 자동 생성하고 엔드포인트 해석 과정을 처리한다. 사용자는 표준 Ray 작업 제출 API를 그대로 사용하면서, 내부적으로는 SageMaker 환경을 인식하는 주소 해석기를 통해 보안이 유지된 상태로 원격 작업을 수행한다.

수동 설정에서 원클릭 가시성 확보로의 전환

HyperPod Observability EKS 애드온을 적용하면 Ray 헤드와 워커 포드를 자동으로 검색해 메트릭 수집을 시작한다. 기존에는 Amazon Managed Service for Prometheus와 Amazon Managed Grafana를 연결하기 위해 Helm 차트 설치, PodMonitor 및 ServiceMonitor 생성, SigV4 서명을 위한 IAM 역할 설정 등 다단계 수동 과정을 거쳐야 했으나, 이제는 애드온 설치만으로 수집 환경이 자동 구축된다.

Amazon Managed Grafana 내부에 Ray 전용 폴더가 생성되며 Ray Core, Ray Data, Ray Train, Ray Serve로 구성된 4종의 사전 구축 대시보드가 자동으로 배치된다. 사용자는 JSON 파일을 수동으로 임포트하거나 스크레이프 타겟을 개별 설정할 필요가 없다. 애드온이 포드의 메트릭 엔드포인트를 직접 스캔해 데이터를 수집하며, 각 대시보드는 특정 Ray 클러스터를 기준으로 메트릭을 필터링해 다중 클러스터 환경에서도 개별 워크로드 상태를 식별한다. 클러스터 목록에서 'Open Grafana' 액션을 클릭하면 해당 클러스터의 지표 화면으로 즉시 이동한다.

이 체계는 기존 HyperPod 인프라 모니터링 환경과 통합되어, GPU 사용량, EFA 상태, 태스크 거버넌스 지표가 표시되는 대시보드와 동일한 위치에서 Ray 워크로드 메트릭을 확인할 수 있다. 인프라 하드웨어 상태와 Ray 애플리케이션 실행 상태를 한 곳에서 대조해 관리함으로써 도구 전환 없이 클러스터 건강 상태와 워크로드 성능을 동시에 관리한다.

파운데이션 모델 학습·서빙의 복원력과 효율 개선

대규모 모델 학습 시 하드웨어 장애가 발생하면 SageMaker HyperPod가 결함 노드를 상시 모니터링하여 자동으로 대체한다. 이때 Ray는 기존 워커 포드를 새 노드에 다시 배치하는 재스케줄링을 수행한다. 또한 작업 정체를 감지하는 hung job detection 기능을 통해 운영자가 직접 개입해 노드를 교체하고 작업을 재시작해야 하는 부담을 줄여 학습 연속성을 확보한다.

복구 속도를 높이기 위해 HyperPod 분산 계층형 스토리지 기반의 tiered checkpointing을 지원한다. 학습 중 주기적으로 저장하는 체크포인트 데이터를 계층형 스토리지에 분산 저장하여 장애 발생 후 최신 지점에서 빠르게 재개한다. 이는 수백 대 이상의 노드가 연결된 대규모 클러스터에서 체크포인트 파일 입출력 병목 현상을 줄여 복구 시간을 단축한다. 학습 코드에 최신 체크포인트 재개 로직이 포함되어 있다면 중단 시점부터 즉시 작업을 이어갈 수 있다.

모델 서빙 단계에서는 SageMaker JumpStart 통합을 통해 모델 가중치를 Ray Serve 엔드포인트로 직접 로드한다. 별도의 가중치 이동 과정을 생략해 배포 시간을 단축하고 인프라 복잡도를 낮춘다. 특히 롱 컨텍스트 요청 처리 시 필요한 KV 캐시를 계층형 스토리지로 오프로딩하여 GPU 메모리 점유율 상승으로 인한 서빙 중단을 방지하고, 더 긴 입력값을 안정적으로 처리한다.

한국 AI 실무자를 위한 인프라 운영 관점의 의미

오픈소스 KubeRay 및 표준 Ray API와 호환되어 기존 스크립트 수정 없이 실행 가능하다. 표준 API를 그대로 유지하므로 기존에 검증된 학습 및 서빙 코드를 수정 없이 HyperPod로 옮겨올 수 있어, 마이그레이션 공수와 인프라 교체 리스크를 최소화한다. 개발자는 인프라의 세부 구현 방식에 구애받지 않고 모델 로직에만 집중할 수 있다.

인프라 관리자는 HyperPod 작업 거버넌스를 통해 Ray 워크로드의 컴퓨팅 쿼타와 우선순위를 제어한다. 각 워크로드에 명확한 자원 한도를 설정하고 중요도에 따라 우선순위를 부여함으로써, 특정 팀의 대규모 실험이 전체 자원을 점유해 다른 작업이 대기하는 자원 충돌 상황을 방지한다. 이를 통해 조직 전체의 GPU 가동률을 최적화하면서 개별 팀의 실험 속도를 보장한다.

또한 Docker 이미지 재빌드와 `kubectl` 포트 포워딩 같은 반복적인 운영 태스크가 제거된다. 라이브러리 추가나 버전 변경 시 이미지를 다시 빌드하고 푸시하는 데 소요되던 수십 분의 시간과, 대시보드 확인을 위해 매번 터미널에서 세션을 유지해야 했던 번거로움이 사라진다. 이러한 단순 반복 작업의 제거는 엔지니어가 인프라 설정이 아닌 모델 튜닝과 실험에 더 많은 시간을 쓰게 만든다.

상세한 구축 절차는 Ray on HyperPod getting started guide에서 확인 가능하다. Amazon EKS 오케스트레이션이 설정된 SageMaker HyperPod 클러스터와 SageMaker Studio 도메인이 사전에 구축되어 있어야 한다. K8s 운영 지식 없이도 분산 학습 환경을 구축할 수 있어 인프라 설정 시간이 단축되고 모델 실험 주기가 빨라진다.