Secret recipe to manage Azure VMSS

class: center, middle, inverse
background-image: url(https://newevolutiondesigns.com/images/freebies/city-wallpaper-18.jpg)
background-position: center
background-size: contains

.title[
# Secret Recipe to manage Azure VMSS

### "아무도 알려주지 않는 Azure VMSS 활용 비법"
]

.author[
Il Joong Kim (iljoong@outlook.com)
]
---

# Agenda

1. VMSS Basic
2. Secret Recipe

.footnote[revised 2018-05-24]
---
class: center, middle, gray

# VMSS Basic

---
# Azure VMSS

Azure VMSS(VM Scale Set)는 Autoscale을 지원하는 IaaS VM 만으로 알려져 있으나, 그 이상의 기능을 제공함

먼저, 주요 특징을 소개하면 다음과 같음

- 커스텀 이미지는 최대 300개 인스턴스, 플랫폼 이미지는 최대 1,000개 인스턴스 ∗
- Over provision을 지원하여 배포 성공율을 보장
- Data Disk 및 Managed Disk 지원
- Auto-scale 지원
- 가용성을 위한 `Availability Set`과 같은 구성은 자동으로 제공
- 다양한 배포 방식 가능: All-at-once, Rolling, Immutable

자세한 내용은 [Azure VMSS](https://docs.microsoft.com/ko-kr/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-overview) 및 [기본 FAQ](https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-overview#frequently-asked-questions-for-scale-sets)도 참조

.footnote[∗ 2017-10-1 기준]
---
# VMSS Architecture

포탈에서 생성 시 기본 구성은 아래와 같음

- VNET
    - 자동으로 생성됨 (ARM template을 이용하여 지정 가능)
    - NSG는 생성하지 않음 (ARM Template으로 추가할 수 있음)
- Public IP(LB 용)
- LB (Load Balancer)
    - NAT Pool이 생성
    - NAT를 통해서 각각의 VM 인스턴스를 접근할 수 있음
- VMs
    - VMSS의 인스턴스

이 구성만으로 보면 최초 PaaS 서비스인 [Cloud Service](https://docs.microsoft.com/ko-kr/azure/cloud-services/cloud-services-choose-me)와 매우 유사함

---
# VM Prep Options for VMSS

VMSS의 VM 인스턴스를 커스터마이징(SW 설치 및 구성)하는 방법으로는 ...

1. Custom extension
    - VM extension을 통해 VM 생성 후 추가 설치 가능
    - => 하지만, 스케일 시 VM의 start-up 시간이 오래 소요되고, Script 생성이 쉽지 않음

2. Custom image
    - 수작업으로 VM의 이미지를 캡처하여 이미지화
    - => 귀찮고/시간 소모적이며 실수 발생 가능성이 높음(sysprep/deprovision을 누락 등)

???

커스텀이미지 작업은 반복적으로 수행되므로 실수가 빈번히 발생

---

# Create VMSS with Template

VMSS는 PowerShell/CLI 커맨드와 template을 이용하여 생성할 수 있음

PowerShell

```PowerShell
New-AzureRmResourceGroup -Name $rgName -Location koreacentral

New-AzureRmResourceGroupDeployment -Name "vmssdeployment" -ResourceGroupName $rgName `
                                   -TemplateFile .\azuredeploy.json `
                                   -TemplateParameterFile .\azuredeploy.parameter.json `
                                   -Verbose
```

CLI

```bash
$ az group create –n $rgname –l koreacentral

$ az group deployment create –n vmmsdeployment –g $rgname –-template-file azuredeploy.json \
  –-parameters @azuredeploy.parameter.json

```

[샘플 스크립트 및 템플릿 참조](https://github.com/iljoong/samples/tree/master/vmss/cli)

---
# Autoscale

고정 사이즈 또는 Autoscale을 설정하여 사용할 수 있음 ∗

Autoscale은 다양한 설정이 가능

- 성능 매트릭에 기반한 설정
- 스케쥴에 기반한 설정
- 여러 룰을 복합 설정

예를 들어, 기본으로 4개의 인스턴스를 설정하고, 주말에는 2개의 인스턴스를 설정하도록 구성할 수 있음

Best Practice 및 사용 방법은 아래를 참조

- [Autoscale Best Practice](https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/insights-autoscale-best-practices#autoscale-best-practices)
- [Scale Metrics](https://docs.microsoft.com/ko-kr/azure/monitoring-and-diagnostics/insights-autoscale-common-metrics)
- [Scale Pattern](https://docs.microsoft.com/ko-kr/azure/monitoring-and-diagnostics/monitoring-autoscale-common-scale-patterns)

.footnote[ ∗ Autoscale이 설정되어 있어야만 수작업으로 조정한 고정 사이즈의 변동 이력이 기록됨 ]
---

# Managing Instance Model

VM 리소스 속성의 `imageReference.id`∗ 값이 변경되면 latest model 상태가 `NO`로 변경됨. 아래의 CLI 커맨드로 최신 이미지로 변경 가능

```bash
$ az vmss update -n myvmss -g rgname \
    --set virtualMachineProfile.storageProfile.imageReference.id=/subscriptions/.../images/cicdimagev2
```

.percent50[
![Image](/images/slide-vmss-latestmodel.png)
]

VMSS의 `"upgradePolicy": {"mode": "Automatic"}` 이면 VM이 최신 이미지로 바로 업데이트됨∗∗ (즉, 다운타임 발생)

.footnote[
∗ managed disk 기준, ∗∗ `Manual`로 설정된 경우 별도의 인스턴스 업데이트 커맨드를 통해서 업데이트됨
]

???

managed disk requires ‘2016-04-30-preview’ api-version
---
class: center, middle, gray

# Secret Recipe

---

# Why VMSS

VMSS는 손쉽게 구성가능하고 멀티 VM 인스턴스를 빠르게 배포할 수 있는 것도 장점이지만 VMSS의 숨겨진 실제 장점은 다양한 배포 방식을 적용할 수 있다는 것임.

포탈 내에서 기능으로 제공되면 좋지만, 아쉽게도 현재는 다양한 배포 방식을 지원할 수 있는 _기반_만 있으며 기능으로 제공하지 않음

기능으로 사용하기 위해서는 추가 ~~재료~~ 도구를 사용해야함

???

아마도 나중에 포탈에서 기능이 제공되지 않을까 싶음

---

# Ingredients

VMSS의 활용 비법의 핵심 ~~재료~~ 도구...

1. [Packer](https://www.packer.io/)

- Docker와 유사하게 커스텀 VM 이미지를 생성 또는 굽는(bake) 도구
    - [https://www.packer.io/](https://www.packer.io/)
    - Script를 만들어야 한다는 것은 Custom Extension 방식과 동일하지만 오류 확인 등이 좀더 나음

2. CLI Script with [JMESPath](http://jmespath.org/)

- Azure CLI로 다양한 배포방식을 적용
    - JMESPath를 이용하여 고급 스크립트 구현 
    - [http://jmespath.org/](http://jmespath.org/)

3. Autoscale Notification with Azure Function

- VM 인스턴스 수의 변경을 이메일 또는 Slack/Teams로 바로바로 확인

---
# Create Image using Packer

Custom Extension과 수작업 Custome Image의 장점을 활용한 방법으로 커스텀 VM 이미지를 손쉽게 구성가능

Linux VM 커스텀 이미지 생성 스텝

1. 준비
    - [Service Principal AD authentication](https://docs.microsoft.com/ko-kr/azure/azure-resource-manager/resource-group-create-service-principal-portal) 생성 및 설정값 준비
2. `Packer` 설치
3. 스크립트 생성
    - [Sample Script 참조](https://github.com/iljoong/samples/tree/master/vmss/packer) (Linux/Tomcat Image)
4. 이미지 굽기

```
$ packer build packer_script.json
```

자세한 생성 방법은 [Packer 문서](https://docs.microsoft.com/ko-kr/azure/virtual-machines/linux/build-image-with-packer) 참조

간단한 SW 설치/구성은 `Packer`를 사용하고, 복잡한 설치/구성은 `Chef`, `Puppet`, `Ansible`과 같은 자동화 도구를 권장

---

# CI/CD

Packer로 생성한 VM 이미지는 VMSS를 생성할때 사용할 수 있으며, CI/CD 도구와 연계한 인프라 자동화에 활용할 수 있음

CI/CD 도구 적용 방법은 아래를 참조

- [Jenkins/Spinnaker에 적용 가이드](https://www.spinnaker.io/guides/tutorials/codelabs/azure-vmss-source-to-prod/)

- [VSTS에 적용 가이드 블로그](https://blogs.msdn.microsoft.com/manibindra/2016/12/26/how-to-continuously-deploy-web-application-to-azure-vm-scale-sets-using-vsts-and-packer/)

---
# Deployment Option

먼저 배포 방식의 특징을 확인

CLI와 [JMESPath](http://jmespath.org/)를 사용하면 `Blue/Green`을 제외한 배포 방식을 모두 구현할 수있음

???

https://www.slideshare.net/AmazonWebServices/deploy-scale-and-manage-your-application-with-aws-elastic-beanstalk?qid=bd9ec14b-28a3-4e05-a29a-d64230a29e65&v=&b=&from_search=2

---

# All at once

앞서 소개한 [Managing Instance Model](#9) 방법을 이용하여 최신 이미지로 인스턴스 모델을 업데이트한 후, 아래의 커맨드로 인스턴스를 업데이트

```bash
$ az vmss update -n myvmss -g rgname \
    --set virtualMachineProfile.storageProfile.imageReference.id=/subscriptions/.../images/cicdimagev2

$ az vmss update-instances -n myvmss -g rgname --instance-ids "*"
```

![Image](/images/slide-vmss-upgrade1.png)

이경우 `"upgradePolicy": {"mode": "Automatic"}`로 설정한 것과 차이가 없음

.footnote[ [Sample 참조](https://github.com/iljoong/samples/blob/master/vmss/cli/vmss-deploy.sh) ]
---
# Rolling upgrade

주의: 최신 CLI에서 아래의 커맨드가 더이상 동작하지 않음. 최신 `rolling-upgrade` sub-command 사용 권장

~~인스턴스를 한번에 모두 업데이트하지 않고, 한개씩 업데이트 (그리고, 업데이트 후 15초 슬립)~~

```bash
$ az vmss update -n myvmss -g rgname \
    --set virtualMachineProfile.storageProfile.imageReference.id=/subscriptions/.../images/cicdimagev2
$ az vmss get-instance-view -n myvmss -g rgname --instance-id "*" \
    --query "[].[instanceView.platformUpdateDomain, instanceId]" -o tsv \
    | sort \
    | awk '{print "az vmss update-instances -n myvmss -g rgname --instance-ids " $2 " && sleep 15s"}' \
    | bash 
```

![Image](/images/slide-vmss-upgrade2.png)

.footnote[ [Sample 참조](https://github.com/iljoong/samples/blob/master/vmss/cli/vmss-deploy.sh) ]
---
# Immutable

최신 모델의 인스턴스를 미리 생성한 후, 이전 모델의 인스턴스들은 삭제 (삭제 대상은 수작업으로 선별)

```bash
$ az vmss update -n myvmss -g rgname \
    --set virtualMachineProfile.storageProfile.imageReference.id=/subscriptions/.../images/cicdimagev2

$ az vmss scale -n myvmss -g rgname --new-capacity 8 && sleep 15s
$ az vmss delete-instances -n myvmss -g rgname --instance-ids 1 2 3 4
```

![Image](/images/slide-vmss-upgrade3.png)

.footnote[ [Sample 참조](https://github.com/iljoong/samples/blob/master/vmss/cli/vmss-deploy.sh) ]
---
# Blue/Green

아쉽게도 'Blue/Green'은 플랫폼 기능을 지원하지 않으나, _Traffic Manager_ 를 이용 유사하게 구성할 수 있음

또는, 아래 URL 참조

[https://msftstack.wordpress.com/2017/02/24/vip-swap-blue-green-deployment-in-azure-resource-manager/](https://msftstack.wordpress.com/2017/02/24/vip-swap-blue-green-deployment-in-azure-resource-manager/)

---

# Immutable (Advanced)

앞서 소개한 Immutable 방식은 수작업으로 처리하는 방식임

CLI의 `--query` 옵션과 `JMESPath` 쿼리를 활용하여 최신 모델이 아닌 인스턴스를 식별하여 이 인스턴스들만 삭제

```bash
$ az vmss update -n myvmss -g rgname \
    --set virtualMachineProfile.storageProfile.imageReference.id=/subscriptions/.../images/cicdimagev2
$ newcap=$((2*$(az vmss list-instances -n myvmss -g rgname --query '[] | length(@)' )))

$ az vmss scale -n myvmss -g rgname --new-capacity $newcap && sleep 15s
$ az vmss list-instances -n myvmss -g rgname \
    --query '[?!latestModelApplied].instanceId | join(`" "`, @)' \
    | awk '{print "az vmss delete-instances -n myvmss -g rgname --instance-ids " $1}' \
    | sed 's/"//g' | bash
```
.footnote[ [Sample 참조](https://github.com/iljoong/samples/blob/master/vmss/cli/vmss-deploy.sh) ]
---
# Rolling upgrade (Advanced)

주의: 최신 CLI에서 아래의 커맨드가 더이상 동작하지 않음. 최신 `rolling-upgrade` sub-command 사용 권장

~~VM의 인스턴스가 100개가 될 경우 앞서 소개한 Rolling Upgrade는 시간이 많이 소요됨
UD group을 이용하여 UD group에 포함된 인스턴스들을 순차적으로 업데이트 (즉, 20%씩 업데이트)~~

```bash
$ az vmss update -n myvmss -g rgname \
--set virtualMachineProfile.storageProfile.imageReference.id=/subscriptions/.../images/cicdimagev2
$ az vmss get-instance-view -n myvmss -g rgname --instance-id "*" \
    --query "[].[instanceView.platformUpdateDomain, instanceId]" -o tsv \
    | sort \
    | awk 'BEGIN {} {a[$1] = a[$1] "@" $2 } END {for (i in a) printf("%s %s\n", i, a[i])} ' \
    | sort \
    | awk '{print "az vmss update-instances -n myvmss -g rgname --instance-ids " $2 " && sleep 15s"}' \
    | sed s/@/' '/g \
    | bash 
```
.percent70[
![Image](/images/slide-vmss-upgrade4.png)
]

.footnote[ [Sample 참조](https://github.com/iljoong/samples/blob/master/vmss/cli/vmss-deploy.sh) ]
---

# Autoscale Notification

Webhook의 endpoint는 Azure Function으로 지정하여 [Slack](https://slack.com/) 또는 [Teams](https://products.office.com/ko-kr/microsoft-teams/group-chat-software)로 메시지 알람을 받을 수 있게 설정할 수 있음

.percent60[
![Image](https://docs.microsoft.com/ko-kr/azure/monitoring-and-diagnostics/media/insights-autoscale-to-webhook-email/insights-autoscale-notify.png)
]

[Autoscale의 Webhook 설정 참조](https://docs.microsoft.com/ko-kr/azure/monitoring-and-diagnostics/insights-autoscale-to-webhook-email)

---
# Azure Function

Webhook을 통해 수신되는 Azure Alert의 JSON 구조는 표준이 아니기 때문에 수신측에 맞게 전환이 필요

Azure Function은 Slack 또는 Teams의 메시지 구조로 전환하는데 사용함

Azure Function 설정

- HTTP Trigger로 Azure Function을 생성
    - [상세 설정 방법 참조](https://docs.microsoft.com/ko-kr/azure/azure-functions/functions-bindings-http-webhook)
- Alert 메시지를 전환하여 수신측 HTTP Webhook으로 호출하는 코드 추가
    - [Azure Function 샘플 코드 참조](https://github.com/iljoong/samples/blob/master/vmss/webhook/run.csx)

---
# Config Notification Service

당연하겠지만, 수신측 서비스의 커스텀 Webhook endpoint를 설정해야함

커스텀 Webhook 설정 참조

- Slack Webhook 설정
    - [https://api.slack.com/incoming-webhooks](https://api.slack.com/incoming-webhooks)
- Microsoft Teams Webhook 설정
    - [https://msdn.microsoft.com/ko-kr/microsoft-teams/connectors](https://msdn.microsoft.com/ko-kr/microsoft-teams/connectors)

---
layout: false
class: center, middle, gray

# End of Slide