[AWS] AWS용어 및 CloudFront, S3, 배포

 

Cloud Front란?

CloudFront를 이해하기 위해서는 CDN과 엣지로케이션에 대해서 이해를 할 필요가 있음.

간단하게 CDN은 AWS 저장공간은 미국에 있다고 하고 내가 만든 프로그램은 한국에서 배포를 해서 미국에 있는 저장공간에다가 요청을 하면 거리도 멀고 하니깐 한국 근처에 미국에 있는 저장고보다 작은 저장고를 만들어 놓고 자주 사용하거나 하는 것들을 여기다가 가져다 놔서 한국 근처에 있는 저장고에서 꺼내쓰게 하는 것임. (이때 이 저장고가 엣지로케이션임 ) 

근처에 있는 저장고에 없으면 미국에 있는거 가져오지만 대체로 여기서 해결가능하게끔 알잘딱하게 설계되어있음.

이걸 왜 알아야하냐?? CloudFront가 바로 이러한 방식을 사용한 CDN서비스이기 때문임!

간략: 본래서버에서 받아와서 캐싱을 해서 서버로의 요청이 필요없게 만들어서 부하를 낮춘다!

 

CloudFront는 뭔데 사용을 해야하느냐?

CDN서비스로써 캐싱된 데이터를 통해서 user에게 좀 더 빠른 컨텐츠 제공을 할 수 있기 때문에 사용해야한다!

---

Cloud Front 구성

CloudFront가 어떻게 구성이 되어있으며 중점적으로 보아야 할 부분을 간략하게나마 설명해 보겠음.

• origin: 컨텐츠가 존재하는 근원 (S3나 EC2라고 보면 될 듯)
• distribution: 컨텐츠 제공 채널 간단하게 하나의 서비스 (뭔지 잘 모르겠음 좀 찾아봐야겠음)
• TTL: 캐싱된 데이터가 살아있는 시간 (revaildate나 이런 작용 없으면 user는 계속 이 데이터를 보고 있는 것임)
• revalidate: 강제로 캐시를 삭제한다. (CloudFront에 업데이트 된 것을 유저에게 보여주고 싶을 때 사용, 1000건은 무료 그 이후로는 한건 당 돈 받음)
• Cache Key: 어떤 기준으로 캐싱할 것인지 정한다.(swr사용할 때 key로 생각해도 될 듯, url이 기본적임 클라우드 프론트의 성능을 올릴 수 있음)

CloudFront는 뭔데 사용을 해야하느냐? (2)

더 많은 user에게 많은 것을 보여주고 싶기에 사용해야 한다. Cache Key를 통해서 쿠기나 헤더의 정보를 받아서 user의 location에 따른 접근의 허용 및 금지 뿐만아니라 컨텐츠의 언어를 무엇으로 제공할지도 결정할 수 있게 해준다. 

 

• 정책: 어떻게 동작하는지 정의해 놓음 (3가지가 있음)

CloudFront는 뭔데 사용을 해야하느냐? (3)

CloudFront를 사용하면 static한 것 뿐만아니라 dynamic한 데이터도 캐시가 가능하다.

이런식으로 경로패턴 분기처리를해서 정적컨텐츠와 동적 컨텐츠에 대해서 캐시를 하게 된다.(둘 다 최적화를 하지만 동적컨텐츠의 경우 네트워크(통신)에 대한 최적화를 하는 것이지 동적컨텐츠처럼 단순히 데이터를 캐시하는 것이 아니다.)

• https 지원: origin에서 https통신을 지원하지 않더라도(백엔드에서 http로 해도)  https통신을  지원할 수 있도록 구성이 가능하다. 클라우드프론트를 통해서 가능하게 만든다 클라우드 프론트와 유저 사이에서는 https를 하고 웹서버와 클라우드프론트 사이에서는 http통신을 한다. (좀 복잡하다 인증키 등등 설치 할 것이 많다. 근데 이게 CloudFront에서 복잡한거였나 기억이 잘...)

---

기타 추가적인 내용

• 커스텀 에러 지역따라 서버 분산 쿠키를 검사해서 다른페이지로 리다이렉팅 가능 (A/b테스팅) 오리진 도착 전 인증
• 클라우드funciton 간단한 캐싱과 헤더조작만 가능한 것 경량의 행동만 가능
• 리포팅기능이 있으니 구글애널리틱스에 비해서는 떨어지지만 간단하게 확인 가능하다.
• 3가지 정책 설정 가능 캐시방법 (TTL 및 Cache key 정책) 캐싱을 어떻게 할 것인가 를 정의한다. 클라우드 프론트가 어떻게 캐싱할지를 정한다 2오리진으로 어떤내용을 보낼 것인지 정한다 3뷰어에게 보낼 header를 정의할 수 있다
• 보안: s3signed URL과 비슷한 방식이다 돈을 낸 사람들만 동영상을 보게끔 하는 방법 url의 접근을 막게할 수 있는 것이기에 하나의 컨텐츠 파일에 대한 허용만 가능하게 한다 signed URL이 이것임 signed Cookie 이건 다수의 컨텐츠에 사용가능하다. 유저의 접근을 제한하거나 인증이 필요할 때 사용할 수 있다.
• 오리진엑세스아이덴티티 s3컨텐츠를 클라우트프론트를 사용해서만 볼 수 있도록 제한하는 방법이다. 유저들이 s3에 바로 접근하도록 하면 안됨 클라우드프론트만 권한을 가지고 나머지는 다 막는 것임
• 필드레벨 인크립션 클라우드프론트와 오리진 사이의 통신읠 암호화하는 것임 유저가 클라우드 프론트를 통해 요청을 하면 오리진까지 요청을 보낼텐데 통신거리가 길기에 좀 불안한 게 있다 중간에 뭔가 안좋은 일이 생길 수 있기에 암호화를 해서 요청을 보내고 오리진에서는 프라이빗키를 통해서 암호화를 해독해서 사용함 이거 안할거면 웹서버에서 https를 해놓으면 된다.

 

 

 

AWS 아키텍쳐

aws에서 가장 중요하다고 생각하는 기능은 s3이다 그 중에 s3와 cloudfront를 연결해서 써야 public으로 사용하지 않을 수 있기에 s3를 잘 사용할 수 있다 request부분에서 비용이 많이 나온다 디도스 공격에 대해서 방어력을 가진 것이 cloudfront임 클라우드프론트는 캐쉬 컨텐츠임 라우터53은 dns쪽에 있네 aws code star??? 이건 뭐지? 모니터링도구 클라우드워치?? 이것도 뭐지? 배포할 때 이정도 사용한다고 함

 

csr배포를 무조건 터지지 않는 배포상태가 된다 url을 닮고싶다면 rout53 cloudFront는 디도스 방어 s3를 public으로 사용하지 않아도 됨 s3는 simple strage service로써 저장공간임

 

 

s3와 athena emr 뭐 이런게 연결이 된다고 한다네요 redshift 이것도 꽤 유명하다네요 

 

여기서는 백엔드 얘기가 좀 가미 됨

(백엔드는 ec2같은 걸로 배포를 할 때 사용하고 서버리스를 사용한다면 람다를 사용한다 ecs도 사용한다네요 로드밸런스 이런것도 있는데 생략을 한다네요)

db는 엘라스틱캐시 래디스를 사용하면 db 안정성을 위해서 사용하는데 cache기능이 있다 sql이나 auroraRDS 이런것도 사용을하는데 db에서 사용되는 것들이라고 생각을 합시다.

eventbridge 이런거랑 sqs뭐 이런 얘기가 나오고 opensearch 이런것도 설명이 되는데 이벤트 관련된 것이랑 que랑 관련된 것이랑 이런저런 얘기를 함

ec2랑 apprunner 비교를 해서 쓰라고 하는데 다 백엔드 얘기인데 ecs가 가장 베스트라고 하는 것을 보니 이게 젤 어렵나 보구나

 

전체적으로 규격화된 아키텍쳐를 알려준다

 

https://www.youtube.com/watch?v=6C9284C-zP4&t=465s

https://www.youtube.com/watch?v=xsErrQJWuwc