<div id="readability-page-1" class="page"><div>
 <a href="/m/category/%ED%8A%B8%EB%9F%AC%EB%B8%94%20%EB%B9%B5%EC%95%BC">트러블 빵야</a><h3>[트러블 빵야] 6개월 동안 즐거웠다.. 잘가고 다신 보지 말자! - 504 Gateway Timeout (해결 편)</h3>
 </div><cite>KoB</cite>
 2024. 3. 27. 00:26
 <div>

<blockquote data-ke-style="style2">이전 글인 <a href="https://kingofbackend.tistory.com/280" target="_blank" rel="noopener">[트러블 빵야] 6개월 동안 즐거웠다.. 잘가고 다신 보지 말자! - 504 Gateway Timeout (이슈 편)</a> 에서 이어집니다!</blockquote>

곰곰이 생각해봤습니다. 504 Gateway Timeout ... 결국 어디선가 Response 를 받아야 하는데 받지 못해서 생기는 이슈 입니다.
<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2024-03-24 오후 3.04.39.png" data-origin-width="1592" data-origin-height="790"><img src="https://blog.kakaocdn.net/dn/0Vj8U/btsF3DW1isX/ZYeydtk62dO96xXRmEkUWk/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2024-03-24 오후 3.04.39.png" data-origin-width="1592" data-origin-height="790"><figcaption>어딜까?</figcaption>
</figure>


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

그래서 위 이미지보다 조금 더 아키텍처를 구체화시켜봤습니다.
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1954" data-origin-height="1374"><img src="https://blog.kakaocdn.net/dn/dBEUbL/btsF025vZaH/rEUaypNQc3YpBmb0mqHRb1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1954" data-origin-height="1374"><figcaption>좀 더 구체화된 아키텍처</figcaption>
</figure>


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

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

여기서 의문점 하나가 듭니다. 만약 Istio Gateway Pod 가 없는 노드에 라우팅 되면 트래픽은 어떻게 될까요?
쿠버네티스 네트워크에 대해 아신다면 쉽게 정답을 알아차리실 겁니다.

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

그리고 홉(hop)이 하나 증가하게 되죠.
<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2024-03-26 오후 11.26.38.png" data-origin-width="1312" data-origin-height="895"><img src="https://blog.kakaocdn.net/dn/E16QK/btsF8xCm12j/kSLIU9m5aqCziRnUbvlGNK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2024-03-26 오후 11.26.38.png" data-origin-width="1312" data-origin-height="895"><figcaption>Hop += 1</figcaption>
</figure>


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

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

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

<blockquote data-ke-style="style3">Karpenter 에 의해 노드가 생성되고, 생성되는 노드는 구분없이 AWS Target Group 에 등록되기 때문에 서비스가 증가함에 따라, 노드도 증가하고, 그에 따라 Istio Gateway Pod 가 있는 노드에 한번에 HIT 하기가 힘들었을 겁니다.만약 20개의 노드가 있고, 2개에 노드에만 Istio Gateway Pod 가 있을 경우 AWS ALB 라운드 로빈에 의해 2/20 확률로만 추가 홉(hop) 이 생기지 않는 거죠. 그 말은 반대로 18/20 확률로 홉(hop) 이 계속 증가되는 것입니다.</blockquote>

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

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

첫번째 방법은 Target Group 에 Istio Gateway Pod 가 있는 노드만 등록해주는 것이고,
두번째 방법은 ExternalTrafficPolicy: Local 를 사용하는 겁니다.


<h2 data-ke-size="size26">첫번째 방법&nbsp;</h2>
<hr contenteditable="false" data-ke-type="horizontalRule" data-ke-style="style6">

아래 이미지처럼 Target Group 에 Istio Gateway Pod 가 있는 노드만 등록해줍니다.
<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2024-03-27 오후 7.54.38.png" data-origin-width="1096" data-origin-height="810"><img src="https://blog.kakaocdn.net/dn/T8fJz/btsGawXGBkP/epp7geO0l5M2DMKYikDEN0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2024-03-27 오후 7.54.38.png" data-origin-width="1096" data-origin-height="810"><figcaption>Target Group 에 Istio Gateway Pod 가 있는 노드만 등록</figcaption>
</figure>


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

Istio 전용 <a href="https://karpenter.sh/docs/concepts/nodepools/" target="_blank" rel="noopener">Kapenter 의 kind: NodePool</a> 를 만들고, Istio 관련 리소스들은 모두 해당 NodePool 로 생성되는 노드에 스케줄링 되게끔 구성합니다.

예제 NodePool.yaml 에 명시되어 있는&nbsp; Label 과 Taint&amp;Toleration 을 이용해서 Istio 리소스를 스케줄링합니다.
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="948" data-origin-height="1148"><img src="https://blog.kakaocdn.net/dn/bIDhpS/btsF9LufycN/TkfV6oYv8Rg30DKKsrc39K/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="948" data-origin-height="1148"><figcaption>예시 NodePool</figcaption>
</figure>


그리고 AWS LB Controller 의 kind: Ingress 를 아래와 같이 작성해줌으로써, Istio 가 있는 노드만 Target Group 에 등록시킬 수 있습니다.
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="962" data-origin-height="283"><img src="https://blog.kakaocdn.net/dn/cAcPwl/btsF7LbhWiX/2XtmVKfhonzu48Ayt1SwJK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="962" data-origin-height="283"><figcaption>예시 Ingress</figcaption>
</figure>


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


<h2 data-ke-size="size26">두번째 방법</h2>
<hr contenteditable="false" data-ke-type="horizontalRule" data-ke-style="style6">

두번째 방법은 <a href="https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-policies" target="_blank" rel="noopener">Service 의 ExternalTrafficPolicy</a> 를 Local 로 설정하는 것입니다.
<blockquote data-ke-style="style2">default 는 Cluster</blockquote>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="907" data-origin-height="314"><img src="https://blog.kakaocdn.net/dn/snOTn/btsF7P5Hg61/mR8kIvwk9dlEQBZkVVsVf0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="907" data-origin-height="314"><figcaption>externalTrafficPolicy: Local</figcaption>
</figure>


ExternalTrafficPolicy: Local 로 설정하게 되면 아래 이미지처럼 동작하게 됩니다.
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1403" data-origin-height="973"><img src="https://blog.kakaocdn.net/dn/cbkSu5/btsF9EPHi2A/VxCjsaLlE0lVhLz1KoYwMk/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1403" data-origin-height="973"><figcaption>ExternalTrafficPolicy</figcaption>
</figure>


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

만약 ExternalTrafficPolicy: Cluster 라면 아래처럼 동작합니다.
<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2024-03-26 오후 11.26.38.png" data-origin-width="1312" data-origin-height="895"><img src="https://blog.kakaocdn.net/dn/E16QK/btsF8xCm12j/kSLIU9m5aqCziRnUbvlGNK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2024-03-26 오후 11.26.38.png" data-origin-width="1312" data-origin-height="895"><figcaption>Hop += 1</figcaption>
</figure>


ExternalTrafficPolicy: Local 의 경우 불필요한 홉(hop) 을 추가시키지 않아 Latency 를 감소시킬 수 있고, SNAT 이 진행되지 않아 Client IP 를 보존할 수 있다는 장점이 있지만, 트래픽이 골고루 분산되지 않을 수 있다는 단점이 존재합니다.
<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2024-03-27 오전 12.04.50.png" data-origin-width="1225" data-origin-height="895"><img src="https://blog.kakaocdn.net/dn/5wUk1/btsF6GAlaQ7/6dVr5i4d5Vfcut8DKUT2k0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2024-03-27 오전 12.04.50.png" data-origin-width="1225" data-origin-height="895"><figcaption>라우팅이 골고루 되지 않음 (골고루라면 33.3%)</figcaption>
</figure>

<blockquote data-ke-style="style2">ExternalTrafficPolicy: Cluster 장단점은 Local 장단점의 반대!</blockquote>


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

<blockquote data-ke-style="style3">두번째 방법을 사용하면 여전히 Target Group 에 Istio Gateway Pod 가 없는 노드가 존재합니다.&nbsp; 어차피 AWS ALB 에서 Istio Gateway Pod 가 없는 노드는 Health Check 가 안될테니 라우팅이 되지 않을 것입니다.하지만 AWS ALB 대시보드에 "실패" 가 표시되죠. 그래서 더 깔끔한 방법으로는 첫번째 방법과 두번째 방법을 섞어주는 것입니다.단, 트래픽을 골고루 분산시켜주기 위해서 되도록이면 노드 당 하나의 Istio Gateway Pod 가 실행될 수 있도록 해주는 것도 괜찮은 방법이라 생각합니다. 약간 데몬셋처럼 말이죠.&nbsp;</blockquote>

<h2 data-ke-size="size26">결론</h2>
<hr contenteditable="false" data-ke-type="horizontalRule" data-ke-style="style6">

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

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

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

그럼 이제 <a href="https://github.com/istio/istio/issues/48578" target="_blank" rel="noopener">Istio Issue</a> 에 해결 방법을 궁금해 하는 분들에게도 알려주러 가보겠습니다!!&nbsp;
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1934" data-origin-height="1236"><img src="https://blog.kakaocdn.net/dn/DUbSL/btsF6ghmSnb/WTGJykSLn7lqLWOyBoGqQK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1934" data-origin-height="1236"><figcaption>https://github.com/istio/istio/issues/48578</figcaption>
</figure>


<blockquote data-ke-style="style2">AWS SG 관련 트러블 슈팅 내용은 <a href="https://github.com/istio/istio/issues/48578" target="_blank" rel="noopener">Istio Issue</a> 에서 직접 확인하시길 바랍니다!</blockquote>

PS.
의심했지만 용의자들이 범인이 아니였던 이유! - <a href="https://kingofbackend.tistory.com/280" target="_blank" rel="noopener">이전 글 참고</a>

Q) AWS ALB 의 timeoute=600 초로 무의미한 커넥션 수의 증가
AWS ALB 는 AWS Managed 였기 때문에 커넥션 수가 늘어난다고 해서 성능면에선 크게 문제가 없습니다. 알아서 퍼포먼스를 증가시키기 때문이죠.
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="2026" data-origin-height="616"><span data-url="https://blog.kakaocdn.net/dn/c0kiIE/btsF79Qqr2N/ikMS2QX2w2dvKcszoWXcW1/img.png" data-lightbox="lightbox" data-alt="https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/introduction.html"><img src="https://blog.kakaocdn.net/dn/c0kiIE/btsF79Qqr2N/ikMS2QX2w2dvKcszoWXcW1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="2026" data-origin-height="616"><figcaption>https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/introduction.html</figcaption>
</figure>



Q) Istio 의 리소스 부족 의심
Istio 의 리소스가 부족하다고 생각하여 2 CPU, 4G Memory 로 증설했지만, 의미가 없던 행동이였습니다.
메트릭을 확인했을 때 이미 기존에 사용하고 있던 250m CPU, 1G Memory 로도 충분합니다.
<figure data-ke-mobilestyle="widthOrigin" data-filename="스크린샷 2024-03-27 오전 12.24.45.png" data-origin-width="728" data-origin-height="778"><img src="https://blog.kakaocdn.net/dn/NnRWW/btsF4ywvc64/nki6GqvUFAK9TULdQcQNh1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="스크린샷 2024-03-27 오전 12.24.45.png" data-origin-width="728" data-origin-height="778"></figure>


그럼 오늘은 여기까지!
<figure data-ke-mobilestyle="widthOrigin" data-filename="아기-로켓.png" data-origin-width="547" data-origin-height="330"><img src="https://blog.kakaocdn.net/dn/rh5FM/btsF87pXpja/mv882noDxUmkRAtK4BKfKK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="아기-로켓.png" data-origin-width="547" data-origin-height="330"></figure>

</div></div>

King of Back-end

이전 글인 [트러블 빵야] 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) 이 증가한다고 해서 큰 문제는 되지 않겠지만, 클러스터 내에는 다양한 서비스들이 존재하기 때문에 하나의 홉(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 가 있는 노드만 등록해줍니다.
 
좀 기술적?으로 얘기해보자면,
 
Istio 전용 Kapenter 의 kind: NodePool 를 만들고, Istio 관련 리소스들은 모두 해당 NodePool 로 생성되는 노드에 스케줄링 되게끔 구성합니다.
 
예제 NodePool.yaml 에 명시되어 있는  Label 과 Taint&Toleration 을 이용해서 Istio 리소스를 스케줄링합니다.
 
그리고 AWS LB Controller 의 kind: Ingress 를 아래와 같이 작성해줌으로써, Istio 가 있는 노드만 Target Group 에 등록시킬 수 있습니다.
 
실제로 이렇게 Istio Gateway Pod 만 있는 노드만 Target Group 에 등록하니 6개월 동안 지속됐던 504 Gateway Time 이 마법처럼 사라졌습니다..
 
 
두번째 방법
 
두번째 방법은 Service 의 ExternalTrafficPolicy 를 Local 로 설정하는 것입니다.
default 는 Cluster
 
ExternalTrafficPolicy: Local 로 설정하게 되면 아래 이미지처럼 동작하게 됩니다.
 
AWS ABL 가 골고루 라우팅(기본 라운드로빈)하게 되는데, 만약 Istio Gateway Pod 가 없는 노드라면 블랙홀에 빠지게 되고, 있는 노드라면 마저 뒷단으로 트래픽을 보내게 됩니다.
 
만약 ExternalTrafficPolicy: Cluster 라면 아래처럼 동작합니다.
 
ExternalTrafficPolicy: Local 의 경우 불필요한 홉(hop) 을 추가시키지 않아 Latency 를 감소시킬 수 있고, SNAT 이 진행되지 않아 Client IP 를 보존할 수 있다는 장점이 있지만, 트래픽이 골고루 분산되지 않을 수 있다는 단점이 존재합니다.
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 에 해결 방법을 궁금해 하는 분들에게도 알려주러 가보겠습니다!! 
 
AWS SG 관련 트러블 슈팅 내용은 Istio Issue 에서 직접 확인하시길 바랍니다!
 
PS.
의심했지만 용의자들이 범인이 아니였던 이유! - 이전 글 참고
 
Q) AWS ALB 의 timeoute=600 초로 무의미한 커넥션 수의 증가
AWS ALB 는 AWS Managed 였기 때문에 커넥션 수가 늘어난다고 해서 성능면에선 크게 문제가 없습니다. 알아서 퍼포먼스를 증가시키기 때문이죠.
 
 
Q) Istio 의 리소스 부족 의심
Istio 의 리소스가 부족하다고 생각하여 2 CPU, 4G Memory 로 증설했지만, 의미가 없던 행동이였습니다.
메트릭을 확인했을 때 이미 기존에 사용하고 있던 250m CPU, 1G Memory 로도 충분합니다.
 
그럼 오늘은 여기까지!

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

댓글