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

 

 

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

 

곰곰이 생각해봤습니다. 504 Gateway Timeout ... 결국 어디선가 Response 를 받아야 하는데 받지 못해서 생기는 이슈 입니다.

어딜까?

 

어디서 Response 을 받지 못했을까요? 위 아키텍처만 봤을땐, 더 이상 도저히 모르겠습니다. 

 

그래서 위 이미지보다 조금 더 아키텍처를 구체화시켜봤습니다.

좀 더 구체화된 아키텍처

 

AWS ALB 는 Target Group 에 등록된 노드에게 트래픽을 라우팅 해주는데, Karpenter 로 생성되는 노드들은 모두 동일한 Target Group 에 등록됩니다.

 

(대수롭지 않게 동일한 Target Group 에 등록되게끔 구성했죠)

 

여기서 의문점 하나가 듭니다. 만약 Istio Gateway Pod 가 없는 노드에 라우팅 되면 트래픽은 어떻게 될까요?

쿠버네티스 네트워크에 대해 아신다면 쉽게 정답을 알아차리실 겁니다.

 

iptables 모드일 경우 각 노드마다 데몬셋으로 존재하는 kube-proxy 가 관리하는 iptables 에 의해 Istio Gateway Pod 가 있는 노드로 다시 한번 라우팅하게 될 것입니다.

 

그리고 홉(hop)이 하나 증가하게 되죠.

Hop += 1

 

하나의 홉(hop) 이 증가한다고 해서 큰 문제는 되지 않겠지만, 클러스터 내에는 다양한 서비스들이 존재하기 때문에 하나의 홉(hop) 일지라도 쌓이면 어마어마한 양이 되고, 결코 무시할 수 없습니다.

 

아하? 원인을 충분히 알 것 같습니다.!

 

결국 증가한 홉(hop) 에 의해 Latency 가 발생했던 것이였고, 이로 인해 504 Gateway Timeout 이 발생했습니다.

 

Karpenter 에 의해 노드가 생성되고, 생성되는 노드는 구분없이 AWS Target Group 에 등록되기 때문에 서비스가 증가함에 따라, 노드도 증가하고, 그에 따라 Istio Gateway Pod 가 있는 노드에 한번에 HIT 하기가 힘들었을 겁니다.

만약 20개의 노드가 있고, 2개에 노드에만 Istio Gateway Pod 가 있을 경우 AWS ALB 라운드 로빈에 의해 2/20 확률로만 추가 홉(hop) 이 생기지 않는 거죠. 그 말은 반대로 18/20 확률로 홉(hop) 이 계속 증가되는 것입니다.

 

그래서 불필요한 홉(hop) 을 줄여줄 필요가 있고, 위 아키텍처를 참고했을 때 줄일 수 있는 방법은 트래픽이 일반 노드가 아닌 Istio Gateway Pod 가 있는 노드에만 보낼 수 있도록 하는 것입니다.

 

이와 관련해서는 2가지 방법을 생각해 볼 수 있는데,

 

첫번째 방법은 Target Group 에 Istio Gateway Pod 가 있는 노드만 등록해주는 것이고,

두번째 방법은 ExternalTrafficPolicy: Local 를 사용하는 겁니다.

 

 

첫번째 방법 

---

 

아래 이미지처럼 Target Group 에 Istio Gateway Pod 가 있는 노드만 등록해줍니다.

Target Group 에 Istio Gateway Pod 가 있는 노드만 등록

 

좀 기술적?으로 얘기해보자면,

 

Istio 전용 Kapenter 의 kind: NodePool 를 만들고, Istio 관련 리소스들은 모두 해당 NodePool 로 생성되는 노드에 스케줄링 되게끔 구성합니다.

 

예제 NodePool.yaml 에 명시되어 있는  Label 과 Taint&Toleration 을 이용해서 Istio 리소스를 스케줄링합니다.

예시 NodePool

 

그리고 AWS LB Controller 의 kind: Ingress 를 아래와 같이 작성해줌으로써, Istio 가 있는 노드만 Target Group 에 등록시킬 수 있습니다.

예시 Ingress

 

실제로 이렇게 Istio Gateway Pod 만 있는 노드만 Target Group 에 등록하니 6개월 동안 지속됐던 504 Gateway Time 이 마법처럼 사라졌습니다..

 

 

두번째 방법

---

 

두번째 방법은 Service 의 ExternalTrafficPolicy 를 Local 로 설정하는 것입니다.

default 는 Cluster

externalTrafficPolicy: Local

 

ExternalTrafficPolicy: Local 로 설정하게 되면 아래 이미지처럼 동작하게 됩니다.

ExternalTrafficPolicy

 

AWS ABL 가 골고루 라우팅(기본 라운드로빈)하게 되는데, 만약 Istio Gateway Pod 가 없는 노드라면 블랙홀에 빠지게 되고, 있는 노드라면 마저 뒷단으로 트래픽을 보내게 됩니다.

 

만약 ExternalTrafficPolicy: Cluster 라면 아래처럼 동작합니다.

Hop += 1

 

ExternalTrafficPolicy: Local 의 경우 불필요한 홉(hop) 을 추가시키지 않아 Latency 를 감소시킬 수 있고, SNAT 이 진행되지 않아 Client IP 를 보존할 수 있다는 장점이 있지만, 트래픽이 골고루 분산되지 않을 수 있다는 단점이 존재합니다.

라우팅이 골고루 되지 않음 (골고루라면 33.3%)

ExternalTrafficPolicy: Cluster 장단점은 Local 장단점의 반대!

 

 

이 방법도 충분히 504 Gateway Timeout 해결할 수 있었습니다.

 

두번째 방법을 사용하면 여전히 Target Group 에 Istio Gateway Pod 가 없는 노드가 존재합니다. 
어차피 AWS ALB 에서 Istio Gateway Pod 가 없는 노드는 Health Check 가 안될테니 라우팅이 되지 않을 것입니다.

하지만 AWS ALB 대시보드에 "실패" 가 표시되죠. 그래서 더 깔끔한 방법으로는 첫번째 방법과 두번째 방법을 섞어주는 것입니다.

단, 트래픽을 골고루 분산시켜주기 위해서 되도록이면 노드 당 하나의 Istio Gateway Pod 가 실행될 수 있도록 해주는 것도 괜찮은 방법이라 생각합니다. 약간 데몬셋처럼 말이죠. 

 

결론

---

 

어느 방법을 사용해도 상관없지만 핵심은 Istio Gateway Pod 가 있는 노드로 한번에 트래픽을 보내줄 수 있도록 하는 것입니다!!

 

오랫동안 이슈를 해결하지 못해서 골치가 정말 아팠는데.. 다행히 읽고 있는 쿠버네티스 서적에서 관련된 아이디어를 우연히 얻게 되어 해결할 수 있었습니다.

 

Istio 도 아니였고, AWS ALB 도 아니였고, 서비스 되는 애플리케이션도 아닌.. 쿠버네티스 설정의 문제였던 거죠.

 

그럼 이제 Istio Issue 에 해결 방법을 궁금해 하는 분들에게도 알려주러 가보겠습니다!! 

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

 

AWS SG 관련 트러블 슈팅 내용은 Istio Issue 에서 직접 확인하시길 바랍니다!

 

PS.

의심했지만 용의자들이 범인이 아니였던 이유! - 이전 글 참고

 

Q) AWS ALB 의 timeoute=600 초로 무의미한 커넥션 수의 증가

AWS ALB 는 AWS Managed 였기 때문에 커넥션 수가 늘어난다고 해서 성능면에선 크게 문제가 없습니다. 알아서 퍼포먼스를 증가시키기 때문이죠.

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

 

 

Q) Istio 의 리소스 부족 의심

Istio 의 리소스가 부족하다고 생각하여 2 CPU, 4G Memory 로 증설했지만, 의미가 없던 행동이였습니다.

메트릭을 확인했을 때 이미 기존에 사용하고 있던 250m CPU, 1G Memory 로도 충분합니다.

 

그럼 오늘은 여기까지!