Cloudfront cache auto invalidate
1. 개요
S3를 Cloudfront로 배포하는 것은 매우 바람직한 일인데, 이때 불편함을 느낀 적이 있다.
일반적으로 Cloudfront를 사용했을 때 얻을 수 있는 이점인 cache가 있다. cache의 지속 시간을 설정할 수 있지만,
S3의 객체를 새로 생성한 경우는 괜찮다. 하지만 업데이트 즉 Put을 한 경우 Cloudfront의 cache는 이전의 데이터가 남아 있어 문제를 일으킬 수 있다. 따라서 수동으로 cache를 날려줘야 하는데, 매우 귀찮은 일이고, 쉽게 잊을 수 있는 일이다.
아키텍처와 실제 동작을 아래에서 살펴볼 예정이다. 모두 실습을 진행할 수 있도록, Terrafrom 코드 또한 Github로 제공한다.
2. 아키텍쳐
해당 문제를 자동화할 수 있는 방법을 생각해 봤고, 아래와 같이 간단하게 해결할 수 있었다.
먼저 사용할 서비스는 S3 Notifiaction과 Lambda이고, 역할을 알아보자.
1. S3 Notification 사용
S3 Notification은 지정한 이벤트가 발생했을 때 consume 할 주체를 정할 수 있는 서비스이다. 해당 이벤트에 해당될 key와 동작을 정하면 된다. 동작은 ObjectCreated:Put과 같은 객체의 동작을 의미한다.
2. Lambda 코드 구현
S3에서 발생한 이벤트를 Lambda가 Trigger로 가지고 있어, 이벤트 발생시 코드가 동작한다.
3. 동작확인
Cloudfront 배포에 들어가서 무효화 탭을 볼 수 있다. 거기서 새롭게 업데이트 했을 때 생기는지 확인하면 된다.
아직 객체 업데이트 전이라서 아래와 같이 무효화가 없다.
아무 객체나 업데이트 진행 후 확인해보면 아래와 같이 무효화를 진행한 모습을 볼 수 있다.
4. 결론
인프라를 사용하면서 항상 느끼는 점은 어떻게 하면 더 편해질까? 간편해질까? 에 집중하게 되는데 결국은 자동화에 결론짓게 된다. 이번 주제는 Cloudfront 캐시를 자동으로 비우는 것이었다.
자동화를 만드는 것은 AWS에서 다양한 서비스가 있기에 활용하면, 어렵지 않다. 또한 console로 하면 lambda코드만 작성하면 쉽게 할 수 있다. 하지만 console로 하면, S3 버킷마다 들어가서 해당 설정을 해줘야 한다. 따라서 추상화해서 적용시키기 위해서는 Terraform 코드로 하는 게 좋을 거 같다는 생각을 했기에 Terraform 코드로 만들어봤다. (물론 해당 글을 보고, 실습을 진행할 수 있게 도와주려고 Terrafomr으로 작성한 목적도 있다.)
'Aws' 카테고리의 다른 글
AWS Event Scheduler 구현 (EventBridge + SNS + SQS) with terraform (0) | 2023.08.07 |
---|---|
AWS Bastion Host (사용자 관리) with terraform (0) | 2023.07.09 |
EKS Fargate 유형 애플리케이션 로그 수집 Part 2 (1) | 2023.05.15 |
S3를 CloudFront로 제공하기 (0) | 2023.05.08 |
EKS Fargate 유형 애플리케이션 로그 수집 Part 1 (0) | 2023.04.05 |
댓글
이 글 공유하기
다른 글
-
AWS Event Scheduler 구현 (EventBridge + SNS + SQS) with terraform
AWS Event Scheduler 구현 (EventBridge + SNS + SQS) with terraform
2023.08.07 -
AWS Bastion Host (사용자 관리) with terraform
AWS Bastion Host (사용자 관리) with terraform
2023.07.09 -
EKS Fargate 유형 애플리케이션 로그 수집 Part 2
EKS Fargate 유형 애플리케이션 로그 수집 Part 2
2023.05.15 -
S3를 CloudFront로 제공하기
S3를 CloudFront로 제공하기
2023.05.08