CloudFront + 람다@ 리디렉션

최근 재미있는 업무 요청이 있었댜

 

EKS로의 접근 구간 게이트웨이는 대개 LB를 배치해서 진입 구간을 제한한댜 (인그레스)

그게 L4가 되었든 L7이 되었든...

 

AWS ELB들을 레버리징하는 EKS의 LB들은 SSL 오프로드가 LB레벨에서 이루어진댜

자세한건 밑의 AWS 레퍼런스를 보쟈

https://aws.amazon.com/ko/blogs/aws/elastic-load-balancer-ssl-support-options/

Elastic Load Balancer SSL Support Options | Amazon Web Services

 

이 떄, 인그레스로 접근 시, path별 리스너가 모두 따로 나뉘게 된댜

/a -> A SVC오브젝트

/b -> B SVC 오브젝트

그리고 호스팅하는 도메인 주소는 AWS 디폴트 주소가 되었든 혹은 SSL 인증서를 입힌 도메인 주소가 된댜

 

따라서, 이 도메인을 myeks.com 이라고 가정하고, a 앱으로 요청하려면 하기 구조를 가진댜

myeks.com/a  ->  EKS내의 A SVC오브젝트 (쿠버프록시) -> A파드

 

이슈는 바로 반드시 /a 라는 컨텍스트 패스를 클라이언트가 명시해야한댜.

마이그레이션 하는 클라이언트는 기존에 xyz.com 이라는 도메인만 호출하고, HTTP 메서드도 유지해야 하는데...

 

처음 생각해본 리디렉션 프록시는 ALB 리디렉션 리스너이댜

https://aws.amazon.com/ko/premiumsupport/knowledge-center/elb-redirect-to-another-domain-with-alb/

Application Load Balancer를 사용하여 한 도메인을 다른 도메인으로 리디렉션

 

여기서 xyz.com -> myeks.com/a  로 보내는 형태이다.

단 이 ALB 리디렉션은 큰 문제가 있댜

바로 301 / 302 응답만 리디렉션이 된댜

 

우리는 대개 2xx, 4xx, 5xx 응답만을 주로 보고 3xx 응답은 왠만하면 크게 볼일이 없댜

이번에 3xx 응답을 볼줄은...

 

만약 POST 메서드로, 고객이 xyz.com > myeks.com/a 로 ALB가 리디렉션하게 되면, 무조건 GET 메서드로 치환된다.

이는 301 / 302 응답을 좀 더 확인해볼 필요가 있댜...

다른 멋진 분이 3xx 응답에 대한 정의 다이어그램을 정리해두었으니, 가서 보쟈

https://perfectacle.github.io/2017/10/16/http-status-code-307-vs-308/

(HTTP) 상태 코드 - 307 vs 308

 

클라이언트가 POST로 요청하면, ALB 리디렉션은 이를 모두 GET으로 치환한댜

 

위와 같은 방법을 유지하고, HTTP Method도 유지할 수 있는 방법은?

307 / 308 응답을 주어서 메서드를 유지하며 리디렉션하는 것!

 

개인적으로 찾은 회피책은 CF와 람다엣지 조합이댜

xyz.com > CF > 람다엣지 - 307/308 응답 > myeks.com/a

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html

Lambda@Edge example functions - Amazon CloudFront

 

코드는 그리 어렵지 않댜

 

유의 사항으로, AWS 클라우드프론트 (CloudFront. CF. 클라우드포메이션 아님) 는 글로벌이고 각 리전 네트워크 엣지에서 서비스를 수행한댜

CF 도메인에 SSL 인증서 (AWS ACM) 을 입혀본 경험이 있는 사람은 바로 눈치챌 것이댜

CF 인증서는 us-east-1, 노스 버지니아에서 따서 입혀야 한다는 것을.

마찬가지로 CF에서 요청을 인터셉트하여 리디렉션을 수행하는 람다엣지 또한 노스 버지니아에 배포한 뒤, CF 요청을 트리거링해야 한댜

람다 콘솔에서 트리거 추가할 떄, 다른 리전과는 달리 us-east-1 에서 람다 트리거 항목에 유일하게 CloudFront가 있는 것을 확인할 수 있댜

 

CF의 네트워킹 구간은 4개로 나뉜다.

https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html

Using AWS Lambda with CloudFront Lambda@Edge - AWS Lambda

- 뷰어 리퀘스트

- 오리진 리퀘스트

- 오리진 리스판스

- 뷰어 리스판스

 

리디렉션 코드를 수행해야 하는 부분은 당연히 최초 요청이 진입하는 뷰어 리퀘스트 구간이므로, 이 구간에 람다 엣지로 인터셉트하여 리디렉션을 돌린댜

오리진 리퀘스트 구간에서는 수행해보진 않았는데 한번 테스트 돌려보길 희망할 수 있지만, 괜히 네트워크 레이턴시를 CF에서 뒤로 또 돌리는걸 원치 않아 뷰어 리퀘스트에서 이를 낚아챘댜

 

추가로, CF에서 람다엣지 인터셉트할 때, event 객체 안에 요청자의 uri path와 쿼리스트링이 들어있는 것을 조합해서 리디렉션해야한댜

이건 지금 참조페이지가 어딨는지 까먹었댜... 검색을 해보도록 하쟈