오늘 실습 목표는 하나였다. 브라우저에서 ALB 공인 IP로 접속하고 새로고침을 누를 때마다 "서버1 작동중"과 "서버2 작동중"이 번갈아 나오게 만드는 것. 이게 되면 부하분산이 실제로 동작한다는 증거다.
AWS 실습 때 ALB를 배웠는데, Azure는 구성 방식이 달랐다. 특히 가용성 집합(Availability Set) 개념이 AWS의 Auto Scaling Group이랑 다르게 동작해서 처음엔 헷갈렸다. 실습 순서대로 기록한다.
전체 실습 구조
시작 전에 전체 흐름을 먼저 그려놨다.
리소스를 만드는 순서가 중요하다. 의존성이 있어서 순서가 틀리면 중간에 막힌다. 오늘 실습에서 정리한 순서:
2. VNet + 서브넷 생성
3. 가용성 집합(Availability Set) 생성
4. NSG 생성 및 규칙 설정
5. 공인 IP 생성 (Static)
6. VM 2개 생성 (가용성 집합에 배치)
7. PowerShell로 IIS 설치
8. HTML 페이지 수정
9. Azure Load Balancer 생성
10. 백엔드 풀, 상태 프로브, 부하분산 규칙 설정
11. 브라우저 접속 확인
1단계 — Resource Group과 VNet 생성
Resource Group 이름: rg-alb-practice
위치: Korea Central
VNet 이름: vnet-alb-main
주소 공간: 10.20.0.0/16
서브넷 이름: snet-web
서브넷 범위: 10.20.1.0/24지난 실습에서 CIDR 대역을 10.10으로 잡았으니까 이번엔 10.20으로 시작했다. 나중에 두 환경을 연결할 때 대역이 안 겹치게 하려고 의도적으로 나눴다.
2단계 — 가용성 집합(Availability Set) 생성
이게 오늘 실습에서 AWS랑 가장 다르게 느껴진 부분이었다.
이름: avset-web
장애 도메인(Fault Domain): 2
업데이트 도메인(Update Domain): 5"장애 도메인은 물리적 랙 단위 분리다. 2로 설정하면 VM-01과 VM-02가 서로 다른 물리 서버 랙에 올라간다. 하나의 랙에 전원 장애가 나도 다른 랙의 VM은 살아있다. AWS의 Multi-AZ 배포랑 목적은 같은데 구현 방식이 다르다."
업데이트 도메인은 패치나 재시작할 때 동시에 영향받는 VM을 나눈다. 5로 설정하면 Azure가 유지보수할 때 VM-01 재시작할 때 VM-02는 안 건드린다.
3단계 — NSG 생성 및 인바운드 규칙 설정
NSG 이름: nsg-web| 우선순위 | 이름 | 포트 | 프로토콜 | 소스 | 동작 |
|---|---|---|---|---|---|
| 100 | Allow-HTTP | 80 | TCP | Any | Allow |
| 110 | Allow-RDP | 3389 | TCP | Any | Allow |
HTTP 80은 ALB에서 VM으로 들어오는 트래픽을 위한 것이고, RDP 3389는 서버에 접속해서 IIS 설치하기 위해 열었다. 실습 이후에는 RDP 규칙을 지우거나 내 IP로 제한하는 게 맞다.
snet-web ← nsg-web 연결4단계 — 공인 IP 생성
이름: pip-alb-frontend
SKU: Standard
할당: 정적(Static)동적(Dynamic)으로 만들면 ALB 재시작 시 IP가 바뀐다. 실습에서 접속 테스트할 IP가 바뀌면 안 되니까 Static으로 잡았다.
"실무에서 ALB 앞단 공인 IP는 무조건 Static이다."
5단계 — VM 2개 생성
이미지: Windows Server 2022 Datacenter
크기: Standard_B1s
인증: 관리자 계정 + 비밀번호
가상 네트워크: vnet-alb-main
서브넷: snet-web
공인 IP: 없음 (ALB 뒤에 숨길 거니까)
NSG: nsg-web 연결
가용성 집합: avset-webVM-WEB-01은 가용성 집합에서 장애 도메인 0, 업데이트 도메인 0에 배치됐다.
VM-WEB-02는 장애 도메인 1, 업데이트 도메인 1에 배치됐다.
6단계 — PowerShell로 IIS 설치
VM-WEB-01에 RDP 접속 후 PowerShell 관리자 모드로 실행:
# IIS 설치
Install-WindowsFeature -name Web-Server -IncludeManagementTools
# 설치 확인
Get-WindowsFeature -Name Web-ServerDisplay Name Name Install State
------------ ---- -------------
[X] 웹 서버(IIS) Web-Server InstalledIIS 기본 페이지 파일 위치: C:\inetpub\wwwroot\iisstart.htm
기본 HTML 파일을 각 서버별로 수정했다.
VM-WEB-01:
Set-Content -Path "C:\inetpub\wwwroot\iisstart.htm" `
-Value "<html><body><h1>서버1 작동중</h1></body></html>"VM-WEB-02:
Set-Content -Path "C:\inetpub\wwwroot\iisstart.htm" `
-Value "<html><body><h1>서버2 작동중</h1></body></html>"ALB 붙이기 전에 각 VM의 프라이빗 IP로 먼저 접속해서 페이지가 정상으로 뜨는지 확인했다.
VM-WEB-02 (10.20.1.5) → "서버2 작동중" 확인
7단계 — Azure Load Balancer 생성
이게 오늘 실습에서 설정 항목이 제일 많았다.
기본 설정
이름: alb-web-frontend
SKU: Standard
유형: 공용(Public)
프런트엔드 IP: pip-alb-frontend백엔드 풀 설정
이름: backend-pool-web
가상 네트워크: vnet-alb-main
백엔드 풀에 추가:
- VM-WEB-01 (NIC)
- VM-WEB-02 (NIC)상태 프로브 설정
이름: probe-http
프로토콜: HTTP
포트: 80
경로: /
간격: 15초
비정상 임계값: 2상태 프로브는 ALB가 백엔드 VM이 살아있는지 15초마다 확인하는 설정이다. / 경로로 HTTP 요청 보내서 200 응답 오면 정상, 2번 연속으로 실패하면 해당 VM을 풀에서 제외한다.
"상태 프로브 간격이 너무 짧으면 VM에 부하가 간다. 너무 길면 VM이 죽었는데 한참 후에야 감지한다. 15초에 임계값 2면 최대 30초 안에 장애 감지되는 구조다. 실무에서 이 값은 서비스 성격에 따라 조정한다."
부하분산 규칙 설정
이름: rule-http-80
프런트엔드 IP: pip-alb-frontend
프로토콜: TCP
프런트엔드 포트: 80
백엔드 포트: 80
백엔드 풀: backend-pool-web
상태 프로브: probe-http
세션 지속성: 없음 (Round Robin) ← 핵심 설정
유휴 시간 초과: 4분
부동 IP: 사용 안 함8단계 — 접속 테스트
ALB 구성 완료 후 공인 IP로 브라우저에서 접속했다.
새로고침 → 서버2 작동중
한 번 더 → 서버1 작동중
됐다. 근데 여기서 한 가지 헷갈리는 일이 있었다. 새로고침을 여러 번 눌렀는데 같은 서버만 계속 나오는 경우가 생겼다.
"브라우저가 HTTP 연결을 캐싱하거나 Keep-Alive 연결을 유지하면 같은 서버로 계속 간다. 크롬에서 테스트하면 이게 생긴다. 시크릿 창 열거나 다른 브라우저로 접속하면 명확하게 번갈아 나오는 게 보인다. 실무에서도 이 차이를 모르면 ALB가 제대로 동작 안 한다고 오해한다."
시크릿 창에서 접속하니까 깔끔하게 번갈아 나왔다.
장애 상황 테스트 — VM 하나 끄면 어떻게 되나
강사님이 추가로 테스트를 시켜주셨다. VM-WEB-01을 Azure 콘솔에서 중지했다.
상태 프로브 간격 15초, 임계값 2 → 최대 30초 후에 ALB가 VM-WEB-01을 풀에서 제외한다.
→ 새로고침 계속 눌러도 서버2 작동중만 나옴
VM-WEB-01 재시작 후 30초 대기
→ 다시 서버1 작동중이 나오기 시작
상태 프로브가 정상 응답을 2번 확인하고 나서 풀에 다시 추가하는 거다. ALB가 죽은 서버를 자동 감지하고 살아있는 서버로만 트래픽을 보내는 구조가 실제로 작동한다는 걸 눈으로 확인했다.
오늘 실습에서 막혔던 것들
The subscription does not have enough quota for
creating a Standard Load Balancer with a public IP address
in the Korea Central region.실습 계정 구독의 리소스 쿼터 문제. Standard SKU 공인 IP를 다른 실습에서 여러 개 만들어뒀던 게 원인이었다. 안 쓰는 공인 IP 두 개 삭제 후 해결됐다.
Cannot create LoadBalancingRule because
BackendAddressPool and Probe must use the same protocol.상태 프로브를 TCP로 만들어놨는데 부하분산 규칙에서 HTTP를 참조하려고 해서 생긴 오류. 프로브를 HTTP로 다시 만들고 나서 해결됐다. 프로토콜을 맞춰야 한다.
AWS ALB랑 뭐가 달랐나
오늘 실습하면서 AWS ALB랑 비교가 자꾸 됐다.
| AWS | Azure | 레이어 | 특징 |
|---|---|---|---|
| NLB | Azure Load Balancer | L4 (TCP/UDP) | IP/포트 기반 분산 |
| ALB | Application Gateway | L7 (HTTP/HTTPS) | URL 경로 기반 분산 |
"Azure에서 URL 기반 라우팅 하려면 Application Gateway를 써야 한다. AWS ALB에 해당하는 게 Azure에서는 Application Gateway다. 오늘 쓴 Azure Load Balancer는 AWS의 NLB에 더 가깝다. 이름 때문에 헷갈리는 사람이 많다."
오늘 실습에서 HTTP 분산이 됐던 건 L4에서 80포트 트래픽을 라운드로빈으로 나눈 거지, HTTP 헤더나 경로를 보고 분산한 게 아니다.
실습 끝내고 정리한 것
오늘 실습에서 손에 익은 건 세 가지다.
2. 상태 프로브 설정(간격 + 임계값)이 ALB 장애 감지 속도를 결정한다.
3. 세션 지속성 "없음" 설정이 Round Robin의 전제 조건이다.
브라우저에서 새로고침할 때마다 서버1, 서버2가 번갈아 나오는 걸 직접 확인하고 나니까 부하분산이 추상적인 개념이 아니라 실제로 어떻게 동작하는지 눈에 들어왔다. VM 하나 껐을 때 나머지로 트래픽이 몰리는 것도 직접 보니까, 고가용성 설계가 왜 필요한지를 자연스럽게 이해하게 됐다.
'서버 구축·실습' 카테고리의 다른 글
| Azure VM에서 OpenAI API를 안전하게 연결해 AI 챗봇을 완성하는 방법 (1) | 2026.03.02 |
|---|---|
| Azure 첫 실습 — AWS만 하던 사람이 느낀 충격적인 차이점 (0) | 2026.02.19 |
| 리눅스 FTP 서버 구축 실습 정리 – 사용자 권한 설계부터 보안 사고 대응 관점까지 (0) | 2026.01.26 |
| 리눅스 NFS 서버 구축 실습 정리: exportfs 옵션 이해부터 nobody 권한 매핑까지 (0) | 2026.01.24 |
| 리눅스 웹 서버 구축 실습 기록 – 방화벽과 Apache를 직접 설정해 보며 (0) | 2026.01.24 |
