高負荷時にトピックのリアルタイム更新がフリーズする

サポート
1

注：これは Discourse のバグかどうか確信が持てません。必要な証拠を集めるために試みましたが、これまでのところ当社のインフラや設定に起因する可能性を示すものは何も見つかっていません。Tappara.co の設定は、可能な限りバニラ（標準設定）のままです。

観測された現象：

  • チャットのような迅速な議論トピックが自動的に更新されなくなります。30〜180 秒の遅延の後、更新が再開され、フリーズ中に投稿された投稿が表示されます。

現時点でわかっていること

  • 昨シーズンはこの現象は見られず、最後の試合は 3 月に行われました。
  • 安定版ブランチを使用しており、最新のメジャーアップデートは 8 月に行いました。
  • この問題は、交通量やアクティビティが中程度だった最初のエキシビションマッチですぐに報告されました。
  • iOS と Android の Chrome で影響を受け、Chromebook でははるかに頻度は低いです。
    • この文章を書いている今、私の Android スマホではフリーズが発生していますが、同じネットワーク内にある Chromebook では議論が期待通りに流れています。2 つの異なるデバイスです。
  • 体験はユーザーやクライアントによって異なります。異なるユーザーが異なるタイミングでフリーズを報告しています。全体として、約 30 分で約 300 件のメッセージを記録しましたが、ユーザーは数十回のフリーズを報告しました。フリーズの多くは、ゲーム内のイベント（ゴール、ペナルティなど）と相関しているようです。

除外するために試したこと

  • CloudFlare – CF キャッシュなしで 1 試合行いましたが、問題は続きました。
  • CPU 過負荷 – CPU 使用率は限度内にあり、通常 20〜30% 前後で推移しています。
  • ディスク容量の枯渇 – ディスク I/O も限度内にあります。UpCloud の MaxIOPS SSD を使用しています。

その他の情報

  • 試合中は Chrome 開発者ツールを起動していましたが、いくつかの 429 エラーが記録されました。しかし、私にとってはフリーズとの相関はありませんでした。
  • 一般ユーザーには、429（スローダウン）や極度の負荷に関する通知は届いていません。更新がフリーズし、その後再開されるだけです。レートリミッターは最近変更されましたか？レートリミットがトリガーされると、UI に通知が表示されるはずだと認識していますが。

これは非常に厄介な問題で、プレイバイプレイのゲームチャットに深刻な影響を及ぼしています。私たちは何年もこれらを運用してきましたが、このような現象は初めてです。

「いいね！」 5
2

ええと、これはバグではなく機能です :sweat_smile:。

Web ワーカーがリクエストでオーバーフローし始めると、新しい投稿が到着した際にトピックを自動的に更新する永続的接続に遅延が生じます。

もしこの現象と、報告されている低い CPU 使用率を確認している場合は、ユニコーンワーカーの数を増やしてください。これで問題が解決するはずです。

「いいね！」 7
3

すでに6コアVPS上で11匹のユニコーンが稼働しています。以前お伝えした通り、これは3月以降の昨シーズンでは発生しませんでした。現在では中程度のトラフィックでも発生します。また、デスクトップに比べてモバイル端末、特にAndroidのChromeで頻繁に発生しています。

以前も（トレード移籍期限の際に）CPUを限界まで使い果たしたことがあります。

ゲームの監視とサーバーの調整を怠ってしまいました。web.ratelimitedパラメータを2倍にしましたが、問題は解決しませんでした。

Inspectorで多数の429エラーが検出されました：

1. リクエストURL:

https://tappara.co/message-bus/3ed86765a67f4c31ba4053a0352ecaf5/poll

2. リクエストメソッド:

POST

3. ステータスコード:

429

明日は次の試合なので、ユニコーンの調整を試してみます。どこまで増やせるでしょうか？最新の主要アップデートで何か変更がありましたか？

編集：

統計を確認したところ、これまでのアクティビティ（ページビュー、ユーザー数）は春よりも少ないことがわかりました。試合チャットの投稿数は同じです（3時間あたり約900〜1000件）。

理由不明ですが、現在では3月に比べて同じ規模のオーディエンスに対応できていません。

「いいね！」 3
4

この問題の分析を今後 2 週間にわたって行っています。改善には時間がかかります。

「いいね！」 9
5

素晴らしい！この問題の原因となった最近（6 ヶ月以内）の変更や回帰があったかどうか、確認いただけますでしょうか？

それまでの間、今夜の試合に向けてユニコーンの数を増やして、結果を見てみます。何かサポートできることがあれば、お知らせください。

「いいね！」 1
6

@falco ユニコーンの数は決して鍵ではありません。今夜のゲーム用に15に増やしました。ゲームのトピックは静かで、メッセージ数は700件だけでしたが、常にフリーズが観測されました。CPU負荷は軽度で、5〜25%の間でした。

これを調査すればするほど、問題であり回帰である可能性が高まっていますが、どこにあるのか特定するには私のスキルが十分ではありません。

7

クライアントにバグがあると考えています。エラーが1回発生すると、更新がほぼ停止してしまうようです。私の推測では、ユーザーがレート制限に引っかかっていることが原因ではないでしょうか。

先ほどお話しした通り、このコードはデリケートで時間がかかるため、今週はクライアントの堅牢性を高めるための調査を進める予定です。

「いいね！」 2
8

素晴らしい。その間、グローバル制限を無効にすることで回避策になるかテストします。水曜日には結果がわかります。

9

この問題をデバッグしている過程で、一般に「ほぼリアルタイム」のディスカッションにおけるユーザーエクスペリエンス（UX）について考えるようになりました。多くのコミュニティは現実世界の出来事を扱っており、それが自然とチャットのような迅速な会話へと議論を「押しや」ることがあります。株式市場、主要な製品発表イベント、あるいはゲーム（e スポーツや物理的なスポーツなど）など、例は挙げればきりがありません。

しかし、このようなチャットのような議論文化では、投稿の質が非常にばらつきます。一方で、投稿は自然とほぼ同時に発生する傾向があります。大きなホッケーの試合が行われていて、誰かがゴールを決めたと想像してみてください。

  • 投稿の大部分は、単なる感情的な反応、歓声、または嘆きです。
    • 「ゴールだ！！！やっほー！」
  • 中には情報提供型のものもあります：
    • 「クロスビーがゴール、ペンズが1-0」
  • 少数派ですが、分析を加えようとする努力を払う投稿もあります：
    • 「クロスビーがブレイクアウェイでゴールを決めた。キャップスの無謀なフォアチェックが招いたものだが、オフサイドのようにも見える。キャップスのコーチはこれを異議申し立てすべきだ。」

さて、Discourse は高速なプラットフォーム（ほぼリアルタイム）であるため、システムが円滑に動作していても、数十件の投稿が事実上「同じ瞬間」に届くことになります。読み手、特に試合を見ていずにチャットトピックでフォローしている人にとって、これは UX 上の課題となります。歓声や嘆きの波の中から、情報性の高い投稿を見つけるのが難しいのです。当フォーラムの試合チャットでは、試合を見ているチャッターが自明のことを投稿するのを忘れたり、情報がメッセージの洪水に埋もれたりするため、よく「スコアはどうなってるの？」という質問が寄せられます。

これが現実世界でどう機能するかはわかりませんが、管理者が議論の「ペース」を設定できるようにテストするのは興味深いかもしれません。例えば、1 秒に 1 投稿というペースです。すべての投稿はキューに入れられますが、サイトには定義されたペースで公開されます。もしゴールによって 20 件の反応投稿が生まれても、それらがトピックに同時に表示されるのではなく、20 秒の時間枠にわたって表示されることになります。これにより、関連する情報を追いかけて捉えるのが容易になるでしょうか？

もちろん、新しいメッセージの発生ペースが公開ペースを常に上回ってしまう場合、他の問題を引き起こす可能性があります。キューの長さが次第に伸びてしまい、チャットが現実世界から遅れ始めてしまうのです。

このアイデアが伝わるかどうかわかりませんし、私自身もこのアイデアが優れているかどうか確信が持てません。結論として、リアルタイムチャットの UX は議論の面白いテーマであり、さらなる開発の可能性があります。Discourse の主な焦点がチャットプラットフォームを作ることではないことは理解しています——そのための他のソフトウェアは存在します。しかし、自然とチャットのような議論が生まれることは確かです。

「いいね！」 1
10

そのアイデアはいいですね。ただ、自分の投稿がすぐに反映されるように、何らかの「逆シャドウバン」的な仕組みが必要になるでしょう。そうしないと、自分が投稿したのに表示されないため、フォーラムが機能していないと誤解し、二重あるいは三重に投稿してしまう可能性があります。

「いいね！」 1
11

これをマージしました：

https://review.discourse.org/t/perf-backoff-background-requests-when-overloaded-10888/16227

これにより、1000 人がトピックを閲覧し投稿が行われている場合でも、サーバーがダウンすることがなくなります。

クライアントはこれらのケースでよりクリーンに動作するようになりました。

@ljpp さんの質問を想定して申し上げますと、バックポートについてはまだ迷っています。これは API の変更を伴うかなり大きな変更です。もしバックポートを行う場合、おそらく数週間後になるでしょう。私はこれを本番環境で負荷の下で観察する必要がありますが、ホスティングに余裕があるためこのようなイベントは非常に稀であり、捕捉するまでには時間がかかるでしょう。

「いいね！」 8
12

ジェダイのメンタルトリック :wink:

  • レートリミッターを無効化することが現実的な回避策かどうかを試してみます。
  • その場合：次の安定版リリースはそう遠くないと思われます。
  • そうでない場合は、ベータチャンネルを検討します。UI カスタマイズがアップデートによって壊れないか確認する必要があります。

エッジブランチ上で動作し、同様のチャット形式の議論を行っているコミュニティは他にいますか？

13

今年末にはリリースされる見込みです…つまり、ごく近い将来にリリースされるとは考えにくいです。ただし、今週中に新たなベータ版をリリースする予定です！

当社のすべてのホスティングはベータ版で動作していますが、容量は十分にありますのでご安心ください。

「いいね！」 2
14

これがなぜバックポート候補にならないのか、その理由を理解しています。ただ、当社のレートリミッターを無効にし、明日が次のゲームとなりますので、ベータ版への移行を望まないインスタンスにとって、これが現実的な回避策となるかどうか、おおよその見通しが立つでしょう。

今後数ヶ月間は、ベータブランチへのロールアウトを確実に検討しています。ただし、他の懸念事項もあります。@rizka 氏はフィンランド語の翻訳が遅れていると指摘しましたが、今週後半に作業を進められるかもしれません。

「いいね！」 1
16

@sam

残念ながら、レートリミッター を無効にしても全く効果がありませんでした。退屈なゲームで、83人のユーザーが投稿したメッセージは580件だけでした。ゲーム中に複数のフリーズが報告されました。
エッジリリースへのアップグレードを待つ間、試せる可能性のあるハックや回避策はありますか？

17

「フリーズ」はクライアント側のバグで、エラー条件に対して適切に反応しませんでした。レート制限エラーが1回でも発生すると、安定版では完全に機能しなくなります。

ベータ版への更新（明日新しいベータ版をリリース予定です）以外に回避策は思いつきません。

「いいね！」 1
18

開発志向のメンバーの一人が、以下の変数の調整を提案しました。どうお考えですか？これは有効な回避策になり得るでしょうか？

DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.2

19

以下のハックを試しました：

DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.2

これにより観測された遅延が大幅に減少しましたが、問題は解決しませんでした。ゲーム内の主要イベントが発生するタイミングで、CPU 負荷が上昇し、約 55% 付近で変動しました。

20

「フリーズ」対策として最近変更が行われ、サーバーが過負荷の場合、クライアントはバックオフして待機するようになりました。ただし、究極的な解決策は、より大きなサーバーを導入し、Unicorn ワーカーをさらに増やすことです。サーバー容量とワーカー数の推奨設定については、discourse-setup スクリプトをご覧ください。

「いいね！」 1
21

懐疑的ですが…高負荷の返信状況における問題は、新しいデザイン以前は、max_reqs_per_ip_per_10_seconds などの制限により、レート制限をトリガーするほどの洪水（flood）を発生させることが可能だったことです。このような負荷を処理するには膨大なリソースが必要になります。

考えてみてください。

  • 30 人のユーザーが 10 秒以内に返信を投稿する
  • 100 人がトピックを閲覧している
  • サーバーは、1 つのポストずつ要求するために 3000 件の GET リクエストを処理できる必要がある
  • これらのリクエストの いずれか が何らかの理由で失敗すると、UI がフリーズして壊れたように見える

新しいデザインはこの問題を非常にクリーンに解決します。負荷がかかると自動的にバックオフし、リクエストが溜まればバッチ処理され、UI はフリーズしません。

旧デザインが、100 人の同時ユーザーと 10 秒間に 30 件の返信という規模にスケールできるとは思えません。

一方、現在の改良されたデザインであれば、1000 人の同時ユーザーがトピックを閲覧し、10 秒間に 30 件の返信があっても問題なく動作するでしょう。

「いいね！」 5