Cloudflareグローバルネットワークに障害発生！サイトへの影響と緊急回避策

この特殊な感情を表すドイツ語って絶対あるはずだよね、そういう感情を表す言葉ってないのかな？

GPのことは分からないけど、もし自分のサービスが原因なら、顧客に直接何かできるからマシだな。このゾッとする感覚は失敗のせいじゃなくて、サービスが止まったせいで給料払えなくなるとか、家賃払えないとか、顧客の従業員にまで影響が出ちゃうことへの共感なんだ。こういう障害って予想外の人間のコストがかかる時があるんだよね。幸い火曜日だから、ほとんどの会社は給料日じゃないし。

Schadenは「損害」でFreudeは「喜び」だから、なんて言えばいいか分からないけど、もしかしたらSchadeleichtigかな？うーん…。

それはちょっと違うかな。それは他人の不幸を喜ぶって感じだね。近いんだけど、自分の不幸じゃないことへの特定の安堵感は捉えられてないよ。

ドイツ語を4年も勉強してるけど、まだ完全に「分かった」って感じじゃないんだよね :^) ありがとう！

CTOからの情報によると、Cloudflareのボット対策機能の基盤となるサービスに潜在的なバグがあって、ルーティンな設定変更後にクラッシュし始めたんだって。それがネットワークや他のサービス全体に影響を及ぼしたらしい。これは攻撃じゃなかったんだね。
情報源: https://x.com/dok2001/status/1990791419653484646

大手企業がまだ設定の段階的ロールアウトをしてないなんて、本当に驚きだよ。コードも設定もデータなんだから、同じものだろ。去年のCrowdStrikeの巨大障害も同じ問題で、設定をグローバルに直接適用したせいで、間違った設定が広まって全部ぶっ飛んだんだ。コードのロールアウトみたいに、設定も段階的にロールアウトするべきなんだよ。

大企業も設定は段階的に展開してるよ。でも2つ弱点があってさ。一つはロードバランサーみたいにグローバルな設定は一箇所でしかできないこと。もう一つは、たとえ1%のサーバーに設定しても、それが連鎖的にネットワーク全体に悪い影響を広げちゃうことだね。

グローバル設定は段階的にできないって話だけど、だからこそ”いつもDNSのせい”って言われるんだよ。DNS自体が不安定ってわけじゃなくて、たとえ他の全てが冗長でも、たった一つのコマンドでシステム全体をぶっ壊せる唯一の領域なんだよね。

DNSの設定って、別に全部グローバルにする必要はないんじゃない？サービスを「my-service-1.example.com」とか複数名で分割すれば、各フェーズのDNSを叩くスモークテストもできるし、エラーが出たら展開を止められるもんね。

確かに、でもそれってユーザー向けサービスにはあんまり役に立たないんだよね。みんなブラウザにドメイン名を入力したり検索結果をクリックしたりして、毎回あなたのサイトにたどり着くことを期待してるからさ。あと、DNSサービスのアクセス制御も、細かい設定ができないことが多くて、誰かが手順を無視して一気に全部のサブドメインを変えちゃうのを防げない場合もあるんだ。

”ユーザー向けには役に立たない”って意見だけど、いや、役に立つよ！例えばうちの会社には「company-staging.com」と「company.com」って二つの公開エンドポイントがあるんだ。まず「company-staging.com」に変更を展開して、スモークテストで問題なければ「company.com」にも展開する。もし失敗したら「company.com」への展開は止めるんだ。ユーザーは「company.com」を使うからね。

それじゃあ「company.com」のDNSアップデートの段階的展開には全然役に立たないじゃん。ここが肝なんだよ。結局”いつもDNSのせい”ってなるのは、本番のDNS設定を、事前プロダクションのスモークテストで試せないからなんだからさ。

俺の理解が正しければさ、「company-staging.com」のDNS設定って、「company.com」と全く同じってことだよね？IPもサーバーも、DNSプロバイダー、ドメインレジストラも。違うのはHostヘッダーくらいで、全部同じサーバーにアクセスするんだろ？なら、「company-staging.com」のDNS設定を更新して大丈夫なら、「company.com」の更新も大丈夫って考え方かな。

段階的展開の目的って、プライベートなステージング環境でテストした後に、実際のプロダクショントラフィックの一部を使って検証することだろ。あなたのステージングURLじゃ、それはできないよね？公開されてない限りさ。現実世界とシミュレーションの差が、失敗のリスクなんだ。良いアイデアだけど、本格的な段階的展開の代わりにはならないよ。

でもユーザーは「example.com」に行くんだよ。「my-service-33.example.com」じゃない。だから、ルートレベルドメインでしか起きないような設定の問題があったら、いくらサブドメインでテストしたって見つけられないだろ。

設定が原因の障害があったからって、彼らが段階的な設定展開をしてないって決めつけるのは意地悪だと思うな。それに、彼らをCrowdStrikeと比較するなんて、もっと失礼だよ。

Cloudflareの事後検証を読んでると、システムへの信頼度が低いんだよね。昔はコントロールプレーンを単一のデータセンターで動かしてたとか、時価総額600億ドル超の企業としてはアマチュアすぎる。Crowdstrikeと比較するのは意地悪じゃないと思う。両社とも多くの人の生活に影響するクリティカルなシステムを動かしてて、障害発生率も似てるし、むしろCloudflareの方がよく壊れてるくらいだよ。

https://blog.cloudflare.com/18-november-2025-outage/
想定よりデカいFeature Fileがネットワーク中の全マシンにばら撒かれたんだって。
その結果、5分ごとに良いか悪いかの設定ファイルが生成されて、ネットワーク中に急速に広がる可能性があったってさ。やっぱりね。悪いデータによるグローバル設定のロールアウトだ。Crowdstrikeとほぼ同じ障害モードだよ。

これってかなり論理的だと思わない？設定変更でサービスがクラッシュしたらロールアウトは止まるべきだよね…少なくとも俺が今まで作ったどんなフェーズドロールアウトシステムでもそうだったけどな。

昔いた会社で、IACで”global CI/CD”を導入した時も同じような議論をしたよ。変更してコミット、プッシュすると、いきなり40以上のサーバクラスタにグローバルに適用されちゃう。最悪だった。上層部は”cattle not pets”とか言って喜んでたけど、みんな大きな変更を加えるのが怖くなって、結果的に作業はかなり遅くなったね。

そうすると、顧客にも見える形で遅延が発生するよね。

敵対者がすぐに適応するから、彼らは対抗策のビットをフェーズ分けせずに迅速にデプロイするシステムを持ってるんだよ。それがコードだろうと設定だろうとね。Crowdstrikeを見てみろ。

フェーズドロールアウトじゃ、潜在的なバグを防ぐことはできないよ。

Cloudflareにとって設定変更は危険みたいだね。今日、Cloudflare株はほぼ4%下がったよ。これらの障害が業界全体にどんな影響を与えるんだろうね？

今日は障害が発生する前から、全てのテクノロジー株がプレマーケットで赤字だったよ。

Cloudflareがこれほど普及していることを知らない投資家が多いから、今回の障害はむしろCloudflareにとって良い兆候じゃない？

設定変更がCloudflareには危険で、今回も株価が下がった。数ヶ月ごとに大規模障害が起きる“ニューノーマル”は、一部プラットフォーム依存と運営の拙さの証だ。航空券やクレカシステムは滅多に障害起こさないのに、CloudflareやAWS、Google Cloudは品質管理が甘い。顧客が障害を「攻撃じゃないからマシ」と受け入れるのはストックホルム症候群だ。規模が大きくても、顧客はもっと改善を要求すべき。そうでなきゃ悪くなるだけだよ。
[0] https://en.wikipedia.org/wiki/Airline_reservations_system
[1] https://en.wikipedia.org/wiki/Stockholm_syndrome

オランダから確認したら、ほとんど全てダウンしてる。Cloudflareのダッシュボードまで障害中だ。Funnyじゃないのは、Betterstackのダッシュボードはダウンしてるのに、Betterstackでホストしてるステータスページは生きてるってこと。ダッシュボードにアクセスできないから、障害情報を作成して顧客に知らせることもできないよ。

またこの時期が来たか。AWSとCloudflareにここまで依存するのは危険だって皆わかってるけど、今となっては乗り換えるのも難しいんだよね。唯一ポジティブな点は、障害が大規模すぎて、顧客が大抵は理解してくれるってことかな。

ああ、俺も同じ経験だよ。Hacker NewsはCloudflareを使ってないけど、それは不要だとわかってるからだ。俺も「必要ないならサイトをCloudflareの裏に置くな」ってブログを書いたところさ。
[1]: https://huijzer.xyz/posts/123/

大規模DDoS攻撃から身を守るための代替策や、他にどこに行けばいいか、誰かの提案を聞きたいな。最近はほとんどのCDNプロバイダーが、こういう攻撃を捌くのに十分なキャパシティを積んでるけど、DDoS攻撃を自分で対抗しようとするのは無理ゲーだよね？

悲しいことに、AIボットやクローラーのせいで、過度な画像配信コストなしでサイトを維持するにはCloudflareが唯一手頃な方法なんだ。TikTokのAIクローラーが俺のサイトを破壊してたんだよ。ByteSpiderボットに何百万もの画像が繰り返し配信されて、止まらなかった。執拗な嫌がらせだった。今は全部Cloudflareでブロックしてるよ。

DDoS攻撃は起こりうると受け入れて、どうすることもできないってことを諦めるしかないよ。それでいいんだ、それがインターネットの仕組みだから。

AnubisやBunnyは、君の具体的なニーズによるけど、良い代替案や組み合わせになるよ。
- https://anubis.techaro.lol/
- https://bunny.net/

はい、Cloudflareみたいな集中型サービスへの執着が全く理解できないんだよね。公平に言うと、うちのちっちゃなブログが月100人くらいの訪問者しかいないなら、1日止まっても関係ないんじゃない？

これ、大きなビジネスチャンスがあると思うな。企業がローカルのVPSにステータス更新を置けるサイトを作って、100ドルとかで提供するんだよ。

クローラーのIPをブロックするUWFを書くなんて簡単じゃない？こんな時は、セルフホストで本当に良かったって思うよ。

もし空港で手荷物クレームの手続きをしてたり…薬局で処方箋をもらおうとしてたりするなら別だけどね。コミュニティとして、この状況よりは良くする責任があると思うんだ。

一部は、証明書（certs）の心配をしなくていいのが、プロキシ（proxy）の裏に隠れる良い理由だと思うな。IPアドレスを隠すのにも役立つだろうしね。もちろん、一方でCloudflareの証明書に頼るのは、基本的にMITM攻撃を招くようなものだって知ってるよ。

それは、DDoSが通常、悪意のある攻撃者によるたまの攻撃だった頃の話だね。最近DDoSされる時は、Facebook直だったり、Azureだったり、あとはランダムなAIだったりするんだ。

これらのサービスが信頼できる限り、これは維持できると本当に思うよ。いくつかの障害はあったけど、現時点では信じられないほど信頼性が高いと主張するね。でも、もしこれが変わったら、競合他社への移行コストは、特にAWSの場合、リポジトリを別の場所にプッシュするほど簡単じゃないだろうね。そこに潜在的な危険があると思うんだ。

もしAWS／Cloudflareを選んでいて、インターネットの半分と一緒にサービスが落ちたら、上司の上司に説明する必要もないんだよ。だって、主流メディアで記事になるからね。もし他のサービスを選んでいて、うちは落ちて、競合は大丈夫だったら、えらい人たちからたくさんの質問が来始めるだろうな。

復旧したら、自分自身のために、OVHとかHetznerみたいなプロバイダから他国の月5ドルのVPSを借りて、そこにステータスページを置くと良いよ。「でもそれも落ちたら？」って思うかもしれないけど、メインの製品／サービスと同じ理由で落ちる可能性があるところでホストするのは災害の元だから、それは関係ないんだ。

5ナインって年間7分くらいなんだよね。彼らはSLAを破って、みんなが頼ってるサービスに影響を与えてる。正直、これは他の企業のせいでもあるんだけどね。「みんな」がAWSとCloudflareを使ってるから、他の企業もそれに続く。今や、自分たちの卵が全て同じカゴに入っているだけでなく、みんなの卵も同じカゴに入ってるんだ。そのカゴが必然的に湖に落ちたら…。プロバイダは障害発生時のグローバルな影響をもっと認識すべきだし、顧客は分散をもっと多様化すべきだよ。