429 zu viele Anfragen

Hallo zusammen, ich weiß, dass es bereits Themen zu „zu viele Anfragen" gibt, aber dieses scheint nicht ganz ins Bild zu passen.

Ich bekomme intermittierende 429-Fehler in Discourse (und generell läuft alles ziemlich langsam) mit folgendem Stacktrace:

Error: Too Many Requests
    at s (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:9:9188)
    at a (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:9:9045)
    at o (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:9:8936)
    at Object.trigger (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:18:7223)
    at https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:18:9212
    at t.invoke (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:9729)
    at e.t.flush (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:8732)
    at e.t.flush (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:10782)
    at e.n._end (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:15440)
    at e.n.end (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:12110)

Es ist immer dieser .js-Link, ein ziemlich beeindruckender Block an JS-Code, der für mich wenig aussagt. Die Instanz, auf der Discourse läuft, scheint minimal belastet zu sein – 10 % CPU-Auslastung, alles andere wirkt ebenfalls völlig normal. Daher ist es für mich etwas verwirrend, dass ich trotzdem 429-Fehler bekomme.

Gibt es Einstellungen, die ich irgendwo hochsetzen kann, um das globale Rate Limiting zu ändern? Die Instanz scheint deutlich mehr Last bewältigen zu können, als Discourse annimmt, oder mir entgeht etwas Größeres, das durch ein Plugin oder einen Bug verursacht wird.

Danke!

Ist Ihre Website hinter einem Reverse-Proxy oder etwas anderem, das die echten eingehenden IP-Adressen verfälschen würde?

Nein, das glaube ich nicht (und die Logs erfassen normalerweise IP-Adressen), aber es liegt hinter einem ELB. Es korrelierte definitiv mit einem signifikanten Anstieg des Datenverkehrs (sieht irgendwie nach einem DDOS-Angriff oder ähnlichem aus)

Aber wenn mein Verständnis der Rate-Limitierung korrekt ist, hätte das nicht jeden Benutzer betreffen dürfen – nur den Benutzer, der versucht hat, eine Million Mal zuzugreifen, oder?

Ich werde dies bezüglich der Netzwerkarchitektur überprüfen. Danke!

Ich vermute, dass der nginx im Discourse-Container die ELB-IP für den Rate-Limiting-Bucket verwendet, anstatt die ursprüngliche Client-IP.

Das klingt durchaus möglich. Ich habe gerade überprüft, dass wir in AWS ein ELB-Setup haben, das nichts Besonderes aufweist – ist das Ergebnis einer Fehlkonfiguration meinerseits?

Ich bin mir nicht zu 100 % sicher, welche nächsten Schritte erforderlich wären. Wenn Sie mir die richtige Richtung weisen, kann ich wahrscheinlich mit meinem Ops-Team gemeinsam eine Lösung finden. Vielen Dank!