米国プロジェクトに影響を及ぼすクエリAPIのパフォーマンスの劣化
- investigating
Mixpanel は、クエリ API のパフォーマンスを劣化させ、米国のデータレジデンシーとのプロジェクトに関するレポートをクエリする際に HTTP 500 レスポンスを生成します。 EUとイン・データ・レジデンシーのプロジェクトは影響を受けません。 エンジニアが正常な機能性を回復させるために働く間、あなたの忍耐を感謝します。 ステータスページで進捗更新を投稿します。 ご不明な点がございましたら、お気軽にお問い合わせ下さい.
- identified
問題が特定され、修正が実装されています.
- monitoring
修正が実装され、クエリ API の成功率が向上しました。 今後もモニタリングを続けてまいります.
- resolved
この事件は解決しました.
- postmortem
#Mixpanel RCA:米国プロジェクトのための一時的な問い合わせサービス中断 8月 26, 2026 # まとめ 2026年8月26日の午後2時02分と午後3時19分の間、アメリカ地域のプロジェクトは、Mixpanel UIとクエリAPIを通じてレポートをロードし、クエリを実行した経験しました。 このウィンドウでは、領域のクエリが失敗したり、エラーが返されたりします。 **顧客データが失われず、データ摂取は影響を受けません。** すべてのイベントは、インシデント全体で通常収集および保存され続ける; クエリサービスが復元されたら、すべてのレポートは、顧客行動を必要としない完全で正確なデータを反映した。 原因は、診断クエリの再生のための最近展開された内部ツールとして識別されました, 私たちのエンジニアは、過去のクエリのコピーを再実行するために使用能力は、パフォーマンスをデバッグします, 予期せず、私たちのクエリサーバのディスクに大量のデータを書いた, ストレージ容量を消費して、サーバは動作する必要があります. これらのディスクが満たされたとき、影響を受けたサーバーはサービスから取り出しました。 本サービスは復元され、影響を受けたサーバーがオンラインに戻り、内部ツーリングが無効になりました。 下の修正は、クエリサーバーにリソースを消費する内部ツーリングの能力を削除するためのストレージ保護策を追加し、将来的に起きている問題のこのクラスを防ぐように設計されています。 # 何が起こったのか Mixpanelのクエリエンジンは、各サーバーの一連のローカルストレージボリュームを使用して、クエリを迅速に解決するために必要なデータをキャッシュします。 別々に、当社のエンジニアは、診断クエリの再生ツールを使用して、当社のエンジニアがクエリのパフォーマンスを再現し、デバッグするために使用する機能を使用します。 大規模な複雑なクエリに診断クエリの再生ツールを適用している間、クエリの再生キャプチャは、単一のサーバーに閉じ込められた代わりに、艦隊全体でファンアウトする。 また、1つのサーバーでタイムリーな操作をせずに保存する予定よりもはるかに多くのデータを引き起こしました。 2つの要因は、問題の影響を広げました。 * 1つのフルストレージのボリュームは、サーバーを完全にサービスから取り出しました。 各サーバーは、すべての他のボリュームが健康である場合でも、そのストレージボリュームのいずれかが使用しきい値を渡るならば、不健康なようにキャッシュを扱います。 再生データは、サーバー毎の特定のボリュームに書かれていたため、地域全体のサーバーは、ほぼ同時に健康チェックを失敗しました。 ※ クリーンアップの制限はデータサイズを考慮していません。 ファイルシステムレベルでバイトではなく、アプリケーションレベルでディスクのカウントされた項目にリプレイデータを制限する保護策なので、大量の容量のほとんどを消費しながら、予期しない大量のキャプチャがチェックを通過しました。 これらは、通常、米国地域を横断する生産クエリを中断するために、必須のフットプリントを持っている単一のデバッグワークフローを許可しました。 # タイムライン \(太平洋時間、8月26日、2026\) ***2:00 PM** — 第一サイズ診断再生キャプチャが書かれていました。 ストレージのボリュームは、容量とクエリの成功率に達するようになりました。 ※2:17 PM** — オンコールエンジニアを自動警戒し、調査が始まり、追加のエンジニアが従事しました。 ※2:39 PM** — ステータスページインシデント投稿、アプリ内バナーは2:40 PMに表示。 ※2:53 PM** — ルートが特定された原因; 回復努力は最初の影響を受けたサーバーグループで始まりました。 ***3:19 PM** — トラフィックの大半のために復元されたクエリサービス。最終サーバーグループは3:27 PMで完全に回復しました。 ※3:45PM — 安定した観測期間を過ぎて解決した場合 問題を引き起こした診断再生ツールは、同じ夕方を完全に無効化しました。 # 根本原因 1。 **当社のクエリ再生ツールのソフトウェアのバグは、生産ストレージへの未踏の書き込みを引き起こしました。** 複雑なクエリの特定のクラスを誤ったクエリを生成するための最近展開された機能により、キャプチャは地域内のすべてのクエリサーバーにスプレッドし、想定される設計よりも影響を受けるボリュームに遠くのデータを書き込むことができます。 2。 **再生ファイルは、クエリサービングが依存するディスク容量を消費しました。** 再生ツールは、クエリサーバーのローカルディスクにファイルを書きました。そのため、実行中の再生データが、サーバーはクエリに応答する必要があります。 3。 **行動のために部分的に考慮されるだけを保護して下さい。** 診断再生データのためのクリーンアップポリシーは、ディスク上のアイテムの数が限られているが、その合計サイズではなく、それに従事しなかった。 ストレージボリュームのアラートは、成長を強調したが、サーバー単位で重要なものとしてエスカレーションされていないため、クエリの失敗が始まったまで検出を遅延させました。 # 変化する 私たちが構築しているのは、専用のオブジェクトストレージに保存された内部診断クエリ再生データです。プロダクションクエリサーバーに負荷をかけません。 既にデプロイされる: ***インシデントを引き起こした内部ツーリング**を無効化し、根本的な問題を修正し、診断キャプチャは単一のサーバーに限定され、特定のクエリクラスが正しく処理されます。 *** 対象となる回復手順** をインシデント中に使用し、すなわち、フルサーバーグループを再起動するのではなく、影響を受けるストレージ容量だけをクリアし、運用中のランブックで、将来のボリュームの容量がなくなると回復時間を短縮しました。 進行中: ***ファイルシステムレベル、診断再生データのサイズベースの制限**、アイテム数ではなく、ディスク上の合計バイトをキャッピングするので、大きすぎるキャプチャは、ボリュームの容量に影響を与えることができる前に拒否またはevictedされます。 ***Stricterストレージアラート**、クエリ健康チェックに影響を与えることができる前に、サーバーのボリューム飽和をクリティカルにエスカレートします。 ***クエリーのリプレイデータを専用のオブジェクトストレージに削除するので、プロダクションクエリサーバにリソースを消費しません。 # 一般的な質問 ***データが失われた場合 いいえ。 事件全体にデータ摂取が不満でした。イベントは収集、キューに入れ、正常に保存されます。 クエリが中断されただけ。 サービスが復元されたら、すべてのレポートは完全なデータを反映しています。 * 保存されたレポート、ダッシュボード、またはプロジェクト設定の影響を受けますか?** いいえ。 インシデントはクエリ実行のみに影響しました。 プロジェクトに格納されていないものは変更されません。 ***複数の米国のプロジェクトに一度に影響したのはなぜですか?** ほぼ同時に、すべてのクエリサーバのディスクに書かれている特大の診断再生データであり、各サーバーは1つのボリュームが満たしたときにサービスから削除されます。 クエリサーバのストレージを消費する内部ツーリングを防止することは、当社の是正作業のコア部分です。 ※この予防措置は?** 工具細工の問題は解決され、工具細工はサイズベースの限界が置かれるまで無効に残ります。 ストレージのアラートは締められており、クエリのサービングに影響を与える前に飽和がキャッチされます。 構造的に、私達は生産の照会サーバーを完全に動かします、従って内部のダバッギングデータは照会の処理を担当するサーバーの貯蔵を消費しません。 ご迷惑をおかけしますが、ご迷惑をおかけいたしますが、何卒ご了承くださいますようお願い申し上げます。 ご質問やご質問など、お気軽にお問い合わせ下さい.
公式のインシデント更新を自動翻訳しています。