엔드포인트 오토스케일링

서비스 중인 엔드포인트에 트래픽이 들쭉날쭉하면, 그때마다 사람이 직접 레플리카 수를 조절하기는 어려워요. Inference Endpoints의 오토스케일링은 트래픽과 하드웨어 사용률에 따라 엔드포인트의 레플리카 수를 자동으로 늘리고 줄여 주는 기능이에요. 덕분에 변동하는 워크로드를 자연스럽게 처리하면서도 비용을 아끼고 가용성을 유지할 수 있어요.

엔드포인트 카드의 "Settings" 탭에서 오토스케일링 설정을 찾을 수 있어요. 관련 지표를 쫓아가고 싶다면 이 카테고리의 Analytics 문서에서 로그·메트릭 추적 방법을 함께 읽어 보는 걸 추천해요.

Scale to Zero

Scale to zero는 일정 시간(기본 1시간) 동안 요청이 없으면 엔드포인트를 유휴 상태로 만드는 기능이에요. 비용을 최대한 아끼고 싶거나 워크로드가 간헐적일 때 특히 유용하죠.

다만 레플리카를 0으로 만들었다는 건, 새 요청이 들어올 때 콜드 스타트(cold start) 기간이 생긴다는 뜻이에요. 새 레플리카가 초기화되는 동안 프록시가 상태 코드 503을 응답할 수 있구요. 이걸 피하고 싶다면 요청에 X-Scale-Up-Timeout 헤더를 추가하는 방법이 있어요. 엔드포인트가 스케일업 중이면 프록시가 레플리카가 준비될 때까지 요청을 잡고 있다가, 지정한 시간이 지나면 타임아웃을 내는 거예요. 예를 들어 X-Scale-Up-Timeout: 600은 600초를 기다리라는 뜻이에요.

스케일업은 모델에 따라 몇 분이 걸릴 수 있어요. 그래서 반응성이 중요한 애플리케이션이라면 요청 한 건 때문에 0→1 스케일업에 의존하는 건 보통 추천하지 않아요.

레플리카 수

이 설정으로 최대·최소 레플리카 수를 바꿀 수 있어요. 즉 비용의 천장(최대)과 바닥(최소)을 손으로 잡아두는 셈이에요. 보통 최소값은 가장 트래픽이 적을 때도 사용자가 납득할 만한 속도로 서빙이 되도록, 최대값은 예산 안에 들면서도 최고 트래픽 때도 사용자를 서빙할 수 있도록 정해요.

주의: scale to zero를 켜면 최소 레플리카 수는 반드시 0이어야 해요.

오토스케일링 전략

오토스케일링이 제대로 작동하려면 언제 늘리고 줄일지 알려주는 신호가 있어야 해요. 여기엔 두 가지 전략이 있어요.

하드웨어 사용률 기반 스케일링

가속기 종류에 따라 스케일링 기준이 달라져요.

CPU: 모든 레플리카의 평균 CPU 사용률이 임계값(기본 80%)에 도달하면 새 레플리카가 추가돼요.
GPU: 모든 레플리카의 평균 GPU 사용률이 1분 윈도우에서 임계값(기본 80%)에 도달하면 새 레플리카가 추가돼요.

스케일업은 매분, 스케일다운은 매 2분마다 진행된다는 점도 알아 두면 좋아요. 이 주기는 반응성과 안정성 사이의 균형을 맞추기 위한 것이고, 스케일다운 후에는 300초의 안정화(스테빌라이제이션) 시간이 적용돼요. 하드웨어 사용률 지표는 Analytics 탭에서도 추적할 수 있어요.

대기 요청(pending requests) 기반 스케일링

하드웨어 사용률은 항상 실제 요청보다 한 박자 늦는 지표예요. 더 앞서 가는 지표가 바로 대기 요청이에요.

Pending requests는 아직 HTTP 상태를 받지 못한 요청이에요. 진행 중(in-flight) 요청과 처리 중인 요청을 합친 개념이죠.
기본적으로 지난 20초 동안 레플리카당 대기 요청이 1.5개를 넘으면 오토스케일링 이벤트가 발생해 레플리카가 추가돼요. 이 임계값은 엔드포인트 설정에서 요구에 맞게 조정할 수 있어요.

하드웨어 지표처럼 대기 요청 수도 Analytics 탭에서 추적할 수 있어요.

더 알아보기

Analytics 문서에서 오토스케일링이 쓰는 하드웨어 사용률·대기 요청 지표를 추적하는 방법을 볼 수 있어요
Foundations 문서에서 엔드포인트의 기본 개념을 복습해 보세요