Was ist eine Ratenbegrenzung?

Unternehmen verwenden Ratenbegrenzungen, um die faire Nutzung ihrer API-basierten Services und anderer Webservices und Ressourcen durch Kunden sicherzustellen. Sie regeln, wie oft ein Benutzer einen bestimmten API-basierten Service in einem bestimmten Zeitraum anfordern kann.

Wenn Tausende von Benutzern gemeinsam einen Service nutzen, trägt die Ratenbegrenzung dazu bei, dass das System für alle Benutzer verfügbar ist. Die Ratenbegrenzung schützt ein System auch vor Denial-of-Service-Angriffen (DoS). Bei einem DoS-Angriff kann ein böswilliger Benutzer in kurzer Zeit eine große Anzahl von Serviceanfragen initiieren, die zur Erschöpfung der Ressourcen führen. Das bedeutet, dass das System für legitime Benutzer nicht verfügbar ist. In einigen Fällen kann ein Webservice eine API oder eine andere Ressource aufgrund eines Fehlers auf der Client- oder Benutzerseite zahlreiche Anfragen erhalten. Die Ratenbegrenzung ist ein praktischer Ansatz, den Unternehmen anwenden, um solche Szenarien zu vermeiden.

Beschränkungen für Social-Media-Messaging sind ein typisches Beispiel für Ratenbegrenzungen, auf die die meisten Internetnutzer stoßen. Social-Media-Websites wie Facebook, LinkedIn oder Instagram begrenzen häufig die Anzahl der Direktnachrichten, die Benutzer an einem Tag senden können. Wenn ein Benutzer beispielsweise beschließt, eine Nachricht an Tausende von Kontakten weiterzuleiten, wird die Ratenbegrenzungslogik des Social-Media-Services aktiviert. Die Begrenzung kann den Benutzer für einen bestimmten Zeitraum daran hindern, weitere Nachrichten zu senden.

Warum benötigen Unternehmen eine Ratenbegrenzung?

Im digitalen Zeitalter bieten Unternehmen den größten Teil ihrer Services über APIs an. Diese API-basierten Services ermöglichen Unternehmen eine hervorragende Kontrolle über ihre Systeme. Das Hosten dieser APIs und der Backend-Datenbank belastet jedoch ihre Ressourcen. Unternehmen setzen Ratenbegrenzungen daher ein, um eine faire Nutzung ihrer APIs sicherzustellen und zu verhindern, dass einige Benutzer ihre Ressourcen verbrauchen. Wenn eine API populär wird, steigt die Anzahl der Benutzer schnell an. In solchen Szenarien müssen Unternehmen sicherstellen, dass alle Services verfügbar und nicht überlastet sind. Die Ratenbegrenzung hilft Unternehmen auch dabei, ihre Services zu sichern, zu managen und zu monetarisieren.

Welche sind die wichtigsten Arten der Ratenbegrenzung?

Es gibt mehrere Haupttypen von Ratenbegrenzungsmodellen, aus denen ein Unternehmen das am besten für seine Zwecke geeignete basierend auf der Art der von ihm angebotenen Webdienste auswählen kann, wie wir im Folgenden noch näher ausführen.

Ratenbegrenzung auf Benutzerebene

In Fällen, in denen ein System einen Benutzer eindeutig identifizieren kann, kann es die Anzahl der API-Anforderungen begrenzen, die ein Benutzer in einem bestimmten Zeitraum stellt. Wenn der Benutzer beispielsweise nur zwei Anfragen pro Sekunde stellen darf, lehnt das System die dritte Anfrage des Benutzers ab, die in derselben Sekunde gestellt wurde. Die Ratenbegrenzung auf Benutzerebene gewährleistet eine faire Nutzung. Die Pflege der Nutzungsstatistiken der einzelnen Benutzer kann jedoch zu einem Aufwand für das System führen, der, wenn er nicht aus anderen Gründen benötigt wird, die Ressourcen belasten kann.

Ratenbegrenzung auf Serverebene

Die meisten API-basierten Services sind verteilt. Das heißt, wenn ein Benutzer eine Anfrage sendet, kann sie von einem der vielen Server bearbeitet werden. In verteilten Systemen kann die Ratenbegrenzung für die Lastverteilung zwischen Servern verwendet werden. Wenn beispielsweise ein Server einen großen Teil der Anforderungen von zehn Servern in einem verteilten System erhält und andere größtenteils inaktiv sind, wird das System nicht vollständig genutzt. Die Anzahl der Serviceanfragen, die ein bestimmter Server bei der Ratenbegrenzung auf Serverebene verarbeiten kann, ist begrenzt. Wenn ein Server Anforderungen erhält, die diese festgelegte Begrenzung überschreiten, werden sie entweder verworfen oder an einen anderen Server weitergeleitet. Die Ratenbegrenzung auf Serverebene stellt die Verfügbarkeit des Systems sicher und verhindert DoS-Angriffe auf einen bestimmten Server.

Geografische Ratenbegrenzung

Die meisten API-basierten Services arbeiten mit Servern auf der ganzen Welt. Wenn ein Benutzer eine API-Anforderung ausgibt, wird sie von einem Server in der Nähe des geografischen Standorts des Benutzers erfüllt. Unternehmen implementieren geografische Ratenbegrenzungen, um die Anzahl der Serviceanfragen aus einem bestimmten geografischen Gebiet zu beschränken. Dies kann auch zeitbasiert erfolgen. Wenn beispielsweise die Anzahl der Anfragen, die von einem bestimmten geografischen Standort kommen, von 01:00 Uhr morgens bis 06:00 Uhr morgens gering ist, kann ein Webserver eine Ratenbegrenzungsregel für diesen spezifischen Zeitraum haben. Wenn während dieses Zeitraums ein Angriff auf den Server stattfindet, steigt die Anzahl der Anfragen. Im Falle eines Anstiegs löst der Ratenbegrenzungsmechanismus eine Warnung aus, und das Unternehmen kann schnell auf einen solchen Angriff reagieren.

Welche Algorithmen werden zur Ratenbegrenzung verwendet?

Feste Fensterratenbegrenzung

Feste Fensterratenbegrenzung beschränkt die Anzahl der API-Anforderungen zu einem bestimmten Zeitpunkt. Ein Server kann beispielsweise eine ratenbegrenzende Komponente haben, die einen Fixed-Window-Algorithmus implementiert, der nur 100 Anforderungen pro Minute akzeptiert. Der Zeitrahmen ist festgelegt und beginnt an einem bestimmten Zeitpunkt. Der Server bearbeitet beispielsweise lediglich 100 Anfragen zwischen 10:00 Uhr und 10:01 Uhr. Um 10:01 Uhr wird das Fenster zurückgesetzt. Fixed-Windows-Algorithmen können auf Benutzer- oder Server-Ebene implementiert werden. Wenn sie auf Benutzerebene implementiert sind, kann jeder Benutzer 100 Anfragen pro Minute stellen. Wenn es sich um eine Implementierung auf Serverebene handelt, können alle Benutzer gemeinsam 100 Anfragen pro Minute stellen.

Das folgende Diagramm zeigt den Workflow des Fixed-Window-Algorithmus mit Ratenbegrenzung auf Benutzerebene. In diesem Workflow wird einem Benutzer ein Schlüssel zur eindeutigen Identifizierung zugewiesen, und jedem einzelnen Benutzer wird ein Zähler zugeordnet, wenn der Benutzer innerhalb eines Zeitraums eine Anfrage stellt, die den Zähler erhöht.

Vor- und Nachteile des Fixed-Window-Algorithmus

Der Fixed-Window-Algorithmus ist leicht zu implementieren, da er auf einem festen Zeitraum basiert. Da die Anzahl der Anfragen zu Beginn des jeweiligen Zeitraums erneuert wird, führt der Fixed-Window-Algorithmus nicht dazu, dass keine neueren Anfragen mehr kommen. Ein Nachteil eines Fixed-Window-Algorithmus besteht dagegen darin, dass er zu einem Ansturm von Anfragen führt, insbesondere zu Beginn des Zeitfensters. Wenn ein Server beispielsweise 1000 Anforderungen pro Sekunde zulässt, können all diese 1000 Anfragen gleichzeitig erfolgen und den Server möglicherweise überlasten. Dieses Problem kann auftreten, weil die minimale Zeitspanne zwischen den zwei Anforderungen nicht beschränkt wird.

Leaky-Bucket-Ratenbegrenzung

Im Gegensatz zum Fixed-Window-Algorithmus ist der Leaky-Bucket-Algorithmus nicht auf Zeitfenster angewiesen. Stattdessen gibt es eine Warteschlange mit fester Länge, die nicht von der Zeit abhängt. Der Webserver bearbeitet die Anfrage nach dem Prinzip „Wer zuerst kommt, mahlt zuerst“. Jede neue Anfrage wird am Ende der Warteschlange hinzugefügt. Wenn die Warteschlange voll ist, wenn eine neue Anfrage eintrifft, verwirft der Server die Anfrage.

Vor- und Nachteile des Leaky Bucket-Algorithmus

Ein großer Vorteil des Leaky-Bucket-Algorithmus besteht darin, dass er leicht zu implementieren ist, da er auf einer Warteschlange basiert. Außerdem werden dem Server API-Anforderungen mit einer konstanten Rate angezeigt. Im Gegensatz zum Fixed-Window-Algorithmus wird die Anzahl der Anforderungen zu einem bestimmten Zeitpunkt nicht erhöht. Da der Leaky-Bucket-Algorithmus jedoch auf einer statischen Warteschlange basiert, besteht die Möglichkeit, dass keine Anfragen mehr angenommen werden, was bedeutet, dass die neueren Anfragen möglicherweise überhaupt nicht bearbeitet werden. Dieses Problem tritt in einem festen Fenster nicht auf, da das Zeitfenster regelmäßig aktualisiert wird, um neue Anfragen anzunehmen.

Sliding-Window-Algorithmus zur Ratenbegrenzung

Der Sliding-Window-Algorithmus ist dem Fixed-Window-Algorithmus ähnlich, der Unterschied liegt im Beginn des Zeitfensters. Im Sliding-Window-Algorithmus beginnt das Zeitfenster nur, wenn eine neue Anfrage gestellt wird. Wenn die erste Anfrage beispielsweise um 10:02 Uhr gestellt wird und der Server zwei Anfragen pro Minute zulässt, beginnt der Zeitrahmen um 10:02 und endet um 10:03 Uhr.

Der Sliding-Window-Algorithmus löst effektiv die Probleme, die beim Fixed-Window-Algorithmus durch die Häufung von Anfragen entstehen. Er löst auch das Problem des „Aushungerns“, mit dem Leaky-Bucket-Algorithmen zu kämpfen haben.

Was sind die Hauptanwendungen der Ratenbegrenzung?

Das Hauptziel der Ratenbegrenzung ist die Gewährleistung einer fairen Nutzung der gemeinsam genutzten Ressourcen. Darüber hinaus ist die Ratenbegrenzung eine vielseitige Technik, die Unternehmen aus einer Vielzahl von Gründen anwenden können.

Die Ratenbegrenzung bietet zusätzliche Sicherheit

Die Ratenbegrenzung verhindert Denial-of Service- oder DoS-Angriffe. Bei einem DoS-Angriff leitet ein böswilliger Benutzer eine große Anzahl von Serviceanfragen ein, um das System zum Absturz zu bringen. Wenn beispielsweise ein Konzertveranstalter und eine Website für den Ticketverkauf innerhalb einer Sekunde eine Million Anfragen erhält, sobald ein Konzert in den Verkauf geht, wird das System überlastet, der Webserver und die Datenbank sind möglicherweise nicht mehr verfügbar. Mit der Ratenbegrenzung kann die Website solche Versuche verhindern. Ein Denial-of-Service-Angriff kann sogar eintreten, wenn der Kunde keine schlechte Absicht hat. Er passiert, wenn im System ein Fehler auftritt, der die Anforderung ausgibt (clientseitig). Die Ratenbegrenzung verhindert auch solche unbeabsichtigten Angriffe.

Zugriffskontrolle

Die Ratenbegrenzung befasst sich nicht nur mit der Begrenzung der Anzahl der Anfragen, sondern kann auch geändert werden, um die Zugriffsstufe zu begrenzen. Wenn es beispielsweise einen API-basierten Service gibt, um die persönlichen Daten eines Benutzers anzuzeigen und zu ändern, kann der Ratenbegrenzungsalgorithmus verschiedene Zugriffsstufen implementieren. Eine Gruppe von Benutzern kann nur die persönlichen Daten anzeigen, während die zweite Gruppe die Daten sowohl anzeigen als auch ändern kann.

Messung für APIs

In API-Geschäftsmodellen kann die Ratenbegrenzung zur Messung der Nutzung verwendet werden. Wenn sich ein Benutzer beispielsweise für einen Plan angemeldet hat, der 1000 API-Anforderungen pro Stunde zulässt, schränkt die Ratenbegrenzungslogik alle API-Anforderungen über der Obergrenze ein. Der Ratenbegrenzungsalgorithmus kann es dem Benutzer außerdem dynamisch ermöglichen, mehr Anfragen pro Sekunde zu kaufen.

Garantierte Leistung

Ein Hauptziel der Implementierung einer Logik zur Ratenbegrenzung ist die Sicherstellung der Leistung einer API. Wenn das System unbegrenzte Anforderungen zulässt, verschlechtert sich die Leistung des Servers und verlangsamt die API. In extremen Fällen nimmt der Server möglicherweise keine Anfragen entgegen. Dies kann in einem verteilten System zu kaskadenartigen Ausfällen führen, bei denen die Last des nicht funktionierenden Servers auf die anderen Server verteilt wird und diese allmählich überlastet. Die Ratenbegrenzung verhindert diese Zustand, indem sie entweder die Anforderungen auf Benutzer- oder Server-Ebene beschränkt.

Sorgt für Verfügbarkeit

Eine der Hauptanforderungen von API-basierten Services ist ihre Verfügbarkeit rund um die Uhr. Jede Sekunde greifen Tausende von Benutzern auf eine API zu. Selbst ein Ausfall von wenigen Sekunden kann zu einem enormen Verlust für das Unternehmen führen. Daher ist es im besten Interesse jedes Unternehmens, Ausfallzeiten zu verhindern. Die Ratenbegrenzung und andere Techniken wie Lastverteilung ermöglichen es Unternehmen, plötzliche starke Anstiege in API-Anfragen zu beschränken und die Verfügbarkeit des Systems sicherzustellen.

Client- und serverseitige Ratenbegrenzung

Serverseitige Ratenbegrenzung

Die Beschränkung von serverseitigen Benutzeranfragen ist eine weit verbreitete Methode zur Ratenbegrenzung. Es liegt im Interesse des Serviceproviders, unbegrenzte Benutzeranfragen einzuschränken, um Leistung und Verfügbarkeit sicherzustellen. Wie oben beschrieben, verwenden Unternehmen die serverseitige Ratenbegrenzung für eine Vielzahl von Zwecken.

Clientseitige Ratenbegrenzung

Es scheint, dass die Ratenbegrenzung ausschließlich im Interesse der API-Anbieter liegt. In der Praxis könnten die Nutzer oder der Kunde des Dienstes auch von einer Tarifbegrenzung profitieren. Kunden, die Nutzungsbeschränkungen einhalten, können immer sicher sein, dass der Serviceprovider ihre Anfragen erfüllt. Wenn der Benutzer die Ratenbegrenzung nicht berücksichtigt, muss er möglicherweise mit einer plötzlichen oder unerwarteten Ablehnung seiner Anfragen rechnen, die sich auf die Funktionalität seiner Lösungen auswirken kann.

Beispielsweise könnte eine mobile Anwendung auf der Facebook-Messaging-API aufbauen. Wenn diese Anwendung verwendet wird, verwenden die Benutzer tatsächlich Facebook-Messaging im Hintergrund. In diesem Fall muss der Kunde Maßnahmen ergreifen, um sicherzustellen, dass die Anwendung den Ratenbegrenzungsnormen entspricht. Wenn die Ratenbegrenzung clientseitig übersehen wird, können Benutzer dieser mobilen Anwendung mit unerwarteten Fehlern konfrontiert werden. Es liegt im besten Interesse der API-Benutzer, die Ratenbegrenzung clientseitig durchzusetzen.

Was sind die Herausforderungen bei der Umsetzung der Ratenbegrenzung?

Verteilte Systeme

Die Implementierung einer Logik zur Ratenbegrenzung in einem System mit verteilten Servern ist eine Herausforderung. Wenn ein Benutzer einen API-basierten Dienst von einem verteilten System anfordert, sollte die Ratenbegrenzungskomponente in jedem der Server miteinander synchronisiert werden. Angenommen, ein Benutzer hat bereits vier von einem Kontingent von fünf Anfragen pro Minute verbraucht und stellt zwei weitere Anfragen. In diesem Fall würden diese beiden Anfragen an zwei verschiedene Server weitergeleitet. Jeder einzelner Server ruft die Anzahl der Anfragen des Benutzers auf und glaubt, dass der Benutzer nur vier Anfragen gestellt hat. Dann gestatten beide Server die Serviceanfrage. Anstelle der ursprünglichen fünf Anfragen pro Minute erhält der Benutzer sechs Anfragen pro Minute. Bei der Implementierung von Ratenbegrenzungen in verteilten Systemen können viele solcher Synchronisationsprobleme und Wettlaufbedingungen auftreten.

Es gibt mehrere Lösungen für die Ratenbegrenzungsinkonsistenzen in verteilten Systemen. Server, die Softwaresperren verwenden, um den Zähler für Benutzeranfragen zu sichern, sind eine Lösung. Bei dieser Methode greift nur ein Server auf den Zähler zu, der die Anzahl der in einem Zeitfenster gestellten Anfragen speichert. Eine weitere einfache, aber weniger elegante Lösung sind Sticky Sessions, bei denen die Anfragen eines Benutzers von einem Server verarbeitet werden. Dies scheitert jedoch an der Idee verteilter Systeme.

Rechenaufwand

Das Hinzufügen einer zusätzlichen Logikebene zur Ratenbegrenzung erhöht den Rechenaufwand eines Servers. Wenn das System bereits überlastet ist, würde das Hinzufügen der Ratenbegrenzungslogik das System weiter verlangsamen und es kann zu Verzögerungen bei den Benutzern kommen.

Anstatt die Ratenbegrenzungslogik innerhalb desselben Servers zu implementieren, könnte sie als externe Komponente integriert werden. Wenn ein Benutzer eine API anfordert, wird die Anforderung zunächst durch diese externe Komponente geleitet, die entscheidet, ob die Anforderung zugelassen oder abgelehnt wird.

Ausfall von Komponenten zur Ratenbegrenzung

Das Hinzufügen einer zusätzlichen Komplexitätsebene für die Ratenbegrenzung erhöht die Wahrscheinlichkeit eines Ausfalls. Selbst wenn die API betriebsbereit ist, führt ein Fehler in der ratenbegrenzenden Komponente zur Ablehnung von Anfragen.

Eine gute Implementierung zur Ratenbegrenzung sollte in der Lage sein, sich schnell von Ausfällen zu erholen. Das kann in Form von kalten Neustarts erfolgen, wenn Ausfälle auftreten. Genau wie bei den Backup-Servern in API-basierten Diensten kann es auch eine zweite ratenbegrenzende Komponente geben, die diese Rolle übernehmen kann, wenn die ursprüngliche Komponente ausfällt.