ML 기반 서비스를 위한 온프레미스 GPU+EKS 하이브리드 클러스터 구축 운영기

이 글은 와탭이 외부 필진과 협력하여 제작한 콘텐츠로, 현업에서 활동하는 전문가의 경험과 인사이트를 독자 여러분께 전달하고자 합니다.

‍

1. 서론: 왜 하이브리드 클러스터인가?

최근 AI 기술의 급속한 발전과 함께 AI를 활용한 서비스가 폭발적으로 증가하고 있습니다. 하지만 이와 동시에 GPU 비용 부담으로 고민하는 팀들도 늘어나고 있습니다. 저희 팀 역시 같은 고민에 빠져 있었습니다. 이 글에서는 이러한 비용문제의 현실적인 해결책이 될 수 있는 온프레미스 GPU와 AWS EKS를 결합한 하이브리드 클러스터 구축 및 운영 경험을 공유하고자 합니다. 아키텍처 설계부터 실제 구축 과정, 운영 중 마주한 문제들과 해결 방법, 그리고 효과적인 모니터링 구성까지 저희가 겪은 시행착오와 노하우를 상세히 전달드리겠습니다.

몇 해 전 제가 속한팀은 AI 기반 건축 설계 엔진을 개발하였습니다. 심층 강화학습(Deep Reinforcement Learning)을 활용하여 수십~수백개의 건축설계 안을 생성한 후 최적안을 고객에게 제공하는 서비스를 개발하였습니다. 이 과정은 모델 학습부터 제품화까지 매우 많은 GPU 리소스를 요구하였습니다. 학습은 ML 엔지니어 별로 할당된 GPU 장비를 사용하였지만, 고객에게 전달되는 결과물은 안정성을 고려하여 EC2 GPU 장비를 사용하여 학습결과를 추론하였습니다. 이로 인하여 월 수천만원의 GPU 인스턴스 비용이 발생하였고 투자금으로 서비스를 운영하는 스타트업으로서는 감당하기 어려운 큰 금액이었습니다.

추론 리소스 비용 최적화를 고민하던 중, 온프레미스와 EC2가 조합된 GPU 클러스터 구축을 검토하게 됐습니다. 서비스는 클라우드에서 운영하되, 학습과 추론은 IDC의 GPU 장비를 사용하고 추론의 스케일링만 EC2를 사용하여 서비스 안정성과 추론 비용의 최적화를 동시에 확보하는 것이 목적이었습니다. 신규 GPU 장비 도입과 IDC 임대 비용을 포함한 초기 투자 비용은 크지만, 비용 산전 결과 1년만 운영해도 비용 절감 효과를 얻을 수 있었습니다. 웹 서비스 및 데이터/ML 파이프라인 등은 클라우드의 탄력성이 필요하여 전체 서비스를 온프레미스로 전환하는 선택은 배제하였습니다.

‍

2. 아키텍처 설계

2.1 전체 아키텍처 구성

하이브리드 클러스터의핵심은 온프레미스와 클라우드를 얼마나 기민하게 연결하느냐입니다. 이를 위하여 우리 팀은 세 단계의 네트워크 연결을 구성했습니다.

첫째, 회사 오피스와 IDC 간 연결입니다. 회사의 ML 엔지니어들이 온프레미스 GPU 장비에 안전하게 접근할 수 있도록 가비아의 Site-to-Site VPN을 활용하여 오피스 네트워크와 IDC 를 연결하였습니다.

둘째, IDC와 AWS 간 연결입니다. 대용량 데이터 전송과 낮은 레이턴시를 위해 AWS Direct Connect 전용선을 구축했습니다. 동시에 AWS Transit Gateway를 중앙 허브로 구성하여 IDC 온프레미스 네트워크와 EKS VPC, 오피스 네트워크를 토폴로지로 연결하였습니다. 이로부터 단일 관리 포인트로 Production EKS 네트워크 환경과 개발용 학습 환경을 효율적으로 분리하여 관리할 수 있었습니다.

‍

2.2 IDC 선정과 인프라 구성

데이터센터 선정에서가장 중요하게 고려한 점은 (당연히) 비용이었습니다. 그 이후로는 “GPU 서버의 안정적 전력 공급”과 “확장/관리 용이한 네트워크 인프라”,“냉각/공조/향온/향습”, “장애에 대한 빠른 1차 현장 대응 가능 여부”를 충족하는 곳을 찾았습니다. 여러 IDC를 검토한 끝에 판교 내 위치한 특정 데이터센터를 선택하였습니다.

‍

2.3 워크로드 구성 전략

워크로드 배치는 각환경의 장점을 최대한 활용하도록 설계했습니다.

온프레미스 GPU 클러스터:

건축 설계 AI의 심층 강화학습
대규모 배치 추론 작업
데이터 전처리 파이프라인
모델 실험과 하이퍼파라미터 튜닝
학습 모델에 대한 고객 전달(추론 API , 스케일링 전)

EKS:

추론 API(GPU Spot 인스턴스 활용) 및 서빙 파이프라인
웹 애플리케이션과 백엔드 서비스
데이터 수집 및 스트리밍 파이프라인
CI/CD 파이프라인

핵심은 추론 서비스의비용 최적화입니다. 평상시엔 온프레미스의 GPU 장비를 사용하다가 고객의 사용량이 증가하면 EC2의 GPU 인스턴스를 사용하여 스케일아웃하였습니다. 이때, Spot 인스턴스를 활용하여 비용 최적화를 진행하였습니다.

‍

3. 구축 과정과 핵심 고려사항

3.1 온프레미스 GPU 장비 구축

IDC 내 GPU 서버구축은 생각보다 복잡했습니다. GPU 서버 하드웨어 선정부터 시작해 구매, OS 설치, GPU 드라이버, CUDA 툴킷, EKS 의 NodeJoin 을 위한 컨테이너 런타임까지 모든 레이어를 직접 관리해야 했습니다.

특히 신경 쓴 부분은 네트워킹이었습니다. 총 18개의 GPU 장비를 IDC에서 운영하기 위해 총 4 Line의 서버 Rack을 임대하였습니다. 서버 Rack 간빠른 통신을 위해서 별도 스위치를 구매하여 IDC 내 작은 전용 망 환경을 구성 후 3rd patry VPN, AWS 네트워크 리소스 등을 연결하여 오피스와의 빠른 연결을 구성하였습니다.

스토리지는 NVMeSSD 기반의 분산 스토리지를 구축했습니다. 추가로 AI 워크로드의 특성상 순차 I/O가 많아 MinIO를 선택했습니다. MinIO의 S3 호환API 덕분에 기존 코드 수정 없이 사용할 수 있었고, 온프레미스와 AWS S3 간 학습 아티팩트 데이터 동기화도 쉽게 적용하였습니다.

‍

3.2 쿠버네티스 클러스터 구성

하이브리드 클러스터를 구현하기 위해 EKS를 Control Plane으로 사용하고, 온프레미스 GPU 서버들을 워커 노드로 조인시키는 아키텍처를 채택했습니다. 이로부터 두 개의 독립적인 클러스터를 연동하는 것보다 더 쉬운 운영과 GPU 장비에 대한 관리 이점을 확보하였습니다.

EKS 내 GPU 인스턴스의탄력적 확장을 위해 Spot.io의 Kubernetes Autoscaler 를 도입하였습니다. Spot.io를 이용하여 오토스케일러는 온프레미스 GPU 리소스가 포화 상태에 도달하면, 자동으로 EKS 내에서 적절한 GPU 인스턴스(p3, p4d,g4dn 등) 타입 군 중 적절한 인스턴스를 프로비저닝하도록 적용하였습니다. 이로부터 아래의 이점을 확보하였습니다.

예측 리밸런싱: Spot 인스턴스 회수 10분 전신호를 감지하고, 사전에 대체 인스턴스를 준비해 무중단 마이그레이션
다중인스턴스 타입 전략: 단일 GPU 타입에 의존하지않고, 여러 인스턴스 패밀리를 혼용해 가용성 극대화
체크 포인트기반 복구: ML 학습 중단 시 자동으로 체크포인트에서재시작. MinIO 에 저장된 모델 가중치를 새 인스턴스에서 즉시 로드
비용 최적화 스케줄링: 온디맨드 대비 최대 80% 절감 가능한 Spot 인스턴스를 우선 배치하되, SLA 준수를 위해 필요시 온디맨드로 폴백

‍

4. 운영 중 마주한 주요 문제점과 해결책

4.1 네트워크 안정성과 대역폭 관리

AWS DirectConnect 를 적용하여 Network 성능은 충분할 거라 생각했지만, 실제론 부족한 경우가 많았습니다. 특히 학습된 모델 파일(수백 GB)을S3로 업로드하거나, 대용량 데이터셋을 온프레미스로 가져올 때 병목이 발생하였습니다.

이를 해결하기 위해 트래픽 우선순위를 설정했습니다. QoS(Quality of Service) 정책을 통해 대고객 추론 API 트래픽에 최우선 순위를, 학습에 사용되는데이터 전처리 배치 데이터 전송엔 낮은 우선순위를 부여했습니다. 또한 대용량 데이터 전송은 트래픽이 적은 새벽 시간대에 스케줄링되도록 적용하였습니다.

‍

4.2 GPU 장애 대응

IDC 내 온프레미스 환경의 가장 큰 단점은 하드웨어 장애 대응입니다. 클라우드는 버튼 입력만으로 인스턴스를 재시작할 수 있지만 물리 서버는 거리적 제약이 있습니다.실제로 GPU 메모리 에러, 팬 고장/수랭 쿨러 오 동작, 전원부 고장 등 다양한 하드웨어 이슈를 경험했습니다. IDC를 선정할 때 이러한 부분을 나름 고려하여 1차 대응이 가능한 곳을 선택했음에도 불구하고 클러스터 구축 후 초기 몇 개월간은 GPU 장비의 오류로 성수동의 오피스에서 판교의 IDC까지 출장이 잦았습니다.

위와 같은 어려움을겪으며 아래와 같은 대응 전략을 수립하여 실행하였습니다.

GPU 하드웨어 오류를 대비해 전체의 20%를 즉시 실행할 수 있는 Ready 상태로 유지(비용이 조금 증가)
하드웨어 모니터링 강화 (nvidia-smi, ipmitool 활용)
학습 중 장애 시 EKS GPU 인스턴스로 자동 페일오버 (GPU 인스턴스 스케일링)

5. Observability: 모니터링 도구 선택과 구축

5.1 모니터링 요구사항 정의

하이브리드 환경의 모니터링은단순히 메트릭을 수집하는 것 이상이 필요합니다. 온프레미스와 클라우드에 분산된 워크로드 간의 상관관계를 파악하고, 문제 발생 시 신속히 원인을찾을 수 있도록 구성되어야 합니다.

저희 팀이 정의했던 핵심 요구사항은 아래와 같습니다.

GPU 하드웨어 메트릭 (사용률, 메모리, 온도, 전력량)
쿠버네티스 리소스 (파드, 노드, PV 상태)
애플리케이션 메트릭 (학습 진행률, 추론 소요/지연시간)
네트워크 메트릭 (응답 레이턴시, in/out packet 량)
통합 대시보드와 알림

‍

5.2 모니터링 솔루션 여정

처음엔 비용 절감을위해 오픈소스 조합을 선택했습니다. Prometheus를 메트릭 수집에, Grafana를 시각화에, AlertManager를 알림에 사용하였습니다.이러한 운영은 초기에 (특히 비용적 관점에서) 만족을 주었지만 곧 운영하면서 여러 한계를 느꼈습니다.

먼저, 구성의 복잡성입니다. Metrics 수집을 위한 Promethues, 시각화를 위한 Grafana, 로깅을 위한 Loki 등 여러 컴포넌트를 직접 관리해야 했고, 수집 metrics의 장기 저장을 위한 별도 리텐션 정책 및 방안도 직접 수립해야 했습니다.

대시보드 관리 또한큰 어려움이 있었습니다. GPU 메트릭을 위한 대시보드, 쿠버네티스 대시보드, 애플리케이션 대시보드 등 목적에 따라 직접 만들고 유지보수해야 했습니다. 새로운 메트릭이 추가될 때마다 대시보드를 수정하는 것도 일이었습니다. 다양한 사용자들이 미리 정의해둔 Grafana Template를 최대한 활용했지만, 필요한 정보가 표시되지 않거나 직접 수정이 어려운 한계가 많았습니다.

가장 치명적인 건 장애 대응이었습니다. 어느 날, 추론 작업이 멈춘 걸 알림으로 받았는데, 원인을 찾는 데 30분이 걸렸습니다. GPU 노드의 메모리 부족이 원인이었지만, 여러 대시보드를 전전하며 로그와 메트릭을 확인하느라 서비스 장애의 회복이 장시간 지연되었습니다.

이후 조금 더 체계화된 모니터링 도구의 필요성을 느꼈고 이전 경험을 바탕으로 글로벌 A사 제품을 PoC 했습니다. 다양한 Integration을 활용한 통합 모니터링 측면에서 사용성이 크게 증가되었고, 쉬운 설치와 metrics와 알림, 로그 정보 등을 연속하여 확인할 수 있는 직관적인 UI는 훌륭했습니다. 다만(처음의 문제가 다시 발생하였습니다) 스타트업으로서는 감당하기 어려운 비용이 문제였습니다.

특히 ML 모델의 학습과 추론 파이프 라인의 세밀한 관찰이 필요하여 커스텀 메트릭스를 추가하였는데 A사 제품은 Data의 Ingest 양 기준으로 과금이 되기 때문에 메트릭스 추가 비용이 예상을 훨씬 초과하였습니다. 월 예측 비용이 예산을 훌쩍 넘어서자 어쩔 수 없이 도입하지 못하고 처음의 오픈 소스 구성을 보완하는 방향으로 진행하였습니다.

오픈소스 조합을 계속 개선하고 있었지만, 파편화된 구현과 적용 방안의 어려움의 근본적 해결은 어려웠습니다. 효과적인 모니터링과 합리적 비용을 위해서 기술 탐색을 계속하였으며 이때 와탭을 알게 됐습니다. 처음엔 "국산 솔루션이 잘알려진 글로벌 제품만큼의 완성도가 있을까?" 하는 의구심이 있었지만, 기술 검토 결과 기대 이상이었습니다.

가장 인상적인 건 적용/관리가 용이한 하이브리드 환경 지원이었습니다. 에이전트 설치 후 별다른 설정 없이 온프레미스 GPU 클러스터와 EKS가 하나의 대시보드에 표시되었습니다. 이는 타 모니터링 도구에서도 적용 가능했지만, 와탭은 더 쉽게적용할 수 있고 더 직관적인 UI 를 제공하였습니다. 특히 쿠버네티스 클러스터 간 워크로드 의존성을 시각화하는 기능은 다른 솔루션에서도 보지 못한것이었습니다.

비용 측면에서도 합리적이었습니다. 타 제품 대비 40% 수준의 비용으로 당시 우리가 필요한 모든 기능을 제공했고, 특히 GPU 메트릭 수집이 기본 제공되는 점이 좋았습니다. 라이브 서비스를 운영하는 입장이다보니 한국 기업의 빠르고 편한기술 지원도 큰 장점입니다.

‍

6. 성능 최적화 및 비용 관리

6.1 클러스터 최적화

수개월간의 운영 데이터를분석하며 클러스터를 꾸준히 최적화했습니다. 클러스터 내 각 워크로드의 특성을 정확히 파악 후 이를 반복적으로 개선하였습니다.

건축 AI 학습은GPU 메모리를 많이 사용하지만 CPU는 거의 사용하지 않았습니다. 반대로 데이터 전처리는 CPU 집약적입니다. 이를 바탕으로 노드 그룹을 세분화했습니다:

GPU 학습 노드: CPU 최소, GPU/메모리 최대
전처리 노드: CPU 최대, GPU 없음
추론 노드: GPU 중간, 네트워크 최적화

‍

6.2 비용 최적화 전략

가장 효과적인 비용 절감은 예약 인스턴스(RI) 활용이었습니다. AWS Cost Explorer로 사용 패턴을 분석한 결과, 특정 인스턴스 타입들이 상시 운영되고 있었습니다. 이러한 타입들은 선납 RI를 구매해 큰 폭 할인을 적용하였습니다.

Spot 인스턴스도적극 활용했습니다. 추론 서비스는 기본적으로 온프레미스에서 운영되었지만, Spot 인스턴스와 3rd party 오토스케일러를 적용하여 다음과 같이 구성했습니다:

Spot 인스턴스 다양화 (여러 타입 혼용)
인터럽션 10분 전 알림 시 자동 드레이닝
온프레미스 GPU로 자동 페일오버

‍

7. 하이브리드 클러스터 도입 성과 및 조언

ML 기반 서비스를 위한 하이브리드 클러스터 도입으로 얻은 성과는 명확하였습니다. 도입 후 월 평균 AWS 비용을 60% 정도 절감했고, 가용되는 GPU 리소스는 3배 증가하였습니다. 건축 AI 모델의 학습 주기도 크게 단축되었으며, 고객은 필지에 대한 다양한 건축 설계안을 더 빠른 시간에 수령하게 되었습니다.

반면 운영 복잡도는 확실히 증가했고, 온프레미스 장비와 IDC 비용도 추가되었습니다(월로 환산 시 AWS 절감 비용보다 훨씬 적은 금액입니다). 클러스터 관리를 위한 인력 리소스가 추가로 필요한 부분도 어떻게 보면 큰 비용 증가입니다. 또한 두 환경 간 데이터 동기화, 보안 정책 일관성 유지 등 예상치 못한 이슈들도 반복 발생하였습니다. 이러한 내용을 바탕으로 하이브리드 클러스터 도입을 고려하는 팀에게는 아래 내용을 조언드리고자 합니다.

첫째, 도입 전명확한 목표와 기준이 필요합니다. 단순히 "비용 절감"이아니라, "월 X원 이상 절감" 같은 구체적인 목표가 필요합니다. 당시 저희팀은 월 수천만원의 AWS 비용을 절반으로 감소하는 것과 ML 결과물의 대 고객 전달 시간 30% 상향이 목표였습니다.
둘째, 팀의 역량을 정직하게 평가해야합니다. 하이브리드 클러스터는 클라우드와 온프레미스 모두에 대한 깊은 이해가 필요합니다. 도입 시 네트워킹, 쿠버네티스, 하드웨어 관리 등 다양한 영역의 문제에 부딪힐 것입니다. 이를 극복할 수 있는 전문성이 필요합니다.
셋째, 모니터링 환경 검토 및 구성에 투자하세요. 하이브리드 클러스터는더 복잡하며 운영이 훨씬 어렵습니다. 처음부터 제대로 된 모니터링 솔루션에 투자하는 게 장기적으로 이득입니다.
마지막으로, 하이브리드 클러스터는 "두 환경의 장점만 취하는"게 아니라 "두 환경을 모두 관리하는" 것임을 명심하시기 바랍니다. 복잡도는 확실히 증가합니다. 하지만 AI 시대에 GPU 인프라는 핵심 경쟁력입니다. 준비가 되어 있다면, 도전할 가치는 충분합니다. 또 재미도 있습니다.^^

제 기고가 비슷한 고민을하는 팀들에게 도움이 되길 바랍니다. 하이브리드 클러스터는 쉽지 않은 길이지만, 제대로 구축하면 비용과 성능 모두를 잡을 수 있는 강력한 무기가될 수 있습니다.