GCPで障害発生中！認証システムが原因か、影響は他サービスにも？

Googleの「Chemist」って中央サービスが原因かもね。それがプロジェクト状態とかポリシーとかチェックしてるから、「visibility check failed」とか「cannot load policy」みたいなエラーや広範な影響も納得だわ。→https://cloud.google.com/service-infrastructure/docs/service…
追記：Googleは原因を「Identity and Access Management Service Issue」だって言ってるよ。

GCPだけじゃなくて、他のネットサービスも落ちてるみたいだね。もしかしたらこの「Chemist」サービスが特に外部から影響受けやすくて、それがGCPの内部サービスにまで広がったのかも。

それも十分あり得るね。でも変なのはCloudflareの状況。https://www.cloudflarestatus.com/
最初は「Access authentication to fail」から始まったんだって。これってGoogleの障害後に認証とかquotaがおかしくなった説を裏付けるかも？でもその後どうなったの？！ただの雪だるま式？！なんか変だよな。

Cloudflareのインシデント報告によるとね、「Workers KV」って重要なサービスが、主要な依存関係である「3rd party service」の障害でオフラインになったらしいよ。だから、KVサービスに依存してる一部のCloudflare製品が使えなくなったって。
Googleの障害がCloudflareに広がるなんて意外だけど、あり得なくはないか。

Cloudflareって自前でインフラ持ってるはずなのに、GCPと一緒にこんなに広い範囲で落ちてるなんてビックリだな。

「3rd party serviceの障害」ってことはさ、CloudflareってGCPに依存してて冗長性がないってこと？まあ、「key dependency」って書いてるし、そう読めるよね。

じゃあどうするっての？インフラを別のクラウドで複数作って自動でfail-overさせる？そんなの無理ゲーだし、どう考えても問題が増えるだけだと思うけどなー。modern devopsでもそこまでは難しくない？

そう思うよなー。DownDetectorではAzureとかOracle Cloudも落ちてるって報告されてるけど、さすがにGoogleには依存してないだろ。DownDetectorも全部が正しいわけじゃないんだろうな。https://ocistatus.oraclecloud.com/#/
https://azure.status.microsoft/en-gb/status
公式ステータスは両方グリーンだよ。

Cloudflareって、ふつうのcloudじゃなくてCDNなんだよね。得意なのはエッジPOPで賢いことすること。だから、自社のcontrol planeみたいなedgeじゃない部分のcomputeは、GCPみたいな「competitor」cloudに置いちゃってる可能性高いと思うよ。
そこはrevenue centerじゃないし、OpExを最適化するほどでもないからね。

彼らって自分たちでdata centerを運営してるcompanyなのに、public cloudが落ちたときに一緒におかしくなるとは思わないよね。

Cloudflareの最新のステータス更新見ると、システムがGCPに依存してるってことがほぼ確定みたいだよ。
「Cloudflareの重要なWorkers KVサービスが、主要な依存先であるサードパーティサービスの停止によってオフラインになった。その結果、KVサービスに情報を保存・配信するCloudflareの一部の製品が利用できなくなった」って言ってるね。

でもさ、もしコントロールプレーンが単一のクラウドプロバイダーに依存してるなら、こういう大きな問題に晒されることになるよね？
特にインターネット全体のReverse ProxyやCDNになりたい会社（Cloudflareのことかな？）なら、なおさらじゃない？

正直、すごく驚いたよ。
他社のクラウドサービスに依存すること自体、一般的になっちゃったけど、やっぱりリスクはあると思うんだよね。
でも、Cloudflareがこんなに依存してるなんて思ってもみなかったな。

俺、通知にはExpoの仲介を使ってるんだけど、今回のGoogle関連の状況を考えると、FCMも影響受けてるんじゃないかなって思うんだよね。
それってありえる？

Down Detectorは、クラウド全体がダウンするような状況だと問題があるんだよね。
予期せぬ依存関係ってやつ。
問題ないクラウドで動いてるアプリがおかしいって Down Detectorに報告しても、そのクラウド自体は大丈夫だったりする。
実際には、そのアプリが、問題のクラウドで動いてる別のSaaSプロバイダーに依存してて、そっちのせいで死んでるってことがよくあるんだよ。
例えば、「本来あるべきBackpressure（処理しきれないデータが溜まること）を受けて、処理キューが閾値を超えたからユーザーにエラーを返したんだけど、実はそれはSaaS Xからのタイムアウト待ちが遅すぎてキューが溜まったせいだった」とかね（こういうので何回も痛い目見てる）。

Googleって、Tech CompanyじゃなくてAdvertising Companyだからね。
広告収入に関係ないクリティカルなことを、Googleに頼るのはやめた方がいいよ。

あー、俺も今それ見たよ。
面白いね、Cloudflareがこれだけ大きな外部依存の表面を持ってるってのは、確かにちょっと驚きかな。

可能性はかなり高いね。
Firebase Authは確実にダウンしてる（まだ公式発表されてないけど）。
だから、FCMも多分そうだろうね。

CloudflareのビジネスモデルはB2Bで、全部のネットをCDNするわけじゃないんだ。
コスト削減できるならGoogleとかのクラウドに依存するのも普通じゃない？

大手クラウドと競合してるCloudflareの製品が、GCPにこんなに依存してるなんてビックリしたわ。

Firebase全体が完全にダウンしてたよ。

世界に主要なIaaSプロバイダーは20～25社くらいあるけど、互いに依存すべきじゃないよね。
Cloudflareはそう思ってたはずだし、今回の障害で対策するんじゃね？

確かにそうだけど、こんな障害って頻繁に起きる？
GoogleがダメならCloudflareも期待できないし、サービスも復旧したみたいだね。
滅多に起きないならGCPに依存しても大した問題ないんじゃない？
自前でフル構築するよりコスト安いしね。

CloudflareはWorkersをコンピュートプラットフォームとして推してるけど、過去の障害報告
（https://blog.cloudflare.com/major-data-center-power-failure-in-sjc/）
見ると、やっぱり自前のDCを持つべきだと思うな。

「代替策は？」じゃないだろ。
Cloudflareは「唯一の」冗長性・CDNプロバイダーとして宣伝してんだから、文句言わずにバックエンドのインフラをきっちり整備しろって話だよ。

数週間前のこのインタビュー
（https://youtu.be/C5-741uQPVU?t=1726s）
でも、ちょっとだけ触れてたんだよね。
あれ、驚いたわ。

Claude Sonnet 4 (Cursor)とかGemini Proでエラー出まくりだよ。
うわー、また自分の脳みそだけでコード書かなきゃいけないのかよ。
2024年12月の原始人コーダーに戻るのか…

俺も同じだよ。AI Studioでさ、「コンテンツ生成失敗：割り当て量オーバーだって。後でやれ」って出るんだよね。

俺さ、Cloud Storageにファイルアップロードのテストしてた最中だったんだ。
だから、まあ、散歩にでも行くのにちょうどいいタイミングかなって。

エラー処理を追加する良い口実になるな。
普段つい忘れがちだから、へへ。