프론트엔드 배포를 S3와 Cloud Front로 바꾼 건에 관하여...
NCP에서 Object Storage에 사용자 지정 도메인을 붙일 수 없었기 때문.
.env로 API주소를 넣어주고 있었는데, 이걸 github actions에서 어떻게 .env를 설정해줄까가 고민이었다.
결론은 .env파일을 working-directory에 만들어서 빌드시에 사용할 수 있게 했다.
Cloud Front는 AWS에서 제공하는 CDN서비스이다.
캐싱을 통해 사용자에게 좀 더 빠른 속도로 컨텐츠를 제공하는 것을 목표로한다.
CloudFront는 전세계 이곳 저곳에 Edge서버를 두고, 클라이언트에게서 가장 가까운 Edge서버를 찾아 빠르게 컨텐츠를 제공한다.
- Origin Server : 원본을 가진 서버이다. 우리의 경우 원본 서버는 S3이다.
- Edge Server(Location) : AWS에서 실질적으로 제공하는 전세계에 퍼져있는 서버다. Edge Server에는 요청 데이터에 대해 빠르게 응답하기위해 Cache기능을 제공한다.
- 클라이언트로부터 Edge서버로 요청이 발생한다.
- Edge서버는 요청 데이터의 캐싱 여부를 확인한다.
- 사용자 근거리에 있는 Edge서버 중 캐싱 데이터가 존재한다면 사용자의 요청에 맞는 데이터를 응답한다.
- 사용자의 요청에 적합한 데이터가 캐싱되어있지않다면 Origin 서버로 요청이 포워딩된다.
- 요청 데이터를 Origin에서 획득한 후에 Edge서버에 캐싱 데이터를 생성하고, 클라이언트에게 응답을 준다.
⇒ Edge 서버의 TTL은 기본적으로 24시간이다.
사용자의 설정에 따라 변경이 가능하다.
TTL을 수정하는 경우, Edge서버에 반영되는 시간이 1시간 가량 소요된다.
이런 캐시의 설정후 반영시간때문에 전체 데이터에 대한 TTL을 수정하는게 아니라 개별 데이터에 대해서 invalidation API를 사용해 캐시를 무력화시키는 형태로 데이터를 업데이트 시킬 수 있다.
- Invalidation API는 Edge Node에 반영되기까지 5~10분 정도 소요된다.
- Invalidation API는 동시에 3개의 요청을 보낼 수 있다.
Origin Access Control의 약자
이 옵션을 통해 설정가능하며, 설정시 사용자는 s3원본에 직접 접근할 수 없고 ,cloud Front를 통해서만 접근할 수 있게된다.
s3원본에 대해 HTTP요청을 HTTPS로 리다이렉트 시키기 위해서는 인증서가 필요하다.
ACM을 통해 인증서를 발급받았고, 도메인 검증 방식으로 진행했다.
cloud front는 전 세계에 퍼진 캐시 서버이다.
따라서 원본 s3의 값이 바뀌었을때, 바뀌었다고 알려줘야 캐시의 값도 바뀐다.
그렇지 않으면 배포를 해도 24시간이 지나야 배포된 내용이 적용 될 것이다.
이를 invalidation api를 사용해서 해결했다.
모든 파일에 대해 invalidation을 하겠다는 명령어이다.
aws cloudfront create-invalidation --distribution-id ${{secrets.AWS_CLOUD_FRONT_ID}} --paths "/*"