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

サポート
44

@sam

これらの設定にすると UX が向上しました。はい、いくつかの「ボトルネック」が発生し、Chrome のインスペクターでは多数の 429 エラーが記録されました。CPU 負荷は低かったです。しかし、これは比較的静かなホームゲームでした（多くのアクティブなメンバーが会場にいて、チャットをしていませんでした）。

どのパラメータを調整すべきかは特定できませんが、私の主観的な経験から言うと：

  • コード機能はサーバー負荷に対してまだ過剰に保護的です。もう少し高いサーバー負荷レベルを許容できるかもしれません。
  • クライアントがバックオフする際、UX の観点から遅延が長すぎます。ゲームは進行しており、1 分の間に多くのことが起こり得ます。チャットが同期しなくなり、人々がゲームの異なる出来事を参照するようになります（これにより、リアルタイムとケーブルテレビ、IPTV、20 秒の Chromecast バッファなどの間の時間遅延の問題がさらに悪化します）。
  • ユーザーはチャットが停止していることしか認識できず、サイトがオンラインでアクティブであるという示唆を受け取りません。そのため、ページをリフレッシュしたり、他の操作を行ったりする可能性が高まり、それがさらに高負荷を招きます。
45

確認のため、サーバーを8 vCore、32GB RAMにアップグレードしました。データベースバッファを16GBに設定し、Unicornのプロセス数を16に増やしました。その他の調整はデフォルトに戻しています。

残念ながら、アップグレードによる効果はほとんどありませんでした。活動が平均的であっても、活発な議論が頻繁にフリーズしてしまいます。

現在のパフォーマンスはひどいものです。Prometheusなどの監視ツールを検討し始める必要があると思います。v2.3 以降、ソフトウェアのパフォーマンスが深刻に劣化していることは95%確信しています。

@Iceman 氏のコメントは9月にほとんど無視されましたが、彼はハードウェアをどんなに強化してもスローダウンが発生すると報告しています。

46

Redis がボトルネックになっている可能性がありますが、前述した通り、その統計データを収集しない限り確実なことは言えません。データがなければ、占星術を使うのと同じです。

もし私の推測が正しければ、低速なコアや RAM を増やしても問題が解決しない理由も説明がつきます。Redis はシングルスレッドであるため、スケーリングするには高性能なコアを取得するしかありません。

今月末には 2.6 の正式版に合わせて新しいイメージをリリースする予定です。これには Redis 6 と、その機能を最大限に活用するための新しい app.yml 変数が含まれています。もしそれよりも早くテストしたい場合はお知らせください。手順をご案内します。

47

閉じたトピックでこれに気づきました。@codinghorror - それは誤りです。高負荷状況で実際のエンドユーザーが経験するのは以下の通りです：

  1. ログアウトしたという通知が表示される
  2. サイトのインデックスページへ移動させられる
  3. インデックスページに高負荷を示すバナー通知が表示される

しかし、ユーザーは実際にはログアウトしていません。通常、アクティブなトピックに戻ると、サイトは通常通り動作します。

48

またしても、この挙動を報告するお客様は一人もおりません（何千人ものお客様がおり、その多くは貴社のサイトよりもはるかに繁忙です）。したがって、現時点でのさらなる議論は基本的に無意味です。貴社側でどのような奇妙な設定状況やハードウェアパフォーマンスの異常が発生しているのか、我々には把握できておりません。

将来的には状況が改善し、実際の問題についてより詳細な把握ができるようになることを願っております。

49

高負荷状況が発生した際の実際の UI/UX を報告しただけです。それ以外のことではありません。

50

その動作は、トピックページに留めてログアウト状態のビューを表示し、ホームページへ遷移させるべきではありません。

51

その通りでしょう。Redis が原因です。新しいベースイメージで状況は改善しましたが、今度はサーバーの容量を超えてしまっています。

おそらくそうなのでしょうが、実際にはそうは動作しません。さっきも再現しました。

52

まあ、少なくともその問題には既知の解決策があります：:moneybag:

53

解決策：コードをより軽快で鋭くすることです :wink:

では、Redisがボトルネックになっている場合、水平スケーリングをどのように行うのでしょうか？

先シーズンから何が変化したのか、まだ私には謎です。有機的な成長やゲームチャットの人気の増加はあまり見られません。それどころか、私たちのサービス提供能力は劇的に低下しており、最も静かなゲームであっても詰まっています。

54

以前の Discourse インスタンスで収集したメトリクスと、現在のインストールで収集するメトリクスを比較し、かつハードウェアを全く同じに保たない限り、この謎は解けないでしょう。

その違い全体は、VPS プロバイダーがあなたを別の物理マシンに移したためか、騒がしい近隣テナントができたためか、あるいは現在 1 台の機械あたり平均 17 個の共有ホストサービスが稼働しているのに対し、以前は 13 個だったためかもしれません。

55

VPS プロバイダー側に問題を押し付ける憶測は控えてください。UpCloud は市場でも最高水準のプロバイダーの一つであり、彼らも自社の側に異常がないか確認済みです。彼らは当サイトで広告を出稿しており、サイトが不調になるのはあまり良い PR ではありませんしね :smiley:

ただし、過去のデータはありませんし、正直なところ、8 月に最初のエキシビションマッチが開催されるまで、すべてが円滑に動いていたため、それほど注意を払っていませんでした。もちろん、COVID の影響で人間の行動パターンは変化しましたし、他にも何かあるかもしれません。しかし、当サイトのメトリクスやサーバーのメトリクスでは確認できません :man_shrugging:

とはいえ、これは優れたテスト材料です。サーバー過負荷が発生した際に何が起こるかについて、@riking にスクリーンショットを送りました。皆さんはそう頻繁には目にしないでしょう。

56

誰もあなたに反対しているわけではありません。インターネット上のビデオカメラを通じて患者を見ることしかできない医師は、診断においてできることに限界があることを指摘しているだけです。:movie_camera:

58

私が初めてサイトを立ち上げた際にも全く同じ現象が発生しました（貴サイト固有の問題ではないということです）。

当時作成したスレッドはこちらです：

これが、こちらで説明されている CPU/メモリオプションのアップグレードに踏み切るきっかけとなりました：

残念ながら、以前説明したように Digital Ocean から Hetzner への移行を適切に行う機会がまだありません（新しい仕事が始まったため）。しかし、今月中に機会があれば実行する予定です。

スレッドから強制退出されるか、スレッド内に留まる（ログアウトメッセージが表示される）というエンドユーザーの体験は、負荷に依存しているように見えました（ゴールが決まると、より多くのユーザーがサイトインデックスへ送られました）。

技術的な知識が不足しており、直接的な解決策は提示できませんが、チャットのようなピークを持つスポーツサイトでも同様の問題が発生しうるという知見が役立つかもしれません。私のサイト（より小規模で新しいサイト）では、サーバーのさらにアップグレードによって解決しました。

59

今後の問題診断に関する意思決定に役立つデータが欲しい場合は、Discourse 用の Prometheus エクスポートプラグインをインストールできます。

60

簡単な更新情報です：

  • 2 台の VPS サーバー（web_only、data）に新しい 2 コンテナ環境をインストールしました。
  • 意外なことに（私にとって）、web_only サーバーはリソースを消費していますが、data サーバーは比較的負荷が軽いです。どちらも UpCloud.com の 4x vCore 8GB RAM プランで動作しています。
  • web_only を UpCloud.com の 6x vCore / 16GB RAM プランにアップグレードしました。Unicorn の数を 18 に増やしました。

それでも、さまざまな 429 制限に直面しています。ただし、「高負荷時のシステム」モードは発動しませんでした。

61

ホッケーのシーズンがCOVIDによって台無しになり、現在は観客なしで数試合のランダムな試合が行われています。UpCloud.com にはホスティングクレジットがあるため、現有リソースを活用して体験を改善する取り組みを進めています。現在は web_only 用に 6x vCore 16GB、data 用に 4x vCore 8GB を運用しており、ユニコーンインスタンスは 18 番です。

再びレートリミッターを無効にしました…

DISCOURSE_MAX_REQS_PER_IP_MODE : none

…これで状況は改善していますが、POLL による 429 エラーはまだ発生しており、これがエンドユーザーにとって長い遅延やフリーズを引き起こしています。引き続き DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS を増やすことで調整を続けていきます。

その前に、@sam / スタッフに質問があります。

極度の負荷による読み取り専用モード のしきい値を上げる環境変数はありますか？あるいは完全に無効にすることは可能でしょうか？

62

これは不要であるはずです。あなたのトラフィックは非常に少ないにもかかわらず、なぜこの制限が頻繁に発動するのかを突き止めたいと考えています。そのため、ぜひ当方でホストさせていただきたいと考えています。

63

おそらくその通りかもしれませんが、自然発生的なアクティビティの急増は非常に短く、通常1分程度で安定するため、サーバーへの保護を少し緩めたいと考えています。そのため、しきい値を少しだけ引き上げることで、移行までの間のユーザー体験が向上する可能性があります。

64

ゲームの開催がCOVIDの影響で scarce（不足）していたため、これを測定したり微調整したりする機会は非常に限られていました。

わかったことは、ハードウェアリソースが向上した（6+4 vCores および 16+8GB RAM）にもかかわらず、わずかに活発な利用者でも 429 エラー（クライアントのフリーズ）を引き起こす可能性があるということです。これは、チャットのために通常のゲーム視聴者の約 50% を集めた U20 ワールドカップの試合で確認されました。

測定と試行錯誤の結果、以下の調整に落ち着きました。

  DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.4
  DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: 400
  DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: 100

これにより 429 エラーの 80% が解消され、大多数のユーザーにとって比較的スムーズな体験が可能になりました。

次のステップとしては、シングルスレッドの速度に特化した専用サーバーを利用するか、gazzillion vCores を提供する VPS プロバイダーに変更するなど、異なる種類のハードウェアリソースを導入することでした。しかし、私たちにとっては、@sam が以前示唆したように、Discourse ホスティングチームと連携することが次のステップとなります。

これらの調整が @iceman、@alec、あるいは他の誰かにも役立つことを願っています。CPU の使用率やキューイングには注意を払ってください。また、この経験から学んだことは、コンテナを 2 つ用意する方が 1 つよりも はるかに 優れているということです。調整をほぼダウンタイムなしで適用でき、ハードウェアリソースをより細かく活用できるからです。

リアルワールドのイベントに駆動されるテンポの速い議論のパフォーマンスや UX を向上させるための新しい調整や知見があれば、引き続き興味があります。