[ DevOps ] - AWS 기반 소규모 & 중규모 아키텍트 설계 - AWS CloudFront와 CDN의 동작원리

AWS Cloudfront

이제 AWS의Cloudfront는 기본적으로 Cache를 위한 서버입니다. 이를 위해 자연스럽게 CDN도 제공한다고 보시면 됩니다. 그리고 이 Cache서버는 전 세계에 흩어져 있는 인프라를 활용하기 때문에 추가적으로 CDN의 기능도 보유합니다. 만약에 싱가폴에 있 는 사람이 서울에 만든 제 서버에 들어오게 된다면 당연히 조금 느리게 될 것입니다. 하지만 이가 해결해 줍니다.

 

그럼 캐싱이 뭐냐. 기존의 방식은 클라이언트가 요청할 때마다 서버가 응답해 주는 방식입니다. HTML문서를 준비해놨다가 뿌려주는 것이 아니라, 동적으로 생성하는 방식인 것입니다. 당연히 연산이 많으니까 서버 과부화가 날 수도 있고 유저 입장에서는 너무 느릴 수 있고, 서버 입장에서는 서버 비용이 너무 많이 나가게 됩니다. 그리고 F5를 계속 누르면 같은 연산을 하게 되는데 이를 계속 요청하고 응답을 받아오는 기존의 문제점에 착안되어 캐싱이라는 새로운 방식이 나옵니다.

기본적으로 캐시를 설명할 때 서버를 origin이라 하고 캐시서버를 distribution이라고 합니다. 클라이언트가 요청하여 응답된 결과를 cache로 저장하게 됩니다. 다음 번에 클라이언트가 요청할 때는 기존 server에 요청할 필요 없이 cache server에 요청하여 저장된 정보를 추출하게 됩니다. 요청할 때마다 동적으로 생성하는 방식에서 벗어나, 준비된 데이터를 cache에 저장하고 그걸 그대로 뿌려줍니다.

 

하지만 여기에도 한가지 문제점을 생각해 볼 수 있습니다. 바로 cache server에 회원정보, 장바구니 목록이 변했는데, 이전의 값을 가지고 있어 사용자에게 잘못된 값을 반환하게 되면 문제가 생깁니다. 그래서 cache server는 일정 시간마다 값을 갈아 엎는 작업을 합니다. 이는 일정한 term을 두고 진행되는데, 민감한 변하기 힘든 정보는 길게, 장바구니 목록같은 빨리빨리 바뀌는 정보는 term을 짧게 합니다.

 

CDN

다음은 CDN입니다. 이는 Cloud Delivery Network의 약자이기도 한데, 전 세계 어느 위치에서 접속하더라도 빠른 속도로 서비스할 수 있도록 하는 서비스입니다. 만약 미국에 있는 사람이 한국의 서버에 접속한다고 해 봅시다. 궁극적으로 cloud front를 사용하게 되는 것인데, 처음에는 당연히 느릴 것입니다. 하지만 한번 응답을 받고 나면, 이 결괏값을 전 세계에 흩어져 있는 Edge Location(캐시 서버)를 활용하게 됩니다. 그럼 다음번 요청에는 한국서버까지 가는 것이 아니라 Edge Location으로 가 캐시값을 빨리 받아오는 원리 입니다.

 

Route53, Certificate manager, CloudFront, ELB, EC2

기존에는 route53, certicate manager, elb, ec2이 4개를 활용했었습니다. 근데 여기에 cloud front를 추가하게 되는 것입니다. 그럼 다음과 같은 상황에 일어나게 됩니다. 만약 유저가 https로 우리의 서비스에 접근을 한다고 해 봅시다. 그럼 인증서를 받아서 cloud front로 가게 하고 cloud front에서 ELB로 가게 해야 합니다. 조금 복잡해 지긴 했습니다. 다음시간부터는 cloud front를 삽입하는 실습을 해 보겠습니다.