Azure App Gateway에 대하여 -쉬움

App Gateway 설정에서 얻은 정보

App GateWay는

기본적으로

1. Listeners 2. BackEnd Settings 3. BackEnd Pools 4. Rules

로 이루워 져있다.

 

 

 

 

Listeners (수신기) :

외부로부터 들어오는 요청을 HTTP/HTTPS로 받아드리는 웹 소켓을 지원하는 것을 의미하며 연결 요청을 확인하는 논리적인 엔티티이다.

DNS Hostname을 설정 할 수 있으며 접속 Port 또한 설정하여 원하는 요청을 가려낸다.

또한 HTTPS로 SSL 통신을 하게 되는 경우 해당 지점에서 SSL Offload가 일어난다.

BackEnd Pools :

실제로 수신기로 통해 들어온 트래픽을 Rule 설정에 따라 나누어 받는 서버들의 모음이다.

해당 타겟에는 가상머신이나 vmss app service 등이 될 수 있다. 기본적으로 라운드 로빈 방식으로 pool의 자원들에 배분되는데 Rule에서 지정하면 경로기반 라우팅 혹은 세션 어피니티 등을 할수 있다.

BackEnd Settings :

리스너에서 트래픽이 들어오게 되면 Rule에서는 지정된 BackEnd Settings를 토대로 BackEnd에서 트래픽을 받게 된다. 백엔드가 어떤 프로토콜로 받을지 백엔드는 어떤 포트로 받을 것인지 호스트를 재정의 할지 등을 정할 수 있다. Custom Probe를 사용하면 Health check 또한 가능하다.

Rules : 룰은 백엔드에 도달하는 트래픽을 전달할 리스너의 선택과 우선순위를 정할 수 있으며

백엔드 타겟에 대한 설정을 할 수 있으며, 추가적으로 경로기반 라우팅 설정이 가능하다.

경로기반 라우팅을 설정 할 경우 기본 라우팅에서 추가적인 경로가 들어올 경우 설정 된 곳으로 라우팅 할 수 있게 된다.

AppGateWay는 Health probes를 설정하여 사용하면 주기적으로 백엔드의 상태를 체크할 수 있다.

Get Http 콜을 사용하여 백앤드가 응답을 할 수 있는 상황인지를 체크하며 응답이 어려운 상황일 경우 Unhealty 상태로 만들어 502 Error를 내어준다. 후에 인스턴스가 이용이 가능해졌다 하더라고 Health Check에 통과하지 못하면 502 에러가 난다.

1. 502 Bad GateWay가 발생을 하였다.

이유는 app gateway는 수신기는 dapp.ksop.co.kr를 설정하여 dapp.ksop.co.kr에서 오는 정보를 80포트를 통해 받는 입구 설정을 하였다.

502의 에러가 많이 발생하지만 기본적으로 아예 요청을 하는 서버를 찾지 못하였을 때는 404가 뜨지만( route 규칙을 아예 지워버린 경우)

app gateway에 접근이 가능하였지만 백엔드 풀에 접근에서 url를 찾지 못한 경우에는 404

백엔드 인스턴스가 죽어있거나 이용 불가 상태일 경우에는 502가 나타날 수 있다.

실제 케이스:

백엔드 설정에서 호스트 이름을 재정의 하는 옵션으로 호스트 이름을 정의하면 시간이 지나면 백엔드 상태가 비정상인 상태로 만들어지고 502 에러가 뜬다. 해당 옵션을 백 앤드에 맞춰 설정으로 바꿔주면 백엔드 상태가 정상으로 되지만 404가 뜬다. 따라서

다시 백 엔드 설정을 호스트 이름의 재정으로 바꿔주는데 이때 일시적으로 한동안 정상 호출이 되며 응답 또한 잘 오게된다. 그리고 시간이 지나면 502 에러가 발생한다.

502가 생긴다는 것은 기본적으로 웹 서버가 게이트웨이나 프록시 역할을 하면서 올바른 응답을 받지 못했을 때 발생한다

즉, url 루트는 찾았지만 웹서버의 응답이 잘못된 경우 발생한다.

이유는 여러가지 이지만 서버 과부하,서버 오류, 네트워크 문제, 원격 서버의 문제 등이 있는데

이번의 경우에는 원격 서버인 iis 가 내려가 있어서 발생한 경우 + Health Check에서의 Check URL의 매칭 실패였다.

처음엔 VM에 IIS가 설정이 되어있고 Rule 설정을 새로하여 Health Check 전까지는 트래픽이 잘 전달 되다가 60초 이후 Health Check가 발동하여 UnHealthy 체크가 되는 순간부터는 502 에러가 발생하였다.

 

 

 

개인적인 의문

그럼 궁금한게 있어 이미 리스너 단계에서 SSL Offload가 되면 복호화 된 트래픽이 Rule를 거쳐 백엔드로 들어가게 될텐데 왜 Rule에선 백엔드가 HTTP으로 받을지 HTTPS으로 받을지 정하는 거야? 이미 오프로드 된 트래픽은 HTTP아닌가?

 

ChatGPT의 대답

 

Azure Application Gateway에서 SSL Offload는 리스너에서 이루어지는 것이 맞습니다.

이것은 클라이언트와 게이트웨이 간의 연결에서 SSL/TLS 암호화를 처리하며, 이를 통해 백엔드 서버에 부하를 주는 SSL/TLS 처리 작업을 줄일 수 있습니다.

 

하지만, 여기서 중요한 점은 게이트웨이와 백엔드 서버 간의 통신을 어떻게 설정하느냐에 따라 HTTP 또는 HTTPS를 사용할 수 있다는 것입니다. 이 설정은 Rule에서 결정됩니다.

즉, 클라이언트에서 게이트웨이로의 통신에서 SSL Offload가 일어나므로, 복호화된 HTTP 트래픽이 게이트웨이를 통해 들어옵니다.

 

그러나 게이트웨이에서 백엔드 서버로 트래픽을 전달하는 방식은 별도로 설정할 수 있습니다. 이는 보안 요구사항에 따라 달라질 수 있으며, 종단 간 SSL을 구현하는 데 필요한 경우가 있습니다.

 

예를 들어, 만약 백엔드 풀의 서버들이 민감한 데이터를 처리하고 있고, 그 통신이 게이트웨이 내부 또는 사설 네트워크 내에서도 암호화되어야 하는 경우, 게이트웨이와 백엔드 서버 사이의 통신을 HTTPS로 설정해야 할 것입니다. 이 경우 게이트웨이는 들어온 트래픽을 다시 암호화하여 백엔드 서버로 전송하게 됩니다.

 

따라서 Rule에 백엔드가 HTTP로 받을지 HTTPS로 받을지 설정하는 이유는 게이트웨이와 백엔드 서버 사이의 통신 방식을 조정하기 위함입니다. 이는 클라이언트에서 게이트웨이로의 통신과는 별개의 설정입니다.

 

https://learn.microsoft.com/ko-kr/azure/application-gateway/how-application-gateway-works

애플리케이션 게이트웨이 작동 원리