Serverless Computing

서버리스 컴퓨팅은 이벤트가 발생할 때만 제공업체가 코드를 실행하고, 기반 서버를 자동으로 시작하고 확장하며, 트래픽이 멈추면 서버를 0개까지 축소하고, 예약된 머신 대신 요청 및 실행 시간에 대해 요금을 청구하는 클라우드 실행 모델입니다. 서버는 여전히 존재하지만 개발자는 서버를 프로비저닝하거나 패치하거나 규모를 조정할 필요가 없습니다. 이 모델은 2014년 11월 발표된 AWS Lambda를 계기로 주류가 되었으며, 현재는 Lambda, Azure Functions, Cloud Run functions와 같은 함수 플랫폼은 물론 Google Cloud Run 및 Azure Container Apps와 같은 서버리스 컨테이너까지 아우릅니다. UC Berkeley 연구진은 2019년 논문 "서버리스 컴퓨팅에 관한 버클리의 관점: 클라우드 프로그래밍의 간소화"에서 서버리스 컴퓨팅의 장점과 한계를 설명했습니다. 머신러닝에서는 트래픽이 급증하거나 예측하기 어려운 모델 서빙에 서버리스가 적합합니다. 트래픽이 급증하는 사이에 유휴 GPU 서버에 비용을 지불하면 실제 작업 비용보다 더 많이 들 수 있기 때문입니다.

서버리스 실행 방식#

코드를 함수 또는 컨테이너 이미지로 패키징하고 HTTP 요청, 객체 스토리지에 파일이 저장되는 이벤트, 큐의 메시지 또는 예약된 일정과 같은 트리거에 연결합니다. 이벤트가 도착했을 때 웜 인스턴스를 사용할 수 있으면 플랫폼이 즉시 해당 인스턴스에서 핸들러를 실행합니다. 그렇지 않으면 콜드 스타트를 수행합니다. AWS가 Lambda용으로 구축한 Firecracker 마이크로VM 중 하나와 같은 격리된 샌드박스를 만들고, 코드를 불러오고, 언어 런타임을 시작한 다음, 이벤트를 처리하기 전에 핸들러 외부의 초기화 코드를 실행합니다. 인스턴스는 상태가 없고 폐기 가능하므로 요청 이후에도 유지해야 하는 데이터는 외부 스토리지나 데이터베이스에 저장합니다.

콜드 스타트와 머신러닝 모델#

초기화 과정에서 PyTorch와 같은 프레임워크를 가져오고 수백 메가바이트에 달할 수 있는 모델 가중치를 불러오므로 머신러닝에서는 콜드 스타트에 많은 비용이 듭니다. 일반적인 패턴은 인스턴스마다 모델을 한 번만, 핸들러 외부에서 또는 처음 사용할 때 불러와 모든 웜 호출에서 재사용하는 것입니다. 다음 핸들러는 torchvision의 ResNet-50 분류기를 사용해 이 패턴을 따릅니다.

import time

import torch
import torchvision

model = None  # module state survives between invocations while the instance stays warm


def handler(event, context):
    """Classify one image tensor, building the model only on a cold start."""
    global model
    cold_start = model is None
    if cold_start:
        model = torchvision.models.resnet50().eval()  # built once per instance
    with torch.inference_mode():
        logits = model(event["image"])
    return {"cold_start": cold_start, "class_id": int(logits.argmax())}


for _ in range(3):
    start = time.perf_counter()
    response = handler({"image": torch.rand(1, 3, 224, 224)}, context=None)
    print(response["cold_start"], f"{(time.perf_counter() - start) * 1000:.0f} ms")

Apple M5 Pro CPU에서 첫 호출은 네트워크를 구성하므로 약 0.2초가 걸리는 반면, 네트워크를 재사용하는 이후 두 번의 웜 호출은 각각 약 15ms가 걸립니다. 팀은 더 작은 컨테이너 이미지, 더 작거나 양자화된 모델, ONNX Runtime과 같은 경량 런타임을 사용해 남은 콜드 스타트 시간을 줄입니다. 또는 Lambda 프로비저닝된 동시성이나 Cloud Run 최소 인스턴스처럼 최소 개수의 웜 인스턴스를 유지해 콜드 스타트를 없앨 수 있지만, 이 경우 유휴 시간에도 다시 요금이 부과됩니다.

AI 워크로드를 위한 서버리스#

서버리스는 이벤트 기반 컴퓨터 비전 파이프라인에 적합합니다. 객체 스토리지에 이미지를 업로드하면 함수가 실행되어 이미지가 학습 데이터 세트에 들어가기 전에 데이터 전처리 과정에서 이미지를 검증하고 크기를 조정할 수 있습니다. 보안 경보 시스템에서는 동작 센서가 단일 프레임을 객체 감지 함수에 전송해 사람이 감지된 경우에만 경고를 보낼 수 있습니다. 그 외에는 플랫폼 제한이 결정합니다. AWS Lambda는 호출당 최대 15분 동안 실행되며 메모리는 최대 10,240MB이고 GPU는 지원하지 않습니다. 따라서 소형 모델의 CPU 추론에는 적합하지만 장시간 학습은 물론 여러 GPU에서의 분산 학습도 지원하지 않습니다. GPU 서버리스가 이 격차를 메웠습니다. Cloud Run은 0개까지 축소되는 컨테이너에 NVIDIA L4 GPU를 연결하며, Modal과 같은 플랫폼은 GPU 사용 시간을 초 단위로 과금합니다.

Ultralytics Platform은 YOLO 배포에 동일한 상충 관계를 제공합니다. 기본 크기인 vCPU 1개와 2GiB를 사용하는 엔드포인트는 무료이며 유휴 상태에서는 0개까지 축소됩니다. 유휴 상태에서 시작하면 약 1분까지 걸릴 수 있지만, 사용자 지정 크기를 선택하면 인스턴스 하나를 웜 상태로 유지하며 가동 시간에 따라 요금을 청구합니다.

서버리스와 관련 모델 비교#

• 서비스형 인프라: 요청 도착 여부와 관계없이 가동되고 요금이 부과되는 가상 머신으로, 고객이 운영 체제와 확장을 관리합니다. 장시간 학습 작업은 대개 이 방식으로 실행됩니다.
• Kubernetes: 팀이 운영하는 클러스터에서 컨테이너를 오케스트레이션합니다. Knative는 그 위에 요청 기반의 0개까지 확장 기능을 추가하며, KServe는 이를 사용해 모델을 서빙합니다.
• 엣지 컴퓨팅: 데이터를 생성하는 디바이스 안에서 또는 디바이스 근처에서 코드를 실행합니다. 서버리스는 클라우드 리전에서 코드를 실행하며, 일부 엣지 플랫폼은 사용자 근처의 여러 소규모 위치에서 함수를 실행해 두 방식을 결합합니다.