
최근에 5xx 에러가 나를 골치아프게 했다.
오늘 작성할 포스트는 그 중 한가지 였는데 5xx대 에러는 막상 해결하면 별 일 아니지만 서버와 직접적인 통신이 이루어지지 않아 로그가 남지 않는 경우가 있어 원인 파악이 매우 어렵다.
일을 하던 중 Backend Engineer 팀원에게 문의가 왔다.
🧔: 특정 도메인에 접근하려고 하면 504가 발생하는데 혹시 원인 아실까요?
504 에러는 Gateway Time-Out 에러로 서버가 게이트웨이 또는 프록시 역할을 할 때, 상위 서버로부터 응답을 기다리는 시간이 초과되었음을 의미한다.
현재 우리 회사의 서버 구조는 아래와 같다.

5xx대 에러는 그래도 서버와 통신은 했다는 것이니까 WAF 까지는 잘 통과했다고 생각할 수 있다.
그렇다면 예상할 수 있는 원인은
이러한 상황에서 우리가 확인해볼 수 있는 로그 값은
이 있을 수 있다.
하지만 이제 변수가 나타난다.
에러가 발생한 서버가 Dev 서버인데 Dev 서버에서는 따로 VPC Flow와 ALB Access Log를 남기지 않고 있다는 것이다. (비용 절감의 목적)
또 같은 에러를 재현하고자 하니 특정 사람에게는 502, 503, 504 심지어는 정상적으로 작동하는 경우도 있는 것이다.
이런 경우 보통 가장 먼저 의심해봐야하는 부분은 브라우저 캐싱이다.
기기마다 브라우저 캐싱값이 다르므로 다른 결과가 나올 수 있기 때문이다.
그래서 일단 WEB Server의 로그를 확인해보았다.
[Apache error log]
[proxy:error] [pid 2709:tid 140529373275904] (70007)The timeout specified has expired: AH00957: http: attempt to connect to {WAS-ALB-IP} ({WAS-ALB-DNS}) failed
[proxy_http:error] [pid 2709:tid 140529373275904] AH01114: HTTP: failed to make connection to backend: {WAS-ALB-DNS}
브라우저 캐시 값 때문에 사람마다 결과값이 다르다면 WEB Server에는 위와 같은 에러 로그가 남겨지면 안된다.
로그를 분석해보면 현재 WAS ALB에 연결을 시도하지만 Timeout이 발생하였고 따라서 연결을 실패하였다는 내용이다.
WAS ALB DNS 주소가 잘못 설정되어있나 확인하였으나 DNS 주소는 정확하게 입력되어 있었다.
그 때 ALB에 대해서 공부했던 기억이 머리속을 스쳐지나갔다.
ALB는 고정 IP를 가지지 못한다.
ALB는 동작할 때 내부적으로 EC2를 생성하여 트래픽을 처리한다.
트래픽이 많아지면 Scale Out 하여 트래픽을 처리하고 트래픽이 줄어들면 Scale In 하여 EC2를 종료한다.
따라서 ALB는 고정 IP를 가지지 못하는것이다.
나는 바로 ALB가 현재 가지고 있는 IP 주소를 확인하였다.
$ nslookup alb-dns-address
원인을 찾았다.
Apache에서 연결을 시도하는 ALB IP 주소와 다른 값을 결과 값으로 보여주는것이다.
이제 원인을 알았으니 조치를 해야한다.
Web Server의 Apache 설정값을 수정했다.
disablereuse=On 해당 옵션을 추가하였는데 이 옵션의 역할은 백엔드 서버와의 연결을 재사용하지 않도록 하는 역할을 한다.
이를 통해 각 요청마다 새로운 연결을 생성하게 된다.
conf.d/extra/httpd-vhosts.conf
ProxyPass / {alb-dns-address} disablereuse=On
ProxyPassReverse / {alb-dns-address}
참고한 내용:
https://iingang.github.io/posts/OHS-proxypass-DNS-Cache/
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass
결국 문제는 아래 httpd 가 Caching 하고있는 IP 정보와 ALB 의 IP 정보가 차이가 나서 발생하는 이슈였다.
근데 이제 Prod 서버에서 다른 원인으로 502에러가 발생하는데...