📝 서론

이전 포스팅에서 로그를 확인해 보고, ALB의 문제임을 확인했다.
이후 구글링을 통해 문제를 해결했는데, 그 과정을 포스팅 하겠다.

🛠️ 문제해결 과정

나의 삽질들

KeepAliveTimeout

일단, 나의 경우에는 ALB에서 EC2의 톰캣으로 요청을 전달해 주지 않았기 때문에 다른사람들의 문제 원인이었던 KeepAliveTimeout 문제는 나에게 해당되지 않았다.

Apatch log 확인

정보를 찾아 보면서 톰캣 자체에서도 간단한 웹서버 기능을 포함하고 있다는 것을 알게 되었다.
나는 별도의 NGINX나 Apatch같은 웹 서버를 사용하고 있지 않지만, 혹시나 웹 서버까지 요청이 전달되고 있는지 확인을 해 보고 싶었다.

내 톰캣이 저장되어 있는 위치의logs 폴더에 localhost-로 시작하는 로그가 존재하는 것을확인할 수 있었다. 그러나, 이곳에서도 502 에러 시점에서 발생한 별도의 로그를 확인할 수 없었다.

패킷 캡쳐

혹시나 패킷을 보면서 문제를 해결할 수 있을까 Wireshark로 패킷을 캡쳐해 보았다.
그런데, 패킷 캡쳐를 분석하는 것이 상당히 번거로웠다.

1. 내가 확인하고 싶던 통신 외에도 다양한 통신이 이루어 지고 있었음
   • 내가 확인하고 싶었던 패킷은 내 도메인으로 전달되는 요청과 도메인에서 받는 응답이었다.
   • 캡쳐되는 패킷에는 주변에 다른사람들이 에어드랍을 사용하면서 발생하는 MDNS 프로토콜의 패킷등 다양한 다른 패킷도 포함하고 있었다.
     • MDNS 패킷은 네가 ***가 맞다면 xxx에게 응답을 보내라. 라는 형식의 프로토콜이더라.
2. 내가 확인하고 싶던 통신은 Https로 암호화된 패킷이었음
   • Https로 암호화된 패킷을 복호화 하는 방법을 찾긴 했다.
   • 오랜 시간의 트러블슈팅으로 상당히 지쳐있었고, 이 방법은 뒤로 미뤄두기로 했다.

문제의 원인

그러다가 티스토리의 어떤 글에서 나와 같은 문제를 겪고 있는 사람을 찾았다.
이 사람의 해결 방법은 로드밸런서의 healthy check 결과가 unhealthy인 것을 해결해 주는 것이었다.

아래 그림은 502 BadGateway 문제가 발생할 때의 나의 target group의 상태였다.

healthy check

ALB는 호스팅 할 서버를 target group으로 설정한다. 이 때, target group이 정상적인 동작을 하는지 확인을 하기 위해 주기적으로 target group에 GET 요청을 보내고, 응답을 확인한다. 이 때 사용하는 요청의 기본값은 GET "[도메인 이름]/"이었다.

나의 서비스는 나에게 필요한 특정 URL만 사용하고 있었으며, "[도메인 이름]/"에 해당하는 요청을 처리해 주지 않아 "[도메인 이름]/"로 접근하면 404 Not Found와 함께 Whitelabel Error 페이지가 반환되고 있었다. 이 때문에 ALB는 나의 서버가 정상적인 동작을 하지 못하는 unhealthy 서버라고 판단한 것 같다.

unhealthy 해결

이 문제를 해결하기 위해 두가지 방법이 있다.

1. ALB의 healthy check 요청을 컨트롤러가 처리하도록 만들어 준다.
2. ALB의 healthy check 요청 경로를 실제 서비스가 이루어지는 경로로 설정해 준다.

나의 경우에는 만들어 둔 모든 URL이 프론트엔드에게 데이터를 받거나, 넘겨주는 용도로 사용되고 있었으며 Welcome page의 개념이 없었기 때문에 2번 방법으로 사용할 URL을 정하기 애매했다. 그래서 GET "[도메인 이름]/" 요청을 처리해 줄 수 있는 컨트롤러를 하나 생성하는 방법으로 해결하였다.

문제 해결

드디어 200 OK와 502 Bad Gateway 응답이 번갈아 발생하던 문제를 해결할 수 있었다!!

✒️정리

AWS의 ALB를 사용하기 위해서는 target group을 healthy로 유지해 주는 것이 중요하다.
healthy check 요청을 처리하기 위한 컨트롤러를 만들거나, 실제 서비스가 동작하는 경로로 ealthy check경로를 설정해 주자.

참고 블로그

ELB 502 Error