Technische Information zu Rate Limits

Welchen Nutzen bietet der Einsatz der Rate Limits bei myleo / dsc für unsere Kunden?

Rate Limits sind Sicherheitswerkzeuge, mit welchen wir eine hohe Plattformstabilität und geringe Latenz der Zugriffe für unsere Kunden gewährleisten.

Durch das Rate Limit wird ein konstanter Datenfluss für alle unsere Kunden bereitgestellt und dadurch ein reibungsloser und störungsfreier Parallelbetrieb ermöglicht.

Die Höhe dieses Limits ist für jede genutzten Schnittstelle individuell und wird definiert wie viel Datenvolumen jeder Kunde/IP an diese Schnittstelle übertragen darf. API Endpunkte die große Daten annehmen, lassen oft weniger Requests zu als Services mit einem kleinen Payload.


Was ist ein Rate Limit technisch?

Wird ein HTTP Request an die API von myleo gesendet, kann man den Antwortstatuscode „HTTP 429 Too Many Requests“ erhalten. Dies zeigt eine Durchsatzbegrenzung an. Von der IP des Benutzers wurden in einem bestimmten Zeitraum zu viele Requests gesendet.

Die IP des Kunden wird für diese Route für einen festen Zeitraum geblockt. Es werden keine neuen Requests zugelassen. Je nachdem welches Rate Limit getroffen wurde, kann dies aktuell bei myleo / dsc bis zu 24h andauern.


Wofür werden Rate Limits in myleo / dsc verwendet?

Die myleo / dsc hat Short-Term Rate Limits und Long-Term Rate Limits implementiert. Beide Rate Limittypen laufen parallel und beide Limittypen haben unterschiedliche Einstellungen.

Short-Term Rate Limits

Short-Term Rate Limits = Kurzzeit-Ratenbegrenzungen beziehen sich auf kurze Zeitintervalle, die sich in der Zeitspanne von einer Minute bis zu einigen Stunden erstrecken können. Sie zielen darauf ab, Requests innerhalb einer kurzen Zeitperiode zu regulieren, um sicherzustellen, dass Systemressourcen nicht überlastet werden.

Long-Term Rate Limits

Long-Term Rate Limits = Langzeit-Ratenbegrenzungen erstrecken sich über längere Zeiträume ab einem Tag bis zu mehreren Wochen. Sie sollen eine gleichmäßige Nutzung von Ressourcen sicherstellen und möglicherweise auch dazu beitragen, wirtschaftliche Ressourcen zu optimieren.


Welche Rate Limits gibt es in myleo / dsc?

myleo / dsc nutzt derzeit zwei verschiedene Technologien für die beiden oben genannten Rate Limittypen:

  • Cluster Rate Limits
  • Service Rate Limits

Die Cluster Rate Limits werden zur Implementierung der Short-Term Rate Limits genutzt.

Die Service Rate Limits werden für die Long-Term Rate Limits gebraucht.

myleo / dsc nutzt diese beiden gleichzeitig aktiven Implementierungen.


Cluster Rate Limits für Short-Term Regulierung

Es gibt drei Antwortheader, die eine Richtlinie für Cluster Rate Limits bieten:

AntwortheaderBeschreibung
X-Cluster-Ratelimit-Limitgibt das mit dem Client in diesem Zeitfenster verbundene Anforderungskontingent an, gefolgt von der Beschreibung der Kontingentrichtlinie. Aktuell wird hier nur eine Zahl angezeigt, welche das Kontingent pro 60 Sekunden beschreibt (siehe Screenshot = 120).
X-Cluster-Ratelimit-Remaininggibt die verbleibenden Requests im aktuellen Zeitfenster an (siehe Screenshot = 119).
X-Cluster-Ratelimit-Resetgibt die Anzahl der Sekunden bis zum Zurücksetzen des aktuellen Zeitfensters an (siehe Screenshot = 58).
Cluster Rate Limit Header im Antwort HTTP Header (beispielhafte Darstellung)

Cluster Rate Limit Header im Antwort HTTP Header (beispielhafte Darstellung)


Microservice Rate Limits für Long-Term Regulierung

Es gibt drei Antwortheader, die eine Richtlinie für die Service Rate Limits bieten:

AntwortheaderBeschreibung
X-Service-Ratelimit-Limitgibt das mit dem Client in diesem Zeitfenster verbundene Anforderungskontingent an, gefolgt von der Beschreibung der Kontingentrichtlinie. Aktuell wird hier nur eine Zahl angezeigt, welche das Kontingent pro 60s beschreibt (siehe Screenshot = 15000).
X-Service-Ratelimit-Remaininggibt die verbleibenden Requests im aktuellen Zeitfenster an (siehe Screenshot = 14998).
X-Service-Ratelimit-Resetgibt die Anzahl der Sekunden bis zum Zurücksetzen des aktuellen Zeitfensters an (siehe Screenshot = 85835).
Service Rate Limit Header im Antwort HTTP Header (beispielhafte Darstellung)

Service Rate Limit Header im Antwort HTTP Header (beispielhafte Darstellung)


Wie geht der Client mit einem Rate Limit um?

Ursachen für die Meldung HTTP 429 Too Many Requests

Die Meldung HTTP 429 Too Many Requests weist dich darauf hin, dass du dein zugewiesenes Rate Limit für die API erreicht hast. Das bedeutet, dass du in kurzer Zeit zu viele Requests übermittelt und die zulässige Anzahl an Requests
überschritten hast.

Dies kann verschiedene Gründe haben:

  • du verwendest eine Schleife, in welcher die Anforderungen gestellt werden

  • du verwendest ein Skript, welches häufige oder gleichzeitige Anforderungen stellt

  • du teilst Deinen API-Schlüssel mit anderen Benutzern oder Anwendungen

  • du nutzt ein internes Netzwerk, welches sich nach außen hin eine statische IP teilt

Behebungsoptionen für die Meldung HTTP 429 Too Many Requests

Subsequent, als Reaktion auf HTTP 429 Too Many Requests

Tritt dieser Fehler auf, so ist die aktuelle IP für die Anzahl der Sekunden in dem x-service/cluster-ratelimit-reset oder x-service/service-ratelimit-reset aufgeführt. In diesem Fall sollte in das Skript eine Wartezeit von den gerade genannten Sekunden eingebaut werden, der letzte Request muss wiederholt werden.

Diese Strategie empfiehlt sich vor allem wenn:

  • die Wartezeit in einem für den Client akzeptablen Rahmen liegt (z.B. beim Short-Term Rate Limit /x-service/cluster-ratelimit-reset)
  • HTTP 429 Too Many Requests Responses keine subsequente manuelle Arbeit erfordern
  • man eine möglichst einfach zu implementierende Technik benötigt
📘

Bitte beachte, dass nachdem das Limit getroffen wurde, in jedem Fall eine Wartezeit nötig ist. Sollte dies ein Problem darstellen wird eine Vermeidungsstrategie empfohlen.

Präzedent, Rate Limitierung vermeiden

Wird in der Route ein Rate Limit verwendet, so kannst du die in jeder Response mitgelieferten Informationen nutzen, um entsprechende Wartezeiten zwischen den Requests einzubauen.

Wenn du eine Schleife oder ein Skript verwendest, stelle sicher, dass du einen Backoff-Mechanismus implementierst, der das Rate Limit und die Antwortheader berücksichtigt.

Diese Strategie empfiehlt sich vor allem wenn:

  • Die 24h Wartezeit des das Log-Term-Limit (24) vermeiden möchtest
  • Eine möglichst Robuste Implementierung haben möchtest

Ausbaustufe:

Der Quotient aus dem max. Wert in -ratelimit-reset (in der Tabelle: 60s bzw. 86400s) und -ratelimit-limit (in der Tabelle: 120 bzw. 15000) ergibt die Zeit pro Request (in der Tabelle: 0,5s bzw. 5,76s), damit kein Limit erreicht wird.

BeispieleLimittyp
60s / 120 = 0,5sShort-Term Limit
86400s / 15000 = 5,76s24h Limit

Optimierung:

Einbau eines internen Threshold für den Backoff-Mechanismus. Nach Erreichen eines internen Grenzwertes des Wertes -ratelimit-remaining wird die Rechnung aus der Ausbaustufe mit dem aktuellen -ratelimit-remaining anstelle des Wertes -ratelimit-limit durchgeführt.