[트러블 빵야] 6개월 동안 즐거웠다.. 잘가고 다신 보지 말자! - 504 Gateway Timeout (이슈 편)

 

 

앞서 작성했던 트러블 슈팅 관련 글 중에 한 글은 제목이 "타노스는 이런 느낌일까?" 라고 지었을 만큼 꽤나 힘들었던 에러였죠.

 

근데 이번에 겪은 이슈는 앞선 글 제목에 타노스 라고 붙이기 민망할 정도로 원인을 찾기가 힘들었고, 또한 이슈가 6개월이나 지속될 정도로 마음 아팠던 트러블 슈팅이였습니다. 

 

들어가기 앞서 간략하게 환경은 다음과 같아요.

현재 환경

 

쿠버네티스는 AWS EKS(v1.28) 를 이용하고 있으며, 서비스메시 서비스인 이스티오(v1.18)의 인그레스 게이트웨이와 AWS ALB 를 맵핑하여 클러스터 외부에서 클러스터 내부 서비스에 접근이 가능합니다. 그리고 여기서 사용할 내부 서비스는 ArgoCD(v2.5) 입니다.

 

이슈는 ME! 가 ArgoCD 에 접근을 했을때 불특정하게 504 Gateway Timeout 이 발생합니다.

어딘진 모르겠지만 504 Gateway Timeout 이 발생

 

근데 정말 미스테리한 건, ArgoCD 서비스 전체에 대한 504 Gateway Timeout 이 발생하는 것이 아니라 랜덤하게 특정 리소스만 발생한다는 것이였죠!

ArgoCD 에 국한된 것은 아니고, EKS 상에 있는 모드 서비스에서 발생했습니다. 

 

 

이게 무슨 말이냐, 아래 이미지처럼 개발자 도구를 켰을 때 js, css 등 상관없이 랜덤으로 하나의 리소스만 pending 상태에 빠지고 결국 설정된 AWS 에 설정된 Idle Timeout 이 지나도록 pending 이 지속되어 결국 커넥션을 끊어버려 504 Gateway Timeout 이 발생합니다.

랜덤한 리소스 하나가 pending 상태에 빠지다 504 gateway timeout 이 발생

Idle Timeout 이 초과되어 에러 발생 (1m == 1 minutes)

 

504 Gateway Timeout 은 어렵지 않게 볼 수 있는 에러였기 때문에 관련된 해결책이 많을 거라 생각했습니다. 언제나처럼 우선 이스티오 공식 레포에 가서 같은 문제를 겪었던 사람이 있는지 찾아봤습니다.

https://github.com/istio/istio/issues/12417

 

상황은 비슷한데 명확한 해결책이 작성되어 있진 않았습니다. 이외에도 관련된 이슈가 있는지 찾아봤지만 이렇다한 해결 방법이 없었습니다. 따라서 직접 원인을 찾아 나서야 했죠.

 

의심되는 부분은 트래픽을 라우팅하는 AWS ALB 와 Istio 그리고 내부 애플리케이션 자체(ArgoCD 와 같은) 입니다. 그럼 누가 범인인지 조사를 한번 시작해보겠습니다!

 

렛츠두더코드!

 

 

 

첫번째 용의자, AWS ALB

---

 

가장 앞단인 ALB 부터 조사를 했습니다.

ALB 부터 조사

 

 

현재 사용하고 있는 AWS ALB 의 모니터링 입니다. 이미지 3개만 가져왔는데, 확실히 스파크가 튀는 부분이 존재합니다. ELB 5XXs 부분도 0 이 아닌 것을 확인할 수 있죠.

 

로드밸런서 상태

 

504 Gateway Timeout 은 Idle Timeout 과 연관이 깊습니다. Idle Timeout 은 AWS ALB 에서도 지정할 수 있고, 자바와 같은 애플리케이션에서 Timeout 을 지정할 수 있는데, 여기서 조심할 점이 있습니다.

 

공식문서에 나와있는 AWS ALB 504 Gateway 의 원인

 

하나의 API 요청에 대해 애플리케이션이 응답하는데 20초가 걸린다고 가정해보겠습니다. 그런데 AWS ALB 에 설정한 Idle Timeout(30초가 Default)이 10초라면 ALB 가 자동으로 커넥션을 끊어버려 504 Gateway Timeout 가 발생하죠. 따라서 애플리케이션의 Idle Timeout 은 AWS ALB 보다 적게 하는 것이 좋습니다.

 

그리고 마침 제가 사용하는 AWS ALB 같은 경우에는 Idle Timeout 을 600초로 해놨었는데, 이게 너무 길어서 커넥션 수가 무의미하게 늘어나고, 그만큼 AWS ALB 에 부하가 걸려 에러가 발생한다고 생각했습니다. 그에 따라 Idle Timeout 을 60초로 재설정 했죠.

 

커넥션수가 급격하게 줄어듬

확실히 효과는 있었습니다. 오후 03시에는 789개나 되었던 커넥션 수가 오후 09시에는 100개 이하까지도 떨어졌죠.

 

근데 이것이 504 Gateway Timeout 을 해결해주진 않았습니다.

 

생각해보면 애초에 AWS ALB 는 AWS Managed 이기 때문에, 워크로드에 맞게 알아서 자동으로 조정되기 때문에 부하가 걸리더라도 큰 부담이 없습니다. (공식문서 참고)

AWS Managed 는 ALB, EKS 처럼 AWS 자체가 관리해주는 서비스이므로, 문제가 생겨도 사용자가 신경 쓸 부분이 없는 반면, 반대인 EC2 와 같은 Client Managed 는 부하 걸리거나 문제가 생겼을 경우 직접 해결해야 합니다.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/introduction.html

 

그리고 ArgoCD 서비스에서 60초가 넘도록 걸리는 응답이 없었기 때문에 600 초에서 60 초로 Idle Timeout 을 줄어줬더라도 효과는 없었을 것입니다.

 

혹시나 해서 새로운 ALB 를 생성해서 트래픽을 라우팅 해줬는데 새로운 ALB 에서도 에러가 똑같았습니다.

이걸로 우선 AWS ALB 은 용의선상에서 벗어났습니다..

 

 

두번째 용의자, Istio

---

 

자, AWS ALB 는 범인이 아니란 걸 알았고 그 다음으로 Istio 를 조사했습니다.

Istio 조사

 

들어가기 앞서 간단하게 이스티오에 대해 설명하고자 합니다.

이스티오에 대한 글이 아니기 때문에 간략하게 설명하고, 다른 글에서 이스티오에 대해 자세히 다루겠습니다!

 

이스티오에는 Istio Ingress Gateway 라는 컴포넌트가 있습니다. Istiod 와 같은 필수 컴포넌트는 아니지만 사실 상 필수 컴포넌트 입니다. 왜냐 클러스터 내부 서비스를 클러스터 외부에 노출하기 위해선 반드시 필요한 컴포넌트이기 때문입니다. 

https://istio.io/latest/docs/concepts/security/arch-sec.svg

 

 

AWS ALB 에 대상 그룹으로 Istio Ingress Gateway 를 등록해서 외부에서 EKS 내부에 있는 서비스로 접근이 가능합니다.

AWS ALB 와 Istio Ingress Gateway 를 맵핑하는 자세한 방법이 궁금하다면 여기!

 

 

32001 포트는 대상 그룹의 Health Check 를 위한 노드의 포트이고, 32002 포트는 실질적으로 트래픽을 라우팅할 포트입니다.

만약 AWS ALB 뒷단에도 443 포트를 이용할 것이라면 32002 포트 대신 32003 포트를 이용하면 됩니다. 

 

ALB 의 SSL Offload 기능 덕분에 32002 포트로 라우팅해도 무방하다고 생각합니다.

 

 

그에 따라 대상 그룹에 등록된 모든 노드들은 32001 - 32002 포트를 허용해주는 보안 그룹 규칙을 가지고 있어야 하며, 이 중 하나라도 Deny 가 된다면 대상 그룹 등록에 실패할 것입니다.

 

Ingress Gateway 는 Egde Proxy 이자 Reverse Proxy 를 역할을 해주기 때문에 이제 ALB 를 통해 들어온 트래픽에 대해선 모두 Ingress Gateway 에게 맡겨주면 됩니다. 

 

Istio Ingress Gateway 와 Gateway Resource 는 알면 알수록 굉장히 흥미로운 컴포넌트들이기 때문에 나중에 블로그에서 더 자세히 다루도록 하겠습니다.

 

 

다시 이제 본론으로 돌아와서, AWS ALB 뒷단에 대상 그룹으로 Istio Ingress Gateway 가 정상적으로 등록된 것으로 보아 AWS ALB 와 Istio Ingress Gateway 사이에는 문제가 없다고 생각을 했습니다.

 

Istio Ingress Gateway 자체에 무언가 문제가 있나하고, 로그를 뒤져봤지만 로그 상에는 보이는 문제는 없었습니다. 그러다 문득 EKS 초창기에 비용을 아낀다고 이스티오와 관련된 컴포넌트의 리소스는 굉장히 적게 주었던 것이 떠올랐습니다. 

 

실제로 Request, Limit 모두 250m CPU, 1G Memory 를 사용하고 있었죠. 초기에 비해 EKS 위에 많은 파드들이 생겨놓았고, 이를 핸들링 하기에는 저 메모리가 현저히 부족했을 것입니다.

 

그에 따라 우선 2 CPU, 4G Memory 를 각각 Istio Ingress Gateway, Istiod 에게 부여해주었습니다. 이렇게 하니 다행히 504 Gateway Timeout 문제가 없어졌습니다!!

 

여기서 해결되었으면 좋았겠지만 몇일이 지난 후에 또 다시 504 Gateway Timeout 이 발생했습니다... 정신이 어지럽더군요.. 

 

이외 이스티오 리소스인 Gateway, Virtual Service, Destination Rule 등 문제가 있나, 또 다른 옵션이 있나 찾아보았지만 역시나 504 Gateway Timeout 문제는 계속 진행되었습니다.

 

이 정도면 이스티오 또한 문제가 없을거라고 판단을 했습니다. 심지어 EKS 초창기에는 아주 잘 동작했기 때문에 다른 곳에 문제가 있을 거라 판단했습니다.

이걸로 이스티오 또한 용의선상에서 벗어났습니다..

 

세번째 용의자, 애플리케이션 자체

---

 

AWS ALB 도 아니고 이스티오 문제도 아니라는 것을 알았습니다. 그렇다면 이제 남은 것은 애플리케이션 자체입니다.

혹시 ArgoCD 애플리케이션 자체에 메모리가 부족하나? 싶어서 메모리도 증설해봤지만 역시 소용없었습니다.

 

ArgoCD 애플리케이션의 Idle Timeout 은 헬름으로 설정조차 할 수 없었기 때문에 애플리케이션 자체는 문제가 아니라고 판단했습니다.

 

그리고 ArgoCD 뿐만 아니라 모든 애플리케이션에서 같은 현상이 발생했기 때문에 애플리케이션 자체 문제는 아닌거 같습니다.

 

 

이대로 영원히 미궁속으로..?!

---

 

504 Gateway Timeout 은 발생 초기엔 큰 지장이 없었으나, 시간이 점차 흐르면서 서서히 개발에 있어서도 지장이 생기게 되었습니다.

ArgoCD 와 같은 클러스터 외부로 노출된 서비스의 속도가 현저히 느려졌고, 504 Gateway Timeout 의 빈도도 늘어난 것이 였죠.

 

이스티오 공식 레포에 이슈를 작성해봤지만 크게 도움은 되지 못했습니다.

https://github.com/istio/istio/issues/48578

 

 

중간중간 실마리와 관련된 글들을 발견했지만, 직접적인 해결 책이 되진 않았습니다.

https://medium.com/@pooyan_razian/how-to-fix-a-http-504-gateway-timeout-error-4ce6f396bab6

 

그리고 저와 같은 이슈를 겪는 분들이 많은지 제가 올렸던 Github Issue 에 해결책을 묻는 분들이 몇 계셨습니다.

 

글은 3월에 작성되었지만, 이 이슈에 대해선 해결하진 꽤 되었고, 코멘트에 이미 해결 방법에 대한 스포가 있네요!

 

 

다음 글 [트러블 빵야] 6개월 동안 즐거웠다.. 잘가고 다신 보지 말자! - 504 Gateway Timeout (해결 편) 에서 이어집니다..