Azure Networking - Load Balancer(L4)로 부하 분산하기

개요

최근 Azure Landing Zone 프로젝트를 하고 있습니다.

그러다 보니 블로그 포스팅이 늦어지고 있습니다

랜딩존이라는 게 Azure 인프라의 기본 골격을 만드는 작업이다 보니, 각 VM 들을 부하분산 시키는

Load Balancer는 필수로 다루게 됩니다.

구성 요소

Azure VNet 내부에서 두 개의 VM을 대상으로 Internal Load Balancer를 구성하고

외부에 있는 Client-VM에서 ILB로 트래픽을 보냈을 때, 자동으로 부하 부산이 되는 과정입니다

.

 

진행 과정

네트워크 환경 설정

먼저 네트워크를 깔아줍니다

서브넷을 만들고 VM에 배치한 뒤 백엔드 풀에 연결하는 순서로 진행할 예정입니다.

.

.

주소 대역은 간단하게 설정해 주고

.

.

웹 서버가 배치될 Subnet-Web을 만들어주고

.

Client 테스트용 Subnet-Client도 만들어줍니다.

Web 서버와 Client를 서로 다른 서브넷에 배치하는 것이 중요합니다.

.

다음은 NSG인데요

따지고 보면 LB 테스트에 NSG가 필요한 건 아니지만,

LB가 보안 역할을 대신해주지는 않다 보니 실제 Landing Zone 프로젝트 때는 기본으로 설정합니다. 

.

nsg-web을 만들어서...

.

아까 만든 Subnet-Web에 연결시켜 주고

.

LB의 Health Probe를 받기 위해서는 80번 포트가 열려있어야 합니다.

.

이왕 하는 거 Client 테스트용 서브넷에도 별도의 NSG를 만들어줍니다.

.

VNet 내에 두 개의 서브넷을 구성했습니다.

• Subnet-Web : 10.0.1.0/24 → nsg-web 연결
• Subnet-Client : 10.0.2.0/24 → nsg-client 연결

각 서브넷에 별도의 NSG가 연결되어 계층별로 보안 정책이 분리된 상태다! 라고 보면 됩니다.

.

---

가용성 집합 + VM 생성

가용성 집합 (Availability Set)은 VM을 서로 다른 Fault Domain과 Update Domain에 배치하여
물리 장애나 유지보수 시에도 동시에 중단되지 않도록 보장한다~ 라고 재미없게 기술문서 쓰여있긴 한데 

 

그냥 LB가 아무리 트래픽을 분산하더라도 동일하게 한 도메인에 속해 있으면 의미가 없으니 그걸 분산시키겠다! 라는 의미입니다. 

.

요런 식으로 하나 만들어주면 됩니다.

.

다음은 VM 생성을 해주겠습니다.

아까 만들어둔 가용성 집합을 선택해 주고 이미지는 우분투든 윈도우 서버든 필요에 따라 구성하면 됩니다.

.

Internal Load Balancer 구조에서는 외부 인터넷에서 들어오는 것이 아니라,
동일 VNet 내부에서만 접근하도록 설계해야 합니다.  ( Client Subnet → ILB Private IP → Web VM)

고로 Public IP는 빼줍니다.

 

서브넷은 Subnet-Web을 설정햬줍니다.

.

트래픽 분산을 위해 동일한 설정으로 이름만 다르게 하여 VM을 하나 더 생성해 주면 됩니다.

.

.

Internal Load Balancer의 Health Probe는 지정된 포트(80) 또는 특정 경로(/health)에 대해 응답을 확인해 주는 친구인데요

따라서 각 VM마다 웹 서비스가 활성화되어 있어야 해서 VM에 원격으로 접속한 뒤 Nginx를 설치해 줍니다.

sudo apt update
sudo apt install nginx -y

.

또한 호옥..시나 해서

ILB의 HTTP Health Probe를 위해 /health 경로에 OK 응답을 반환하도록 파일을 생성했습니다

이제 ILB가 다음 경로로 요청을 보내면 → http://<ILB-IP>/health → 정상 응답(200 OK)을 받게 됩니다.

echo "OK" | sudo tee /var/www/html/health

 

이제 마지막으로 80번 포트가 LISTEN 상태임을 확인해 줍니다.

.

꼭 해야 하는 설정은 아니지만

echo "VM이름" | sudo tee /var/www/html/index.html

해주면 마지막 LB 테스트할 때 좀 더 직관적으로 기능을 확인할 수 있습니다.

 

 동일한 과정을 2번 서버에도 설정해 줍니다.

---

Load Balancer 생성

이제 오늘의 주인공 차례입니다.

.

형식은 내부로 설정해 준 뒤...

.

서브넷은 아까 생성한 두 VM과 같은 VNet으로 설정해 주고

IP는 두 VM이 쓰지 않는 정적 IP를 붙여줍니다.

 

이렇게 설정해 주면

 

• ILB는 반드시 VNet 내부 IP를 가진다.
• 이 IP(10.0.1.10)가 앞으로 웹 서비스의 대표 IP가 된다.
• 클라이언트는 VM 개별 IP(10.0.1.4~5)가 아니라 10.0.1.10으로 접속하게 되는 겁니다.

 

.

Backend Pool에

• VM-WEB-01 (10.0.1.4)
• VM-WEB-02 (10.0.1.5)

두 VM의 NIC를 추가해 주고

.

부하 분산 규칙을 추가하여 LB에 대한 상세 설정을 해줍니다.

.

 

이름: probe-http-80
프로토콜: HTTP
포트: 80
경로: /health
간격: 5초

 

.

 

.

이렇게 규칙을 설정해 주면

ILB는 친절하게도 5초마다 각 VM에 매번 건강 검진...! 을 실시합니다.

200 ok가 반환되면 Healthy로 판단하고 만약 응답이 없으면 해당 VM은 자동으로 트래픽 대상에서 제외됩니다.

.

---

Client VM 생성 및 테스트

이제 마지막 테스트 단계를 위해

Subnet-Client로 Client VM을 생성해 줍니다.

.

.

Client VM에 원격으로 연결하여 ILB IP(10.0.1.10)로 10회 요청을 보내보면 

for i in {1..10}; do curl -s http://10.0.1.10; echo; done

현재 세션이 vm-web-01에 붙어 있기 때문에 동일 백엔드에서 응답이 지속적으로 반환됩니다.

.

테스트를 위해 vm-web-01의 nginx를 중지 (혹은 VM 자체를) 하게 되면

sudo systemctl stop nginx

.

다시 동일 명령으로 요청을 반복 실행하면 모든 응답이 vm-web-02에서 반환되는 것을 확인할 수 있었습니다.

즉, Health Probe 기반으로 백엔드 상태를 판단한 뒤,

서비스 장애 발생 시 자동으로 트래픽을 전환하는 과정이었습니다.

.

---

 

 

참고자료

Azure Load Balancer란? - Azure Load Balancer | Microsoft Learn

Azure Load Balancer란? - Azure Load Balancer

Azure Load Balancer 개념 | Microsoft Learn

Azure Load Balancer 개념