Limity zużycia w API PHP chronią dostępność usługi i kontrolują jej koszty, ale źle zaprojektowana polityka może zakłócić działanie prawidłowych integracji. Aby dobrać ją właściwie, nie wystarczy ustalić liczby żądań na minutę: trzeba określić, kto korzysta z API, jaką operację wykonuje, jaki zasób jest zagrożony i jak zachowuje się rzeczywisty ruch.
Skuteczny projekt łączy limity dopasowane do wzorca użycia, spójne liczniki działające między instancjami oraz odpowiedzi ułatwiające konsumentowi poradzenie sobie z odrzuceniem. Wymaga też obserwowania skutków reguł, zanim zostaną zaostrzone — szczególnie wtedy, gdy kilku klientów korzysta ze wspólnych danych uwierzytelniających lub zależy od wspólnych zasobów.
Odróżnij limit liczby żądań, limit łącznego zużycia i współbieżność
Te mechanizmy chronią przed różnymi problemami i nie można ich stosować zamiennie:
- Limit liczby żądań: ogranicza liczbę żądań akceptowanych w krótkim przedziale czasu. Pomaga opanować nagłe skoki ruchu lub długotrwały ruch przeciążający aplikację.
- Limit łącznego zużycia: ogranicza całkowite zużycie w dłuższym okresie, na przykład liczbę operacji dziennie lub w cyklu rozliczeniowym. Pozwala kontrolować zakontraktowane użycie lub skumulowane obciążenie kosztownymi operacjami.
- Współbieżność: ogranicza liczbę operacji wykonywanych w tym samym czasie. Przydaje się, gdy każda operacja może na długo zająć workery, połączenia lub inne zasoby.
Klient może przestrzegać limitu liczby żądań, a mimo to uruchomić wiele długotrwałych operacji jednocześnie. Może też wysyłać niewiele żądań, które zużywają znaczną część dziennego limitu. Dobierz mechanizm do ryzyka, które chcesz ograniczyć, a jeśli potrzebnych jest kilka mechanizmów, określ, jak ze sobą współdziałają i który jest stosowany jako pierwszy.
Zdecyduj, jaką tożsamość i zasób będziesz ograniczać
Klucz limitu powinien odpowiadać jednostce zużycia, która ma sens z punktu widzenia działania systemu. Zależnie od produktu może to być poświadczenie, użytkownik, organizacja, aplikacja kliencka, ścieżka lub ich kombinacja. Ograniczanie wyłącznie według adresu IP może niekorzystnie wpływać na użytkowników współdzielonych sieci i nie pozwala dobrze odróżniać uwierzytelnionych klientów. Adres IP może być dodatkowym sygnałem w przypadku ruchu anonimowego lub kontroli bezpieczeństwa.
W przypadku uwierzytelnionych klientów warto powiązać politykę ze stabilną tożsamością i zapewnić izolację między organizacjami. Wspólne dane uwierzytelniające używane przez kilka systemów mogą utrudniać ustalenie, kto generuje nagły skok ruchu. Jeśli to możliwe, używaj oddzielnych danych uwierzytelniających lub dodaj wymiary pozwalające przypisać zużycie do konkretnego klienta. Nie umieszczaj nieprzetworzonych sekretów w kluczach liczników ani w logach.
Nie wszystkie ścieżki mają taki sam koszt. Proste zapytanie i rozbudowany eksport nie powinny koniecznie zużywać tego samego budżetu. Możesz przypisać kosztownym operacjom wagi lub odrębne polityki, o ile kryterium jest zrozumiałe dla klientów i stosowane konsekwentnie. Uwzględnij też limity usługi: API może otrzymywać niewiele żądań, a mimo to przeciążać wspólną zależność, taką jak baza danych lub zewnętrzny dostawca.
Wybierz okna czasowe odzwierciedlające wzorzec użycia
Stałe okno jest łatwe do wyjaśnienia, ale może pozwolić na nagły wzrost ruchu pod koniec jednego przedziału, po którym następuje kolejny na początku następnego. Okno przesuwne ogranicza ten efekt, kosztem większego nakładu pracy na przechowywanie i obliczenia. Mechanizm tokenów pozwala na ograniczone skoki ruchu przy kontrolowanym średnim tempie; sprawdza się, gdy prawidłowy ruch napływa falami. Wybór zależy od wzorca użycia i wymaganej dokładności.
Nie utożsamiaj uzasadnionego szczytu aktywności z nadużyciem. Zaplanowane zadania, synchronizacje rozpoczynające się na początku dnia lub ponowienia prób po przerwie mogą skupiać żądania w krótkim czasie. Jeśli produkt dopuszcza skoki ruchu, określ ich rozmiar i czas potrzebny na odnowienie dostępnego budżetu. W przypadku długotrwałych operacji ogranicz również współbieżność lub zastosuj kontrolę dopuszczania, zanim zostaną zajęte ograniczone zasoby.
Znaczenie mają również ponowienia prób po stronie klienta. Jeśli tymczasowa odpowiedź powoduje natychmiastowe ponowienia, limit może nasilić skok ruchu. Zalecaj stopniowe zwiększanie odstępów między ponowieniami, najlepiej z losowym rozrzutem, i określ, czy powtórzone operacje z tym samym kluczem idempotencji są liczone jako nowe żądania, czy jako bezpieczne ponowienie tej samej operacji.
Koordynuj liczniki, gdy PHP działa w wielu instancjach
Licznik przechowywany wyłącznie w pamięci procesu może działać w jednej instancji, ale traci spójność, gdy ruch jest rozdzielany między wiele instancji. Każdy serwer może zaakceptować część limitu, przez co łączne użycie go przekroczy. W środowiskach z wieloma instancjami stan należy koordynować za pomocą współdzielonego magazynu lub równoważnego mechanizmu z odpowiednimi operacjami atomowymi.
Zaprojektuj również zachowanie na wypadek awarii systemu liczników. Jeśli przestanie on być dostępny, odrzucenie wszystkich żądań może przerwać działanie prawidłowych klientów, a akceptowanie wszystkich może narazić krytyczną zależność na przeciążenie. Decyzja zależy od ryzyka związanego ze ścieżką: inne zachowanie w przypadku zapytania o niewielkim wpływie może być uzasadnione niż w przypadku operacji generującej wysokie koszty. Udokumentuj kryterium i informuj o degradacji.
Unikaj zbyt ogólnych kluczy liczników, które łączą organizacje lub ścieżki, oraz nadmiernie rozdrobnionych kluczy, które utrudniają kontrolowanie łącznego zużycia. Określ czas wygaśnięcia i czyszczenie stanu, aby tymczasowe klucze nie gromadziły się bez końca. Sprawdź, czy zmiany konfiguracji nie resetują ani nie dublują liczników w nieoczekiwany sposób.
Traktuj informowanie o odrzuceniu jako część kontraktu API
Po osiągnięciu limitu zwróć status HTTP zgodny z kontraktem API — zwykle 429 Too Many Requests w przypadku ograniczenia liczby żądań — oraz ustrukturyzowaną treść odpowiedzi wskazującą rodzaj limitu, bez ujawniania informacji wewnętrznych. Jeśli żądanie jest odrzucane z innego powodu, nie używaj tego statusu w sposób wprowadzający w błąd.
Podaj przydatne wskazówki, które pomogą konsumentowi poradzić sobie z odrzuceniem, takie jak szacowany moment, od którego można ponowić próbę, lub informacje o limicie i zużyciu określone w kontrakcie. Jeśli wysyłasz Retry-After, upewnij się, że wskazuje prawidłowy czas oczekiwania. Zachowaj spójność odpowiedzi między ścieżkami i nie ujawniaj liczników innych klientów. Klienci powinni móc odróżnić tymczasowe odrzucenie od błędów uwierzytelniania, walidacji lub dostępności.
Obserwuj wpływ i wprowadzaj zmiany na podstawie danych
Rejestruj zaakceptowane i odrzucone żądania, tożsamość lub segment klienta w bezpieczny sposób, ścieżkę, zastosowaną politykę i przyczynę. Mierz również opóźnienia, współbieżność oraz obciążenie istotnych zależności. Nie zapisuj danych uwierzytelniających ani zbędnych danych osobowych; gdy wystarczą do analizy, używaj chronionych lub zagregowanych identyfikatorów.
Sam wzrost liczby odrzuceń nie dowodzi, że próg jest zbyt restrykcyjny. Szukaj wzorców: dotkniętych klientów, godzin, ścieżek, czasu trwania operacji i późniejszych ponowień. Sprawdzaj sygnały fałszywych alarmów, takie jak odrzucenia skupione w organizacjach korzystających ze wspólnych danych uwierzytelniających lub w zadaniach zaplanowanych. Zmieniaj jedną wartość naraz i zachowaj możliwość wycofania zmiany.
Wprowadzaj politykę stopniowo
Przed rozpoczęciem egzekwowania limitu oceń politykę na podstawie danych o użyciu i przetestuj reprezentatywne scenariusze. Jeśli pozwala na to architektura, rejestruj żądania, które zostałyby odrzucone, nie blokując ich. Taka obserwacja nie zastępuje testów obciążeniowych ani nie gwarantuje, że dane historyczne pozwolą przewidzieć wszystkie szczyty ruchu.
- Określ ryzyko, które chcesz kontrolować, oraz to, czy właściwy będzie limit liczby żądań, limit łącznego zużycia, współbieżność czy ich kombinacja.
- Przypisz limity do tożsamości i zasobu, a następnie zweryfikuj izolację między użytkownikami i organizacjami.
- Przetestuj skoki ruchu, powolne operacje, ponowienia prób, współdzielone dane uwierzytelniające i awarie magazynu liczników.
- Sprawdź, czy wiele instancji stosuje limit w skoordynowany sposób i czy stan tymczasowy jest czyszczony.
- Zweryfikuj odpowiedź o odrzuceniu, wskazówki dotyczące ponowienia i zgodność z obecnymi klientami.
- Monitoruj odrzucenia, opóźnienia i zależności; informuj o zmianach, które mogą wpłynąć na integracje.
Limity zużycia w API PHP powinny chronić zarówno platformę, jak i ciągłość działania klientów. Najlepsza polityka nie jest najbardziej restrykcyjna, lecz taka, która ogranicza ryzyko za pomocą reguł pozwalających przypisać zużycie do konkretnego klienta, przewidywalnych odpowiedzi i wystarczających danych do korygowania niepożądanych skutków.
