Config, Amazon EKS Spot으로 대규모 RFM 데이터 파이프라인 구축

Config는 General-Purpose Robot Foundation Model을 위해 약 10만 시간의 액션 데이터와 월 2만 시간 규모의 신규 데이터를 처리하는 전처리 파이프라인을 운영한다. 사람 조작 영상에서 robot-aligned action을 추정하고, 에피소드 단위로 분할·정렬해 학습 가능한 데이터셋으로 만드는 것이 핵심이다.

기존에는 Amazon SQS + AWS Lambda 기반의 단일 큐 구조였지만, 사용자 증가와 대규모 배치 처리로 인해 병목이 심해졌다. 하나의 큐에 작업이 몰리면 순차 대기가 발생했고, Lambda의 동시 실행 한도와 15분 실행 제한, On-Demand 요금 구조 때문에 대규모 워크로드에 맞지 않았다.

새 아키텍처는 Amazon EKS 위에 RabbitMQ, KEDA, Karpenter, Amazon EC2 Spot Instances를 결합했다. 핵심은 작업마다 독립적인 동적 큐를 생성하는 방식으로, 여러 사용자의 배치를 서로 간섭 없이 병렬 처리하고 각 Job의 진행 상황도 개별적으로 추적할 수 있게 한 점이다.

인프라는 워크로드 성격에 따라 분리했다.

• On-Demand 노드: RabbitMQ, KEDA 같은 핵심 컴포넌트 배치
• CPU Spot 노드: 영상 전처리, 후처리 워커
• GPU Spot 노드: 액션 라벨링 추론 워커

Spot 용량 확보를 위해 인스턴스 패밀리를 다양하게 구성했고, Karpenter가 pending pod를 감지해 자동 프로비저닝하도록 설계했다. RabbitMQ는 Quorum Queue로 구성해 메시지 복제와 내구성을 확보했으며, x-delivery-limit, DLQ, consumer timeout 20분으로 재시도와 복구를 자동화했다.

자동 확장은 KEDA가 RabbitMQ 큐 길이를 보고 pod를 늘리고 줄이는 방식으로 동작한다. 큐가 비면 0개까지 스케일다운되고, 메시지가 쌓이면 10초 내 스케일업이 시작된다. 이후 Karpenter가 노드를 붙이면서 CPU/GPU 워커가 유연하게 확장된다.

Spot 중단 대응도 다층으로 구성했다. Karpenter가 이벤트를 받아 노드를 drain하고, 워커는 SIGTERM 수신 시 처리 중인 메시지를 NACK해 재처리 가능하게 만든다. 메시지는 Quorum Queue에 복제되어 있고, 워커가 비정상 종료돼도 timeout 이후 자동 재분배된다.

액션 라벨링 워크로드는 CPU 전처리 → GPU 추론 → CPU 후처리의 3단계로 나뉘며, 각 단계가 독립 큐와 ScaledObject를 가진다. 이 구조 덕분에 대규모 비디오와 액션 데이터 처리가 병렬화됐고, 결과적으로 On-Demand 대비 70~90% 비용 절감, 처리 시간 수 일 → 수 시간, 1,000+ pod 동시 운영을 달성했다.