CDN 대체를위한 로컬 JS 및 CSS 리소스 제공

을 고려하면

• CDN은 클라이언트에 더 가까운 리소스를 제공 할 수 있고 클라이언트가 캐시 할 수 있으며 자체 서버의 부하를 줄일 수 있기 때문에 좋은 것 입니다.
• 최근 브라우저에서는 타사 서버에서 리소스를로드해도 SRI (Subresource Integrity) 덕분에 보안이 저하되지 않습니다 .
• 일부 국가에서는 CDN이 다운되거나 차단 될 수 있으며 오프라인으로 개발할 때는 사용할 수 없습니다 ¹ .

CDN을 사용하는 것이 매력적이지만 CDN을 사용할 수 없도록 준비해야한다고 생각합니다. 이 블로그 게시물 은 대체를 제공하기위한 다양한 접근 방식을 소개합니다. 기본 예제 를 살펴보면 jQuery와 Bootstrap에 대한 대체를 제공하는 꽤 많은 상용구 코드가 이미 포함되어 있음을 알 수 있습니다. 반면 선호되는 솔루션은 작년에 거의 유지되지 않은 것으로 보이는 Fallback.js 사용을 제안 합니다 . 마찬가지로 주제 와 관련하여 가장 관련성이 높은 질문 은 jQuery에 대한 대체를 제공하는 것입니다.

그러나 대부분의 실제 프로젝트에서는 5 개 이상의 js / css 리소스가 필요할 것으로 예상되므로 지저분한 보일러 플레이트를 반복하여 모든 것을 대체 할 필요가 없다고 생각합니다. 또한 리소스를 추가하거나 업데이트 할 때마다

• CDN 링크 업데이트
• 수동 다운로드 또는 npm / bower 구성에서 버전 변경으로 로컬 대체 사본 업데이트
• 폴백에 대한 링크 업데이트
• SRI 해시 업데이트

에있는 반면에 이상적인 세계 , 내가 추가 / 하나 개의 구성 파일에서 리소스를 업데이트하고 다른 모든 단계 (업데이트 아무것도 부러 있는지 확인하기 위해 다음 테스트를 실행) 자동 실행이 기대.

이를 달성하기 위해 이미 확립 된 워크 플로우가 있습니까?

아니면 CDN, 특히 SRI가 아직 너무 최근입니까?

아니면 대부분의 사람들은 단순히 CDN 리소스에 대한 폴백을 제공하지 않습니까?

_{1. CDN에 의존하지 않는 개발 빌드를 가질 수 있지만 유지 관리가 필요하기 때문에 폴백 형태도 고려합니다.}

이런 종류의 복원력이 필요할 수있는 더 큰 사이트가 CDN을 사용하는 방식을 오해하고 있다고 생각합니다.

jQuery 또는 일부 이미지를 호스팅하는 것이 아닙니다. 사이트의 대부분은 CDN에서 호스팅되며 결제 페이지 나 쇼핑 바구니와 같은 동적으로 생성 된 항목 만 '기본 웹팜'에서 호스팅됩니다.

심지어 서버 측 처리에 영향을 미치지 않고 사용자 특정 항목을 표시하기 위해 JS 및 쿠키를 사용하여 로컬로 처리하는 작업이 점점 더 많아지고 있습니다.

CDN에 장애가 발생하여 모든 트래픽이 웹 서버로 전달되기 시작하면 넘어 질 가능성이 있습니다. 그렇지 않으면 CDN이 실제로 필요하지 않은 것입니다.

CDN에서 작업하는 사이트가 점점 더 중요해졌습니다. 처음에는 단순히 이미지 / CSS / JS를 캐시하는 데 사용했습니다. 이 단계에서는 www.mysite.com/에서 www.cdn.com/으로 이러한 리소스의 호스트 이름을 다시 작성하는 구성 속성이 있으므로 CDN이 다운 된 경우이 호스트 값을 변경하거나 완전히 끄고 그대로 둘 수 있습니다. 웹 서버를 가리키는 URL.

그러나 이제 AJAX를 통해 개인화 된 컨텐츠가로드 된 기본 페이지 전체를 캐싱하는 작업을 진행했습니다. 우리의 CDN은 우리 사이트에 필수적이었으며 우리 자신의 HTTP 서버만큼 CD 없이도 운영 할 수있었습니다. 복원력과 가동 시간에 대한 SLA 약속으로 인해 CDN에 상당한 돈을 지불하므로 시간과 노력을 대체하는 것은 시간 낭비입니다. 제공 업체에 중대한 문제가있는 경우를 대비하여 DR 계획이 마련되어 있지만 간단한 자동화 된 프로세스가 아니며 대체 CDN으로 마이그레이션 할 때 중단 기간이있을 수 있습니다.

따라서 귀하의 질문에 대한 답변으로 귀하의 사이트에 CDN이 얼마나 중요한지에 달려 있습니다. CDN에 넣는 자산이고 http 서버가이 컨텐츠를 제공하는로드를 처리 할 수 ​​있다고 가정하면 구성 스위치를 사용하여 CDN을 기본적으로 켜거나 끌 수 있습니다. 모니터링 도구와 함께 사용하여 해당 스위치를 켜거나 끌 수 있습니다.

CDN을 사용해야하는 3 가지 중요한 이유가 있습니다.

1. 원격 지역의 사용자에 대한 네트워크 대기 시간을 줄입니다. 전 세계 사용자를위한 웹 사이트가있는 경우 북미 지역의 호스팅은 남아시아, 특히 중국 사용자에게는 빠르지 않습니다. 사용자 경험의 차이가 너무 커서 사용자가 사이트를 사용하지 못하게 될 수 있습니다. 이 경우 다중 지역 CDN이 비즈니스에 필수적입니다.

2. 고 가용성 리소스를 최대한 활용하십시오. 안정성은 클라우드 CDN을 사용하는 주요 이유 중 하나입니다. 트래픽은 사용 가능한 노드로 자동 라우팅되며 전체 클라우드 지역이 다운 된 경우 트래픽을 다시 라우팅하기위한 몇 가지 추가 조치를 추가 할 수 있습니다.

3. CDN은 동적 컨텐츠를 제공하는 애플리케이션 서버보다 유지 관리가 쉽고 저렴합니다. 위에서 언급 한 문제를 해결해야 할 때 돈을 절약하는 자연스러운 방법입니다.

CDN의 목표는 최종 사용자의 콘텐츠 가용성을 높이는 것입니다. CDN이 실패하거나 어떤 이유로 느려질 경우, 클라이언트 측 폴백은 먼저 액세스 할 수없는 리소스를 가져 오려고하기 때문에 페이지로드를 크게 증가시킵니다. 더 나은 솔루션은 "{CDN} /js/jquery-version-min.js"와 같은 링크에서 기본 URL을 대체 할 서버 측 설계를 갖는 것입니다. 이렇게하면 CDN 상태 확인에 실패한 경우 CDN 대신 애플리케이션 서버로 트래픽을 다시 라우팅 할 수 있습니다. 클라이언트는 불필요한 요청을 수행하지 않고 클라이언트 측 솔루션으로 대체되는 앱 서버로 직접 이동합니다. 또한 로컬 및 준비 배포 문제를 해결합니다.