TM Taeyang Moon
Hands-on Lab · 약 60분 · 초급~중급

고가용성 웹서버 만들기

VMSS + Application Gateway + 자동확장

가상 머신 스케일 세트(VMSS)로 웹서버를 여러 대 띄우고, Application Gateway(L7 + WAF)로 부하를 분산하며, 트래픽에 따라 서버가 자동으로 늘고 주는 자동확장을 직접 구성합니다.

VMSSApplication Gateway WAF_v2AutoscaleVirtual Network

랩 정보

🧭 이 랩에서 만드는 그림 인터넷 → [공용 IP] → [Application Gateway + WAF] → [VMSS: web000000, web000001 …] Application Gateway가 "스마트 안내데스크"처럼 들어오는 요청을 여러 웹서버로 나눠주고, 서버가 바빠지면 자동으로 더 늘립니다.

사전 준비

💡 왜 포털로 하나요? 실무에서는 코드(Bicep/Terraform)로 자동화하지만, 처음에는 포털에서 직접 클릭하며 각 구성요소가 무엇이고 어떻게 연결되는지 눈으로 익히는 것이 이해에 가장 좋습니다. (같은 구성을 코드로 한 번에 배포하는 버전은 demos/vmss-appgw-ha/에 있습니다.)

실습 단계

모듈 0: 리소스 그룹 만들기 (5분)

목표: 이 랩의 모든 리소스를 담을 "상자"를 만든다.

  1. 포털 상단 검색창에 리소스 그룹 입력 → 클릭.
  2. + 만들기 클릭.
  3. 다음 값 입력: - 구독: (본인 구독) - 리소스 그룹: rg-lab-ha - 지역: Korea Central
  4. 검토 + 만들기 → 만들기.

💡 왜 리소스 그룹부터? Azure의 모든 리소스는 리소스 그룹 안에 삽니다. 상자 하나에 모아두면 랩이 끝났을 때 상자째 삭제해서 비용을 깔끔히 정리할 수 있어요(모듈 7 참고).

✅ 확인: 리소스 그룹 목록에 rg-lab-ha가 보이면 성공.

모듈 1: 가상 네트워크(VNet)와 서브넷 2개 만들기 (8분)

목표: 웹서버와 Application Gateway가 살 "사설 네트워크"를 만든다. 서브넷(작은 구역)을 2개로 나눈다.

  1. 검색창에 가상 네트워크 → + 만들기.
  2. 기본 사항 탭: - 리소스 그룹: rg-lab-ha - 이름: lab-vnet - 지역: Korea Central
  3. IP 주소 탭에서 서브넷을 다음과 같이 구성: - 기본 주소 공간이 10.0.0.0/16인지 확인. - 기본 서브넷 이름을 snet-appgw, 범위 10.0.1.0/24로 수정(또는 삭제 후 새로 추가). - + 서브넷 추가 클릭 → 이름 snet-vmss, 범위 10.0.2.0/24 → 추가.
  4. 검토 + 만들기 → 만들기.

💡 왜 서브넷을 둘로 나누나요? Application Gateway는 자기만 쓰는 전용 서브넷이 반드시 필요합니다. 그래서 snet-appgw(게이트웨이 전용)와 snet-vmss(웹서버용)로 분리합니다. Microsoft는 게이트웨이 자동확장을 위해 /24(약 251개 IP) 크기를 권장합니다.

✅ 확인: lab-vnet > 서브넷 블레이드에 snet-appgw, snet-vmss 두 개가 보이면 성공.

모듈 2: VMSS(가상 머신 스케일 세트)로 웹서버 띄우기 (12분)

목표: 똑같은 웹서버 여러 대를 한 번에 만들고, 부팅 시 자동으로 nginx 웹서버를 설치한다.

  1. 검색창에 Virtual machine scale sets → + 만들기.
  2. 기본 사항 탭: - 리소스 그룹: rg-lab-ha - 이름: lab-vmss - 지역: Korea Central - 오케스트레이션 모드: Flexible (권장) - 보안 유형: 표준 - 이미지: Ubuntu Server 22.04 LTS - 크기: Standard_B2s (저렴, 데모 충분) - 인증 유형: 암호 → 사용자 이름 azureuser, 강력한 암호 입력(메모해두기) - 확장 규모(인스턴스 수): 2 로 설정.
  3. 네트워킹 탭: - 가상 네트워크: lab-vnet - 서브넷: snet-vmss 선택. - 로드 밸런싱 옵션: 없음(None) 으로 둠 — Application Gateway는 다음 모듈에서 따로 붙입니다.
  4. 고급(Advanced) 탭 > 사용자 지정 데이터(Custom data) 칸에 아래 cloud-init을 붙여넣기: ```yaml #cloud-config package_update: true packages:
    • nginx runcmd:
    • HOSTN=$(hostname)
    • echo "

      Azure 고가용성 웹서버 랩

      응답 인스턴스: $HOSTN

      새로고침 해보세요.

      " > /var/www/html/index.html
    • systemctl enable nginx
    • systemctl restart nginx ```
  5. 검토 + 만들기 → 만들기. (1~2분)

💡 VMSS가 뭔가요? "붕어빵 틀"이라고 생각하세요. 똑같은 설정의 VM을 1대든 100대든 동일하게 찍어냅니다. cloud-init(사용자 지정 데이터) 는 VM이 처음 부팅할 때 자동 실행되는 설치 스크립트예요. 덕분에 모든 인스턴스가 같은 웹페이지를 갖게 됩니다.

✅ 확인: lab-vmss > 인스턴스 블레이드에 인스턴스 2개가 "실행 중"으로 보이면 성공.

모듈 3: Application Gateway(WAF) 만들고 VMSS 연결 (15분)

목표: 인터넷 요청을 받아 두 웹서버로 나눠주는 L7 게이트웨이를 만들고, WAF(웹 방화벽)를 켠다.

  1. 검색창에 Application gateways → + 만들기.
  2. 기본 사항 탭: - 리소스 그룹: rg-lab-ha, 이름: lab-appgw, 지역: Korea Central - 계층(Tier): WAF V2 - WAF 정책: 새로 만들기 (이름 lab-wafpolicy), 모드 방지(Prevention) - 자동 크기 조정: 예 (최소 1) - 가상 네트워크: lab-vnet, 서브넷: snet-appgw
  3. 프런트엔드 탭: - 프런트엔드 IP 유형: 공용 - 공용 IP 주소: 새로 만들기 → 이름 lab-appgw-pip.
  4. 백엔드(Backends) 탭: - + 백엔드 풀 추가 → 이름 vmssBackendPool. - "대상 없이 백엔드 풀 추가" 를 아니요 로 두고, 대상 유형: VMSS → lab-vmss 선택 → 추가.
  5. 구성(Configuration) 탭 — 라우팅 규칙 연결: - + 라우팅 규칙 추가: 규칙 이름 routingRule, 우선순위 100. - 수신기(Listener): 이름 httpListener, 프런트엔드 공용, 프로토콜 HTTP, 포트 80. - 백엔드 대상 탭: 백엔드 풀 vmssBackendPool 선택 → 백엔드 설정 새로 추가(이름 httpSettings, 포트 80, HTTP) → 추가. - 규칙 추가.
  6. 검토 + 만들기 → 만들기.

⏳ 여기서 5~10분 걸립니다. App Gateway는 내부적으로 여러 구성요소를 만들기 때문에 느립니다. 커피 한 잔 ☕

💡 왜 WAF를 켜나요? WAF(Web Application Firewall)는 SQL 인젝션·XSS 같은 흔한 웹 공격을 게이트웨이 단에서 막아줍니다. OWASP 규칙셋(업계 표준 공격 목록)을 "방지" 모드로 적용하면 의심스러운 요청을 자동 차단합니다.

✅ 확인: 배포 완료 후 lab-appgw > 백엔드 풀 > vmssBackendPool에 VMSS가 연결되어 있고, 백엔드 상태가 정상(녹색)으로 보이면 성공.

모듈 4: 부하분산 확인하기 (5분)

목표: 한 주소로 들어온 요청이 여러 서버로 나뉘는 것을 눈으로 본다.

  1. lab-appgw > 개요에서 프런트엔드 공용 IP 주소를 복사.
  2. 브라우저 주소창에 http://<그 IP> 입력 → 접속.
  3. 페이지의 응답 인스턴스 이름을 확인하고, 여러 번 새로고침(Ctrl+F5).

💡 왜 이름이 바뀌나요? Application Gateway가 요청마다 다른 인스턴스로 분배(부하분산)하기 때문입니다. 우리가 쿠키 기반 고정(affinity)을 껐기 때문에 새로고침마다 다른 서버가 응답할 수 있어요.

✅ 확인: 새로고침할 때 인스턴스 이름이 web... 형태로 번갈아 바뀌면 부하분산 성공.

모듈 5: 고가용성 확인하기 (5분)

목표: 서버 한 대가 죽어도 서비스가 끊기지 않음을 확인한다.

  1. lab-vmss > 인스턴스 에서 인스턴스 하나를 선택 → 중지 또는 삭제.
  2. 다시 브라우저에서 App Gateway 주소를 새로고침.

💡 왜 안 끊기나요? Application Gateway의 상태 프로브(health probe) 가 30초마다 각 서버를 확인합니다. 죽은 서버는 자동으로 분배 대상에서 빼고, 살아있는 서버로만 보냅니다. 이것이 고가용성입니다.

✅ 확인: 한 대를 내렸는데도 페이지가 계속 정상 응답하면 성공. (살아있는 인스턴스 이름만 보임)

🔁 다음 모듈을 위해 인스턴스를 다시 정상(2대)으로 만들어 두세요(중지했다면 시작, 삭제했다면 잠시 후 자동 복구되거나 수동 인스턴스 추가).

모듈 6: 자동확장 규칙 만들고 시연하기 (10분)

목표: CPU 사용률에 따라 서버가 자동으로 늘고(scale-out) 주는(scale-in) 규칙을 만든다.

  1. lab-vmss > 크기 조정(Scaling) 블레이드 열기.
  2. 사용자 지정 자동 크기 조정(Custom autoscale) 선택.
  3. 인스턴스 한도: 최소 2 / 최대 5 / 기본 2.
  4. 규칙 추가 (확장, scale-out): - 메트릭: Percentage CPU, 연산자 보다 큼, 임계값 70, 기간 5분(평균). - 작업: 수 증가, 인스턴스 수 1, 휴지 기간 3분.
  5. 규칙 추가 (축소, scale-in): - 메트릭: Percentage CPU, 연산자 보다 작음, 임계값 30, 기간 5분(평균). - 작업: 수 감소, 인스턴스 수 1, 휴지 기간 5분.
  6. 저장.
  7. 부하를 주어 CPU를 올립니다. lab-vmss > 인스턴스 에서 한 인스턴스 선택 > (포털 SSH 또는 Run command) 후: - VMSS > 인스턴스 > (선택) > 실행 명령 > RunShellScript 에 입력: bash sudo apt-get update -y && sudo apt-get install -y stress-ng sudo stress-ng --cpu 0 --timeout 300s

💡 자동확장이 왜 좋나요? 트래픽이 적을 땐 적은 서버로 비용을 아끼고, 갑자기 몰리면 자동으로 늘려 느려지거나 죽지 않게 합니다. 사람이 밤에 일어나 서버를 켤 필요가 없어요. 평균 5분 동안 CPU가 70%를 넘으면 한 대씩 늘어납니다.

✅ 확인: lab-vmss > 크기 조정 > 실행 기록(Run history) 또는 인스턴스 수가 5분 내 2→3→…로 증가하면 성공. 부하를 멈추면 약 5분 뒤 다시 줄어듭니다.

정리 (Cleanup)

⚠️ 랩이 끝나면 반드시 삭제하세요. Application Gateway는 켜둔 만큼 과금됩니다.

포털에서: rg-lab-ha 리소스 그룹 > 리소스 그룹 삭제 > 이름 입력 후 삭제.

CLI에서:

az group delete -n rg-lab-ha --yes --no-wait

✅ 삭제 여부: [ ] 완료

강사 노트

참고 자료

← 랩 목록학습 포털 홈