새로운 루다를 지탱하는 모델 서빙 아키텍처 — 2편: ArgoCD와 모델 서빙

이루다 2.0의 모델 추론 구조를 서비스 백엔드에서 분리하고, 빠르게 바뀌는 모델 조합을 Kubernetes와 ArgoCD로 안정적으로 배포한 과정을 설명한다. 핵심은 모델별 서버와 추론 순서를 파이프라인으로 추상화하고, Helm 차트를 계층화해 A/B 테스트 단위의 전체 인프라를 한 번에 생성·교체하는 것이다.

핵심 포인트

모델 파이프라인 서버가 여러 모델 서버와 Faiss 같은 보조 서비스를 조합해 Retrieval·Generation 추론 흐름을 캡슐화한다.
Helm 차트를 Components, Infrastructures, Applications 세 계층으로 나눠 서버 재사용성과 환경별 설정, ArgoCD 배포 대상을 분리했다.
추론 구조가 바뀔 때는 개별 파드의 롤링 업데이트가 아니라 모델 인프라 전체를 블루/그린 방식으로 교체해 비호환 위험을 피한다.
ArgoCD SyncWave와 커스텀 Health Check로 계층형 서버의 종료·배포 순서와 정상 상태 판정을 제어한다.
모델 서버의 최대 처리 RPS, 실험군 트래픽 비율을 기준으로 HPA 파드 수를 계산해 소규모 실험군의 비용을 줄인다.

상세 정리

추론 경계: 서비스 백엔드는 A/B Proxy에 답변 생성만 요청하고, Proxy가 실험군에 맞는 모델 파이프라인 서버로 트래픽을 보낸다.
파이프라인 추상화: 답변 생성 과정을 여러 모델 사이로 데이터가 흐르는 파이프라인으로 정의했다. 비슷한 흐름은 설정 공유와 상속으로 중복을 줄였다.
서버 역할: 파이프라인 서버는 직접 추론하지 않는다. 모델 서버와 Faiss 등 외부 서비스의 입출력을 조율해 최종 답변을 구성한다.
Components 계층: 모델 서버와 파이프라인 서버를 독립 배포 가능한 Helm 차트로 만든다. 부하 테스트도 다른 계층 없이 서버 단위로 수행할 수 있다.
Infrastructures 계층: 특정 모델 아키텍처에 필요한 Components를 조합한다. 클러스터별 values.yaml은 기능 활성화만 바꾸며 컴포넌트 자체 설정은 건드리지 않는다.
Applications 계층: ArgoCD App of Apps 패턴으로 실제 배포할 실험군과 환경을 선택한다. 비정기적으로 테스트 환경을 내리므로 ApplicationSet은 쓰지 않았다.
검증 환경: Development, Stage, Production 클러스터에 같은 인프라 차트를 차례로 배포해 유닛 테스트부터 E2E까지 확인한다.
종료 순서: 계층형 구조에서는 상위 파이프라인 서버를 먼저 닫아 신규 트래픽을 차단하고 처리 중 요청을 끝낸 뒤 하위 모델 서버를 종료한다. SyncWave가 순서를 보장한다.
무중단 교체: 단순 버그 수정은 서버별 롤링 업데이트를 쓰지만 추론 구조 변경은 전체 인프라를 블루/그린으로 띄운 뒤 A/B Proxy 설정만 전환한다.
확장 계산: 각 서버가 안정적인 지연 시간을 지키는 최대 RPS를 측정하고, 실험군 비율과 유입량으로 필요한 파드 수를 산정한다.
운영 보강: 순정 App of Apps의 상태·순서 제약을 보완하려고 리소스 상태 기반 판정과 커스텀 Health Check를 적용했다. 실험 단위 애플리케이션은 배포 이력과 롤백 지점도 제공한다.