한계를 넘어 확장하기: 대규모 워크로드에 Azure Compute Fleet이 필요한 이유

By Mirko Peters · 2026-08-13

고도화된 클라우드 아키텍처를 계속 살펴보는 이번 글에 다시 오신 것을 환영합니다. 최신 팟캐스트 에피소드 “Azure Compute Fleet – Simply Explained”에서는 대규모 …

Automatically translated with AI from the original post. Read the English original

고도화된 클라우드 아키텍처를 계속 살펴보는 이번 글에 다시 오신 것을 환영합니다. 최신 팟캐스트 에피소드 Azure Compute Fleet – Simply Explained에서는 오늘날 기업이 클라우드 인프라를 다룰 때 마주하는 큰 과제를 다뤘습니다. 대규모 배치 작업, 고성능 컴퓨팅 시뮬레이션, 또는 대규모 데이터 처리 파이프라인을 위해 가상 머신을 수백 또는 수천 개 한 번에 프로비저닝하려고 해 보셨다면, 갑자기 용량 한계에 부딪히는 답답함을 이미 잘 아실 것입니다. 이번 블로그 글에서는 그 내용을 더 자세히 다루며, 기존 방식이 왜 부족한지, 그리고 Azure Compute Fleet이 클라우드에서 대규모 컴퓨팅 리소스를 확보하고 관리하는 방식을 어떻게 근본적으로 바꾸는지 설명하겠습니다.

Azure Compute Fleet이란 무엇인가?

Azure Compute Fleet은 대규모 용량 문제를 해결하기 위해 특별히 설계된 관리형 서비스입니다. 워크로드를 0개에서 수천 개의 워커로 즉시 확장해야 할 때, 일반적인 배포 방식은 쉽게 병목이 될 수 있습니다. 가상 머신 한 대를 만드는 것은 간단하지만, 특정 SKU의 동일한 가상 머신 1,000대를 한 리전에서 확보하는 것은 전혀 다른 문제입니다. Azure Compute Fleet은 클라우드에 던지는 근본적인 질문을 바꿉니다. “이 정확한 크기의 가상 머신 1,000대를 어떻게 확보할까?”라고 묻는 대신, “허용 가능한 여러 옵션을 활용해 워크로드에 필요한 컴퓨팅 용량을 어떻게 확보할까?”라고 묻게 됩니다. 전체 용량 요구 사항, 허용 가능한 가상 머신 크기, 리전 선호도, 그리고 온디맨드와 비용이 낮은 Spot 가격 중 어느 쪽을 얼마나 수용할지를 정의하면, Azure는 여러 가용성 풀을 지능적으로 탐색해 애플리케이션에 필요한 리소스를 확보할 수 있습니다.

유연성이 중요한 이유

Compute Fleet이 얼마나 강력한지 이해하려면 클라우드 용량이 어떻게 작동하는지 자세히 살펴봐야 합니다. 가상 머신 SKU는 CPU, 메모리, 스토리지 아키텍처, 프로세서 제품군의 특정 조합을 나타냅니다. 자동화 스크립트가 특정 SKU 하나만 요청하면, Azure는 정확히 일치하는 항목만 찾을 수 있습니다. 해당 제품군의 대상 리전 수요가 높으면 배포는 대기열에서 멈추거나 완전히 실패합니다. Compute Fleet은 허용 가능한 가상 머신 크기를 여러 개 지정할 수 있게 하여 유연성을 제공합니다. 워크로드가 이러한 서로 다른 하드웨어 구성에서도 성공적으로 실행되도록 설계되어 있다면, Azure는 워커를 동적으로 분산할 수 있습니다. 대규모 환경에서는 이러한 유연성이 필요한 총 컴퓨팅 성능을 필요한 시점에 확보할 가능성을 기하급수적으로 높여 줍니다.

하나의 Fleet에서 최대 10,000개의 VM

대규모 인프라를 수작업으로 관리하면 운영 피로가 쌓일 수밖에 없습니다. 여러 구성에 걸쳐 배포 재시도, 대체 가상 머신 크기, 모니터링을 처리하는 맞춤형 오케스트레이션 스크립트를 작성하다 보면 금방 유지 관리가 불가능한 악몽이 됩니다. Compute Fleet은 단일 Fleet 요청에서 최대 10,000개의 가상 머신을 지원함으로써 이러한 운영 부담을 줄이도록 설계되었습니다. Fleet 매개 변수를 한 번 정의하면 Azure가 허용된 모든 선택지에서 사용 가능한 인벤토리를 평가하고, 최적의 리소스 조합을 자동으로 찾아 필요한 기반 가상 머신 그룹을 생성합니다. 이 기본 기능 덕분에 엔지니어링 팀은 인프라 할당 오류를 해결하느라 수많은 시간을 쓰는 대신 실제 워크로드에 집중할 수 있습니다.

Compute Fleet이 하지 않는 일

Azure Compute Fleet은 용량 확보에 있어 판도를 바꿀 기능이지만, 그 한계도 분명히 이해해야 합니다. Compute Fleet은 용량 문제를 해결할 뿐이며, 애플리케이션 아키텍처 전체를 결정하거나 대체하지 않습니다. 각 워커가 실행하는 데 필요한 가상 머신 이미지, 네트워크 구성, 보안 그룹, 애플리케이션 소프트웨어는 여전히 사용자가 직접 제공해야 합니다. Compute Fleet은 워커가 시네마틱 시각 효과를 렌더링하는지, 복잡한 금융 계산을 수행하는지, 자동화된 회귀 테스트를 실행하는지, 원시 과학 텔레메트리를 분석하는지 본질적으로 알지 못합니다. 또한 로드 밸런서, 내구성 있는 메시지 큐, 애플리케이션 로직, 재해 복구 메커니즘과 같은 핵심 아키텍처 구성 요소를 대신하지도 않습니다. Compute Fleet의 유일하고 명확한 역할은 여러 허용 가능한 구성이 존재할 때 대규모 컴퓨팅 용량을 확보하고 관리하는 것입니다.

허용 가능한 VM 크기 선택

효과적인 플릿 배포를 설계하려면 가장 중요한 아키텍처 결정부터 시작해야 합니다. 바로 애플리케이션이 실제로 사용할 수 있는 VM 크기를 정하는 것입니다. 플릿 규모에서는 개인적 선호에 따라 특정 프로세서 모델을 확보하는 데 집중하기보다, 소프트웨어 요구 사항을 철저히 점검하는 것이 우선입니다. 애플리케이션이 실제로 의존하는 CPU 코어 수, 메모리 임계값, 로컬 스토리지 성능 지표, 가속기 유형은 무엇입니까? 여러 VM 패밀리가 이러한 운영 기준을 충족한다면, 모두 허용하는 것이 Azure에 훨씬 넓은 검색 범위를 제공합니다. 다만 포함하는 모든 크기는 엄격하게 검증해야 합니다. 애플리케이션이 특정 명령어 세트, 전용 드라이버, 고유한 스토리지 구성, 또는 특정 하드웨어 기능을 요구한다면, 단지 저렴해 보인다는 이유만으로 VM 패밀리를 플릿 구성에 추가해서는 안 됩니다.

용량 대 가격

또 다른 중요한 설계 고려 사항은 즉각적인 용량 필요와 전체 비용 최적화의 균형을 맞추는 것입니다. 워크로드마다 요구하는 배포 전략은 전혀 다릅니다. 예를 들어, 야간에 수행하는 금융 리스크 계산은 실행 시간이 엄격하게 정해져 있어, 다음 날 아침 글로벌 시장이 열리기 전에 반드시 완료되어야 할 수 있습니다. 이러한 특정 시나리오에서는 코어당 가장 낮은 가격을 확보하는 것보다 보장된 용량을 즉시 확보하는 것이 훨씬 더 중요합니다. 반면 일정 조정의 여유가 큰 워크로드도 있습니다. 백그라운드 테스트, 장기 시뮬레이션, 누적된 데이터 처리, 임시 개발 환경은 전체 용량 확보가 다소 지연되더라도 인프라 비용을 크게 낮출 수 있다면 대체로 감수할 수 있습니다. Compute Fleet은 조직이 이러한 서로 다른 운영 우선순위에 맞춰 배포를 조정할 수 있는 아키텍처상의 자유를 제공합니다.

속성 기반 VM 선택

구성을 한층 더 강력하게 만들 수 있도록, Azure는 최근 팟캐스트 자료에서 강력한 미리 보기 기능으로 소개된 속성 기반 VM 선택 방식을 제공합니다. 수십 개의 개별 정확한 VM SKU를 수동으로 나열하도록 요구하는 대신, 이 기능을 사용하면 일반화된 특성을 정의할 수 있습니다. 최소 및 최대 vCPU, 메모리 범위, 로컬 NVMe 스토리지 요구 사항, 또는 특수 GPU 가속기와 같은 매개변수를 지정할 수 있습니다. 그러면 Azure가 해당 정확한 속성 정의와 일치하는 VM 크기를 동적으로 식별하여 사용합니다. 이는 Microsoft가 더 새롭고 효율적인 VM 세대를 클라우드에 도입할 때 놀라운 미래 대응력을 제공합니다. 다만 애플리케이션은 새로 매칭된 하드웨어 프로필에 대해 여전히 적절한 검증을 거쳐야 합니다.

온디맨드 VM

견고한 플릿을 구축하려면 서로 다른 구매 모델이 맡는 역할을 이해해야 합니다. 온디맨드 가상 머신은 플릿의 안정적이고 탄탄한 기반을 형성합니다. 온디맨드 VM을 요청하면 표준의 예측 가능한 요금을 지불하며, Azure는 다른 고객의 수요가 급증한다는 이유만으로 해당 리소스를 회수하지 않도록 보장합니다. 따라서 온디맨드 용량은 워크로드가 항상 운영 상태를 유지하는 데 필요한 최소한의 기준 컴퓨팅 리소스에 이상적입니다. 작업 코디네이터, 메시지 큐 리스너, 기본 기준 워커와 같은 핵심 인프라 구성 요소는 중단 없는 감시를 보장하기 위해 거의 항상 온디맨드 용량을 사용해야 합니다.

스팟 VM

구매 방식의 반대편에는 Spot 가상 머신이 있습니다. Spot VM을 사용하면 사용되지 않는 Azure 컴퓨팅 용량을 큰 폭의 할인가로 활용할 수 있으며, 표준 온디맨드 가격과 비교해 최대 90%까지 절감할 수 있는 경우가 많습니다. 이처럼 큰 비용 절감의 대가는 중단 위험입니다. Azure는 지역 수요에 따라 해당 물리적 리소스가 다시 필요할 때 짧은 사전 통지만으로 Spot 용량을 회수할 권리를 가집니다. 따라서 Spot VM은 작업자가 작업 도중 사라져도 치명적인 장애로 이어지지 않는 내결함성 워크로드에 매우 적합하며, 중단된 작업을 안전하게 재시도하도록 아키텍처가 구성되어 있어야 합니다.

Spot 용량과 온디맨드 용량 혼합

순수 온디맨드 전략과 Spot 중심 접근 방식 중 하나를 반드시 선택할 필요는 없습니다. 사실 가장 탄력적인 아키텍처는 두 구매 모델을 하나의 일관된 플릿으로 결합합니다. 지속적으로 실행되는 컨트롤 플레인과 기본 작업자에는 온디맨드 VM을 사용하면 예측 가능한 최소 처리량을 보장할 수 있습니다. 동시에 Spot VM으로 플릿을 대규모로 확장하면 일반 비용의 일부만으로 대규모 연산 확장을 처리할 수 있습니다. 용량이 부족한 시기에 Azure가 Spot 작업자 일부를 회수하더라도 핵심 온디맨드 작업자는 중단 없이 계속 처리하므로, 비용 절감과 운영 안정성 사이에서 훌륭한 경제적 균형을 달성할 수 있습니다.

중단을 고려한 설계

Azure Compute Fleet은 기반 용량 할당을 원활하게 관리하고 Spot 중단에 대한 사전 알림도 처리하지만, 개별 작업자의 메모리에만 저장된 애플리케이션 데이터를 마법처럼 보호해 주지는 않습니다. 플릿의 장점을 제대로 활용하려면 워크로드를 작업자 종료를 처리할 수 있도록 처음부터 설계해야 합니다. 예를 들어 분산 비디오 렌더링 파이프라인을 생각해 보겠습니다. 프로젝트가 프레임 단위 렌더링 작업으로 나뉘어 있고 프레임 412를 처리하던 중 Azure가 Spot VM을 회수했다면, 해당 작업은 사용 가능한 다른 작업자가 가져갈 수 있도록 중앙 메시지 큐에 자동으로 다시 들어가야 합니다. 이와 같은 아키텍처 패턴은 과학 시뮬레이션, 자동화된 소프트웨어 빌드, 지속적 통합 테스트, 대규모 데이터 분석에도 똑같이 적용됩니다.

상태는 작업자 외부에 보관

동적인 플릿 환경에서 살아남으려면 애플리케이션은 한 가지 황금률을 따라야 합니다. 상태를 전적으로 작업자 외부에 보관하는 것입니다. 중요한 영구 데이터를 로컬 임시 디스크에 의존하지 마십시오. 대신 Azure Blob Storage, 관리형 관계형 데이터베이스, 분산 NoSQL 저장소와 같은 내구성 있는 스토리지 솔루션을 활용해 원본 데이터(source of truth)를 유지하십시오. 내구성 있는 큐를 사용해 플릿 전체에 작업을 분배하고, 오래 실행되는 작업 중에는 작업자가 정기적으로 체크포인트를 기록하도록 하십시오. 또한 작업을 멱등성(idempotent)을 갖도록 설계하십시오. 즉, 중복 레코드를 만들거나 출력이 손상되지 않고 여러 번 실행할 수 있어야 합니다. Spot VM이 예기치 않게 사라지더라도 복구할 수 없는 몇 시간 분량의 처리 시간이 아니라, 현재 진행 중이던 아주 작은 부분의 작업만 잃게 됩니다.

Compute Fleet과 가상 머신 확장 집합 비교

이 기술을 살펴볼 때 엔지니어들이 흔히 묻는 질문은 Compute Fleet이 Azure Virtual Machine Scale Sets(VMSS)와 어떻게 다른가 하는 것입니다. 두 서비스 모두 가상 머신 그룹을 관리하지만, 근본적으로 다른 문제를 해결하도록 설계되었습니다. Virtual Machine Scale Sets는 보통 특정 애플리케이션 계층에서 시작합니다. 로드 밸런서 뒤에 웹 앱, 마이크로서비스 API, 또는 기업 라인 오브 비즈니스 애플리케이션을 배포하면, VMSS는 들어오는 네트워크 트래픽이나 CPU 임곗값에 따라 동일한 인스턴스 수를 늘리거나 줄입니다. 반면 Compute Fleet은 전혀 다른 전제에서 출발합니다. 방대한 분산 작업을 처리하기 위해 유연한 컴퓨팅 용량 풀을 얼마나 빠르게 확보할 수 있을까 하는 질문입니다.

Virtual Machine Scale Sets를 사용해야 하는 경우

Virtual Machine Scale Sets는 인스턴스가 동일한 역할을 수행하고 사용자 트래픽에 동적으로 대응해야 하는, 장기간 연속 실행되는 애플리케이션 계층에 여전히 가장 확실한 표준입니다. 이상적인 사용 사례로는 고객 대면 웹 애플리케이션, 퍼블릭 API, 전자상거래 스토어프런트, Azure LoadBalancer 또는 Application Gateway 뒤에 위치한 백엔드 애플리케이션 서버가 있습니다. 이러한 환경에서는 지속적인 애플리케이션 상태 유지, 실시간 클라이언트 트래픽의 원활한 라우팅, 동일한 인스턴스 전반에 걸친 롤링 운영 체제 업그레이드 관리가 주요 설계 기준이 됩니다.

Compute Fleet을 사용해야 할 때

반대로 Compute Fleet은 비동기, 배치 지향 또는 독립적인 작업을 위해 대량의 원시 컴퓨팅 성능을 확보하는 것이 주요 과제일 때 가장 빛을 발합니다. 일반적인 시나리오로는 고성능 컴퓨팅 클러스터, 금융 배치 처리, 분자 모델링 시뮬레이션, 대규모 데이터 수집 파이프라인, 자동화된 테스트 스위트, 미디어 렌더링 팜, 임시 작업자 풀이 있습니다. 이러한 아키텍처에서 작업자는 개별 작업 단위를 가져와 처리하고, 최종 결과를 영구 스토리지에 기록한 뒤 즉시 다음 작업으로 넘어갑니다. 작업자가 사라지더라도 시스템은 해당 작업 단위를 사용 가능한 다른 노드에 할당하기만 하면 됩니다.

두 가지 모두 사용할 수 있습니다

최신 클라우드 아키텍처의 가장 큰 장점은 도구 하나만 골라야 할 필요가 없다는 점입니다. Azure Compute Fleet과 Virtual Machine Scale Sets는 상호 배타적이지 않으며, 같은 엔터프라이즈 생태계 안에서 조화롭게 함께 동작할 수 있습니다. 예를 들어 정교한 엔터프라이즈 애플리케이션은 고가용성 웹 프런트엔드와 API 계층을 구동하기 위해 Virtual Machine Scale Set을 사용하면서, 동시에 백그라운드에서 Azure Compute Fleet을 실행해 대규모 야간 데이터 웨어하우징, 배치 보고서 생성, 복잡한 시뮬레이션 같은 고부하 작업을 처리할 수 있습니다. 각 계층에 맞는 도구를 선택하면 사용자에게 매우 민첩하게 반응하면서도 규모가 커져도 비용 효율적인 아키텍처를 구축할 수 있습니다.

이러한 아키텍처를 더 깊이 살펴보고 실무 구현 팁을 듣고 싶으시다면, 전체 보완 팟캐스트 에피소드인 Azure Compute Fleet – Simply Explained를 꼭 들어 보시기 바랍니다. 잊지 마시고 방송을 응원해 주시고, 클라우드 엔지니어링에 관한 더 많은 심층 분석을 기대해 주세요!

이 팟캐스트의 후원자가 되어 주세요: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.