Azure Virtual Machines

서비스를 운영하려면 어딘가에 코드가 실행될 서버가 있어야 합니다. 물리 서버를 직접 구매하면 용량을 예측해야 하고, 초기 비용이 크며, 트래픽이 줄어도 장비는 그대로 남습니다. 반대로 트래픽이 급증하면 서버를 추가하기까지 수 주가 걸리기도 합니다. 거기에 장비 고장, OS 패치, 데이터센터 전력과 냉각까지 직접 관리해야 합니다. 이 상황에서 필요한 건 서버의 사양과 OS를 직접 고를 수 있으면서도, 물리 인프라 관리 부담은 클라우드에 넘길 수 있는 방법입니다.

클라우드 이전 시대에 서버를 쓰려면 하드웨어를 직접 구매하고 데이터센터에 입주시킨 다음, OS 설치부터 네트워크 연결까지 직접 해야 했습니다. 서비스가 성공하면 서버를 추가하는 데 몇 주가 걸렸고, 실패하면 투자한 장비는 유휴 자산이 됐습니다. 이 문제는 스타트업만의 것이 아니라, 대기업도 프로젝트마다 용량 산정을 잘못 맞히면 예산이 낭비됐습니다. 가상화 기술이 성숙하면서 하나의 물리 서버 위에 여러 가상 서버를 올릴 수 있게 되었고, 클라우드 공급자가 이 가상화를 서비스로 제공하면서 분 단위로 서버를 만들고 없앨 수 있는 모델이 생겼습니다. Azure VM은 이 흐름 위에 있으며, '서버를 소유하지 않고 빌려 쓴다'는 전환의 가장 기본적인 형태입니다.

Azure VM은 물리 서버 위의 하이퍼바이저가 가상 하드웨어를 만들어 독립된 서버처럼 동작하게 합니다. 사용자는 VM 시리즈(범용, 컴퓨팅 최적화, 메모리 최적화, GPU 등)에서 워크로드에 맞는 CPU·메모리 조합을 고르고, 원하는 OS 이미지를 올립니다. VM이 시작되면 Virtual Network 안의 서브넷에 배치되며, 네트워크 보안 그룹(NSG)이 인바운드·아웃바운드 트래픽을 필터링합니다. 스토리지는 OS 디스크와 데이터 디스크가 분리된 관리 디스크(Managed Disk)로 처리되고, 디스크 성능 등급(Standard HDD, SSD, Premium SSD)도 별도로 선택합니다. 여러 대의 VM을 가용성 세트나 가용성 영역에 분산 배치하면 하드웨어 장애 시에도 일부 인스턴스가 살아남아 서비스가 유지됩니다. 즉 VM 하나는 단독 서버가 아니라, 네트워크·보안·스토리지·가용성 구성 요소가 조합된 인프라 단위입니다.

Azure VM과 App Service는 둘 다 코드를 실행하는 컴퓨팅 서비스라는 점에서는 같습니다. 차이는 제어 범위와 관리 부담의 균형에 있습니다. VM은 OS 선택, 커널 설정, 미들웨어 설치, 네트워크 구성까지 직접 관리하므로 자유도가 높지만, 패치와 보안 업데이트도 운영자의 몫입니다. App Service는 런타임과 배포 파이프라인을 플랫폼이 관리하므로 인프라 신경을 덜 쓰지만, OS에 직접 손댈 수 없고 지원하는 런타임과 구성에 맞춰야 합니다. 특정 OS 설정이 필요하거나, 플랫폼이 지원하지 않는 소프트웨어를 설치해야 하거나, 기존 온프레미스 환경을 그대로 옮겨야 하면 VM이 적합하고, 웹 앱을 빠르게 배포하고 인프라 관리를 최소화하고 싶다면 다른 선택이 맞습니다.

Azure VM은 OS 수준의 제어가 필요한 거의 모든 상황에서 출발점이 됩니다. 온프레미스에서 돌리던 Windows Server 기반 애플리케이션을 그대로 클라우드로 옮기는 마이그레이션, 특정 버전의 데이터베이스나 미들웨어를 직접 설치해야 하는 레거시 시스템, GPU가 필요한 머신러닝 학습 환경이 대표적인 장면입니다. 개발·테스트 환경을 필요할 때만 켜고 쓴 만큼만 비용을 내는 것도 물리 서버 시절에는 어려웠던 방식입니다. 반면 VM은 OS 패치, 보안 업데이트, 장애 대응을 운영자가 직접 챙겨야 하므로, 관리 인력과 운영 프로세스가 따라오지 않으면 부담이 커집니다. 웹 앱처럼 표준 런타임 위에서 돌아가는 워크로드라면, VM이 아닌 관리형 플랫폼이 운영 비용 면에서 더 효율적인 경우가 많습니다.

다음에 볼 개념

함께 보면 좋은 개념