라인의 CDN 플랫폼 세미나를 참고하였습니다.
CDN이란?
Content Delivery Network.
지역적으로 분산되어 있는 프록시 서버들의 클러스터, 데이터 센터이다. 유저들에게 가장 가까운 위치에 서비스를 배치해서 높은 가용성과 성능을 제공해준다.
CDN은 주요 ISP 내부에 CDN 내부에 배치를 해서 CDN 서비스 제공이 가능하다.
CDN 다운로드 흐름
[DNS]
CDN 접속에서부터 시작을 한다.
1) DNS Lookup이라는 단계를 통해, 근처의 CDN 서버의 IP를 받게 된다. 유저가 접근하는 DNS Record(서비스 도메인)을 CNAME이라는 레코드 타입을 써서 CDN 서비스의 DNS 서버로 위임을 시켜줄 필요가 있다.
2) 이 상태에서 유저가 IP Address를 받기 위해 DNS Resolving을 시작하면, 유저가 가지고 있는 Recursive DNS 서버를 통해서 최종적으로는 CDN 서비스가 가지고 있는 DNS 서버로 'IP를 주세요'라는 요청이 가게 된다.
3) 요청이 갈 때, 유저가 가지고 있는 DNS 서버의 Recursive DNS 서버의 주소가 같이 전달이 된다. CDN의 DNS 서버에서는 IP를 보고, IP가 한국인지/일본인지 판단하여, 가까운 Edge 서버의 IP를 돌려준다.
4) 유저는 실제 다운로드를 받기 위해, IP에 CDN 서버에 HTTP 리퀘스트를 전달한다.
[CDN 서버 동작]
1) 요청을 받은 CDN 서버는 일단 그 요청에 해당하는 콘텐츠가 있는지 확인한다. 캐싱이 되어 있는지 확인한다.
2) 콘텐츠가 없다면, 원본 오리진 서버에 요청을 던져서 오리진 서버가 요청을 주면 그걸 캐싱을 하여 전달한다.
3) 이후 다른 유저가 같은 콘텐츠를 요청을 하면 캐싱된 콘텐츠를 그대로 다운로드할 수 있게 도와준다.
CDN의 Value는 어떤 것인가요
CDN을 썼을 때 얻을 수 있는 효과는, 크게 3가지이다.
첫 번째는 성능이다.
User 관점에서 빠르게 콘텐츠를 받아볼 수 있다. 멀리 있는 원본 서버에서 가져오는 것보다 캐싱된 콘텐츠를 가져올 때 더 빠르다.
원본 서버가 유저에서 거리가 멀수록 CDN에서 받는 속도가 빨라진다.
두 번째는 원본 서버의 부하 경감(오프로드)이다.
원본 서버 입장에서는 유저들의 요청을 감당해야 하는데, 앞의 CDN 서버가 처리해주기 때문에 원본 서버의 부하가 경감된다.
실제 유저의 다운로드 대역폭을 보면, 실제 요청 150Gbps에서 원본은 4.5Gbps만 처리하고 있다. 원본 서버를 작게 유지할 수 있다.
세 번째는 보안이다.
원본 서비스가 직접 유저의 요청을 받는게 아니라 CDN에서 받기 때문에 보안적인 효과가 있다.
앞의 CDN 서버에서는 저수준 L4 Level 수준의 DDoS 공격이 있어도 처리가 가능하며, CDN 위에 L7 레이어의 웹 방화벽을 설치해서 고수준의 공격도 차단하는 기능도 제공을 하고 있다.
CDN 용어
Time to Live Control
모든 캐시에 적용이 되는 부분이다. 캐시가 얼마나 오랫동안 콘텐츠를 보관하고 있어야 하느냐의 뜻.
지정된 TTL만큼 콘텐츠를 유지하게 되고, 기간 만료가 되면 콘텐츠가 갱신이 있는지 원본에 확인을 해보며, 갱신된 게 없으면 원래의 콘텐츠를 TTL만큼 사용할 수 있도록 처리해준다. 바뀐 게 있다면 원본에서 새로운 콘텐츠를 내려준다.
원본 서버에서 Last Modified Time 혹은 Etag 정보를 포함해서, 원본 서버에서 이를 바탕으로 갱신이 있는지 없는지를 판단한다.
Cache Key
유저가 요청할 때 요청을 바탕으로 색인을 만들어서 이를 바탕으로 콘텐츠를 찾는다.
보통 Domain, URL, Query String을 기본적으로 사용하고 있으며, 추가하여 유저의 IP 정보 User Agent 정보 등을 Cache Key로 지정할 수도 있다.
중요한 점이, 동일한 Cache key를 많이 호출할 수록 캐시의 효율성이 올라가나, 잘못 쓰면 잘못된 콘텐츠가 내려갈 수 있어서 주의 깊게 사용해야 한다.
예시) 프로덕트 아이디별로 다른 사이트를 호출하도록. product ID라는 Query String을 반드시 Cache Key로 포함해야 한다.
Purge and eviction
캐시 서버는 TTL을 준수해서 콘텐츠를 유지한다. TTL을 지키지 못하는 경우는 다음과 같다.
Purge, 서비스 개발자가 필요하여 콘텐츠를 제거하는 경우가 있다. 새로운 객체로 변경해야 하기 때문에 현재의 콘텐츠를 모두 삭제한다.
모든 서버에 가서 이 콘텐츠는 서빙하면 안되니, 새로운 서비스를 가져오도록 지시하는 것이다.
Eviction. 엣지 서버도 서버이기에, 필요한 경우 인기 없는 콘텐츠부터 제거해서 공간을 확보하게 된다. Edge가 필요해서 콘텐츠를 지키는 것이다.
Client Cache
캐시가 두 가지가 있다.
CDN 서버 자체가 캐싱하는 것이 있고, 클라이언트 쪽에서 캐싱하는 것이 있다.
CDN 관련 문제가 생기면, 트러블슈팅 시 CDN 서버나 클라이언트 캐시가 있어서 혼란을 겪는 경우가 있으며, 클라이언트 캐시를 분리하여 결정을 해야 한다.
CDN 서버 캐시 TTL에는 smax-age를 통, 클라이언트 캐시 TTL은 max-age를 통해 설정을 할 수 있다.
[참고]
'🍀 Cloud Architect > CDN' 카테고리의 다른 글
| GCP Cloud CDN 구성하기 (0) | 2023.11.26 |
|---|
