이번 글에서는 Cloudfront를 사용하여 배포 무효화, 사용자 정의 오류 페이지 구성 및 Origin 그룹 구성 3가지의 실습을 진행할 것입니다. 이전 글인 “Amazon Cloudfront를 사용하여 컨텐츠 가속화하기#1” 참고하여 이전 환경 구성을 이어서 사용하세요.
[실습 순서]
1. 배포 무효화
2. 사용자 정의 오류 페이지 구성
3. Origin 그룹 구성
[1. 배포 무효화]
Cloudfront에서 무효화를 실행하여 새로 업데이트된 콘텐츠를 배포합니다.
기본 index.html 페이지는 캐시에 있으며 CloudFront에서 Cache hit가 발생합니다. HTML 파일을 변경해야 하지만 새 버전을 가리키도록 URL을 변경할 수 없다고 가정해보겠습니다. 이 경우 페이지를 무효화해야 합니다.
AWS Console에서 Cloudfront 서비스로 이동 후 무효화 탭으로 이동합니다.
Index.html에 대한 무효화를 생성합니다. 이미 index.html을 default root object로 설정했기 때문에 Object paths에 /를 지정할 수 있습니다.
잠시 후 브라우저 개발자 도구를 사용하여 페이지를 다시 테스트하면 Cache miss가 발생했음을 알 수 있습니다.
[2. 사용자 정의 오류페이지 구성]
요청한 콘텐츠를 찾을 수 없는 경우 단계적 장애 조치를 위한 사용자 지정 오류 페이지를 구성합니다.CloudFront 도메인 이름을 사용하여 임의의 URL을 테스트하면 파일이 존재하지 않기 때문에 CloudFront 뒤의 S3에서 403 Forbidden 응답을 받게 됩니다. CloudFront는 이 응답을 10초 동안 캐시합니다.
텍스트 편집기를 사용하여 error.html 파일을 생성하고 S3 버킷에 업로드합니다.
<html lang="en"> <body> <h1>CloudFront Lab</h1> <strong>Ops, this is a nice error page!</strong> </body> </html>
CloudFront 오류 페이지 탭으로 이동하고 사용자 지정 오류 응답 생성 버튼을 클릭합니다.
Custom error response를 다음과 같이 생성합니다.
– HTTP error code: 403: Forbidden
– Error caching minimum TTL: 60
– Customize error response: Yes
CloudFront에서 임의의 페이지를 요청하여 사용자 지정 오류 페이지를 테스트합니다. 배포가 업데이트되고 몇 분 정도 기다려야 할 수 있습니다.
CloudFront에서 오리진에 연결할 수 없을 때 트리거될 또 다른 사용자 지정 오류 페이지를 생성합니다.
– HTTP error coed: 504: Gateway Timeout
– Error caching minimum TTL: 5
– Customize error response: Yes
– Response page path: /error.html
– HTTP Response code: 200: OK
EC2 보안 그룹으로 이동하여 Nodejs API를 호스팅하는 EC2 인스턴스에 대한 인바운드 트래픽 규칙을 제거합니다.
브라우저에서 index.html 페이지를 테스트합니다. API 호출이 사용자 정의 오류 페이지에 정상적으로 실패할 때까지 잠시 기다립니다.
[3. 오리진 그룹 생성]
장애 조치 동안 경로 재지정을 제공하도록 오리진 그룹을 구성합니다. 오리진 그룹을 캐시 동작과 연결하여 장애 조치를 위해 요청이 기본 오리진에서 보조 오리진으로 라우팅 되도록 할 수 있습니다.
다른 리전에 새 S3 버킷을 생성합니다. S3 버킷 이름은 고유해야 합니다.
secondary-index.html 파일을 생성하고 새 리전의 S3 버킷에 업로드합니다.
<html lang="en"> <body> <h1>CloudFront Lab</h1> <strong>Hi, this is a page from my secondary Origin! We now support Origin group and failover!</strong> </body> </html>
CloudFront 배포로 돌아가서 새로 생성된 S3 버킷으로 새 오리진을 생성합니다.
– Origin domain: 새로 생성한 S3 버킷 선택
– S3 bucket access: Yes use OAI
– Origin access identity: 이전에 생성한 OAI 선택
– Bucket policy: Yes, update the bucket policy
CloudFront 오리진 탭으로 이동하여 오리진 그룹을 생성합니다.
cloudfrontlab-s3bucket-*을 default origin으로 사용하고 cloudfrontlab-s3bucket-secondary-*을 secondary origin으로 사용합니다. 장애 조치 기준으로 403 Forbidden 및 404 Not Found를 선택합니다.
새 Origin 그룹을 사용하도록 배포의 기본 동작을 편집합니다. 이를 통해 장애 조치를 테스트할 수 있습니다.
– CloudFront 동작 탭으로 이동하여 Default(*) 를 선택하고 편집 을 클릭 합니다.
– 동작을 편집하고 이전 단계에서 생성 한 Origin Group을 선택합니다.
배포 상태가 Deployed, request secondary-index.html page from CloudFront 로 변경된 후 Secondary S3 버킷 Origin이 요청을 정상적으로 처리하는 것을 확인할 수 있습니다.
[참고자료]