개발

AWS S3 를 Cloud Front 로 배포하기

76 views as of December 9, 2024.

S3 서버를 이용한 파일 배포
클라우드 프론트(Cloud Front)
Cloud Front 세팅 방법
1. Cloud Front 배포 생성
2. S3 버킷 정책 변경
테스트 방법
마무리
Cloud Front 추가 기능들

S3 서버를 이용한 파일 배포

AWS S3서버를 이용해서 이미지나 기타 파일등을 배포하는 방식을 웹사이트 구현에 써먹을 수 있다.

이는 호스팅 서버에 직접적으로 파일이 업로드되지 않으므로 웹 서버용량에 문제될일도 거의없고, 또 스토리지 전용 서버인 S3는 기타 호스팅 서버보다 그 비용도 월등이 작다.

지금까지는 문제없이 잘 써왔는데 최근에 우연히 구글 페이지 스피드 인사이트를 통해 페이지 속도 검사를 하다가 S3서버에 올려둔 이미지의 로딩 속도가 느리다는 검사 결과지를 보게되었다.

애초에 S3를 사용하는 이유가 속도를 위한거라기보다 호스팅 서버와 스토리지 서버를 격리하기위함이어서 속도쪽에 관해서는 생각을 해보지도 않았고 심지어 웹사이트 탐색중에도 크게 속도 이슈를 느끼질 못해서 전혀 알아차리지 못했던 부분이었다.

관련내용으로 알아본바, S3는 링크를 통해서 이미지파일이나 다운로드 파일을 요구하면 매번 스토리지 서버에서 꺼낸다음에 파일을 전달해주는 방식을 취하고 있고 여기에 캐싱관련 로직이 전혀 작동을 안한다고 한다.

즉 자주 요청되는 이미지나 파일도 매번 1:1로 처리해주고 어디다가 꺼내놓고 쉽게쉽게 꺼내주는 방식이 아니라는것이다.

이게 특히나 해외 사이트로 가면갈수록 큰 문제가 발생되는데, 국내 리전에 스토리지 서버를 두고 쓸때는 그 지연처리가 그렇게까지 문제될일이 아닌데, 해외에서 접근할경우 국내 스토리지 서버에 요청하고 답변받는과정이 2000~3000ms까지 올라가게되고 그만큼 속도 지연문제가 발생한다고 한다.

그래서 관련내용에 대해서 S3서버도 캐싱을 지원하면 될거같아서 검색해보니 이럴땐 AWS Cloud Front 서비스를 사용한다면 된다고 한다.

클라우드 프론트(Cloud Front)

Cloud Front는 AWS의 전 세계 엣지 로케이션(Edge Locatioin)을 활용해 콘텐츠를 사용자와 가장 가까운 서버에 캐싱해두고 제공하는 서비스를 말한다.

이에 따라 사용자는 위의 경우처럼 리전에 있는 S3에 직접 접근하지않아도 된다.

이는 결론적으로 네트워크 대기시간(Latency)와 첫 바이트 응답시간(TTFB)을 감소시켜 사용자 경험을 향상시킬 수 있다.

최초로 요청된 리소스의 경우에는 지연이 발생하지만 그 이후의 리소스는 캐싱된 리소스를 제공받는다.

항목	S3 URL	Cloud Front URL
예시 URL	https://cdn.erulabo.com/...	https://d12345abcdefg.cloudfront.net/...
접속 위치	S3 버킷의 특정 리전(예: ap-northeast-2)	전 세계 CloudFront 엣지 로케이션
속도	S3 리전 위치에 따라 지연 발생 가능	가장 가까운 엣지 로케이션에서 콘텐츠 제공 (빠름)
캐싱	지원하지 않음	엣지 로케이션에서 캐싱 가능
압축(Gzip/Brotli)	지원하지 않음	CloudFront에서 지원 (더 작은 데이터 전송)

기존 S3 URL과의 차별점을 정리해보자면 위의 표와 같다.

이런 CloudFront의 비용은 데이터 전송량에 따라 달라지는데 아시아 태평양 지역에서는 대략 $0.085/GB 의 비용이 발생하게된다.

Cloud Front 세팅 방법

그럼 기본적인 클라우드 프론트 방법을 세팅해보자.

우선 기존에 퍼블릭 엑세스(Public Access)가 가능한 S3 스토리지의 데이터를 사용하고 있다고 가정하고 작업을 시작할 것이다.

1. Cloud Front 배포 생성

AWS Management Console 에 접속해 Cloud Front 서비스 화면에 들어가자.

처음에 배포 페이지가 보일텐데, 여기서 우측상단의 "배포 생성" 버튼을 누르자.

순차적으로 Origin Domain, 그러니까 어떤 리소스를 배포할지를 선택한다.

가장위에 S3 서비스가 있고 여기서 배포할 S3 버킷을 선택한다.

이후에 스크롤을 내리면 기본적으로 옵션이 선택되어있는데, 일단 간단한 구현을 해보는게 목적이면 기본 옵션 그대로 사용하면 된다.

좀 더 스크롤을 내려보면 웹 애플리케이션 방화벽(WAF) 설정이 있는데 이는 과금옵션이라 일단 보안 보호를 비활성화를 해준다.

그리고 아래 설정에 가격분류에 우리는 아시아권만들어있는 효율적인 캐싱을위해 "북미, 유럽, 아시아, 중동 및 아프리카에서 사용"을 클릭한다.

여기서 최고의 성능옵션은 일부 고비용 리전(인도, 남아메리카)등이 포함되어있어서 다른 비용보다 더 비싸다고한다.

여기까지하면 기본적인 Cloud Front 배포 설정이 완료되고 페이지 우측 하단의 "배포 생성"버튼을 통해 생성작업을 완료할 수있다.

2. S3 버킷 정책 변경

다음으로 할 작업은 Cloud Front 에서 S3의 리소스를 가져갈 수 있도록 버킷 설정을 변경해주어야한다.

S3 서비스의 범용 버킷에서 아까 Cloud Front에서 선택한 오리진 도메인에 해당하는 버킷을 클릭하고 버킷탭에서 '권한'페이지에 들어가 버키시 정책을 '편집'해보자.

우리가 추가해야할 것은 아래 코드다.

{
    "Sid": "AllowCloudFrontAccess",
    "Effect": "Allow",
    "Principal": {
        "Service": "cloudfront.amazonaws.com"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::erulabo/*",
    "Condition": {
        "StringEquals": {
            "AWS:SourceArn": "arn:aws:cloudfront::YOUR_ACCOUNT_ID:distribution/YOUR_DISTRIBUTION_ID"
            }
    }
}Copy

"Statement": [ ] 배열내에 위의 단락을 추가해주자.

아마 기존에 퍼블릭 엑세스를 했다면 이미 Statement 단락에 s3:GetObject Action으로 추가되어있을것이다. 그 아래에 추가해주면된다.

여기서 위 내용을 그대로 추가하면안되고 YOUR_ACCOUNT_ID 와 YOUR_DISTRIBUTION_ID 이 2개를 자신의 AWS 계정에 맞게 바꾸어줘야한다.

YOUR_ACCOUNT_ID 는 우측상단의 메뉴를 누르면 바로 확인할 수 있으며 계정 페이지에 들어가서도 계정 ID 영역에서 쉽게 확인할 수 있다.

이미지의 빨간 영역이 ACCOUNT_ID

그리고 YOUR_DISTRIBUTION_ID 는 아까 만들었던 Cloud Front의 배포 ID이다

이미지의 빨간 영역이 DISTRIBUTION_ID

즉, 예를들면 아래와 같이 각자의 ID 값으로 내용을 바꿔서 넣으면된다.

"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1A2B3C4D5E6F7"Copy

(예시: CLIENT_ID = 123456789012, DISTRIBUTION_ID = E1A2B3C4D5E6F7)

여기까지 했으면 끝이다.

테스트 방법

기존의 S3 서비스 링크를 Cloud Front 링크로 바꿔서 리소스가 제대로 웹에서 보이나 테스트해보면 된다.

예를들어 아래 이미지의 경로는 다음과 같다.

- S3 링크: https://cdn.erulabo.com/editor/cBhFtzstjBlA5srQtMtQTpIMtg7zlCIDqkhQwJVW.webp

- Cloud Front 링크: https://d3hhksoelq0jvb.cloudfront.net/editor/cBhFtzstjBlA5srQtMtQTpIMtg7zlCIDqkhQwJVW.webp

다른점이 보이는가? 도메인에 해당하는 부분이 cdn.erulabo.com 에서 d3hhksoelq0jvb.cloudfront.net 으로 바뀌었다.

이 Cloud Front 링크는 각자 만든 배포 설정에 따라 다르며 이 도메인은 아래에서 확인할 수 있다.

새로운 Cloud Front 링크로도 원본 S3 링크처럼 제대로 리소스접근이 되면 설정이 잘 되고 배포가 잘되고 있다는 뜻이다.

만약에 제대로 파일이 안보이면 대체적으로 S3 정책 설정 이슈이므로 그쪽을 다시 한 번 확인해보자.

마무리

CDN 서버의 가치는 자주 이용하는 리소스를 캐싱에 절여 배포하는것에 있다.

물론 이런 CDN 서버도 서버 지연자체의 영향은 받지만, S3 같은 스토리지 서비스의 경우에는 직접 리소스를 링크로 가져다쓰는거보다 이런 캐싱 서비스를 이용해 배포하는게 속도면에선 더 나을 수도 있을것이다.

위에선 기술하지 않았지만 Cloud Front를 통한다면 로깅을 통해서 접속량, 요청에 따른 통계와 모니터링도 충분히 가능하고 더욱 전략적으로 리소스 관리를 할 수 있고 무엇보다도 AWS 내 리소스 관리가 쉬워지므로 S3를 사용한다면 Cloud Front를 이용해 배포하는것도 고려해보는게 좋지않을까?