함께 구매하면 좋은 상품이에요! - 장바구니 추천 개발기 2부

장바구니 추천 모델을 실시간 서빙하기 위한 아키텍처 구축기다. AWS EKS와 GCP 위에서 서빙 프레임워크 선정, TorchServe 튜닝, 무중단 배포(GracefulShutdown), warm-up, MLOps·모니터링·GitOps 배포까지 다룬다.

핵심 포인트

서비스 API를 모델 API 앞에 둬 fallback·A/B 라우팅·후처리·로깅을 담당하게 하고, 로그는 Kafka→Nifi→BigQuery로 거의 실시간 적재한다.
BentoML과 TorchServe를 Locust로 성능 비교해 응답시간이 더 나은 TorchServe를 택했고, 튜닝 결과 부가 옵션보다 CPU Clock Speed가 지연시간의 핵심 요인(FIFO 큐 특성)임을 확인했다.
Rolling Update만으론 ALB TargetGroup 연결 교체 시 다운타임이 나서, PreStop Hook·terminationGracePeriodSeconds·ALB idle timeout을 맞춘 GracefulShutdown으로 502를 없앴다.
배포 후 첫 요청이 3초 이상 지연되는 콜드 스타트를 StartupProbe 기반 warm-up으로 해소하고, 모델/서빙 레포 분리와 ArgoCD Image Updater로 GitOps 배포를 구성했다.

상세 정리

전체 구성: 추천 모델 작업 대부분을 AWS EKS에서 수행하고, 학습·분석 데이터는 BigQuery, 모니터링은 Datadog·Slack로 감지·알럿한다.
서비스 API 역할: 모델 API 실패 시 fallback 추천, A/B용 버전 라우팅, 필터·부스팅 후처리, 요청/응답 로깅을 맡는다. 로깅 모듈이 파일로 로그를 내리면 Kafka 토픽으로 보내 Nifi가 BigQuery로 실시간 적재한다.
프레임워크 선정: 운영 노하우가 있는 BentoML과 PyTorch 모델에 맞는 TorchServe를 Locust로 비교해 응답시간이 우수한 TorchServe를 채택했다.
TorchServe 튜닝: async_logging·disable_system_metrics·netty_client_threads는 지연에 큰 영향이 없었고, CPU Clock Speed 높은 인스턴스가 결정적이었다. FIFO 큐라 선행 요청을 빨리 처리하는 게 전체 성능을 좌우한다.
무중단 필요성: 모델 업데이트로 배포가 잦은데, 새 TargetGroup이 Initial이고 기존이 draining되는 구간에서 다운타임이 필연적으로 발생한다.
GracefulShutdown: PreStop Hook으로 종료 전 대기 시간을 벌고 terminationGracePeriodSeconds(기본 30초)로 처리 완료를 보장하되, ALB idle timeout(기본 60초)보다 조금 높게 잡아 ALB 커넥션이 먼저 닫히게 해 502를 제거했다.
Warm up: Frontend(Java)의 클래스 로딩·모델 초기화가 첫 요청 때 일어나 3초 이상 지연돼, StartupProbe로 warm-up 후 트래픽을 받게 해 잦은 배포에도 안정화했다.
MLOps: Kubeflow Notebook·Pipeline으로 학습하고 MLFlow로 아티팩트를 관리하며, GPU는 Karpenter로 프로비저닝, Growthbook으로 A/B 분석, Locust로 부하 테스트를 수행한다(모두 Helm Chart로 배포).
모니터링: Datadog 클러스터 에이전트로 CPU/Memory/RPS를 수집하고, 필요한 컨테이너만 로그를 수집하도록 include/exclude를 설정했으며, TorchServe Access Logs는 중복·과다라 제외했다.
배포: 모델 레포(train.py·Dockerfile)와 서빙 레포(K8S manifest, Kustomize)를 분리하고, GitHub Actions로 이미지 빌드·ECR 푸시, ArgoCD Image Updater가 ECR을 watch해 태그를 서빙 레포에 커밋, ArgoCD가 sync해 EKS에 배포한다(Slack 알림).
향후: 아직 개인화 미반영이라 유저 프로파일·상품 정보를 실시간 반영하는 개인화 추천으로 아키텍처를 개선할 예정이다.