기존 KubeRay에 관측·작업 제출 더한 Anyscale Connect

최윤서 기자 2026.10.28 08:46

Anyscale이 KubeRay Connect를 비공개 프리뷰로 공개했다. 기존 KubeRay 클러스터를 유지하면서 작업 관측과 제출 기능을 제공한다.

토포AI로 이 기사 더 깊이 읽기

KubeRay 파드 설정에 추가된 관측용 사이드카 / TokenPost.ai

Anyscale이 기존 KubeRay 클러스터에 작업 관측과 제출 기능을 더하는 KubeRay Connect를 비공개 프리뷰로 공개했다. 운영자는 기존 KubeRay 설정과 도구를 유지하면서 Ray 작업 상태를 살펴볼 수 있다.

Anyscale은 2026년 8월 25일 발표에서 Connect가 기존 KubeRay 클러스터에 연결된다고 밝혔다. Connect는 작업 실행을 위한 파드를 직접 만들고 관리하지 않으며, KubeRay가 클러스터를 관리하는 구조에 Anyscale 기능을 더한다. 회사 문서도 Connect가 Ray 클러스터를 직접 생성하거나 관리하지 않는다고 설명한다.

발표 당시 작업 로그와 지표를 보여주는 Observe, 작업 제출과 상태 추적을 지원하는 Orchestrate는 비공개 프리뷰였다. 성능과 비용을 조정하는 Optimize는 출시 예정으로 표시됐다. 비공개 프리뷰는 접근을 신청해야 하는 단계다.

Connect는 기존 KubeRay 설정에 관측용 사이드카를 추가한다. 구성 요소는 △KubeRay 사용자 정의 자원(CR)을 수정하고 상태를 동기화하는 Connector △로그와 지표를 모으는 OpenTelemetry Collector 기반 Cluster Telemetry Gateway △콘솔에 관측 데이터를 제공하는 Observability API다. Anyscale은 발표 당시 Connector가 단일 파드로 운영된다고 밝혔다.

Ray 공식 문서에 따르면 로그는 기본적으로 각 파드의 /tmp/ray/session_*/logs에 저장되며, Ray 자체는 로그 보관 서비스를 제공하지 않는다. 파드나 노드가 갑자기 종료된 뒤에도 원인을 조사하려면 별도의 로그 수집·보존 수단이 필요하다.

Anyscale은 같은 날 GPU Health Observability도 비공개 프리뷰로 발표했다. 회사는 GPU의 XID·ECC 오류, 클록과 메모리 상태를 Ray 작업·노드 정보와 연결해 보여준다고 설명했다. 실제 운영 환경에서 장애 진단 시간이나 가용성이 얼마나 달라지는지는 제시하지 않았다.

Ray의 KubeRay 오토스케일러는 작업·액터의 자원 수요에 따라 Ray 파드 수를 조정한다. CPU·메모리 사용률을 기준으로 하는 일반적인 Kubernetes HPA와 조정 기준이 다르다. Ray 문서는 GPU와 메모리의 자원 요청값·제한값을 가능한 한 같게 설정하라고 권고한다.

헤드 노드는 기본 설정에서 단일 장애 지점이다. Ray는 클러스터 오토스케일러의 노드 통합 과정에서 헤드 파드가 퇴거되지 않도록 설정하는 방법을 안내하지만, 이 설정이 노드 고장까지 막지는 않는다고 명시한다.

Ray 문서는 GCS 장애 허용 기능을 구성한 경우 헤드 노드 복구 중에도 Serve 애플리케이션이 작업을 처리할 수 있다고 설명한다. 다만 복구가 진행되는 동안 액터·워커 장애 대응과 클러스터 갱신에는 제한이 생길 수 있다.