1つの欠けていた並行性制限がBlueskyを8時間にわたり全ユーザーの半数に対してダウンさせた

2026年4月4日土曜日、BlueskyのAppViewデータプレーン——ソーシャルアプリの読み取りを提供するバックエンド——が「failed to set post cache item: dial tcp: bind: address already in use」のようなエラーを記録し始めた。データプレーンは、主要なScyllaデータベースへの負荷を抑えるためにmemcachedに大きく依存しており、オンコール担当のインフラエンジニアであるJim Calabroは、ログの急増がユーザー向けトラフィックの落ち込みと一致していることに気づいた。ネットワーク監視は正常だったため、サービスがぎこちなく動き続ける週末の間、原因は隠れたままだった。

根本原因はその週にデプロイされた新しい内部サービスだった。GetPostRecordリクエストは毎秒3件未満だが、バッチあたり15,000〜20,000件の投稿URIを含んでいた（通常は1〜50件）。データプレーンのすべてのRPCハンドラはerrgroup.SetLimitで並行性を制限しているが、このエンドポイントだけがその行を欠いていた。1回の呼び出しが最大20,000個のgoroutineを生成し、memcached接続の嵐をダイヤルした。1,000ソケットのアイドルプールがあふれると、それらはTCP TIME_WAITに積み上がり、すべてのエフェメラルポートを枯渇させた。クライアントは1つのデータセンターで動作しており、クライアントごとのメトリクスがなかったため、あらゆる種類のキャッシュエラーが犯人を覆い隠していた。

4月6日月曜日、事態はデススパイラルに陥った。毎秒数百万件のmemcachedリクエストが失敗する中、Blueskyの「すべてのエラーをログに記録する」ポリシーが毎秒数百万件のブロッキングwrite(2)ログ書き込みを試みた。ブロッキングシステムコールの洪水により、GoランタイムのOSスレッド数は約150から1,500に押し上げられ、GCが長いストップ・ザ・ワールド停止に陥った。積極的に調整されたGOGCとGOMEMLIMITにより、データプレーンは定期的にOOMクラッシュするようになった——約30分稼働してはダウンし、それを繰り返した。再起動のたびに穴は深まった。TIME_WAITソケットが残ったため、再起動したプロセスはmemcachedプールを再作成できなかった。

月曜日の応急処置は見事に馬鹿げていた。発信接続ごとにランダムな127.x.y.zのループバックIPを選ぶカスタムダイヤラーで、ip+port空間を枯渇した範囲の外へ広げた。これでスパイラルは止まり、チームが真の根本原因を突き止めて欠けていたSetLimit(50)を復元したのは水曜日になってからだった。Calabroの公開ポストモーテムはコミュニケーションの失敗も認めている。ステータスページはサードパーティのネットワークプロバイダーのせいにしていたが、それは「明らかにそうではなかった」。

2026年4月6日の約8時間にわたり、全Blueskyユーザーのおよそ半数に対して断続的なダウンタイムが発生した——同プラットフォームのインフラリードが在籍して以来、最悪の障害だった

並行性の制限は構造ではなく慣習によって強制されていた。1つを除くすべてのハンドラにSetLimitがあり、1つの無制限のエンドポイントだけでホストレベルのリソースを枯渇させるのに十分だった。

トラフィック契約には形状の制限がなかった。20,000件のバッチを拒否するものは何もなく、静かな内部クライアント1つ——毎秒3リクエスト——が、負荷源として数百万の通常クライアントを上回った。

障害処理が障害を増幅した。毎秒数百万件のエラーでmemcachedのすべてのエラーをログに記録したことで、キャッシュの問題がスレッド爆発、GC停止、OOMクラッシュへと変わった。

可観測性は小さなリクエストを前提としており、クライアントごとのメトリクスがなかったため、あらゆるキャッシュ種別からのエラーが、責任のある1つの呼び出し元と1つのエンドポイントを何日も覆い隠した。

再起動による復旧は壊れていた。死んだプロセスからのTIME_WAITソケットが新しいプロセスのmemcachedプール再構築を妨げ、OOM再起動をさらなるポート枯渇に変えた。

1つの無制限のgoroutineループが、他のあらゆる安全策を上回った。並行性制限はエンドポイントごとの習慣ではなく、構造的でなければならない。制限を欠いた唯一のエンドポイントが、障害全体となった。

サービスは月曜日にランダムループバックダイヤラーで安定化し、本当の修正——並行性制限の復元——が4月8日水曜日に適用された後にそのダイヤラーは削除された。総露出は、およそ半数のユーザーに対して約8時間の断続的なダウンタイムだった。2026年4月10日に公開されたポストモーテムは、クライアントごとの可観測性、少数の過大なリクエストを送るクライアントの検出、そして大量ログ記録からPrometheusメトリクスとOpenTelemetryトレーシングへの移行を約束した。それは2日後に信頼性研究者Lorin Hochsteinによる詳細な独立分析を招いた。