Go, Vantage point
가까운 곳을 걷지 않고 서는 먼 곳을 갈 수 없다.
Github | https://github.com/overnew/
Blog | https://everenew.tistory.com/
티스토리 뷰
CloudFront는 CDN 서비스로 많이 사용되지만, 클라이언트를 인접 Edge location에 접속하게 해서 빠르게 리전의 서비스에 접속하는 기능도 수행할 수 있다.
이를 확인해 보기 위해서 CloudFront로 웹페이지를 동적으로 서비스해 보자.
CloudFront 배포 생성
phpBB 웹서비스를 제공하는 EC2 인스턴스를 origin으로 등록한다.
이 phpBB는 사용자에 따른 동적인 페이지를 제공하는 커뮤니티 기능을 제공하고 있다.
이 서비스를 제대로 사용하기 위해서는 동적 콘텐츠를 제공해야만 한다.
캐싱의 TTL이 0이면 캐싱이 되지 않고 항상 새로운 데이터를 가져오게 된다.
즉, 항상 원본에 접근하므로 동적 콘텐츠를 제공할 수 있게 된다.
방화벽은 다음과 같이 설정해 주자.
생성완료.
CloudFront 동작 생성
캐싱을 위한 동작(action)을 생성한다.
첫 번째 동작은 .gif인 파일에 접근하는 경우 캐싱하도록 세팅한다.
gif는 비교적 큰 정적 데이터이므로, 웹 사이트의 gif들을 캐싱하면 페이지 로딩 속도를 올릴 수 있다.
캐싱이 보관되는 TTL은 1일로 설정해 준다.
나머지는 기본 세팅대로 동작을 생성한다.
S3 원본(오리진) 생성
s3를 하나 생성해서 404 오류 안내를 위한 html을 업로드해 두자.
이를 CloudFront에 캐싱하여, 잘못된 경로의 접근에 404 오류 페이지를 띄울 수 있다.
접근을 퍼블릭으로 만들어 주자.
생성해 준 S3에 대한 추가적인 원본도 생성한다.
우리가 에러 페이지를 업로드한 S3를 등록한다.
OAI는 새 OAI를 생성해 주자.
이에 대한 동작도 생성한다.
CloudFront 오류 페이지 생성
존재하지 않는 파일을 요청하면 /Custom404ErrorPage.html 로 가도록 만든다.
이 경로는 우리가 위에서 S3의 파일을 캐싱하도록 만들었다.
EC2에 phpBB 설치
EC2에 phpBB를 설치하여 웹 페이지에서 우리의 CloudFront 경로를 사용하도록 세팅해 보자.
phpBB를 설치 후, 로그에 있는 초기 패스워드를 기록해 두고 phpBB 사이트에 접근한다.
Access Control 메뉴로 들어간다.
여기서 서버 세팅을 진행하자.
서버의 Domain name에 클라우드 프런트의 배포 도메인을 넣어준다.
ex) d2mjrui98cp1va.cloudfront.net
이를 통해 EC2로의 접근을 CloudFront를 거치게 만들어 줄 수 있다.
단, CloudFront 사용으로 인해 Source IP가 변경되므로 Session IP Validation을 확인하는 보안 설정을 비활성화해 주자.
세팅이 완료되면 cloud front의 domain으로 접속이 된다.
이로써 동적 콘텐츠를 CloudFront로 배포할 수 있게 된다.
여기서 눈여겨볼 점이 http로 접속하던 것이, CloudFront 도메인으로 접속하니 자동으로 HTTPS로 변경되었다.
CloudFront는 자체의 인증서를 사용해서 클라이언트와 연결되기 때문에 HTTPS로 접속이 되고, CloudFront에서 EC2 인스턴스로는 http로 요청이 가게 된다.
우리가 세팅해 둔 404 페이지를 확인하기 위해서, 존재하지 없는 경로 접근하게 되면 캐싱된 오류 페이지가 정상적으로 출력된다.
.gif 캐싱 확인하기
다음과 같이 페이지 내에 gif가 많은 경우 캐싱에 의해 속도 차이를 확인해 보자.
ec2에 직접 접근한 경우 로딩에 1.73 초가 걸린다.
하지만 cloudfront 경로로 접근하면, gif들이 caching 되기 때문에 537ms 밖에 걸리지 않았다.
그런데 gif와 같은 캐싱할 리소스가 없는 경우 클라우드 프런트로의 접근이 오히려 오래 걸리는 것이 확인된다.
ec2로 접근 시, 627ms
cloudfront로 접근 시, 843ms
이는 브라우저가 자체로 메모리에 캐싱을 하기 때문이다.
네트워크에서 캐시 사용 안 함을 선택하면 로딩에 1.95초가 걸리게 된다.
반면 cloud front는 헤더의 세팅 값으로 인해서 브라우저 캐싱을 안 하고 항상 새로 가져오게 된다.
그래서 비교적 조금 느린 것처럼 보일 수 있다.
브라우저 캐싱을 쓸려면 헤더나 쿠키를 변경해야 하는데 이러한 세팅을 위해서는 lambd@edge를 사용해야 하는 것으로 예상된다.
'Cloud > AWS' 카테고리의 다른 글
| Amazon ECS를 사용한 컨테이너 CI/CD환경 구축 (0) | 2024.04.03 |
|---|---|
| AWS CodePipeline 구성하기 (commit, build, deploy) (0) | 2024.04.02 |
| AWS Database Migration Service (DMS)로 MySQL 마이그레이션하기 (1) | 2024.04.01 |
| AWS Transit Gateway로 VPC 연결하기 (0) | 2024.03.31 |
| AWS DataSync & Storage Gateway로 하이브리드 환경 구성 (0) | 2024.03.28 |