AWS EC2를 통한 Airflow CeleryExcutor 구축기 를 진행하던 중 발생한
Flower Troubleshooting에 관해 다뤄보겠습니다.
docker container에 올라간 flower 대시보드가 ALB를 통한 연결이 되지 않는 문제가 발생했었습니다.
http request의 결과는 HTTP 504 gateway time-out로 어떠한 원인으로 인해 연결이 닿지 않는 것으로 추정되었습니다.
이 원인을 찾아보고자,
-
가장 먼저 ALB의 보안 그룹을 살펴보았고 관련 포트번호(5555)가 열려있는 것을 확인했습니다.
( 밑에서 서술하겠지만 여기서부터가 잘못된 전제였습니다. ) -
Docker logs 명령어를 통해 flower의 log를 살펴보았습니다. 이 또한 문제가 없었습니다.
-
해당 EC2 환경에서 5555 port가 listen 상태인지 확인을 해보았는데 이 또한 문제가 없었습니다.
-
ALB가 아닌 Local 환경에서 ssh를 통한 포트포워딩을 진행했습니다. 이 경우에도 time out이 발생했기에 ALB 문제가 아니라고 판단했습니다.
그렇게 관련 이슈를 stackoverflow나 github issue들을 쭉 뒤져보았습니다.
거기서 제가 얻은 단서는 airflow 버전에 따른 flower 버전이 중요하다는 것, 또한 kombu의 버전이 5.3.2 보다 높으면 대시보드의 출력에 버그가 발생한다는 것.. 정도 였습니다.
그래서 관련 dependency들을 모두 조율해주었는데 그럼에도 상황은 개선되지 않았습니다.
그렇게 한참을 또 헤메다가 EC2 환경에서 curl -v http://localhost:5555를 입력해보니 http 페이지가 정상적으로 출력이 되었습니다.
문득 생각이 들어, ssh가 아닌 SSM을 통한 local 환경에서 포트포워딩을 해보았는데 flower 대시보드가 정상적으로 출력이 되었습니다.
정리를 해보면,
EC2 환경에서는 flower가 정상적으로 동작하고 있다는 것이고
그렇다는 것은 포트포워딩의 문제라는 것인데 ALB, SSH는 안되고 SSM 만이 가능했다는 것은..
SSM 만이 가지고 있는 특성으로 인해 연결이 되었다는 것이므로 그 특성을 생각해보았습니다.SSM은 Private subnet에 접근할 때 bastion host를 거치지 않고 중앙에서 direct로 진입할 수 있습니다.
즉, EC2 보안 그룹의 영향을 받지 않는다는 것이죠.
이 부분이 ALB와 SSH와 구분이 되는 SSM만의 특성이였습니다.
그래서 해당 EC2의 보안그룹을 확인해보니 인바운드 규칙에 5555포트가 당연히 열려있지 않았습니다.
저는 포트포워딩이 local port (80) -> EC2 port (5555) 이런 식으로 이루어지니 해당 EC2에서는 인바운드 규칙으로 80포트를 열고 아웃바운드 규칙으로 5555를 열면 될 것이라고 생각을 하고 있었습니다. 그러나 이는 잘못된 생각이였고 5555포트를 인바운드 규칙에 개방했어야 했던 것이죠..
그렇게 5555포트를 개방함으로써 Flower는 정상적으로 연결이 되었습니다.
-> 결론 :
EC2 보안 그룹에서 특정 포트를 허용해주지 않아서 생긴 문제로,
위와 같이 80:5555 포트를 연결해주고 싶다고 했을 때,
ALB의 인바운드 규칙에서는 리스너인 '80 포트'만 개방해주면 되는 것이고,
대상이 되는 5555 포트는 EC2의 인바운드 규칙에서 열어줘야한다는 것입니다.
