Caching i optymalizacja wydajności
Najszybszy request to ten, którego nie trzeba przetwarzać. Caching (buforowanie) to jedna z najpotężniejszych technik optymalizacji. Zamiast za każdym razem odpytywać bazę danych czy generować stronę od nowa, serwujesz gotową odpowiedź z pamięci podręcznej. W tej lekcji poznasz strategie cachingu w AWS i inne techniki przyspieszania aplikacji.
Dlaczego caching jest ważny?
Wyobraź sobie restaurację. Kucharz nie gotuje zupy od zera dla każdego klienta. Rano gotuje duży gar i nalewa z niego porcje. To jest caching w kulinarnym wydaniu.
W aplikacjach webowych bez cachingu:
- Każdy request trafia do bazy danych (obciążenie rośnie liniowo z ruchem)
- Te same dane są pobierane tysiące razy na minutę
- Czas odpowiedzi rośnie, użytkownicy się frustrują
- Koszty infrastruktury rosną, bo potrzebujesz coraz większych baz danych
Amazon CloudFront: caching na edge
CloudFront to CDN (Content Delivery Network) od AWS. Przechowuje kopie Twoich danych w ponad 400 lokalizacjach na całym świecie (edge locations). Gdy użytkownik z Warszawy requestuje Twoją stronę, dostaje ją z najbliższej edge location, a nie z serwera w Virginii.
Co CloudFront cachuje?
- Statyczne pliki: obrazy, CSS, JS, fonty, filmy
- Dynamiczne odpowiedzi API (z konfigurowalnym TTL)
- Całe strony webowe (dla stron, które się rzadko zmieniają)
Jak działa cache w CloudFront?
- Użytkownik requestuje plik (np. logo.png)
- Request trafia do najbliższej edge location
- Cache HIT: plik jest w cache, CloudFront serwuje go natychmiast (latencja: milisekundy)
- Cache MISS: pliku nie ma w cache, CloudFront pobiera go z origin (S3/EC2/ALB), cachuje lokalnie i serwuje użytkownikowi
- Kolejne requesty o ten sam plik z tej edge location to cache HIT
Amazon ElastiCache
ElastiCache to zarządzana usługa in-memory cache. Dane trzymane w pamięci RAM, więc dostęp jest o rząd wielkości szybszy niż z dysku (mikrosek. vs milisek.). AWS oferuje dwa silniki:
| Cecha | Redis | Memcached |
|---|---|---|
| Struktury danych | Zaawansowane (strings, lists, sets, hashes, sorted sets) | Proste (key-value) |
| Persistence | Tak (snapshots, AOF) | Nie (dane giną po restarcie) |
| Replikacja | Tak (Multi-AZ, read replicas) | Nie |
| Pub/Sub | Tak | Nie |
| Przypadek użycia | Sesje, leaderboardy, kolejki, pub/sub | Prosty cache, duże obiekty |
Typowe zastosowania ElastiCache:
- Database caching: wyniki częstych zapytań SQL trzymasz w cache. Zamiast odpytywać bazę 10 000 razy/s, odpytujesz cache.
- Session store: sesje użytkowników w Redis (wspiera stateless applications i Auto Scaling)
- Leaderboard/ranking: Redis Sorted Sets idealnie nadają się do rankingów w grach
- Real-time analytics: szybki zapis i odczyt liczników, metryk
DynamoDB Accelerator (DAX)
DAX to in-memory cache specjalnie dla DynamoDB. Działa jako warstwa pośrednia: Twoja aplikacja komunikuje się z DAX zamiast bezpośrednio z DynamoDB. DAX cachuje wyniki odczytów i zwraca je z opóźnieniem mierzonym w mikrosekundach.
Kluczowe cechy DAX:
- Kompatybilny z API DynamoDB (minimalne zmiany w kodzie)
- Latencja: z milisekund (DynamoDB) do mikrosekund (DAX)
- Idealny dla read-heavy workloads z powtarzalnymi zapytaniami
- Nie pomaga przy write-heavy workloads (cache dotyczy odczytów)
Kiedy ElastiCache? Twoja aplikacja używa RDS (MySQL, PostgreSQL) i chcesz zcachować wyniki zapytań SQL. ElastiCache (Redis) jest uniwersalny i działa z każdą bazą danych.
Kiedy DAX? Twoja aplikacja używa DynamoDB i potrzebujesz ultra-niskiej latencji odczytów. DAX jest dedykowany wyłącznie dla DynamoDB i wymaga minimalnych zmian w kodzie.
Prosta reguła: DynamoDB + cache = DAX. Cokolwiek innego + cache = ElastiCache.
API Gateway Caching
Amazon API Gateway ma wbudowany cache. Możesz cachować odpowiedzi API, żeby nie odpytywać backendu (Lambda, EC2) przy każdym requescie. Konfigurowalny TTL od 0 do 3600 sekund.
Przykład: Twoje API zwraca listę produktów. Ta lista zmienia się raz na godzinę. Zamiast wywoływać Lambda 10 000 razy na minutę, API Gateway cachuje odpowiedź i serwuje z cache. Lambda wywoływana jest raz na godzinę.
Efekt: niższe koszty Lambda, niższa latencja, mniejsze obciążenie backendu.
Database Read Replicas
Read replicas to nie caching w tradycyjnym sensie, ale technika optymalizacji odczytów z bazy danych. Tworzysz kopie bazy danych (repliki), które obsługują tylko odczyty. Główna baza (primary/master) obsługuje zapisy i replikuje dane do replik.
Korzyści:
- Rozdzielasz ruch odczytowy na wiele replik (odciążasz primary)
- Możesz tworzyć repliki w różnych regionach (cross-region read replicas) dla niższej latencji globalnej
- RDS wspiera do 5 read replik (Aurora do 15)
S3 Transfer Acceleration
S3 Transfer Acceleration przyspiesza upload plików do S3, wykorzystując sieć edge locations CloudFront. Zamiast wysyłać plik bezpośrednio do bucketu w us-east-1, wysyłasz go do najbliższej edge location, a AWS przesyła go do bucketu przez swoją szybką sieć wewnętrzną.
Szczególnie użyteczne przy dużych plikach uploadowanych z różnych części świata. Może przyspieszyć transfer nawet o 50-500% w porównaniu z bezpośrednim uploadem.
W dobrze zaprojektowanej architekturze masz wiele warstw cachingu:
- Browser cache: przeglądarka cachuje statyczne zasoby (kontrolowane przez HTTP headers: Cache-Control, ETag)
- CDN cache (CloudFront): edge locations cachują content blisko użytkowników
- API Gateway cache: cachuje odpowiedzi API
- Application cache (ElastiCache/DAX): cachuje wyniki zapytań do bazy danych
- Database cache: wbudowane mechanizmy cachowania bazy danych (InnoDB buffer pool, itp.)
Im bliżej użytkownika cache, tym niższa latencja i tym mniej obciążona infrastruktura backendowa. Idealnie, większość requestów powinna być obsłużona z cache bez dotykania bazy danych.
- CloudFront to CDN cachujący content w edge locations na całym świecie. Redukuje latencję i odciąża origin
- ElastiCache (Redis/Memcached) to in-memory cache. Redis jest bogatszy (persistence, replikacja, pub/sub). Memcached prostszy
- DAX to in-memory cache dedykowany dla DynamoDB (mikrosek. latencja). DynamoDB + cache = DAX
- API Gateway ma wbudowany cache odpowiedzi (TTL 0-3600s), redukuje wywołania backendu
- Read Replicas odciążają primary DB z ruchu odczytowego. Multi-AZ to HA, Read Replica to wydajność
- S3 Transfer Acceleration przyspiesza uploady przez edge locations
Aplikacja używa DynamoDB i potrzebuje ultra-niskiej latencji odczytów (mikrosek.). Która usługa AWS jest najlepsza?
Firma chce przyspieszyć dostarczanie statycznych zasobów (obrazy, CSS, JS) do użytkowników na całym świecie. Która usługa AWS jest najlepsza?
Czym różni się RDS Read Replica od RDS Multi-AZ?