서버가 다운 되어도 CDN이 계속 작동합니까?

Amazon의 cloudfront S3를 사용하려는 웹 사이트 소유자입니다. 나는 CDN이 무엇을 할 수 있는지에 대한 모든 것들을 읽었지만 여전히 답이없는 질문이 있습니다.

주 서버가 다운 되어도 CDN이 계속 작동합니까? 그것이 내가 관심을 갖는 주된 이유입니다. 내 서버는 일반적으로 말리에서 정전으로 인해 자주 중단됩니다.

누가 CDN을 호스팅하는지에 따라 다릅니다. 하나의 서버에서 웹 사이트를 호스팅하고 타사와 함께 CDN을 호스팅하는 경우 웹 사이트를 다운해도 CDN이 활성 상태로 유지 될 수 있습니다. 그러나 일부 CDN은 확인할 수있는 콘텐츠 만 웹 사이트에 배포하므로 배포 할 수 없습니다.

참고로 CDN은 전체 웹 사이트를 호스팅하지 않습니다. 따라서 하나를 사용하여 웹 호스팅을 교체하거나 일종의 장애 조치 계획으로 사용할 수 있다고 생각하면 잘못된 트리를 짖는 것입니다.

TL; DR-CDN 제공 업체에 문의해야합니다.

CDN은 확장 성과 성능을 위해 설계되었지만 고 가용성은 아닙니다. 언제든지 원본 파일에 액세스해야 할 수 있습니다.

대부분의 사람들은 이미지, CSS 및 자바 스크립트 파일과 같은 정적 파일을 저장하는 데 사용합니다. 일부는 HTML을 캐시하도록 구성 할 수 있지만 완전히 정적 웹 사이트가있는 경우에만 해당됩니다. 이 경우 S3에서 전체를 호스팅 할 수 있으며 서버가 전혀 필요하지 않습니다.

일반적으로 TTL까지 가능합니다.

CDN을 사용할 때는 일반적으로 콘텐츠에 대한 TTL (Time To Live)을 구성합니다. 캐시가 최신 컨텐츠로 캐시를 새로 고쳐야한다고 결정하기 전에 캐시를 얻을 수있는 최대 시간입니다. 예를 들어, 모든 * .jpg URL이 5 분 TTL을 갖도록 구성한다고 가정하십시오.

그런 다음 서버가 다운되면 사용자에게 알리기 전에 추가 5 분 동안 서버를 다시 가동해야합니다. 적어도 .jpg에는 적합합니다. 적어도 미리 캐시 된 .jpg 파일의 경우

또한 일부 CDN은 Akamai NetStorage와 같은 기능을 사용하여 콘텐츠를 CDN에 직접 업로드 할 수 있습니다. CDN에는 일부 콘텐츠가 제공되며 우선 순위에 따라 직접 제공하라는 메시지가 표시됩니다. "온 디맨드" "풀"스타일 캐싱은 여기에서 시작되지 않으므로 서버가 다운되었을 때 작동해야합니다.

그러나 다른 포스터에서 언급했듯이 이것은 CDN이 설계된 것이 아니며 이러한 동작이 작동한다는 보장을 제공하지 않습니다. 그것은 단지 정상적으로 작동합니다 (그리고 당신이 그것을 볼 때 굉장합니다!). 물론 특정 기술 정보는 제공 업체에 문의해야합니다.

예 : 사이트가 다운 되어도 CDN 서버는 계속 실행되며 이는 주요 중단을 처리하는 데 유용한 옵션입니다. 자원과 우선 순위에 따라 경험을 조정할 수 있도록 발생하는 상황을 공정하게 제어 할 수 있습니다. 옵션은 일반적으로 다음 범주에 속합니다.

1. 캐싱을 위해 구성된 개체 (가장 일반적으로 Cache-Control헤더 를 설정하여 )는 만료 될 때까지 사용할 수 있어야합니다. 일부 CDN은 CDN 에지 서버가 다른 CDN 서버에서 콘텐츠를 검색 할 수있는 기능을 제공하여 중단시 도움을 줄 수 있으며 원본 서버가 CDN 서버에 비해 상대적으로 높은 대기 시간 일 때 성능을 향상시킬 수 있습니다.

2. 일부 CDN은 백엔드 서버를 사용할 수 없을 때 만료 된 컨텐츠를 제공 할 수있는 기능을 제공합니다 (예 : 바니시의 유예 또는 성자 모드를 빠르게 사용할 수 있음). 분명히 이것은 캐시되지 않은 콘텐츠에는 도움이되지 않지만 대부분의 경우 서버를 다시 온라인 상태로 만드는 동안 핵심 홈페이지, 연락처 정보 등을 온라인으로 유지할 수 있습니다.

3. 대부분의 CDN은 여러 백엔드 서버를 시도 할 수있는 기능을 제공하므로 별도의 장애 조치 사이트가 사이트에 적합한 경험을 제공 할 수 있습니다. 다른 서버 나 기능 제한 사이트로의 장애 조치, 정적 HTML 페이지 등. 완전히 다른 회사 또는 Akamai NetStorage와 같은 경우 CDN 공급자와 직접 호스팅 할 수 있으므로 전체 스택을 지원하므로 호스팅 오류가 발생합니다.

세 번째 옵션을 제외하고는 CDN 서버에 캐시되는 내용을 제어 할 수 없으므로 프로세스의 가장 중요한 부분은 다양한 기능을 사용할 수없는 경우 사이트 성능이 저하되는 방식을 결정하는 것입니다. JavaScript가 완전히 실패하더라도 합리적인 HTML 컨텐츠 대부분의 정보 중심 사이트는 고급 기능이 백그라운드에서 조용히 실패하는 경우에도 기본 페이지 컨텐츠로만 실행될 수 있습니다.

대부분의 CDN은 원래 서버 (이 경우 서버)에서 일정 기간 (TTL) 동안 캐싱 (동적) 컨텐츠를 캐싱합니다. Amazon Cloudfront Management Console에서 S3 버킷의 캐시 제어에 대해 설명합니다.

1. Amazon S3의 기본 동작은 24 시간 동안 객체를 캐시하는 것입니다.

2. 오리진 서버 또는 Expires 헤더에서 Cache-Control 헤더를 제공 / 작성하여 기본 동작에 영향을 줄 수 있습니다.

   • Cache-Control max-age 헤더를 사용하는 경우 최소값은 0입니다.이 시점에서 Amazon은 원본 서버에 콘텐츠를 제공하여 매번 객체가 변경되었는지 확인합니다.

   • 객체에 Expires 헤더를 사용하면 Amazon은 해당 날짜까지 오리진 서버에 접속하지 않습니다.

이것이 아마존의 행동을 명확히하기를 바랍니다.

나는 CDN에서 1 년 이상 지원 엔지니어였으며 여기에있는 모든 답변이 훌륭하다고 말하지만 IMO @ Chris-Adams가 최선의 답변을 얻었습니다 (투표 할 수 있다면).

고객이하는 일 중 하나는 www가 CDN을 가리키고 301이 TLD를 www를 가리 키도록하는 것입니다. 개체 TTL이 만료되면 에지는 캐시에서 사용 가능한 경우 만료 된 콘텐츠를 제공합니다.

즉, 가동 시간 (및 최신 콘텐츠)이 중요한 경우 전원 공급이 자주 중단되지 않는 호스트로 원점 (내가 아는 엉덩이의 통증)을 옮기는 것을 고려할 것입니다.