AWS Lambda@Edge 를 활용한 HTTP Redirection

Goal : Lambda@Edge와 CloudFront를 이용한 간단한 HTTP Redirection 서비스 제작

https://aws.amazon.com/ko/lambda/edge/
Lambda@Edge는 Region에 종속되는 기존 Lambda와는 달리, CloudFront를 이용하여
더 가까운 로케이션에서 Lambda 함수를 실행할 수 있는 서비스입니다.

Lambda@Edge는 Redirection이나 Image Size Reduction 등에 활용될 수 있습니다.


test.example.com으로 접속 시도시 www.example.com으로 Redirection 해주는 웹서버가 서울에 있다고 상상해봅시다.

만일 브라질에 있는 사용자가 test.example.com으로 접속을 하게 되면
트래픽이 브라질에서 출발해서 지구 반대편에 있는 서울로 도착,
301이나 302 Redirect 지시를 받고 서울에서 다시 지구 반대편으로 건너가게 됩니다.

마찬가지로 사용자가 유럽이나 미국에 있으면,
서울에 있는 test.example.com 서버에 접속해 단순 Redirect Code를 받으려
최소 100ms에서 심하면 몇 초를 기다려야 하는 상황이 발생합니다.
(전용선이 아닌 일반 ISP를 이어가므로)

이는 웹서버가 한 지역에 종속되어 있어 발생하는 문제입니다.


Lambda@Edge를 이용해 Redirection 서비스를 만들면 Redirect 코드를 받는 데 걸리는 시간을 감소시킬 수 있습니다.
대부분의 사용자가 한 곳에 몰려있으면 큰 Performance 향상을 기대할 수 없지만,
사용자가 전 세계에 있다면 그 효과는 매우 클 것입니다.

Lambda@Edge는 서버리스형 서비스입니다.
만일 엣지 컴퓨팅을 직접 IaaS로 구현하려면 굉장히 많은 비용이 발생하겠지만,
Lambda@Edge는 전 세계에 내 서버를 두고 운영할 필요 없이 그냥 코드만 올리면 됩니다.
비용은 전 세계에서 실행한 만큼만 지불하게 됩니다.

엣지컴퓨팅의 장점과 서버리스의 장점을 합친다고 보면 될 거 같습니다.



인트로가 엄청 길었네요.

AWS Lambda@Edge를 활용한 HTTP Redirection 지금 시작합니다~~~

( Test : https://www.bitcatcha.com/)
간단한 before & after sample 입니다.

서울에 있던 Redirection 서버와, Lambda@Edge로 구축한 Redirection 서비스의
소요시간 비교입니다. 전 지구적으로 속도 개선이 있는 모습을 볼 수 있습니다.

두 서버 모두 DB 연결이 없던, 백엔드가 없던 서비스였습니다.
만일 DB가 있었다면 소요시간이 엄청 더 벌어졌을 거 같네요.

(1) Lambda 함수 생성

★☆★주의 : Lambda@Edge 함수는 버지니아 리전(us-east-1)에서 생성해야합니다!

함수 이름은 원하시는 대로 기입하시면 됩니다.
제가 작성한 코드는 Node.js 10.x 기반입니다.

해당 Lambda 는 Lambda@Edge 권한이 필요합니다.
새 Role을 만들어주시면 됩니다.

다 작성 후 함수를 생성합니다

 코드를 작성합니다. 다음과 같습니다.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

exports.handler = async (event, context) => {     const cname = event.Records[0].cf.request.headers.host[0].value;     const URI = event.Records[0].cf.request.uri;        var target = 'https://www.example.com';     target += URI;       const response = {         status: '302',         statusDescription: 'Found',         headers: {             location: [{                 key: 'Location',                 value: target,             }],         },     };     return response; }; Colored by Color Scripter

cs

사실 초간단 예제에선 response 만 잘 이루어져도 작동합니다.
여러분들이 코드를 마개조하기 쉽게하기 위해 cname과 URI 변수를 추가했습니다.

만일 사용자가 www.test.com/user/1234를 요청하면,
cname 변수에는 'www.test.com'이, uri 변수에는 '/user/1234'가 담겨집니다.
target은 내가 Redirection 시키고자 하는 주소입니다.

status 값은 301로 할지 302로 할지는 선택하시면 됩니다.
둘다 HTTP Redirection인건 똑같고, 봇이나 크롤러들한테만 차이가 있습니다.
(Permanently Move냐 Temporarily Move 냐의 차이입니다)

코드는 입맛에 맞게 바꾸시면 됩니다.

코드를 잘 작성했나 확인차 테스트를 구성합니다.

테스트 이벤트 구성을 눌러주시면 됩니다.

이벤트 템플릿에서 Amazon CloudFront HTTP Redirect를 선택합니다.

제가 표시해둔 uri, method, value는 자유로이 수정하시면 됩니다.
(테스트용 변수들입니다)

저장 버튼을 누르고 테스트를 실행합니다.
다음과 같이 302 코드가 리턴이 되야 정상입니다.

작업 > Publish New Version을 누릅니다.
버전 이름을 작성하고 게시를 눌러 Lambda 함수에 대한 새 버전을 생성합니다.

이것으로 Lambda 설정은 끝입니다.
Lambda 함수의 ARN을 복사하여 저장해둡니다. (오른쪽 위에서 쉽게 찾을 수 있습니다)

(2) CloudFront 설정

CloudFront 설정은 매우 쉽습니다.

이 글에선 CloudFront를 상세히 다루지 않습니다.
CloudFront 설정은 자신의 입맛에 맞게 수정하시길 바랍니다.

Web 으로 생성합니다.

S3 버킷을 하나 생성한 후 해당 버킷을 선택하면 됩니다.
Origin Domain Name 칸을 클릭, 해당 버킷을 클릭하면 됩니다.

크게 수정할 부분은 없습니다. 자신의 입맛에 맞게 수정하시면 됩니다.
주로 헤더, 캐싱에 대한 옵션입니다.

이 부분이 중요합니다.

CloudFront Event 는 Viewer Request를 선택합니다.
Lambda Function ARN은 아까 복사해둔 Lambda의 ARN을 입력합니다.

(주의) Lambda에서, 새롭게 만든 버전에 대한 ARN을 복사해야 합니다. $LATEST의 ARN이 아닙니다.

확인법 : ARN 끝에 :$LATEST가 아니라 :버전명이 있으면 됩니다.

이 항목 역시 입맛에 맞게 수정하시면 됩니다.
Custom Domain, Edge 위치, ACL 등을 지정할 수 있습니다.

Custom SSL Certificate는 ACM을 이용하면 무료로 SSL 인증서를 만들 수 있습니다.
WAF ACL은 Rule 하나에 4달러였나 하는 비용이 드는 걸로 알고 있습니다.

이 항목 역시 입맛에 맞게 수정하시면 됩니다.
주로 로깅에 관한 내용입니다.

CloudFront를 생성합니다.

구성 끝~~~~

(3) 확인

CloudFront 생성은 수십 분이 걸립니다. 커피 한잔 하고 오면 얼추 맞습니다(?)

CloudFront 생성이 완료되면, 만든 CloudFront 주소 (혹은 ACM 세팅시 해당 커스텀 주소)
를 브라우저에서 테스트하면 됩니다.

wget 커맨드를 넣어봤습니다.

HTTP Redirection이 잘 이루어지고, Redirection시 uri가 잘 인수인계 되네요.




지금까지 Lambda@Edge를 이용한 간단한 HTTP Redirection 구축기를 소개해드렸습니다.

긴 글 읽어주셔서 감사합니다.