AWS Solutions Architect · Lekcja

Ograniczanie, buforowanie i plany użycia

Zabezpieczą backendy limitami ograniczania ruchu dla skoków i stanu ustalonego, włączą buforowanie odpowiedzi oraz utworzą plany użycia z kluczami API dla partnerów.

Ograniczanie, buforowanie i plany użycia to bezpłatna lekcja AWS Solutions Architect na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AWS Solutions Architect, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.

Dlaczego ograniczanie przepustowości jest niezbędne

Bez ograniczania przepustowości pojedynczy wadliwie działający klient lub nagły wzrost ruchu może przeciążyć usługi backendowe — współbieżność Lambda, połączenia RDS lub interfejsy API usług zależnych. Ograniczanie przepustowości w API Gateway limituje liczbę żądań na sekundę i pozwala na krótkotrwałe skoki powyżej stałej wartości. Żądania przekraczające limit natychmiast otrzymują odpowiedź 429 Too Many Requests, bez dotarcia do backendu, co chroni zasoby zależne przed przeciążeniem.

Ograniczanie przepustowości na poziomie konta i etapu

Ograniczanie przepustowości działa na wielu poziomach. Limit na poziomie konta wynosi 10 000 żądań na sekundę (RPS), z możliwością nagłego wzrostu o 5000 żądań (jest to limit miękki, który można zwiększyć). Na poziomie etapu można ustawić domyślną szybkość ograniczania (RPS) i limit nagłego wzrostu obowiązujące dla wszystkich metod w danym etapie. Na poziomie metody można zastąpić ustawienia etapu dla konkretnych endpointów — na przykład przyznać endpointowi GET obsługującemu głównie odczyt wyższy limit niż endpointowi POST obsługującemu głównie zapis.

aws apigateway update-stage \
  --rest-api-id 'abc123' \
  --stage-name 'prod' \
  --patch-operations \
    'op=replace,path=/*/*/throttling/rateLimit,value=1000' \
    'op=replace,path=/*/*/throttling/burstLimit,value=2000'

Algorytm wiadra tokenów

Ograniczanie przepustowości w API Gateway korzysta z algorytmu wiadra tokenów. Tokeny gromadzą się w wiadrze do wysokości limitu nagłego wzrostu (maksymalnej chwilowej pojemności). Każde żądanie zużywa jeden token. Tokeny są uzupełniane z szybkością określoną przez limit szybkości (stałą liczbę RPS). Gdy wiadro jest puste, żądania są ograniczane. Przykład: burst=5000, rate=1000 RPS. Na początku można obsłużyć 5000 jednoczesnych żądań, a wiadro jest uzupełniane w tempie 1000 tokenów na sekundę. Pozwala to absorbować krótkotrwałe skoki ruchu przy jednoczesnym egzekwowaniu długoterminowych limitów szybkości.

Buforowanie odpowiedzi API Gateway

Buforowanie odpowiedzi (dostępne na etapach REST API) przechowuje odpowiedzi backendu w pamięci podręcznej zarządzanej przez API Gateway, dzięki czemu identyczne żądania są obsługiwane z pamięci podręcznej bez wywoływania backendu. Zmniejsza to obciążenie backendu, skraca opóźnienia i może znacząco ograniczyć koszty wywołań Lambda w interfejsach API obsługujących głównie odczyt. Klucz pamięci podręcznej jest tworzony na podstawie żądania (metody, ścieżki, ciągów zapytania i nagłówków, zgodnie z konfiguracją). TTL pamięci podręcznej można skonfigurować w zakresie od 0 do 3600 sekund (domyślnie 300 sekund).

aws apigateway update-stage \
  --rest-api-id 'abc123' \
  --stage-name 'prod' \
  --patch-operations \
    'op=replace,path=/cacheClusterEnabled,value=true' \
    'op=replace,path=/cacheClusterSize,value=0.5' \
    'op=replace,path=/*/*/caching/ttlInSeconds,value=300'

Dostosowywanie klucza pamięci podręcznej

Domyślnie kluczem pamięci podręcznej jest pełny adres URL żądania. Mogą Państwo dostosować elementy uwzględniane w kluczu pamięci podręcznej: uwzględnić konkretne parametry zapytania (np. pageSize, filter), a wykluczyć te nieistotne (np. znacznik czasu). Mogą Państwo również uwzględnić w kluczu pamięci podręcznej konkretne nagłówki. Należy wykluczyć z niego nagłówki zawierające dane wrażliwe, aby zapobiec zanieczyszczaniu współdzielonych wpisów pamięci podręcznej prywatnymi danymi. Strojenie klucza pamięci podręcznej pozwala maksymalizować współczynnik trafień, a jednocześnie zapewniać, że różne logiczne żądania otrzymają różne buforowane odpowiedzi.

Unieważnianie pamięci podręcznej

Klienci mogą unieważnić pamięć podręczną dla konkretnego żądania, dołączając nagłówek Cache-Control: max-age=0. Mogą Państwo również opróżnić całą pamięć podręczną etapu z poziomu konsoli lub interfejsu API. Należy skonfigurować, czy klienci mogą unieważniać pamięć podręczną — w środowisku produkcyjnym warto to ograniczyć, aby uniemożliwić klientom celowe omijanie buforowania. Aby selektywnie przyznawać uprawnienia do opróżniania pamięci podręcznej, należy dołączyć politykę zasobów lub użyć autoryzatora Lambda, który sprawdza, czy wywołujący ma uprawnienia do wykonania tej operacji.

# Flush entire stage cache
aws apigateway flush-stage-cache \
  --rest-api-id 'abc123' \
  --stage-name 'prod'

Plany użycia: limity szybkości dla klientów

Usage Plan definiuje limity ograniczania szybkości i limity kwot dla grupy klientów interfejsu API. Należy powiązać etap API z planem użycia, a następnie powiązać z tym planem API keys. Każdy klucz API niezależnie egzekwuje limity planu. Plany użycia umożliwiają oferowanie dostępu w różnych poziomach: plan Free z limitem 100 RPM/10 000 żądań dziennie oraz plan Pro z limitem 1000 RPM/100 000 żądań dziennie. Jest to model stosowany w płatnych interfejsach API i integracjach partnerskich, w których różni klienci potrzebują różnych limitów szybkości.

# Create a usage plan
aws apigateway create-usage-plan \
  --name 'ProTier' \
  --throttle 'rateLimit=1000,burstLimit=2000' \
  --quota 'limit=100000,period=DAY' \
  --api-stages 'apiId=abc123,stage=prod'

Klucze API i identyfikacja klienta

API keys to nieprzejrzyste tokeny tekstowe, które klienci umieszczają w nagłówku żądania x-api-key. API Gateway weryfikuje klucz i przypisuje żądanie do powiązanego planu użycia. Klucze API NIE są mechanizmem bezpieczeństwa — służą wyłącznie do identyfikowania klientów na potrzeby ograniczania szybkości i limitów kwot. Ze względów bezpieczeństwa należy zawsze łączyć klucze API z właściwą autoryzacją (IAM, autoryzatorem Lambda lub Cognito). Klucze API, które nie są powiązane z planem użycia, nie mają zastosowanych limitów ograniczania szybkości.

# Create an API key and associate with usage plan
aws apigateway create-api-key \
  --name 'PartnerABC-Key' \
  --enabled

aws apigateway create-usage-plan-key \
  --usage-plan-id 'uvw321' \
  --key-id 'xyz789' \
  --key-type API_KEY

Limity kwot w planach użycia

Oprócz limitów szybkości określanych na sekundę plany użycia obsługują limity kwot: maksymalną liczbę żądań w określonym przedziale czasu (DAY, WEEK lub MONTH). Gdy klient wyczerpie swoją kwotę, kolejne żądania zwracają kod 429 do momentu zresetowania kwoty. Limity kwot są przydatne przy egzekwowaniu zasad bezpłatnego poziomu, zapobieganiu nadużyciom interfejsu API oraz dostosowywaniu wykorzystania API do rozliczeń. Liczniki kwot są ostatecznie spójne, dlatego klient może nieznacznie przekroczyć limit, zanim zostanie zablokowany.

Metryki CloudWatch dotyczące ograniczania szybkości i buforowania

Stan API Gateway należy monitorować za pomocą następujących metryk CloudWatch:

Count: łączna liczba wywołań API
4XXError: błędy klienta, w tym ograniczenia 429
5XXError: błędy zaplecza
Latency: czas żądania od początku do końca
IntegrationLatency: czas oczekiwania na zaplecze
CacheHitCount / CacheMissCount: skuteczność pamięci podręcznej

Należy ustawić alarmy dotyczące skoków wartości 4XXError, aby wykrywać problemy z ograniczaniem szybkości, zanim wpłyną one na użytkowników, oraz dotyczące wartości CacheMissCount, aby identyfikować problemy z konfiguracją pamięci podręcznej.

Kiedy włączyć buforowanie, a kiedy ograniczanie szybkości

Buforowania należy używać w interfejsach API z przewagą odczytów, w których odpowiedzi zmieniają się rzadko — na przykład przy wyszukiwaniu produktów w katalogu, danych referencyjnych i konfiguracji statycznych. Buforowanie przynosi efekt przeciwny do zamierzonego w przypadku danych specyficznych dla użytkownika lub często zmieniających się. Ograniczanie szybkości należy stosować zawsze, nawet w wewnętrznych interfejsach API, aby chronić usługi zaplecza przed przeciążeniem. Warto łączyć oba mechanizmy: buforować często używane dane, aby zmniejszyć obciążenie zaplecza, i stosować restrykcyjne ograniczanie szybkości, aby zapobiec zdominowaniu API przez pojedynczego klienta. Na egzaminie SAA-C03 należy pamiętać, że buforowanie zmniejsza koszty i opóźnienia, a ograniczanie szybkości zapewnia dostępność.

Szybki test

Sprawdź swoją wiedzę na temat zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

Podsumowanie lekcji

W tej lekcji poznali Państwo następujące zagadnienia: Throttling na poziomie konta, etapu i metody chroni zaplecza za pomocą algorytmu token bucket z konfigurowalnymi limitami szybkości i serii żądań, Response Caching przechowuje odpowiedzi zaplecza przez konfigurowalny czas TTL, zmniejszając obciążenie zaplecza i opóźnienia w punktach końcowych z przewagą odczytów, a Usage Plans with API Keys egzekwują limity szybkości i kwoty dla poszczególnych klientów, umożliwiając warstwową kontrolę dostępu do partnerskich i publicznych interfejsów API. W następnej części omówimy klastry ECS, definicje zadań i usługi na potrzeby obciążeń kontenerowych.

Często zadawane pytania

Czy lekcja „Ograniczanie, buforowanie i plany użycia” jest bezpłatna?

Tak — pełny tekst „Ograniczanie, buforowanie i plany użycia” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AWS Solutions Architect, przejdź na CoddyKit PRO. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.

Co nauczysz się w „Ograniczanie, buforowanie i plany użycia”?

Zabezpieczą backendy limitami ograniczania ruchu dla skoków i stanu ustalonego, włączą buforowanie odpowiedzi oraz utworzą plany użycia z kluczami API dla partnerów. Ćwiczysz AWS Solutions Architect z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć AWS Solutions Architect?

Nie wymagamy żadnego doświadczenia. AWS Solutions Architect w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Ograniczanie, buforowanie i plany użycia”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji AWS Solutions Architect?

Tak. Każda lekcja AWS Solutions Architect zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

REST API a HTTP API i WebSocket API
Integracje: Lambda, HTTP i Mock
Autoryzacja: IAM, autoryzatory Lambda i Cognito
Ograniczanie, buforowanie i plany użycia

← Powrót do AWS Solutions Architect