유휴 GPU에 비용을 지불하지 마십시오. 컴퓨팅을 적시에 프로비저닝하고, 워크로드를 처리한 다음 해체하여 자본 비용을 작업별 운영 비용으로 전환합니다.

귀하의 워크로드가 버스티합니다 — 콘텐츠가 업로드될 때 급증하는 비디오 인코딩 작업, 4시간 동안 8개의 GPU가 필요하다가 아무것도 필요 없는 ML 훈련 실행, 비즈니스 이벤트에 의해 트리거되는 배치 추론 작업, 또는 밤새 실행되는 렌더링 파이프라인과 같은 경우입니다. 귀하는 과도하게 프로비저닝되었거나(80% 시간 동안 유휴 리소스에 비용 지불) 과소하게 프로비저닝되었습니다(피크 시 작업이 몇 시간 동안 대기). 귀하는 필요한 컴퓨팅을 정확히 필요한 시점에 프로비저닝하고, 작업이 완료되면 해제하는 아키텍처가 필요합니다 — "scale to zero"를 GPU 워크로드에 비현실적으로 만드는 콜드 스타트 페널티 없이 말입니다.
Explore more design patterns and system architectures
MicrocosmWorks 고객들은 batch-heavy 또는 주기적인 workload를 가진 경우, on-off 스케일링 구현 후 일반적으로 60-80%의 클라우드 비용 절감을 경험합니다. 이는 compute resources가 24/7이 아닌 active processing windows 동안에만 실행되기 때문입니다. 당사는 실제 usage telemetry를 기반으로 scaling policies를 설계합니다. 예를 들어, 매일 4시간 동안 실행되는 data processing pipeline은 전체 24시간 대신 해당 4시간에 대해서만 비용을 지불합니다. 당사의 architects는 discovery phase 동안 귀사의 workload patterns를 분석하여, 어떠한 구현이 시작되기 전에 정확한 절감액을 예측해 드립니다.
사전 워밍업된 노드 풀의 컨테이너화된 애플리케이션의 콜드 스타트 시간은 2-3초 정도이며, 특수 GPU 인스턴스 또는 대규모 모델 로딩이 필요한 워크로드의 경우 5-10분까지 걸립니다. MicrocosmWorks는 이러한 지연을 최소화하기 위해 여러 기술을 사용합니다. 저희는 과거 트래픽 패턴과 예약된 이벤트를 활용하여 예상 수요가 발생하기 전에 리소스를 미리 준비하는 예측 스케일링을 구현하고, 지연 시간에 민감한 워크로드를 위해 컨테이너 이미지 사전 풀링 및 웜 풀 예약을 사용합니다. 콜드 스타트를 전혀 허용할 수 없는 애플리케이션의 경우, 수요가 발생하면 즉시 공격적으로 확장되는 최소한의 웜 베이스라인을 유지합니다.
MicrocosmWorks는 큐 깊이, CPU 사용률 또는 커스텀 애플리케이션 지표에 의해 트리거되는 공격적인 스케일업 정책과, 쓰레싱을 방지하기 위한 쿨다운 기간을 포함하는 더 점진적인 스케일다운 정책을 결합한 반응형 오토스케일링을 구현합니다. 우리는 스케일업 이벤트 동안 초과 프로비저닝 버퍼를 구성하여, 시스템이 한 번에 하나의 인스턴스씩 수요를 쫓기보다는 지속적인 성장을 예상하도록 합니다. 플래시 세일이나 바이럴 이벤트와 같이 정말 예측 불가능한 스파이크의 경우, 마케팅 또는 운영 캘린더의 이벤트 기반 트리거를 사용하여 용량을 사전 프로비저닝합니다.
MicrocosmWorks는 유휴 기간 동안 컴퓨팅을 0으로 스케일링하고 스토리지는 영구적이고 즉시 사용 가능하게 유지하는 Aurora Serverless, Neon 또는 PlanetScale과 같은 서버리스 데이터베이스 오퍼링을 사용하여 데이터베이스에 온오프 스케일링을 적용합니다. 서버리스 데이터베이스를 사용할 수 없는 상태 저장 워크로드의 경우, 쿼리 부하에 따라 복제본을 추가하고 제거하면서 최소한의 기본 인스턴스는 항상 실행 상태로 유지하는 읽기 복제본 스케일링을 구현합니다. 이 하이브리드 접근 방식은 종료 및 재시작 주기 동안 데이터베이스 상태를 관리하는 복잡성 없이 클라이언트에게 데이터 티어 스케일링의 비용 이점을 제공합니다.
MicrocosmWorks는 Grafana 또는 Datadog 대시보드를 사용하여 인스턴스 수, 스케일링 이벤트 지연 시간, 실패한 스케일링 시도, 그리고 원하는 용량과 실제 용량 간의 격차를 실시간으로 추적하는 포괄적인 스케일링 관측성(observability)을 배포합니다. 저희는 스케일링 실패, 스케일링 상한선이 너무 낮음을 시사하는 지속적인 높은 활용률, 그리고 폭주 스케일링(runaway scaling)을 나타내는 비용 이상(anomaly)에 대해 다중 채널 알림을 구성합니다. 저희 런북(runbook)에는 클라우드 공급업체 인스턴스 제한 도달 또는 특정 가용성 영역(availability zone)에서 용량 부족 오류 발생과 같은 일반적인 실패 모드에 대한 자동화된 문제 해결 기능이 포함되어 있습니다.
온-오프 스케일링 아키텍처는 웜/콜드 풀링, 작업 큐 기반 프로비저닝, 자동 해체를 통해 컴퓨팅 리소스를 관리합니다. 웜 풀은 즉시 사용할 수 있도록 미리 초기화된 소수의 인스턴스를 유지합니다. 콜드 풀은 수요가 웜 풀을 초과할 때 Spot/Preemptible 인스턴스에서 추가 용량을 프로비저닝합니다. 작업 오케스트레이터는 사용 가능한 인스턴스로 작업을 라우팅하고, 진행 상황을 모니터링하며, Spot 강제 종료 시 재시도를 처리하고, 큐가 비워지면 스케일 다운을 트리거합니다. 이 패턴은 콜드 스타트(컨테이너 풀 + 모델 로딩)가 3-10분 걸릴 수 있는 GPU 워크로드에 특히 중요합니다.
이 시스템은 들어오는 작업 요청을 버퍼링하는 작업 큐(SQS, Redis 또는 사용자 지정)를 중심으로 합니다. 스케일링 컨트롤러는 큐 깊이를 모니터링하고 웜 풀에서 먼저 인스턴스를 프로비저닝한 다음 콜드 풀(Spot 인스턴스)에서 프로비저닝합니다. 각 워커 인스턴스는 큐에서 작업을 가져와 워크로드(인코딩, 훈련, 추론)를 실행하고 완료를 보고하며 풀로 돌아가거나 종료됩니다. 체크포인트 관리자는 중간 상태를 S3에 저장하여 Spot 강제 종료를 처리하고, 작업이 처음부터 다시 시작하지 않고 다른 인스턴스에서 재개될 수 있도록 합니다.
| 계층 | 기술 |
|---|---|
| 컴퓨팅 | AWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal |
| 오케스트레이션 | Kubernetes (오토스케일링을 위한 Karpenter), AWS Batch, 사용자 지정 작업 오케스트레이터 |
| 작업 큐 | AWS SQS, BullMQ (Redis), Temporal, Celery |
| 스토리지 | S3 (체크포인트, 모델 아티팩트), NVMe (모델 캐시), EFS (공유 작업 공간) |
| 모니터링 | CloudWatch/Prometheus (큐 깊이, 인스턴스 활용률, 작업 지연 시간), 사용자 지정 비용 대시보드 |
| 사용 시점 | 피해야 할 시점 |
|---|---|
| 워크로드가 버스티한 경우 — 피크 수요가 평균 수요의 5배 이상 | 트래픽이 꾸준하고 예측 가능한 경우 — 적절한 크기의 Reserved Instances가 더 저렴 |
| 유휴 상태일 때 비용이 많이 드는 GPU/고성능 컴퓨팅 작업 | 워크로드가 Serverless (Lambda)에 적합한 경량 CPU 처리인 경우 |
| 콜드 풀 프로비저닝을 위해 1-5분 콜드 스타트를 허용할 수 있는 작업 | 초미만 작업 시작 지연 시간이 필요한 경우 — 상시 가동 인프라가 필요합니다 |
| 비용 최적화가 주요 관심사이며 Spot 가격 책정이 60-90% 절감 효과를 제공하는 경우 | Spot 중단이 체크포인팅으로 완화할 수 없는 데이터 손실을 유발할 수 있는 경우 |
MW는 "작업당 비용" 관점에서 온-오프 스케일링을 설계합니다. 우리는 다양한 스케일링 전략에 걸쳐 한 단위의 작업(하나의 비디오, 한 번의 훈련 실행, 한 번의 배치 추론)을 처리하는 총 비용을 모델링하고, 필요한 지연 시간 SLA에서 비용을 최소화하는 전략을 선택합니다. 우리의 구현에는 작업당 비용, 인프라 활용률, Spot 절감액을 보여주는 실시간 비용 대시보드가 포함됩니다. 우리는 Reserved Instances에 비해 비디오 처리 비용을 70% 절감한 온-오프 GPU 인프라와, 4시간 훈련 실행을 위해 64개의 GPU를 프로비저닝하고 자동으로 해제하는 ML 훈련 클러스터를 구축했습니다.
보안은 출시 후 추가하는 기능이 아닙니다. 그것은 아키텍처의 속성입니다 — 시스템이 보안을 위해 설계되었거나 그렇지 않거나.