Azure Virtual Machine Scale Set #1 – 개요

같은 역할을 하는 VM이 수십, 수백대가 필요한 상황이 있을 수 있다. 규모가 큰 서비스 인프라를 운영하거나 또는 평소에는 2-3개의 VM으로 운영되다가 필요할 때 수십대의 VM으로 확장해서 사용해야하는 애플리케이션도 있다. 이렇게 VM의 개수가 많아지면 관리의 문제가 생긴다. 한꺼번에 만드는 건 Azure Poweshell이나 CLI를 통해서 한다고 하지만 VM 업데이트, 자동 확장(Auto Scale) 등 관리요소가 많아지고 스크립트도 많아진다. 이런 상황에 도움을 주기 위해 Azure Virtual Machine Scale Set(이하 VMSS)이 있다.

어떤 때에  Scale In/Out이 쉬운 수십대의 VM을 사용하게 될까? Azure 의 어떤 서비스는 VMSS를 사용해서 만들어진다. PaaS 서비스를 구축하는데 VMSS 가 사용되는 경우도 있다. 여기에 몇 가지 예가 있다.

  • Azure Service Fabric 은 VMSS로 VM을 생성하여 클러스터를 만든다.
  • Azure Batch 는 계산노드(Compute Node)를 VMSS 로 만든다.
  • Azure의 Pivotal Cloud Foundary는 인프라를 생성할 때 VMSS를 사용한다.
  • MRI 에서 나온 이미지를 VMSS를 사용하여 VM들을 Scale out 해서 처리하고 다시 자동으로 Scale In 하는 사례
  • 대용량의 데이터 분석을 위해 분석 VM 노드를 VMSS로 Scale Out/In을 처리
  • 게임서버를 테스트 하기 위한 클라이언트를 VMSS를 이용하여 VM 400대에서 수행

VMSS의 특징

  • 최대 1000개의 VM 생성
  • Custom VM을 이용하여 생성 가능 (Custom VM이미지의 경우 300대가 최대)
  • 서비스 중지 없이 업데이트 가능(Rolling Update)
  • 동적으로 VM 인스턴스 갯수를 관리하여 비용 절감
  • Auto Scale: 특정 조건에서 VM 개수를 자동으로 증가/감소
  • Azure Load Balancer와 통합 (100대 이하)
  • VMSS 전체 VM을 대상으로 Auto Scale, 업데이트가 가능하다. 개별 VM을 새로운 이미지로 업데이트하거나 자동 크기조정을 할 수는 없다.
  • Managed Disk를 사용하는 것이 유리하다.

Azure Portal에서 VMSS 생성

Azure Portal에서 VMSS를 생성할 수 있다. OS, 인스턴스 갯수(VM 갯수), 위치, ID/Pwd, 인스턴스 크기 등을 정해주면 만들 수 있다. 하지만 Portal UI에서는 Custom VM 이미지를 사용할 수 가 없고 세밀한 설정이 어렵다. Powershell 또는 CLI로 스크립트를 이용하거나 ARM Template을 이용하는 것이 바람직하다.

100개 인스턴스가 넘는 크기 조정 사용

대규모 Virtual Machine Scale Sets와 작동 문서에 잘 설명이 되어 있다. 100개 이하와 이상의 VMSS는 차이가 있다.

100개 이하에서는 Load Balancer를 붙일 수 있고 Load Balancer를 설정하여 부하를 분산하고 Probe 설정을 통해 문제가 있는 VM에 로드를 주지 않을 수 있다. 100개 이하의 VM은 하나의 Placement Group 안에 배치되고 각각 5개의 Fault Domain / Update Domain 에 VM들이 배치된다.  LB는 표준크기를 사용할 수 있는데 표준 크기의 LB의 Back end pool 의 최대 크기가 100개라는 제약이 적용되기 때문이기도 하다.  Load Blancer가 붙어있고 Probe 설정이 되어 있어야 자동 Rolling Update가 가능하다.

하지만 100대가 넘어가면 Placement Group이 여러개가 되고 Load Balancer를 붙일 수 없다. 최대 1000대의 VM이 생성되지만 내가 만든 Custom 이미지를 사용하는 경우 최대 300대까지 배포가 가능하다. 위 그림은 97대의 VM을 Load Balancer 없이 100대 이상 사용 옵션으로 만든 후의 배포 모습이다. 초록색 점이 VM 한대 인데 3개의 Placement Group이 만들어지고 VM이 적절히 분산되어 있다.

100대 이상과 이하를 구분하여 생성할 때 스크립트에서 쓰는 스위치는 singlePlacementGroup  이다. True로 설정하면 100대 이하 False로 설정하면 100대 이상이고 False일 때 LB를 만들지 않아야 오류가 나지 않는다.

VM의 생성은 병렬로 만들어 지기 때문에 빠르게 수백대의 VM을 생성할 수 있다.

오버프로비전(OverProvisioning)

VM을 만들어 내는 걸 Provisioning 한다고 한다. SSD 를 가진 하나의 VM은 99.5% 임을 알고 있을 것이다. 이걸 10대 생성한다면 (99.5%)^10 = 95%, 100대 생성한다면 (99.5%)^100 = 60% 로 SLA가 떨어진다. 계산이 그렇다는 것이다. VM 생성이 실패할 확률이 높아 진다는 얘기고 실제로 큰 문제가 발생하지는 않는다. 하지만 이를 보완할 필요가 있기 때문에 OverProvisioning을 한다. 만약 100대를 만든다면 경우에 따라 다르지만 120대를 생성요청하고 먼저 성공한 100대의 VM만 남기는 식이다. 이렇게 Provisioning의 실패율을 현저히 낮출 수 있다.  여기서 추가로 만들기 요청된 20 대에 대해서는 비용이 청구되지는 않는다. OverProvisioning은 기본값이 True로 되어 있고 끌 수도 있다. 아래 그림은 100대를 만들어야 하지만 OverProvisioning으로 110대가 만들어졌다.

OverProvisioning 를 Off 로 설정해서 사용하지 않아야 하는 때는 어떤 상황일까? 구독의 Core 제약이 걸려서 추가로 VM이 설정되지 않거나 가상네트워크의 서브넷 개수가 적어서 추가 VM을 넣을 수 없는 경우 등이 그렇다.

Managed Disk 사용

VMSS에서 Managed Disk를 사용하는 것이 유리하다. 100대 이상의 인스턴스를 만들 때는 반드시 Managed Disk를 사용해야 한다. Unmanaged Disk는 Storage Account를 만들어야하고 Storage Account는 자신의 네트워크 제약 때문에 최대 20대 이하의 VM 디스크를 넣어야 한다. Unmanaged Disk를 사용해도 VMSS가 알아서 Storage Account를 관리해주기는 하지만 굳이 Unmanaged Disk를 사용할 이유는 찾지 못하겠다.

Custom VM의 생성

여러대의 VM을 생성해서 내 인프라를 꾸미는데 아무것도 설치되지 않은 Windows Server 2016을 사용하고 100대를 하나씩 RDP로 들어가서 관리를 할 수 는 없다. 거의 불가능한 작업이고 실수를 할 위험이 있다. 따라서 자동으로 이 설정을 해줘야 한다. 두가지 방법이 있다. Custom Script Extension을 사용하는 방법이 있고 VM 이미지를 사용하는 방법이 있다.

Custom Script Extension

VM의 확장(Extension)이고 VM이 Provision 되면 설정된 스크립트를 다운받아서 실행한다. Windows VM이라면 PowerShell, Linux라면 Bash 스크립트를 실행하는 식이고 이 스크립트에서 해당 VM에 필요한 모든 미들웨어와 데이터, 내 Application을 설치하고 설정까지 자동으로 실행하는 것이다. 스크립트를 만드는데 노력이 들어가는 일이지만 VMSS의 최대값이 1000대까지 VM을 만들 수 있고 코드이기 때문에 업데이트와 관리가 쉽다.

VM 이미지 사용

VM을 하나 만들어서 필요한 모든 미들웨어와 Application을 설치한 후에 VM을 이미지로 만들고 VMSS 가 VM을 생성할 때 이 이미지를 사용하는 방법이다. 스크립트보다는 빠르게 적용할 수 있다. 다만 Applicsation의 업데이트가 있을 때 이미지를 다시 생성해야 한다. 이 부분을 어느정도 스크립트로 작성해 놓으면 좋다. 단점은 최대 300대까지만 생성이 가능하다.

Azure 가상 네트워크

VMSS가 VM을 생성하지만 그 VM들은 Azure의 가상네트워크의 하나의 Subnet 안에 모두 만들어진다. 여기서 주의할 것은 Subnet의 IP 갯수다. 300대를 만들어야 하는데 Subnet의 설정이 10.0.0.0/24 (256개 영역. 실제로는 251개 사용 가능)로 되어 있다면 오류가 발생한다. 따라서 가상네트워크를 미리 만들면서 네트워크 주소 범위와 서브넷을 잘 설정해놓고 VMSS를 만들 때 그 서브넷을 지정해서 만드는 게 실수를 줄여준다. Subnet의 IP 개수는 필요한 것 보다 약 20% 정도 더 여유를 둬야 하는데 이는 OverProvisioning을 생각해야 하기 때문이다.

구독(Subscription)의 Core 수 제약

구독은 기본값으로 20개의 Core 수 제약이 있다. 이는 어떤 실수로 인해 비용이 과다 청구되는 것을 막기 위한 제약이다. 하지만 VMSS를 쓰기로 했다면 20개의 Core 보다 더 많이 사용할 가능성이 있다. 따라서 코어 제약을 원하는 개수로 늘려놔야 한다.  Azure 구독의 코어수 제약 늘리기를 참조해서 변경할 수 있다.