サーバーがダウンしていてもCDNは機能しますか？
私は、Amazonのcloudfront S3を使用することを計画しているWebサイトの所有者です。私はCDNで何ができるかについてすべてを読んでいますが、まだ答えのない質問があります。
メインサーバーがダウンしている場合でも、CDNは機能しますか？それが私がそれに興味を持っている主な理由です。なぜなら、私のサーバーは通常、ここマリで停電が原因で頻繁に停止するからです。
CDNをホストしているのは誰かによって異なります。 1つのサーバーでWebサイトをホストし、サードパーティとCDNを使用している場合、WebサイトがダウンしてもCDNはアクティブなままになる可能性があります。ただし、一部のCDNは、Webサイトにあることを確認できるコンテンツのみを配布するため、これは当てはまらない場合があります。
ちなみに、CDNはWebサイト全体をホストするためのものではありません。したがって、1つを使用してWebホスティングを置き換えたり、ある種のフェイルオーバープランとして使用したりできると考えている場合は、間違ったツリーを吠えています。
TL; DR-CDNプロバイダーに問い合わせる必要があります。
CDNは、スケーラビリティとパフォーマンスを目的として設計されていますが、高可用性を目的として設計されていません。いつでも、元のファイルへのアクセスが必要になる場合があります。
ほとんどの人はそれらを使用して、画像、CSS、JavaScriptファイルなどの静的ファイルを格納します。 HTMLをキャッシュするように構成できるものもありますが、それは完全に静的なWebサイトがある場合のみです。その場合は、S3ですべてをホストでき、サーバーはまったく必要ありません。
一般的に、はい、TTLまでです。
CDNを使用する場合、通常、コンテンツのTTL（存続時間）を構成します。これは、キャッシュを最新のコンテンツで絶対に更新する必要があると判断する前に、キャッシュが取得できる最大値です。たとえば、すべての* .jpg URLが5分のTTLを持つように設定するとします。
その後、サーバーがダウンした場合、ユーザーが気付く前にサーバーを復旧するためにさらに5分かかります。まあ、少なくとも.jpgについては。まあ、少なくとも事前にキャッシュされていた.jpgについては。
また、一部のCDNは、コンテンツをCDNに直接アップロードできるAkamai NetStorageなどの機能を使用しています。そもそもここで「オンデマンド」「プル」スタイルのキャッシュが行われることは決してないので、もちろんサーバーがダウンしているときにも機能するはずです。
ただし、他の投稿者が指摘したように、これはCDNが設計されたものではなく、この動作が機能することを保証するものではありません。それは通常はうまくいくだけです（そしてそれが起こるのを見ると素晴らしいです！）。もちろん、特定の技術的な詳細については、プロバイダーに問い合わせる必要があります。
はい：CDNサーバーは、サイトがダウンしている間も引き続き実行されます。これは、大規模な停止に対処するための適切なオプションです。リソースと優先順位に基づいてエクスペリエンスを調整できるように、何が起こるかをかなり制御できます。オプションは一般的に次のカテゴリに分類されます。
キャッシュ用に構成されたオブジェクト（最も一般的には
Cache-Controlヘッダーを設定することによって）は、期限切れになるまで使用可能である必要があります。一部のCDNは、CDNエッジサーバーが他のCDNサーバーからコンテンツを取得する機能を提供します。これは、停止中に役立つだけでなく、通常、オリジンサーバーがCDNサーバーに比べてレイテンシが比較的高い場合のパフォーマンスを向上させます。一部のCDNは、バックエンドサーバーが利用できない場合に期限切れになったコンテンツを提供する機能を提供します（たとえば、Fastlyを使用すると、Varnishの猶予モードまたは聖モードを有効にできます）。明らかに、これはキャッシュされなかったコンテンツには役立ちませんが、多くの場合、サーバーをオンラインに戻す作業をしている間、少なくともコアホームページや連絡先情報などをオンラインに保つことができます。
ほとんどのCDNは複数のバックエンドサーバーを試す機能を提供するため、別のフェイルオーバーサイトにサイトに適したエクスペリエンスを提供することができます。別のサーバーまたは機能制限サイトへのフェイルオーバー、静的HTMLページなど。これは壊滅的な場合に役立ちます。完全に異なる会社、またはAkamai NetStorageのような場合はCDNプロバイダーと直接ホスティングしてフルスタックをサポートするオプションがあるため、ホスティングの失敗。
3番目のオプションを除いて、CDNサーバーに何をキャッシュするかを制御できないため、プロセスの最も重要な部分は、さまざまな機能が利用できない場合にサイトをどのように劣化させるかを決定することです。 JavaScriptが完全に失敗した場合でも、合理的なHTMLコンテンツは、より高度な機能がバックグラウンドで静かに失敗している場合でも、ほとんどの情報駆動型サイトは基本的なページコンテンツのみで実行できる可能性があります。
ほとんどのCDNは、オリジン（この場合はサーバー）から一定期間（TTL）コンテンツをキャッシュしています。 AmazonのCloudfront管理コンソールでは、S3バケットのキャッシュ制御について説明しています。
AmazonのS3のデフォルトの動作は、オブジェクトを24時間キャッシュすることです。
OriginサーバーにCache-ControlヘッダーまたはExpiresヘッダーを指定/書き込むことで、デフォルトの動作に影響を与えることができます。
Cache-Control max-ageヘッダーを使用する場合、最小値は0です。その時点で、AmazonはOriginサーバーにコンテンツを送信し、オブジェクトが変更されたかどうかを毎回確認します。
オブジェクトにExpiresヘッダーを使用すると、Amazonはその日付までOriginサーバーに接続しません。
これがAmazonの振る舞いを明らかにすることを願っています。
私は1年以上CDNのサポートエンジニアでした。ここでの回答はすべて素晴らしいと思いますが、IMO @ Chris-Adamsが最良の回答です（賛成票を投じることができれば）。
お客様が行うことの1つは、wwwをCDNにポイントし、301 TLDをwwwにポイントすることです。オブジェクトTTL=が期限切れの場合、期限切れのコンテンツがキャッシュで利用可能であれば、Edgeがコンテンツを提供します。
そうは言っても、稼働時間（および新鮮なコンテンツ）が重要な場合は、頻繁な停電が発生しないホストにオリジン（私が知っているお尻の痛み）を移動することを検討します。