소속: 4by4 Inc. · Pixell Lab 역할: MLOps Engineer 기간: 2024.06 – 2025.01 산업 도메인: 미디어 AI SaaS (Video Enhancement)
Situation
PMS v1.0에서 On-Premise + AWS VM 기반 Ray Cluster를 운영하고 있었으나, 세 가지 핵심 과제가 있었다.
첫째, GPU 비용을 아끼기 위해 On-Premise 클러스터를 우선 사용하고 AWS 클러스터를 후순위로 사용하는 다중 클러스터 추론 시스템 구현이 필요했다. 둘째, v1.0에서는 한 번에 하나의 모델만 처리할 수 있었으나, Denoise 후 SR 등 시퀀셜하게 여러 모델에 대한 추론을 수행할 수 있는 워크플로우 구조가 필요했다. 셋째, Ray Cluster VM의 노드 프로비저닝이 간헐적으로 실패하여 시스템이 마비되는 현상을 근본적으로 해결해야 했다.
SaaS 구조에 맞는 Frontend/Backend 분리도 함께 진행되었다.
Task
- 팀 구성:
- Sales & PM ×1: BM 기획, 프로젝트 관리
- DL Researcher ×2: Model 개발
- Frontend Engineer ×1: Frontend Service 개발
- Backend Engineer ×1: Backend Service 개발
- ML Engineer(본인) ×1: Inference Service 개발
- 담당 영역:
- 다양한 추론 모델이 적용되는 Inference Workflow 구현
- 추론 워크플로우를 여러 Cluster에 할당 및 처리할 수 있는 스케줄러 개발
- On-Premise + AWS Cluster 구축 (VM RayCluster AZ 오류 해결)
- Prod/Dev 개별 구축
- ONNX → TensorRT 모델 변환 및 최적화
- MLflow 업로드까지 포함한 모델 자동화 파이프라인 구축
Action
기술 스택 & 시스템 구성
| 분류 | 기술 |
|---|---|
| Language | Python |
| Framework | Ray, KubeRay |
| Inference | TensorRT, ONNX |
| ML Ops | MLflow |
| Infrastructure | AWS EKS, Terraform, Karpenter, Packer |
| Orchestration | Kubernetes |
이전 버전 대비 변경점
| 항목 | v1.0 | v2.0 | 개선 효과 |
|---|---|---|---|
| 인프라 | AWS VM 기반 Ray Cluster | EKS + KubeRay + Karpenter | AZ 오류 해결, GPU 프로비저닝 120~240초 |
| Cold Start | 컨테이너 이미지 매번 Pull | Packer AMI 기반 이미지 캐싱 | 83% 감소 (900s → 150s) |
| IaC | 수동 인프라 관리 | Terraform 기반 Git 관리 | 3개 EKS 클러스터 자동 구축 |
| 워크플로우 | 단일 모델 처리 (택 1) | 다중 모델 직렬 처리 | Denoise → SR 등 복합 처리 지원 |
| 모델 파이프라인 | 수동 변환 + 수동 업로드 | 변환~MLflow 업로드 자동화 | 전 과정 100% 자동화 |
| 클러스터 | On-Premise + Cloud 분리 | On-Premise + AWS 하이브리드 동시 처리 | 단일 스케줄러로 통합 관리 |
| 모델 수 | 2개 (SharpClear, SR) | 5개 (+Color Enhance, Deinterlacing, FI) | 대폭 확장 |
핵심 구현 사례
1. VM 기반 Ray Cluster → EKS + KubeRay + Karpenter 전환
문제: VM 기반 Ray Cluster는 AZ 관련 프로비저닝 오류가 간헐적으로 발생하여 Worker Node가 프로비저닝되지 않고 시스템이 마비되는 현상이 있었다.
구현 과정: Kubernetes를 전혀 모르는 상태에서 처음부터 공부하며 진행해야 했다. EKS 구성 PoC 시, 인프라 구성을 잘못하여 해결이 불가능해 클러스터를 통째로 재생성해야 하는 경우가 있었는데, 수동 구성이었기 때문에 재생성에 막대한 공수가 들었다. 이 경험을 계기로 Terraform을 공부하여 인프라를 코드로 구축하는 방식을 도입했다. Terraform 덕분에 실수로 생성해놓고 삭제하지 않는 자원이 없게 되었고, 클러스터 재생성도 매우 간편해졌다.
Karpenter 도입 시에는 권한 설정에 대한 적절한 자료를 찾기 어려워 많은 시행착오를 겪었으나, 결국 여러 시도 끝에 권한 문제를 해결하고 성공적으로 노드 프로비저닝을 구현했다. 최종적으로 Terraform으로 3개의 EKS 클러스터(Prod, Dev, Infra)를 구축하고, EKS + Karpenter + KubeRay 조합으로 기존 VM 기반 Ray Cluster에서 발생하던 프로비저닝 오류를 해결했다. GPU 노드 프로비저닝 시간은 120~240초 수준으로 유지했다.
2. Packer 기반 GPU AMI 최적화로 Cold Start 83% 감소
문제: GPU Worker Node가 시작될 때 대용량 컨테이너 이미지를 매번 Pull하여 Cold Start가 900초에 달했다.
구현: Packer로 GPU Worker Node용 AMI를 별도 구성하여 런타임 컨테이너 이미지를 사전 캐싱했다. Cold Start를 900초 → 150초로 83% 감소시켰다.
3. On-Premise 우선 하이브리드 스케줄러 및 다중 모델 워크플로우
문제: GPU 비용 절감을 위해 On-Premise를 우선 사용하되, AWS도 활용할 수 있는 스케줄링이 필요했다. 또한 다중 모델을 시퀀셜하게 처리하는 워크플로우가 필요했다.
스케줄링 로직: On-Premise에 미리 정해둔 작업 한계까지는 On-Premise에 우선 할당하고, AWS는 후순위로 배정했다. 다만 On-Premise에서 작업 한계에 도달하지 않았는데도 지속적으로 처리가 지연되면, 작업 분배를 AWS 우선으로 전환하는 Fallback 로직을 적용했다.
워크플로우 구현: Ray Cluster Client Session에 대한 Sub-Processor를 생성하고, RPC 기반의 작업 처리 구조를 구현하여 다중 모델 직렬 워크플로우를 지원했다. 5개 모델(SharpClear, SR, Color Enhance, Deinterlacing, Frame Interpolation)을 지원했다.
4. ONNX → TensorRT 변환 자동화 파이프라인
구현: 모델 변환(ONNX → TensorRT)부터 MLflow 업로드까지 전 과정을 100% 자동화하는 파이프라인을 구축했다. 5개 모델의 최적화를 지원했다.
Result
기술 성과
- EKS + Karpenter + KubeRay로 AZ 프로비저닝 오류 해결 및 GPU 프로비저닝 120~240초 유지
- Packer AMI 기반 Cold Start 83% 감소 (900s → 150s)
- On-Premise 우선 하이브리드 스케줄러로 GPU 비용 최적화
- On-Premise + Multi Region GPU Cluster로 동시 대량 비디오 처리 가능
- 5개 모델에 대한 직렬 추론 처리 지원
- 모델 등록 및 운영 전 과정 100% 자동화
- Terraform 기반 3개 EKS 클러스터(Prod/Dev/Infra) 자동 구축
비즈니스 임팩트
- SaaS 서비스 정식 오픈 및 상용 고객 확보 (Wavve 외), 매출 발생
- AWS Partner Software Path 인증
- SGO사 MISTIKA 솔루션에 Plugin으로 통합
회고
잘한 점
기술적으로 목표했던 것들을 모두 달성했다. Kubernetes를 전혀 모르는 상태에서 시작하여 EKS + Karpenter + KubeRay를 프로덕션에 적용했고, Terraform을 통해 인프라를 코드로 관리하는 체계를 수립했다. VM 기반 Ray Cluster의 프로비저닝 오류라는 근본적인 문제를 해결하고, 다중 클러스터 하이브리드 스케줄링과 다중 모델 직렬 워크플로우라는 두 가지 핵심 요구사항을 모두 충족시켰다.
아쉬운 점 / 다시 한다면
운영 관점에서 여러 부채가 쌓였다. 클러스터 추가/삭제를 위해서는 스케줄러를 재시작해야 하는 불편함이 있었고, 스케줄러에 문제가 발생했을 때 알람 대책이 없어 장애 감지가 늦었다. 의도치 않게 백엔드 로직이 추가되면서 ORM 없이 쿼리문을 직접 사용했는데, 스키마 변경 시 실수가 발생할 수밖에 없는 구조였다. Packer로 런타임 이미지를 AMI에 구워넣는 과정이 번거로웠고, Redis 및 DB 연결 끊김에 대한 보호 대책도 없었다. 이러한 문제들은 v3.0에서 체계적으로 해결하게 되었다.
배운 점
새로운 기술 스택(Kubernetes, Terraform, Karpenter)을 프로덕션에 도입하는 과정에서, 초기 PoC의 실패 비용을 최소화하는 것이 중요하다는 것을 배웠다. 수동으로 구성한 EKS 클러스터를 재생성해야 했을 때의 막대한 공수가 Terraform 도입의 직접적 계기가 되었으며, 이후 인프라를 코드로 관리하면서 실험과 재생성의 비용이 극적으로 줄었다. 또한 기능 구현에만 집중하다 보면 운영 부채(모니터링, 알람, 에러 핸들링)가 쌓인다는 것을 체감했고, 이는 v3.0의 설계 방향에 직접적인 영향을 주었다.