ALB 리스너 - 리디렉션 Pod 부하

외부(match) ALB로 특정 경로나 쿼리 문자열로 Client가 요청을 하면 리디렉션 대상으로 내부에 Stress ALB로 리디렉션할 수 있게 구성해보았다.

ALB에 Pod가 연결되면 ALB에서는 계속 Pod에 상태검사를 하기 때문에 ELB-HealthChecker로 계속 Log가 찍힙니다. 즉, ALB에서는 계속 Pod에 상태검사를 진행합니다

---

실습

1. ALB 리스너를 편집합니다(Match ALB 수정). IF 부분입니다.

2. THEN

3. Test

Internet에 접근 가능한 ALB를 Query합니다.

curl -L wsi-eks-alb-811018148.ap-northeast-2.elb.amazonaws.com/?type=test

#curl -L 옵션은 리디렉션 해주는 옵션입니다!!! -L을 안 붙이면 부하가 안 간다는 사실!!

3.1. Test(https://velog.io/@aylee5/Kubernetes-HPAHorizontal-Pod-Autoscaler)

#부하!!
#!/bin/bash

count=0

while :
do
	curl -L LoadBalancerDNS/wsi-eks-alb-811018148.ap-northeast-2.elb.amazonaws.com/?type=test > /dev/null 2>&1

	if [ `expr $count % 100` -eq 0 ]
	then
		echo $count
	fi
	((count++))
done

4. 결과: 리디렉션을 확인할 수 있습니다.

5. 결과2: Pod에 Log를 확인해보겠습니다. 이런식으로 Log가 찍히는 것을 확인할 수 있습니다.

---

Cloudwatch Metric 확인. Cloudwatch 로그로 확인할 수 있을까? 가능합니다

1. 외부(match) ALB에 리디렉션을 확인하기 위해서는 지표 - “HTTP_Redirect_Count”를 확인해야합니다.

2. 내부(stress) ALB에서는 로그는 해당 ALB에 지표에서 “Request Count”를 확인합니다.

HTTP 301, 302 상태 코드

• 301: 영구 이동은 해당 URL가 영구적으로 새로운 URL로 변경되었음을 나타냅니다. 검색 엔진 크롤러는 301 요청을 만나면 컨텐트가 완전히 새로운 URL로 영원히 이동됐다고 판단합니다.
• 302: 요청한 리소스가 임시적으로 새로운 URL로 이동했다는 것을 나타냅니다. 따라서 검색엔진은 페이지랭킹이나 링크에 대한 점수를 새로운 URL로 옮기지 않으며 기존 URL을 그대로 유지합니다.

💡 즉, 둘의 차이점은 301 상태코드는 영구적인 리다이렉션 방법이고, 302 상태코드는 임시적인 리다이렉션 방법입니다.