서빙과 운영¶

서빙은 model 파일 하나를 API에 올리는 작업이 아닙니다. 학습 때 사용한 feature 순서와 preprocessing을 추론에서도 재현하고, 어떤 model version이 응답했는지 확인할 수 있어야 합니다.

요청 형태에 맞는 경계¶

이미 계산된 feature: 짧은 online prediction 요청
FASTQ처럼 오래 걸리는 원시 입력: 비동기 job 제출과 상태 조회
많은 샘플: batch inference

원시 데이터 처리를 동기 HTTP 요청에 넣지 않습니다. timeout을 늘리는 대신 job ID, retry, cancellation, idempotency 경계를 설계합니다.

Model bundle¶

model
preprocessor
feature manifest
class mapping
input schema
training metadata
metrics and limitations

API는 model version과 feature schema version을 응답에 포함합니다. 학습과 서빙이 같은 bundle을 읽는지는 contract test로 확인합니다.

관측할 값¶

request 수, error rate, p50/p95/p99 latency
queue wait time과 worker 실패율
schema mismatch와 missing feature 비율
입력·예측 분포 변화와 OOD 비율
CPU, memory, throughput, 비용

배포 gate¶

clean environment에서 bundle을 load하고 fixture prediction을 재현한다.
/health는 process 상태, /ready는 model load와 dependency 준비 상태를 구분한다.
request schema 위반은 예측 실패와 다른 error code로 기록한다.
배포 전후에 같은 contract test와 대표 prediction을 실행한다.
rollback할 image tag와 model version을 함께 남긴다.

운영 판단¶

data drift는 입력이 달라졌다는 신호이지 model 성능 저하의 직접 증거는 아닙니다. label이 늦게 도착하면 prediction distribution과 input quality를 먼저 보고, label이 확보된 뒤 subgroup별 성능과 calibration을 다시 계산합니다.

AWS의 ML Engineer 기준은 model inference뿐 아니라 workflow anomaly, utilization, throughput, availability, scalability, fault tolerance, 비용과 access control을 함께 봅니다. 따라서 dashboard의 graph 수보다 alert가 어떤 대응으로 이어지는지를 먼저 정의합니다.