ネットワーク障害の原因は、米国の一社の不具合？

どこかを経由しているからと言って、データの中身をその経由場所で全部見えるとは限らないと思いますよ。

CDNについて詳しいことはあまり知りませんが、(負荷の振り分けをしているらしい、くらいしか)データをそこに置いている訳じゃなさそうですし。

仮にデータを置いていたとしても中身を見られるとは限りません。

>>それと、ロイター通信はその事情をすぐに発表できる。という事？

ロイター通信のツイッター第一報より早く掲示板を立ててしまって、なんか恐縮です。

[他社情報][解決しました] Fastlyがダウン。見れないWebサイトががが…… | 掲示板 | マイネ王
https://king.mineo.jp/reports/122247

ナイス！
でもロイターは発表まで少し時間をおいてると思います。(^^♪

へ～っ！？「CDN」とか初めて知りました！😲🙏✨✨
https://www.nikkei.com/article/DGXZQOUC08C8K0Y1A600C2000000/
＞世界のサイトで大規模障害　NYタイムズや日経電子版

日経や官公庁、Amazonや楽天、ニコ動やメルカリ～

たった一社の不具合が、あんなに影響及ぼすなんて、なんかネットって（全然、全く分かんないで😅使ってるけどｗ😖😂）いろんな意味ですごいんですね～？(;^ω^)

CDNはどちらかと言うと「情報伝達上、広範に参照される可能性があるものを分散して配置しているサービス」なので、キャッシュサーバーそのものとも言えます。

なのでキャッシュサーバーが落ちてもご本尊にはアクセスできるわけですが、それ以前に「キャッシュサーバーがひとまずの接続先として方向を向けている(DNSサーバー側としてはキャッシュサーバーが本体だと思ってそちらへ振り向けてる)」ので。

CDNが落ちると「ご本尊向けの通信に対するルートがなければ、ネットワーク的に本来の接続先へ至る経路が無くなった扱い」となるため、そりゃあ接続できませんよね！、となってしまいます。

※本当はそれぞれのサイトアドレス(ドメインなり IPレベルで)を知っていれば、
　CDNが落ちてもアクセスできますけどね。
　→それらの隠蔽を行うことで負荷分散にも寄与してる、と考えれば、
　　CDNの役割は非常に大きいです。

ナイスなまとめはこちら。
今回のポイントは「１時間かからずにほぼ直しちゃったFastlyさんスゲー」ですかね。

あと「CDN切り替えを準備済み」だったAmazonさんは、もっともっとすごかった。
『こんな事もあろうかと…』と、Fastlyから自社運用にサクッと切り替えたのはスゲェェーーーーーと思います。

>> amiyy さん

そうなんですね。
早い人は本当に早いのかぁ。

>> さと8@寝落ちの達人🐣 さん

私もその辺がよく分かってないんですよね。🤔🤔

むかし、ビルゲイツ氏が「網の目の様にPCをつないで、どんなルートからでもアクセスできる環境だ。」みたいなことを言ってたと思うんですけど、これでは話が違うなぁ・・・。

私のイメージが間違ってたんでしょうかね。

>> いいや見てない@眺めただけだ。 さん

＞どんなルートからでもアクセスできる環境
あの日経のページのコメントに、ちょうどその辺りの事言ってる人が😂

＞どこからも素早くアクセスできる
今回のCDNとは関係ないけど😅
いろんなページ見てる時の自分のPCと、ネットの繋がりとか、改めてちょっと気になりましたｗ(^^)/

>>「網の目の様にPCをつないで、どんなルートからでもアクセスできる環境だ。」
これには…
・経営者が正しく必要性を理解し
・開発者が難解な設計し
・運用者が適切にオペレーションし
・経理部門がちゃんとカネを払う
ことが必要なんです。
『リスクを理解したうえで、そのコスト（金、人、技術、時間…）を払えるかい？』ですね。


今回の障害でも、”Fastly利用者だけどサービス中断がおきてない”Webサイトもあるわけです。
そういうところは記事に社名が出ないわけですよ。
私個人としては、そういう”ちゃんと準備してあったWebサイト”を評価してあげたいです。

>> さと8@寝落ちの達人🐣 さん

なるほど。
ビル・ゲイツさんが言ってた頃とは、スタイルが変わってきているという事ですか。

>> amiyy さん

> 今回の障害でも、”Fastly利用者だけどサービス中断がおきてない”Webサイトもあるわけです。
> そういうところは記事に社名が出ないわけですよ。
> 私個人としては、そういう”ちゃんと準備してあったWebサイト”を評価してあげたいです。

とはいえ、Webサイトなどで考えたら「ドメイン参照先がどこか？」をある程度 DNSサーバーが決定しますので.....。

CDN側で本来のサイト(ご本尊側)の代理応答をするから.....でしょうが、これも「結局毎日多数のアクセスが有って、Webサーバーの処理容量を増強するよりはコンテンツ分散(キャッシュの複数配置)で収めておくのがまだマシでしょ？」という妥当な判断です。

実際、CDN障害での混乱は過去にも Cloudflareで発生してますし、経営者とすれば「どれだけアクセスが発生するのか想像もつかない状況」で「公開 Webサーバーに無尽蔵のリソースをつぎ込む必要があるのか？」という疑念→経営判断もありますので。

むしろ「アクセス飽和時はサイト着信時点で破棄してしまう」方法もありですが、そうなると応答せずに「Not reachable」ですし、設計上は色々頭の痛いところです。:)

追伸：
この手のお話は秒間リクエスト(接続要求)数やらシステム要件から考える内容です。
そのリクエスト数でもサービスが飽和しないようにするためには何を拡張すべきか？、
その要素は自分たちの資産として持たせるのか？などもありますから。
CDN自体はある意味キャッシュサーバーの塊ですので複数の CDNと契約した場合でも
「コンテンツ同期タイミングを完全に一致させないと情報のズレが発生する」ことから
実際には「ほぼ無限に近い容量をさばききれる Akamaiあたりでも契約するしかない」と
いうのもあります。Akamaiも過去に障害ありましたね。

AWS Cloud Frontだって容量稼げばすごい課金になります。(^^;)