안녕하세요 추천팀 Jaeyoung 입니다. 앞선 포스트에서는 개인화 추천 시스템의 컴포넌트 중 Ranker와 Twiddler를 다루었는데요, 이번에는 추천팀의 모델 서빙 시스템을 소개하려 합니다. 특히 Kubernetes Controller(쿠버네티스 컨트롤러) 패턴을 사용해 모델별 확장성을 보장하고, 다양한 모델을 일관된 방식으로 운영될 수 있도록 개선한 과정에 대해 자세히 이야기하려 합니다.
기존 모델 서빙 방식과 한계
추천팀은 pCTR(predicted Click-Through Rate) Ranking Model들을 실시간으로 서빙하기 위해 TensorFlow의 공식 서빙 시스템인 Tensorflow Serving(TF Serving)을 사용하고 있습니다. 이 툴은 낮은 latency와 높은 throughput을 보장하도록 최적화되어 있지만, 쿠버네티스 환경에서 안정적으로 운영하기 위해서는 추가적인 개선이 필요했습니다.
2023년 하반기 제가 입사했을 당시, 서버 구조는 TF Serving의 Model Loader 기능과 주기적으로 S3 모델 레포지토리를 싱크하는 사이드카가 결합된 형태였습니다. 이 방식은 심플하다는 장점이 있었지만, 서빙하는 모델들이 추가되면서 확장성과 운영 효율성을 개선이 필요했습니다.
쿠버네티스와 같은 분산 운영체제를 활용하면 스케일링의 이점을 얻을 수 있지만, 이로 인해 운영 복잡성도 증가합니다. 서버 수가 늘어남에 따라 단순한 로그 확인만으론 모델 배포 현황을 알기가 어려워졌고, 모델 서빙 Config이 여러 곳에 분산되어 있어 혼선 발생의 여지가 있었습니다. 또한 여러 모델이 동일한 Pod에서 실행되면서, 문제 발생 시 원인을 분석하는 데 어려움이 있었습니다. 이에 따라, 증가하는 모델 수와 트래픽을 안정적으로 지원할 수 있는 새로운 시스템 설계를 고민하게 되었습니다.
요구사항
기존 모델 서빙 방식의 문제를 해결하기 위해 개편되는 시스템에는 다음과 같은 요구사항이 주어졌습니다.
모델별 유연한 Scaling In/Out 지원
추천팀이 TF Serving을 통해 서빙하는 모델들은 각기 다른 요청량을 가지고 있습니다. 기존 TF Serving은 모든 모델이 단일 Service 내에서 함께 로딩되기 때문에, 모델별로 유연하게 Scaling In/Out을 적용할 수 없었습니다. 따라서 각 모델의 요청량에 맞춰 개별적으로 확장할 수 있는 구조가 필요했습니다.
다양한 Framework의 서빙 지원
TensorFlow뿐만 아니라 생성 모델을 비롯한 PyTorch 기반 모델도 서빙할 수 있도록 다양한 Framework를 지원하는 시스템이 요구되었습니다.
동일한 모델 배포 방식 사용
모델의 실험 로그와 정보를 중앙에서 관리할 수 있도록 MLflow Model Registry가 파이프라인에 통합되면서, 신규 모델 저장소와의 통합도 필요하게 되었습니다. MLflow Model Registry에서 제공하는 Model Version Alias 기능은 배포 환경별로 배포 타겟을 효율적으로 관리할 수 있어 새로운 설계의 중요한 요소로 포함되었습니다.
동일한 방식으로 서버 관리, 모니터링 지원
관리 소요를 최소화하기 위해 다양한 스펙의 모델들을 일관적으로 관리할 수 있는 시스템이 필요합니다. 또한 안정적인 서비스를 제공하기 위해 서버 상태를 한눈에 파악할 수 있는 모니터링 대시보드와 이상징후에 신속하게 대처할 수 있는 온콜알람을 제공합니다.
설계와 구현
이러한 요구사항들을 충족하기 위해, 기존의 TF Serving Model Loader에 의존하는 방식 대신 커스텀 쿠버네티스 컨트롤러를 구현하는 방안을 검토하게 되었습니다.
- 관리가 어려운 TF Serving Model Loader를 통한 업데이트 대신, 쿠버네티스에 내재된 서비스 업데이트 기능을 사용하기
- 쿠버네티스 API를 활용해 모델 저장소에 업데이트되는 모델들을 자동으로 배포하기
쿠버네티스 컨트롤러란
쿠버네티스를 사용해 본 경험이 있다면 '컨트롤러'라는 용어가 익숙할 것입니다. 대표적인 예로, 'Deployment'를 선언하면, 설정된 스케일링 기준에 따라 클러스터가 실제 노드에 할당되는 Pod를 자동으로 생성합니다. 이때 Pod 생성을 담당하는 컴포넌트가 컨트롤러입니다. 컨트롤러의 역할은 사용자가 정의한 상태('desired state')을 읽고, 이를 현재 상태 ('current state')에 반영하는 반복(loop) 구조로 이해할 수 있습니다.
쿠버네티스 시스템 컨트롤러를 구현하는 데 사용되는 API는 사용자에게도 제공되므로, 이를 활용하여 사용자의 운용 로직을 실행하는 커스텀 컨트롤러를 개발할 수 있습니다. 이를 통해 사용자는 기존 쿠버네티스 기능을 확장하고, 특정 요구 사항에 맞는 자동화된 운영 방식을 적용할 수 있습니다.
신규 모델 서빙 시스템의 구성
신규 모델 서빙 시스템은 다음 세 가지 주요 영역으로 구성됩니다.
Model Serving Config
Model Serving Config은 서빙해야 하는 모델들의 모델 정보와 서빙 설정 정보가 있는 설정입니다. 모델별로 다음 정보를 담고 있습니다.
- 저장소에 있는 모델 이름과 배포 타겟 버전 Alias
- 서빙 설정 (resources, autoscaling, endpoint)
설정된 배포 타겟 버전 정보는 아래와 같이 MLflow Model Registry에 있는 모델 버전 리스트에서 환경별로 ('prod) 배포할 모델 버전을 가져오는 데 사용됩니다.
컨트롤러
컨트롤러는 공식 파이썬 클라이언트 라이브러리의 예시 코드를 참고하여 필요한 기능을 쉽게 구현할 수 있었습니다. 컨트롤러가 저에게는 새로운 기술이었고, 팀 내에서 개발 선례가 없었기 때문에 접근 방식의 핵심은 '단순함'이였습니다. 아래의 루프 함수가 컨트롤러의 역할을 잘 함축하고 있습니다.
모니터링 대시보드
모니터링 대시보드는 모델별 및 버전별로 트래픽, 자원 사용량, 클라우드 비용 트래킹을 지원합니다. 운영 이슈를 해소하는 것이 큰 목표였기에, 모니터링 시스템 디자인에 많은 노력을 기울였습니다. Datadog APM에서 제공하는 정보와 애플리케이션의 커스텀 메트릭을 결합하여 다양한 측면에서 시스템을 관찰할 수 있는 모니터링 대시보드를 구축했습니다.
신규 모델 서빙 시스템의 기반이 되는 쿠버네티스는 핵심 컴포넌트 중 하나였습니다. 쿠버네티스 API를 사용하는 애플리케이션이기 때문에 개발을 초기 단계에서 클러스터 환경을 할당받아야 했습니다. 다행히 인프라팀의 지원 덕분에 빠르게 클러스터 환경을 구축할 수 있었고, 이를 바탕으로 신규 모델 서빙 시스템의 PoC(Proof of Concept)를 개발할 수 있었습니다.
임팩트
신규 모델 서빙 시스템은 2024년 8월에 런칭했습니다. 실시간 추론 모델이 사용되는 지면이 확대됨에 따라, 요청량이 런칭 이전보다 40% 증가했지만 시스템은 안정적으로 운영되고 있습니다.
안정성을 높이기 위해 쿠버네티스의 분산 환경에서 서비스 품질을 보장하는 다양한 기능을 적극 활용했습니다. Rolling Update, Readiness probe, 모니터링 스택 생태계 같은 기능을 설계에 적용함으로써 안정성을 향상시켰습니다. 또한 모델 추가 후 모니터링을 통해 정상 동작 여부를 바로 확인 가능한 점 역시 안정성에 크게 기여하고 있습니다.
비용 최적화 또한 중요한 과제였습니다. 서빙 인프라 비용을 모델별로 추적할 수 있게 되면서 최적화를 더욱 효과적으로 수행할 수 있었습니다. 모델별로 서버를 분리하여 발생하는 오버헤드가 일부 있었지만, 지속적인 로드 테스트와 튜닝을 통해 전체 운영 비용을 이전 대비 60% 감소시킬 수 있었습니다. 특히, 서버 부하가 낮을 경우 CPU 인스턴스, 높을 경우 GPU 인스턴스를 사용하여 선택적으로 튜닝할 수 있는 점이 비용 절감에 기여했습니다.
MLflow Model Registry와의 연동 덕분에 현재 서빙 중인 모델의 버전을 정확히 파악할 수 있으며, 필요시 손쉽게 모델 롤백도 가능합니다. 실제로 모델 배포 후 이슈가 발생해 롤백이 필요했던 사례가 있었는데, 이는 의도치 않게 시스템의 가치를 검증하는 계기가 되었습니다.
Pytorch 모델 서빙 지원은 공식 서빙 툴인 TorchServe을 사용하는 플랫폼으로 개발하였고, 2025년 2월에 첫 모델을 서빙하기 시작했습니다. TFServing에 깊이 coupling 되지 않은 유연한 설계 덕분에 PyTorch 서빙 기능을 빠르게 추가할 수 있었습니다.
앞으로
이번 포스트에서는 추천팀에서 어떻게 모델 서빙 시스템의 안정성을 개선했는지 소개드렸습니다. ML Platform 팀에서는 앞으로도 오늘의집 ML 모델들의 학습/서빙 자동화를 위한 안정적인 데이터 파이프라인, 서비스, 개발 환경을 고민하며 지속적으로 발전시켜 나갈 계획입니다. 새로운 기술을 탐색하고, 더 나은 방식을 찾아과는 과정에서 함께 몰입하고 성장할 동료분들을 기다리고 있겠습니다. 읽어주셔서 감사합니다!
