TwitterのセルフDDoS攻撃
(sfba.social/@sysop408)- その日の午前中の大半にわたり Twitter のホームフィードが停止している間、Webクライアントがコンテンツ要求を繰り返し続け、自らDDoSを引き起こしているような 状況が観測された
- 画面が読み込まれない状態でも再試行は止まらず、最初の動画には rate limited エラーと揺れるスクロールバーが映っている
- 2本目の動画では、届かないコンテンツを取得しようとする過程で Twitter が自分自身に 毎秒約10件のリクエスト を送っている様子が確認できる
- 最近適用された 未ログインユーザーの閲覧制限 が、予期しない条件を生んだ可能性が原因として挙げられている
- 続報の Firefox ネットワークコンソールでもリクエストが出続けており、ユーザーのブラウザが Twitter に対して要求を繰り返す セルフDDoS 状況につながったと解釈されている
Twitter Webクライアントで見られた反復リクエスト
- Twitter のホームフィードはその日の午前中の大半で停止しており、何も読み込まれない状態でもWebサイトはリクエストの再試行を止めなかった
- 最初の動画には、ユーザーが rate limited 状態であるというエラーメッセージと、右側のスクロールバーが揺れる場面が収められている
- 2本目の動画はスクロールバーが揺れた理由を示しており、Twitter がコンテンツを取得しようとして自分自身に 毎秒約10件のリクエスト を送る場面が映っている
- コンテンツが届かない背景としては、ログインしていないユーザーが Twitter を読めないようにした変更が指摘されている
続報と添付資料
- 続報の投稿では、Firefox のネットワークコンソール画面を通じてネットワークリクエストが継続して発生する様子が追加で示されている
- 配布されたコードが 競合状態(race condition) を引き起こし、結果としてユーザーが Twitter に対してDDoS的なリクエストを実行することになった、という解釈が添えられている
- 投稿者は最初は接続を閉じたが、その後もしばらく Twitter がリクエストを誘発し続ける状況が続いたと明かしている
- 添付資料:
2件のコメント
Twitter、一時的にレート制限モードへ移行
Hacker News の意見
とてもつらい個人的経験から言うと、ひどいアイデアだとはっきり分かっていることを実行するよう強いられるほど、人を揺さぶるものはめったにありません
特に、こちらの最善の判断に反するよう圧力をかけてくる相手にその事実を伝えようとして失敗したときはなおさらで、後になってその人が書面の証拠まであるのに、そんな要求はしていないと大声で言い張るとさらにきついです
今 Twitter で働いている人たちが、最近の措置がこうした大きな副作用を生み得ると警告していたのかは分かりませんが、リーダーシップの運営の仕方を見るとまったく驚きません
この数か月で Twitter が変わった姿は非常に嫌いですし、買収前から、短文形式のせいでニュアンスが失われ、埋め込みやすいツイート数件が記事の根拠になる点が好きではありませんでしたが、ああいう経営陣の下で働かなければならない人たちのことは本当に気の毒に思います
推測ですが、Elon が「サイトが遅すぎる」と言い、エンジニアたちはホームフィードのリクエストが遅いことは見たものの、構造を理解しておらず、プロファイリングツールもなく、非現実的な期限内に直せと圧力をかけられていたのでしょう
そのため、できることはほぼ唯一、複数の並列リクエストを投げて、そのうち一つでも速いことを期待するやり方だったのだと思います
ゲーム業界で働いてみて、莫大なお金と時間を費やしても基本機能すら壊れたゲームをリリースする理由が分かりました
こうした極端なスケジュール圧力は逆説的に、一つを変えると十個が壊れる巨大な泥沼を作り出し、結局進捗が止まります
これは数年前から入っているべき基本的なエラー処理です
403 であれ何であれ、ツイートをブロックするレスポンスが短い間隔での無限リトライを引き起こしてはいけません
チームの脆弱性チケットを管理するツールを作ったのですが、最初のユースケースが、私の反対にもかかわらずすべての脆弱性チケットを削除することでした
実行する人は、実際のセキュリティ改善よりも、書類上の見栄えをよくすることに気を使っています
ずっと前から知っていて繰り返し提案していたのに、試すことすら許されず、むしろ排斥されて「例の人」扱いされるような場合です
「従来のやり方」が今もどうにか動いてはいるものの、会社をじわじわ殺していく技術的・事業的アプローチをめぐって経験したことがあります
ただし、上位者が危険だが必要だと判断したことに明確に責任を持てば、問題が起きたときにもずっと対応しやすい余地が生まれ、開発者が後からの皮肉を背負わされることも減ります
もちろん、こういうものは叩くほうが簡単ではあります
今回が連休の週末だという点を見るべきです
Elon が大きなリリースを押し進め、エンジニアたちを出社させて、この12時間でいくつものパッチを繰り返させたようなものです
プログラマーたちが心配です
さらに驚くのは、最近の Twitter エンジニアリングがどれほど場当たり的に見えるかです
コードベースを深く掘り下げることに力を使わず、最も単純で短い修正だけを選ぶので問題が起きます
この時点では、雇用条件も上司の期待値もどちらも非常に明確です
どんな理由で残っているにせよ、踏みとどまり続ける人たちに共感するのは難しいです
このバグが原因である可能性は非常に低いです
サーバー側のレートリミッターはコストが小さく、フロントエンドのバグはレート制限が有効になったときだけトリガーされます
私が管理しているシステムでも、ネットワークライブラリがデフォルトでまともな制限なしにリクエストをリトライしたがるため、似たようなバグを見たことはあります
しかし、そのリトライがレートリミッターを苦しめたことはありませんでした
実際に高価な処理を少ししてからエラーを返す API を叩くともう少し厄介ですが、だからこそすべての公開エンドポイントにレート制限を置くのです
Web アプリは Twitter トラフィックの最も小さい部分である可能性が高く、ネイティブアプリにはおそらくこの問題はないと思います
匿名アクセスの遮断がDDoSを引き起こし、それが何らかの指標の巨大なスパイクにつながり、その結果 Elon がスクレイピングの増加だと結論づけたうえで、スクレイパーを罰するために1日600ツイートの制限をかけた可能性はあります
私の割り当てがリセットされたのか、ポリシーが変わったようで、またサイトにアクセスできるようになっています
このバグが全体の根本原因である可能性は低い、という点には同意します
しかし、Musk が事実上サイトを閉じる理由として売り込んでいる話も信じていません
両方とも事実かもしれないし、ほかの潜在的な理由を考え続けてしまいます。完全な時間の無駄ですが、奇妙な精神的な餌のように感じます
『Nothing is true and everything is possible』という本は、Putin が大衆統制と民主政治の排除のために偽情報を使う方法を扱っていますが、ここにも当てはまる感じがします
Musk のファンたちは彼が言えということをそのまま繰り返すでしょうが、大半の人はそれが単に自分の都合のためのたわごとだと分かっているはずです
そして根本原因を探そうとする人は、このバグのようにもっともらしく感じるものの裏付けデータがまったくない物語に簡単に流れてしまいます
米国の将来のあり得る進路を見たいなら、この本を強くおすすめします
https://en.wikipedia.org/wiki/Nothing_Is_True_and_Everything...
こうしたリトライがバックエンドを圧倒し、サーバーがリクエストを拒否することすら追いつかない退行ケースを実際に見て、緩和しようとしたことがあります
上流の呼び出し元が何層にもわたってリトライするせいで状況が悪化し、リクエストがアプリケーションで処理される前に TCP バッファ／キュー内で事実上タイムアウトすることもありました
Twitter ホームページのバックエンドが同じような規模なのかは分かりません
興味深い状況だと思う
スクリーンショットを見ると、膨大な量の
GET /TweetDetailが生成されており、429 が見えるように、何らかのレート制限をトリガーしているように見えるこれが最近すべての API 呼び出しに認証を強制した決定によるものなら、犯人は実際には API ゲートウェイか、その下にある似たようなコンポーネントかもしれない
また、この挙動は止まらないように見えるが、これは指数バックオフのリトライで期待される挙動ではない
自分が Twitter で働く人たちより優れたエンジニアだと主張するつもりはないが、Musk 関連の事情を抜きにしても、こういう現象を本番で見るのは興味深い
ユーザーリクエストを低レイテンシで処理することがあまりに重要だと判断して、指数バックオフよりも一定のランダムバックオフを好むケースをあまりに多く見てきた
複数の設計会議や文書で、過負荷とシステム復旧のトレードオフを理解したうえで、指数バックオフを使わないという決定を明示的に下すのを見たことがある
バックエンド側の変更、つまり 必須認証 + レート制限が、フロントとバックを十分に一緒にテストしないままデプロイされた可能性がある
それがもっともらしい犯人に見える
Twitter のインスタンスが強制終了されているのかもしれない
「Twitter が 6月30日の契約更新日を前に Google クラウドサービスの支払いを拒否していた」と Platformer が 6月10日に報じた、という内容
「Twitter の Google Cloud 契約は 2018年から続いていた」ともある
https://www.engadget.com/twitter-has-supposedly-started-payi...
ああ、この混乱が全部説明できるように見える
おそらく GCP から脱却しようとしている途中ではあるだろうが、支払い拒否のせいで突然 GCP へのアクセスを失って起きたことではないはず
これは1週間前の記事
すべて自社ホスティングだ
Gcloud はバッチ処理とデータ分析だけを支えている
興味深い理論だが、DDoS は匿名アクセスを無効化する決定より前からあった
実際、その決定は進行中だった DDoS 緩和のために下されたものだ[0][1]
したがって、疑わしい Web フロントエンドのリトライロジックが状況を悪化させた可能性はあるが、根本原因ではない
[0] https://twitter.com/elonmusk/status/1674865731136020505
「一時的な緊急措置です。データの略奪があまりに激しく、一般ユーザー向けサービスの品質が低下していました！」
[1] https://twitter.com/elonmusk/status/1674942336583757825
「まもなく解除されます。前の投稿のとおり、極端なレベルのデータスクレイピングのため、大胆かつ即時の対応が必要でした。」
「スタートアップから地球上最大級の企業の一部まで、AI をやっているほぼすべての会社が膨大な量のデータをスクレイピングしていました。」
「どこかの AI スタートアップの馬鹿げたバリュエーションを助けるために、緊急で大量のサーバーを立ち上げなければならないというのは、かなり腹立たしいことです。」
そのスタートアップたちが使っている、ある日付以前の全ツイートの巨大なアーカイブがどこかに出回っているのは間違いないだろう
ログイン必須への変更前にも、こういうリクエストがあったのか知っている人はいる？
巨大なスクレイピング作業が実は彼らの JavaScript バグだったなら、本当に笑える
「スクレイピング流入」の大部分が Twitter 自身のせいだったとしても、まったく驚かない
愚かだが、当然の結果だ
レート制限がかかるまでの数秒間に、数十個のリクエストが出ていたはずだ
こうした小さなバグが大量に集まって、何らかの DDoS やスクレイピングのように見えた可能性もある
バグではない可能性もありそうだ
Elon は1日に見られるツイートを600件に制限したと言っていたが、これは正気とは思えない制限だ
ほとんどの人は5分スクロールするだけでそのくらいは超えるだろう
Tweetbot が自分のフィードに500件以上あると表示していたとき、20分のトラム移動を数回する間に読むくだらないものとしては十分だったと記憶している
Twitter が最近トラフィックの大幅な増加を見たことは疑わないが、その大部分は Twitter が 自ら作り出した問題だとある程度確信している
Elonはただ放っておけばよかったのに。あ、そうだ、440億ドルがあったんだった
Parag Agrawalと彼のチームは、自分たちが何をしているのか正確にわかっていた
「愚か者と金はすぐに別れる」という言葉そのもの
ElonがDelaware裁判所によってTwitterを買うよう強制された後、金のある独裁者たちのところへ行き、440億ドルを受け取って、彼らの代わりにTwitterを焼き払って消し去ると言った、というもの
TwitterがなければArab Springもなく、災害時のリアルタイム更新もなく、反対の声が広がるのを防ぐためにインターネットを遮断する必要もなくなる
大きな意味はないが、速度制限がまた緩和されている
6k/600/300 → 8k/800/400（正午ごろ）→ 10k/1k/500（午後3時ごろ）
https://twitter.com/elonmusk/status/1675214274627530754 と本人の返信が基準
“Something went wrong”が出る
新しいログイン専用ルールの下では、サイトが生きていても読めなかったと思う
もはやTwitterリンクは汚染されたリンクになり、実質的に使い物にならなくなった
完全なサーカスだ