Azure Networking - Application Gateway(L7)로 Path 기반 Routing 검증 하기

개요

1편에서는 Application Gateway로 Health Probe를 검증해 봤습니다만,

사실 이러한 부하 분산 기능은 이보다 단계가 낮은 L4 - Azure Load Balancer로 충분히 가능합니다.

 

이번 편에서는 L7 - Application Gateway의 핵심 기능인 Path 기반 라우팅을 구성해 보겠습니다.

 

Path 기반 라우팅은 단순히 트래픽을 분산하는 것이 아니라

URL 경로에 따라 다른 서버로 라우팅 할 수 있다는 것을 확인하는 것입니다.

 

http://AppGW_IP/api  (api 요청) → vm-web-01

http://AppGW_IP/web  (web 요청) → vm-web-02

 

 

리소스는 이전 글에서 이어집니다.

Azure Networking - Application Gateway(L7)로 Health Probe 검증하기

Azure Networking - Application Gateway(L7)로 Health Probe 검증하기

---

진행 과정

VM Localhost 작업

만들어둔 VM 1번에 접속하여 다음 명령어를 순차대로 실행합니다.

sudo mkdir /var/www/html/api
echo "API SERVER" | sudo tee /var/www/html/api/index.html
sudo systemctl restart nginx

 

.

curl localhost/api/

.

2번째 VM 작업도 비슷하게 진행해 줍니다.

sudo mkdir /var/www/html/web
echo "WEB SERVER" | sudo tee /var/www/html/web/index.html
sudo systemctl restart nginx

 

---

백엔드 풀 및 회람 규칙 생성

API용 백엔드 풀(pool-api)을 생성해 준 뒤 대상 서버로 vm-web-01을 지정해 줍니다.

.

VM 2번에 대한 백엔드 풀(pool-web)도 추가해 줍니다.

.

또한 회람 규칙에서

Path 기반 라우팅을 적용하기 위해 HTTP Listener를 먼저 정의해 줍니다.

.

기본 라우팅 대상은 pool-web으로 설정하고, 추가적으로 경로 기반 분기를 위해 Path Rule을 정의해 줍니다.

URL 경로가 /api/* 패턴과 일치할 경우 pool-api로 트래픽을 전달하도록 설정하고

그렇지 않은 경우는 기본 라우팅 대상 즉, pool-web으로 전달됩니다.

.

.

다음과 같이 /api/* 요청은 pool-api, /web/* 요청은 pool-web로 분기되도록 구성이 되었습니다.

Path Rule이 다른 것들보다 우선적으로 평가됩니다

이를 통해 단일 Listener에서도 URL 경로 기준으로 서비스(API/Web)를 분리할 수 있게 될 겁니다...!!

.

마지막으로 테스트를 위해 프런트 엔드 공용 IP를 복사한 뒤...

.

공용 IP 뒤에 /api가 붙으면 API Server

/web이 붙으면 Web Server로 분기되는 것을 확인할 수 있었습니다.

 

---

참고자료

Azure Application Gateway URL 기반 콘텐츠 라우팅 개요 | Microsoft Learn

Azure Application Gateway URL 기반 콘텐츠 라우팅 개요