秋のスタックオーバーフロー:何が起こったのか

木曜日から金曜日の夜、スタックオーバーフローは利用できませんでした。 しばらくして作業は回復しましたが、金曜日の朝にサイトは再び「 落ちました 」。



SO 、障害が同時に発生する一連の問題を引き起こしたと指摘しました。 システムは、増加する接続数に対処できませんでした。 これで、サイトは正常に動作しています。



カットの下で、失敗の原因について説明します。





/写真ハムザバット CC



スタックオーバーフローは9台のWebサーバーで実行され、各サーバーは1秒あたり200〜500件のリクエストを処理します。 Nick CraverがStack Overflowプラットフォームのアーキテクチャリードについて述べているように、金曜日、この問題は2つのサーバーに影響を及ぼしました。 これにより、 IISスレッドプールが枯渇し、データベースからの要求を処理するための待機時間が長くなりました。



そのため、新しいリクエストがスレッドプールからの応答を待っている間に、古いリクエストの終了を許可していませんでした。 デッドロックが発生しました。 ニックによると、理論上のトラフィックの制限は問題を解決しますが、これはロードバランサーの動作のエラーのために発生しませんでした。



ロードバランサーの問題



理想的には、HAProxyは、管理者の介入が必要になる前であっても、2つの「問題」サーバーを自動的にシャットダウンする必要があります。 しかし、スタックオーバーフローのASP.NETはホームページから/エラーにリダイレクトされ、HAProxyは応答コード302を受信しました。これは「成功」と解釈されました。 したがって、サーバーを切断しようとしませんでした。



Nick Craver氏は、この問題に対する解決策はすでにあると指摘しています。 チームは、HAProxyが特定のステータスコードのみを想定し、ホームページからのユーザーのリダイレクトを停止するようにします。 ニックはかなり以前からこの機能を実装していますが、本番環境には追加されていません。 現在、その実装は来週に予定されています。



ニックは、これまでのところ、チームはSQLクエリの数の増加につながった理由特定できなかったと述べています(SOのスレッドで、彼はグラフを公開しました-アクティビティの大きなバーストを示しています )。 SOはこれに取り組んでおり、プラットフォームの常駐者を最新の状態に保つ計画です。



過去の停止



過去にスタックオーバーフローのクラッシュが発生したことに注意してください-2014年にシャットダウンが発生しました。 ただし、この問題は、プラットフォームが連携するネットワークサービスプロバイダーに対する大規模なDDoS攻撃が原因で発生しました 。 その時点で、問題は1時間で解決されました。



免責事項: SO分析の「infrastructure落」、ITインフラストラクチャまたは情報セキュリティに関する決定に関する新しい情報が利用可能になり次第、この資料を補足します。






PS最初の企業IaaSブログで書いていること:






All Articles