Snorkel AI가 Amazon EKS를 사용하여 기계 학습 워크로드를 확장하면서 40% 이상의 비용을 절감한 방법

기계 학습(ML) Startup은 하이엔드 GPU를 사용해 대규모 모델을 훈련하고 추론을 위해 대규모로 배포하기 때문에 대개 컴퓨팅 사용량이 많습니다. AWS Startup은 창업부터 IPO까지 Startup과 협력하여 수천 명의 설립자와 인공 지능(AI) 혁신가가 Amazon Elastic Kubernetes Service(Amazon EKS)를 기반으로 비즈니스를 구축하도록 지원해 왔습니다. Amazon EKS는 Kubernetes의 유연성은 물론, 컨테이너화된 고가용성 워크로드 구축에 최적화된 AWS 관리형 서비스의 보안 및 복원력까지 제공하기 때문에 ML 모델을 구축하고 호스팅하는 데 널리 사용됩니다.

Snorkel AI는 이러한 Amazon EKS의 이점을 활용하는 회사 중 하나입니다. Snorkel AI는 포춘지 선정 500대 기업, 연방 기관 및 AI 혁신 기업이 파운데이션 모델(FM)과 대규모 언어 모델(LLM)을 구축, 조정 및 고도화하여 분야별 데이터 세트에 대해 매우 정확하게 작동하도록 지원합니다. 많은 조직들이 Snorkel의 데이터 중심 AI 개발 방식을 사용하여 보험 청구 처리, 금융 스프레딩, 임상 시험 분석, 해양 시추를 위한 사전 예방적 유정 관리 가속화 등 사용 사례에 따라 프로덕션 환경에 바로 사용할 수 있는 AI 서비스를 구축했습니다.

지난 몇 개월 동안 Snorkel 팀은 인프라 비용을 늘리거나, 개발자의 개발 속도를 떨어뜨리거나, 사용자 경험을 저해하지 않으면서 ML 개발 워크로드를 지원하는 효율적인 인프라를 설계하는 데 따르는 고유한 문제를 해결하기 위해 열심히 노력해 왔습니다. 이들의 궁극적인 목표는 자사의 엔드-투-엔드 ML 플랫폼인 Snorkel Flow의 클러스터 컴퓨팅 지출을 40% 이상 줄이는 것이었습니다.

Snorkel Flow 개요

Snorkel의 Snorkel Flow AI 데이터 개발 플랫폼을 사용하면 데이터 팀이 프로그래밍 방식의 레이블링, 빠른 모델 훈련 및 오류 분석의 반복 루프를 통해 AI 애플리케이션을 신속하게 구축할 수 있습니다. 각 프로젝트는 사용자가 소수의 레이블링 함수를 만들 때 시작됩니다.

레이블링 함수는 간단한 휴리스틱, 외부 데이터베이스, 레거시 모델을 사용하며, 인코딩된 전문가의 직관에 따라 레이블링되지 않은 데이터 전체에 레이블을 적용하기 위해 대규모 언어 모델을 직접적으로 호출하기도 합니다. 플랫폼의 취약성 감시 알고리즘은 이러한 규칙 기반 함수를 결합하여 각 레코드에 대해 가장 유망한 레이블을 결정합니다. 그런 다음 사용자는 이러한 확률적 데이터 포인트를 기반으로 간단한 모델을 훈련하고 각 레이블링 함수의 영향을 평가합니다. 분석 단계에서 사용자는 모델의 성능이 저조한 데이터 부분을 조사합니다. 그런 다음 레이블링 함수를 구축하거나 수정하고 또 다른 간단한 모델을 훈련하면서 루프를 계속 진행합니다. 사용자가 레이블 품질에 만족하면 로지스틱 회귀부터 FM에 이르기까지 모델 주(model zoo)의 아키텍처를 기반으로 최종 모델을 구축한 다음 배포를 위해 내보냅니다.

이 워크플로의 특성상 Snorkel Flow의 인프라에서는 컴퓨팅 사용량이 늘어나는 시기가 있고 저마다 그 기간이 다릅니다. Snorkel Flow의 고객 기반과 ML 제품 기능이 확장됨에 따라 운영 비용이 자연스럽게 증가했습니다. 효율적인 성장을 달성하기 위해 Snorkel은 첨단 ML 소프트웨어를 운영하면서 마진을 높이는 방법을 찾는 것을 목표로 삼았습니다. 이에 Snorkel은 클러스터 컴퓨팅 비용을 40% 이상 절감하기 위해 다음과 같은 사례를 구현했습니다.

클라우드 비용 최적화를 위한 솔루션 

서비스형 소프트웨어(SaaS) Startup에게는 클라우드 지출을 최적화할 여지가 많습니다. 비용을 유발하는 고유한 요인을 이해하는 것이 중요합니다.

Snorkel의 경우 다음과 같은 두 가지 중요한 요인이 있었습니다.

1. ML 개발 워크로드에는 GPU와 같은 전문적이고 값비싼 하드웨어가 필요한 경우가 많습니다. 일반적으로 이러한 워크로드는 그 특성상 '폭증'하기 쉽습니다.
2. 특정 배포 및 데이터 프라이버시 요구 사항이 있는 복잡한 IT 부서를 운영하는 주요 금융 기관을 비롯하여, 포춘지 선정 500대 기업과 대규모 연방 기관들이 컨테이너화된 플랫폼을 통해 Snorkel을 이용하고 있습니다.

Snorkel의 팀은 인프라 비용의 선형적 증가 없이 효율적인 확장이 가능한 시스템을 만드는 데 주력하고 있습니다. 그 결과로, Snorkel은 클라우드 비용 문제를 해결하기 위해 Amazon EKS에서 ML 워크로드에 맞게 조정된 포괄적인 자동 확장 솔루션을 개발했습니다. 이 솔루션은 버스트 컴퓨팅이 요구되는 워크로드를 신속하게 처리했을 뿐만 아니라 비용 절감 목표도 달성해주었습니다.

자동 확장 솔루션 외에 다음과 같은 주요 전략도 클라우드 비용을 40% 이상 절감하는 데 기여했습니다.

• 클라우드 구성 최적화를 통해서 절감형 플랜을 도입하기 위해 엔지니어링 리더 및 AWS 팀과 협력하고 있습니다.
• Prometheus를 사용하여 노드 활용도를 모니터링하고 백엔드 엔지니어와 논의하여 플랫폼 구성 요소 요구 사항을 평가함으로써 리소스 규모를 적절하게 조정합니다.
• Amazon EKS에서 비용 효율적인 가상 머신(VM) 유형으로 전환하고 여러 개의 GPU를 갖춘 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 활용하여 가격 대비 성능을 개선합니다.
• 엔지니어가 고객 응대 팀과 협력하여 유휴 컴퓨팅을 최소화하는 내부 프로세스 수정 사항을 적용했습니다.

이 게시물에서는 ML 시스템을 위한 더 나은 인프라의 설계를 지원하는 데 있어 이러한 확장 문제를 해결하는 Snorkel의 프로세스를 소개합니다. Kubernetes에 대해 잘 모른다면 Snorkel의 Introduction to Kubernetes(Kubernetes 소개) 게시물을 통해 기본적인 정보를 알아보고 Machine learning on Kubernetes: wisdom learned at Snorkel(Kubernetes의 기계 학습: Snorkel이 얻은 지혜) 게시물을 통해 지금까지 Snorkel의 Kubernetes 여정에 대해 알아보세요.

AWS 기반의 Snorkel Flow

실제로 Snorkel Flow와 AWS의 상호 작용은 다음과 같은 순서를 따릅니다. Snorkel Flow 플랫폼은 컨테이너에 크게 의존하기 때문에 AWS로의 마이그레이션은 매우 원활하게 진행되었습니다.

• 사용자가 Amazon Route 53의 규칙에 매핑되는 웹 브라우저를 통해 Snorkel Flow 인스턴스에 접속합니다.
• Route 53이 요청을 Application Load Balancer에 전달합니다.
• 그러면 Application Load Balancer가 공유 EKS 클러스터에서 실행되는 Snorkel Flow 포드에 요청을 전달합니다. Snorkel은 비용을 최적화하기 위해 EC2 인스턴스 유형을 m5에서 m6a로 전환했습니다. 그 결과 동일한 CPU와 RAM의 시간당 비용을 기준으로 할 때 성능은 거의 그대로 유지하면서 컴퓨팅 비용을 10% 절감할 수 있었습니다.
• 또한 단일 g4dn.8xlarge GPU 인스턴스에서 g4dn.12xlarge 다중 GPU 인스턴스로 업그레이드하면서 4배 더 많은 GPU 포드를 제공할 수 있게 되었습니다.
• 각 Snorkel Flow 인스턴스는 Amazon Elastic File System(Amazon EFS) 볼륨을 사용하여 디스크에 파일을 저장합니다.
• EC2 인스턴스의 포드에 있는 자체 호스팅 Redis 대기열에는 들어오는 작업이 보관되어 작업자 포드가 작업을 픽업할 때까지 대기합니다.
• EKS 지표가 Amazon CloudWatch로 푸시되며, 사용자 지정 스크립트가 클러스터 성능 이상 로그에 대한 로그를 모니터링합니다.

이 아키텍처는 Snorkel Flow 사용자에게 안정적이고 빠른 경험을 제공했습니다.

규모 조정 방법 혁신

그림 1에서 설명하는 아키텍처 이전의 Snorkel 인프라 초기 버전에서는 고정 리소스를 사용했습니다. Snorkel의 사용자들은 이러한 버스트 워크로드가 완료되는 데 너무 오래 걸려 경험에 부정적인 영향을 미칠 수 있다는 것을 공감했습니다.

컴퓨팅 리소스의 수동 규모 조정 방식으로는 규모 조정이 불가능하고 오류가 발생하기 쉬워 사용량이 적은 기간에도 클라우드 비용이 계속 상승하는 것으로 판명되었습니다. 클라우드 비용 효율성이 낮았고 성능도 요구 성능에 한참 못 미쳤습니다.

이러한 문제를 해결하기 위해 Snorkel은 다음 섹션에서 설명하는 것처럼 인프라의 여러 수준에서 오토 스케일링을 구현했습니다.

비용 효율성을 염두에 둔 규모 조정이 가능한 인프라 설계

Snorkel Flow의 Kubernetes 배포에는 플랫폼의 다양한 구성 요소를 실행하는 포드가 포함된 EKS 클러스터에서 실행되는 배포 세트가 사용됩니다.

그림 2에서 보듯이, 폭증하는 컴퓨팅 워크로드를 처리하는 데 있어서의 고유한 문제를 해결하기 위해 Snorkel의 팀은 Kubernetes 포드에 대한 새로운 개념을 도입했습니다. 바로 포드를 의미론적으로 ‘픽스드(fixed)’ 포드 또는 ‘플렉시블(flexible)’ 포드로 분류하는 것입니다.

• 픽스드 포드는 중요한 메모리 내 상태(예: 체크포인트 없이 진행 중인 컴퓨팅 작업)를 잃게 되기 때문에, 또는 기본 플랫폼 구성 요소(예: Ray 클러스터용 오케스트레이터)의 방지할 수 있는 가동 중지 시간을 최소화해야 하기 때문에 노드 간에 안전하게 이동할 수 없습니다.
• 플렉시블 포드는 새 노드로 안전하게 이동할 수 있습니다. 이러한 구분은 오토 스케일링과 관련해서 의미가 있는데, 노드 다운스케일링에는 포드가 종료될 때 활용도가 낮은 노드에서 다른 곳으로 포드를 옮기는 동작이 포함되기 때문입니다.

이 픽스드/플렉시블 프레임워크는 Snorkel에 자동화된 클러스터 다운스케일링을 지원하는 수단을 분야별로 제공합니다. 이를 통해 재무 부서에서 매시간 메시지를 보내지 않고도 Amazon EKS에서 클러스터 오토스케일러를 사용할 수 있습니다.

Snorkel의 초기 접근 방식은 EKS 클러스터에 podDisruptionBudgets를 배포하여 클러스터 오토스케일러가 일과 시간 동안 플렉시블 포드를 이동하고 픽스드 포드를 전혀 옮기지 않도록 하는 것이었습니다. 이 접근 방식은 효과적이기는 했지만 이론적인 최적 상태보다 훨씬 적은 수의 노드를 다운스케일링했기 때문에 Snorkel 팀은 만족하지 못했습니다.

이 문제를 해결하기 위해 Snorkel은 픽스드 포드를 작은 픽스드 노드 그룹으로 분리하는 포드 스케줄링 최적화를 적용했습니다. 나머지 플렉시블 노드 그룹에 플렉시블 및 워커 포드(픽스드 포드로 간주되지만 워커 노드 오토 스케일링으로 인해 일시적임)를 스케줄링했습니다.

이러한 변화를 통해 Snorkel은 야간에 플렉시블 노드를 효율적으로 다운스케일링할 수 있었습니다. 결과적으로 플렉시블 포드를 안전하게 이리저리 이동하고 워커 포드 대다수를 축소할 수 있게 되었습니다.

클러스터 노드(즉, 플렉시블 노드) 대다수를 효율적으로 다운스케일링할 수 있게 되면서 Snorkel은 Snorkel Flow 호스팅에 드는 클라우드 비용을 40% 이상 절감한다는 목표를 달성할 수 있었습니다.

Snorkel의 오토 스케일링 솔루션에 대한 세부 정보

Snorkel은 이전 섹션에서 설명한 솔루션 구현을 세 가지 순차적 단계로 나눕니다.

1. 먼저 Snorkel은 워커의 대기열에 있는 작업에 따라 워커 포드를 스케일 업하거나 스케일 다운할 수 있는 맞춤형 Redis 기반 오토 스케일링 서비스인 ‘워커 오토 스케일링’을 구현했습니다.
2. 둘째, Kubernetes 클러스터 오토스케일러가 노드를 스케일 업하는 것은 물론 노드를 스케일 다운할 수도 있도록 Kubernetes 배포를 재구성하여 ‘클러스터 오토 스케일링’을 구현했습니다.
3. 셋째, Snorkel은 픽스드 포드가 나머지 노드의 다운스케일링을 방해하지 않도록 픽스드 포드를 작은 픽스드 노드 그룹으로 그룹화하여 ‘노드 다운스케일링 최적화’를 구현했습니다.

워커 오토 스케일링

Snorkel Flow 플랫폼은 컴퓨팅을 패러다임으로 추상화합니다. 패러다임에서는 작업이 Redis 대기열에서 대기하고 워커는 워커 포드에서 프로세스로 실행됩니다.

Snorkel은 Snorkel Flow의 백엔드 API에서 반복 함수를 실행하여 워커 포드에 워커 오토 스케일링 솔루션(그림 3)을 구현했습니다. 이 함수는 몇 초마다 Kubernetes 클러스터와 Redis에서 업스케일링 및 다운스케일링 적격성을 확인합니다.

하나 이상의 관련 Redis 기반 대기열에 대기 중인 작업이 있는 경우, 이 함수는 이러한 작업을 처리할 추가 워커 포드를 프로비저닝하도록 Kubernetes API에 요청합니다. Redis 대기열이 비어 있고 작업 레지스트리에 실행 중인 작업이 없는 경우, 워커 포드를 삭제하여 예약된 CPU 및 RAM 리소스를 확보하도록 Kubernetes API에 요청합니다.

그림 4에서 보듯이 이 워커 오토 스케일링 조정 구현이 도입되면서 Snorkel Flow의 워커 포드는 일시적인 형태로 바뀌어 작업을 처리해야 할 때만 클러스터에 나타나게 되었습니다.

클러스터 오토 스케일링

PodDisruptionBudget 리소스는 특정 시점에 사용할 수 없도록 하려는 포드 복제본의 최대 수를 지정하여 특정 포드를 가동 중단(예: 자발적 재시작)으로부터 보호합니다. 그림 5에서 보듯이, 배포의 경우 이 값을 0으로 명시적으로 설정하면 클러스터 오토 스케일러가 배포의 포드를 실행하는 노드를 다운스케일링하지 않게 됩니다.

호스팅된 Snorkel Flow 인스턴스에 이 리소스를 구현함으로써 클러스터 오토스케일러는 사용률이 낮은 노드를 안전하게 다운스케일링할 수 있었습니다. 하지만 Snorkel이 실현한 비용 절감은 미미했습니다. 모든 Snorkel Flow 포드가 관련 podDisruptionBudget으로 보호되어 있었기 때문에 여전히 대부분의 노드를 다운스케일링할 수 없었습니다.

Snorkel의 팀은 면밀한 조사를 통해 이러한 보호 장치가 항상 존재할 필요는 없다는 것을 깨달았습니다. 워크로드는 폭증하고 Snorkel Flow와의 사용자 상호 작용은 대부분 고객의 영업일에 이루어집니다. 즉, 업무 시간 외에는 이러한 보호 기능을 완화해도 무방합니다. 워커 오토 스케일링과 마찬가지로 Snorkel은 사용 불가능한 포드 복제본의 최대 수를 0에서 1로 높여 인스턴스의 플렉시블 포드에 대해 야간에 p‘비활성화’하는 반복 기능을 구현했습니다(그림 6). 이전의 워커 오토 스케일링 솔루션과 ClusterAutoscaler 및 PodDisruptionBudget 기능을 함께 사용함으로써 활용도가 낮은 워커 노드를 이전보다 더 많이 다운스케일링할 수 있었습니다. Snorkel Flow를 클라우드에 배포하는 고객은 필요에 따라 이를 구성할 수 있습니다.

노드 다운스케일링 최적화

Snorkel은 이러한 개선에도 불구하고 활용도가 낮은 노드 대다수가 전혀 축소되지 않고 있음을 확인했습니다.

Snorkel은 추가 조사를 통해 동일한 노드를 차지하는 픽스드 및 플렉시블 포드로 인해 이러한 문제가 발생한다는 사실을 깨달았습니다. 플렉시블 포드가 포함된 노드에 유사 무작위 방식으로 할당된 픽스드 포드는 활용도가 낮더라도 해당 노드를 ‘고정’하여 다운스케일링되는 것을 방지하기 때문에 문제가 되었습니다. 픽스드 포드 스케줄링에 대한 이러한 통제력 부족으로 인해, 컴퓨팅 파워가 해당 시점에 필요한 양을 초과함에도 불구하고 클러스터 노드 대다수를 다운스케일링할 수 없는 기간이 발생했습니다.

Snorkel은 이 문제를 해결하기 위해 podAffinity Kubernetes 리소스를 활용했으며, 이를 통해 특정 노드에서 이미 실행 중인 다른 포드의 레이블을 기반으로 포드를 실행하기에 가능한 노드를 제한할 수 있었습니다. 픽스드 포드와 플렉시블 포드를 구분하기 위해 포드에 레이블을 추가하고, 배포 구성에 podAntiaffinity 스탠자를 추가하여 플렉시블 포드를 실행하는 노드에서 픽스드 포드가 스케줄링되지 않도록 했으며, 그 반대의 경우도 마찬가지로 스케줄링되지 않도록 했습니다.

Snorkel AI는 podAffinities를 통해 노드를 두 개의 기능 그룹으로 나눌 수 있었습니다. 그중 하나는 노드 간에 안전하게 이동할 수 없는 픽스드 포드가 포함된 고정된 노드 그룹(예: 캐시로 인한 Redis)이고, 다른 하나는 임시포드(예: 워커 포드)이거나 업무 시간 외에 이동해도 안전한 ‘플렉시블’ 포드(예: 야간인 경우)를 포함하는 플렉시블 노드 그룹입니다.

플랫폼 유지 보수 중 수동 조작으로는 가능하지만, Snorkel은 픽스드 노드를 자동으로 다운스케일링할 수 없습니다. 하지만 이 솔루션을 사용하면 이제 이동 불가능한 포드를 픽스드 노드로 분리했기 때문에 플렉시블 노드를 자동으로 다운스케일링할 수 있습니다.

결론

Snorkel과 AWS Startup 팀은 이러한 사고 프로세스와 솔루션을 공유함으로써 다른 Startup이 ML 워크로드를 위한 더 나은 인프라를 구축하는 데 도움을 줄 수 있기를 바랍니다. 세계 여러 조직의 프로덕션 환경에 ML, 대규모 언어 모델 및 기타 FM이 도입됨에 따라 이러한 인프라의 중요성이 빠르게 커지고 있습니다.

AWS re:Invent 2023에 참가하시나요? 이 배포는 Snorkel의 Navigating the future of AI: Deploying generative models on Amazon EKS(AI의 미래 탐구: Amazon EKS에서 생성형 모델 배포, 세션 CON312)에서 중점적으로 다룰 예정입니다. 꼭 확인해 보세요!

Snorkel의 이러한 기술적 비전을 현실로 만드는 데 도움을 준 David Hao, Edmond Liu, Alec Xiang에게 많은 감사를 드립니다. 앞서 언급한 Matt Casey, Henry Ehrenberg, Anthony Bishopric, 그리고 Snorkel Infrastructure Engineering 팀의 모든 분과 이 기사에 대해 사려 깊은 피드백을 보내주신 모든 분들께도 특별히 감사드립니다.