Red Hat OpenShift Service on AWS는 Machine Learning을 위한 Capacity Reservations 및 Capacity Blocks를 지원합니다.

발행: (2025년 12월 3일 오전 09:00 GMT+9)
6 min read

Source: Red Hat Blog

왜 보장된 용량이 중요한가

특정 가용 영역(AZ)에서 특정 인프라 유형에 대한 보장되거나 중단 없는 접근을 유지하는 것은 여러 중요한 시나리오에서 필수적입니다:

  • GPU 기반 가속 컴퓨팅 워크로드 – AI/ML 팀이 학습, 파인튜닝 또는 추론을 수행할 때 GPU 인스턴스에 대한 중단 없는 접근이 필수적입니다. 용량 예약을 통해 이러한 시간에 민감하고 자원 집약적인 작업에서 컴퓨팅 가용성 위험을 없앨 수 있습니다.
  • 계획된 스케일링 이벤트 – 피크 트래픽 시즌, 주요 제품 출시, 혹은 예정된 배치 처리 작업을 프로비저닝 지연 없이 자신 있게 지원합니다.
  • 고가용성 및 재해 복구 – 여러 AZ에 워크로드를 배포하거나 지역 간 재해 복구 프로토콜을 실행할 때 용량을 보장함으로써 복원력을 강화합니다.

ML을 위한 용량 예약 및 용량 블록

  • Amazon EC2 용량 예약은 특정 AZ에서 EC2 인스턴스에 대한 컴퓨팅 용량을 원하는 기간 동안 예약할 수 있게 해줍니다.
  • ML용 용량 블록은 향후 날짜에 GPU 기반 가속 컴퓨팅 인스턴스를 예약하여 짧은 기간의 ML 워크로드를 지원합니다.

호스팅된 컨트롤 플레인(HCP) 클러스터에 대한 용량 예약을 지원함에 따라, 플랫폼 관리자는 AWS에서 이미 예약된 용량을 직접 활용하는 ROSA 머신 풀을 생성할 수 있습니다.

ROSA와 함께 용량 예약을 활용하기 위한 주요 모범 사례

  • AZ, 인스턴스 유형 및 용량 사전 계획 – 예약된 용량과 ROSA 머신 풀 속성(VPC 서브넷, 노드 복제 수, 인스턴스 유형) 사이에 정확히 일치하도록 합니다. AWS 용량 예약 상태가 활성이 될 때까지 해당 예약을 사용하는 ROSA 머신 풀을 프로비저닝하지 마세요.
  • 적절한 인스턴스 매칭 기준 선택 – AWS는 ODCR에 대해 두 가지 매칭 기준을 제공합니다: “Open”“Targeted.” ROSA 클러스터에서 예약된 용량만을 독점적으로 사용해야 하는 워크로드의 경우, Targeted 기준을 강력히 권장합니다. ODCR은 “사용하지 않으면 소멸” 원칙으로 동작하며, 활용 여부와 관계없이 온디맨드 요금이 적용됩니다.
  • 예약 용량 사용 방식을 제어 – ROSA에서는 머신 풀이 예약이 소진될 경우 온디맨드 인스턴스로 전환할지, 아니면 즉시 실패하도록 할지 정의할 수 있습니다.
  • 구매 및 할당 중앙화 – 여러 AWS 계정을 보유한 조직은 ODCR 구매를 중앙에서 관리하고 AWS Resource Access Manager를 통해 멤버 계정에 할당할 수 있습니다. ROSA는 클러스터가 생성된 AWS 계정에 공유된 용량 예약을 완전히 지원하므로 재무 관리가 간소화됩니다.
  • 예약 활용률을 사전적으로 모니터링 – 예약이 여러 워크로드나 계정에 공유될 수 있기 때문에 지속적으로 활용률을 모니터링하세요. 잠재적인 소진을 대비해 계획하면 중요한 워크로드에 대한 ROSA 클러스터 노드 가용성 중단을 방지할 수 있습니다.

추가 자료

  • AWS 문서에서 용량 예약 및 ML용 용량 블록을 구매하는 방법을 확인하세요.
  • ROSA 클러스터에서 머신 풀을 관리하고 용량 선호도를 설정하는 방법은 ROSA 문서 Managing Nodes 장을 참고하세요.
  • ROSA 제품 페이지에서 ROSA 시작 방법을 확인하세요.
Back to Blog

관련 글

더 보기 »

Friday Five — 2025년 12월 5일

!1https://www.redhat.com/rhdc/managed-files/styles/default_800/private/number-1.png.webp?itok=pDWx13kK Red Hat이 AWS 전반에 걸쳐 향상된 AI 추론을 제공한다 Red H...

llm-d와 vLLM을 풀어보자: 올바른 길에

조직들이 large language model LLM 워크로드를 프로덕션화하기 위해 경쟁함에 따라, 추론의 복잡성을 해결하기 위해 두 개의 강력한 open‑source 프로젝트가 등장했습니다.