Amazon RDS - relacyjna baza danych jako usługa
Amazon RDS (Relational Database Service) to jedna z najpopularniejszych usług AWS. Pozwala uruchomić zarządzaną bazę relacyjną w kilka minut, bez instalowania czegokolwiek na serwerze, bez konfigurowania replikacji i bez martwienia się o backupy.
Pomyśl o tym tak: chcesz bazę PostgreSQL? W modelu tradycyjnym stawiasz serwer, instalujesz PostgreSQL, konfigurujesz użytkowników, ustawiasz crona na backupy, pilnujesz aktualizacji. Z RDS? Wybierasz PostgreSQL, klikasz rozmiar instancji, podajesz hasło admina i po 5 minutach masz działający endpoint bazy.
Obsługiwane silniki baz danych
RDS obsługuje 6 silników:
- MySQL - najpopularniejszy open-source, świetny do aplikacji webowych
- PostgreSQL - zaawansowany open-source, obsługuje złożone typy danych (JSON, GIS)
- MariaDB - fork MySQL stworzony przez oryginalnego twórcę MySQL
- Oracle - enterprise, wymagane licencje (Bring Your Own License lub License Included)
- Microsoft SQL Server - popularne w środowiskach .NET / Windows
- Amazon Aurora - autorski silnik AWS (o tym za chwilę)
Co AWS robi za Ciebie w RDS?
Lista jest imponująca:
- Automatyczne backupy - codzienne snapshoty + transaction logs, retention od 0 do 35 dni
- Patching silnika - AWS aktualizuje silnik bazy w zdefiniowanym oknie serwisowym
- Monitoring - metryki w CloudWatch (CPU, pamięć, IOPS, connections)
- Multi-AZ deployment - automatyczny failover na standby w innej AZ
- Szyfrowanie - encryption at rest (KMS) i in transit (SSL/TLS)
- Snapshoty manualne - możesz tworzyć snapshoty na żądanie (zachowywane do ręcznego usunięcia)
Multi-AZ - wysoka dostępność
To jedna z najważniejszych funkcji RDS na egzaminie. Multi-AZ oznacza, że AWS automatycznie tworzy synchroniczną replikę Twojej bazy w innej Availability Zone.
Jak to działa?
- Masz instancję primary w AZ-A
- AWS tworzy instancję standby w AZ-B
- Każdy zapis na primary jest synchronicznie replikowany na standby
- Jeśli primary padnie, AWS automatycznie przełącza DNS endpoint na standby (failover trwa 60-120 sekund)
- Ty nie zmieniasz nic w kodzie aplikacji, bo endpoint DNS pozostaje ten sam
Read Replicas - skalowanie odczytów
Gdy Twoja aplikacja robi dużo odczytów (np. wyświetlanie katalogu produktów), możesz odciążyć główną bazę tworząc Read Replicas.
Kluczowe fakty:
- Replikacja jest asynchroniczna (w przeciwieństwie do Multi-AZ, która jest synchroniczna)
- Możesz utworzyć do 15 Read Replicas (Aurora) lub 5 Read Replicas (inne silniki RDS)
- Read Replica może być w innym regionie (Cross-Region Read Replica)
- Możesz promować Read Replica do samodzielnej bazy danych
- Aplikacja musi kierować odczyty na endpoint Read Replica (wymaga zmiany w kodzie)
| Cecha | Multi-AZ | Read Replica |
|---|---|---|
| Cel | High availability (HA) | Skalowanie odczytów |
| Replikacja | Synchroniczna | Asynchroniczna |
| Obsługuje ruch? | Nie (standby jest nieaktywny) | Tak (odczyty) |
| Cross-Region? | Nie (tylko w tym samym regionie) | Tak |
| Automatyczny failover? | Tak | Nie (wymaga ręcznej promocji) |
| Zmiana w kodzie? | Nie | Tak (osobny endpoint) |
RDS wykorzystuje Amazon EBS jako storage. Dostępne typy:
- gp3 / gp2 - General Purpose SSD, dobre do większości obciążeń
- io1 / io2 - Provisioned IOPS SSD, dla obciążeń wymagających niskiej latencji I/O
- magnetic - stary typ, rzadko używany, nie zalecany
RDS obsługuje Storage Auto Scaling. Ustawiasz maksymalny rozmiar storage, a AWS automatycznie zwiększa go, gdy zużycie przekroczy próg. Nie musisz ręcznie powiększać dysków.
Typy instancji RDS to te same rodziny co EC2: m (general purpose), r (memory optimized), t (burstable). Dla produkcyjnych baz danych unikaj t-class (burstable), bo wydajność jest ograniczona kredytami CPU.
Amazon Aurora - baza danych nowej generacji
Aurora to flagowy produkt bazodanowy AWS. To autorski, cloud-native silnik relacyjny, który jest kompatybilny z MySQL i PostgreSQL, ale zbudowany od podstaw dla chmury.
Co to znaczy „kompatybilny"? Twoja aplikacja napisana pod MySQL może połączyć się z Aurora MySQL bez żadnych zmian w kodzie. Te same sterowniki, te same zapytania SQL. Ale pod spodem Aurora działa zupełnie inaczej.
Dlaczego Aurora jest wyjątkowa?
- 5x szybsza od standardowego MySQL i 3x szybsza od PostgreSQL (wg benchmarków AWS)
- Storage rośnie automatycznie od 10 GB do 128 TB, płacisz za zużyte miejsce
- 6 kopii danych w 3 AZ - Twoje dane są replikowane automatycznie
- Do 15 Read Replicas z opóźnieniem replikacji poniżej 10ms
- Natychmiastowy failover - szybszy niż w standardowym RDS Multi-AZ
- Ciągłe backupy do S3 - bez wpływu na wydajność
Architektura storage Aurora
To jest serce wyższości Aurora nad standardowym RDS. W zwykłym RDS masz jedną instancję z jednym wolumenem EBS. W Aurora storage jest oddzielony od compute.
Aurora przechowuje dane w klastrze storage, który:
- Automatycznie replikuje dane w 6 kopiach, rozmieszczonych w 3 AZ
- Toleruje utratę 2 kopii bez wpływu na zapisy
- Toleruje utratę 3 kopii bez wpływu na odczyty
- Naprawia się samodzielnie (self-healing storage)
- Rośnie automatycznie w blokach 10 GB
Firma e-commerce ma bazę MySQL na RDS. W Black Friday baza nie nadąża z odczytami. Mają 3 Read Replicas, ale opóźnienie replikacji rośnie do kilku sekund.
Rozwiązanie: Migracja z RDS MySQL do Aurora MySQL. Aurora pozwala na 15 Read Replicas z opóźnieniem poniżej 10ms. Storage jest rozproszony w 3 AZ, więc jest szybszy. Dodatkowy bonus: Aurora Auto Scaling automatycznie dodaje i usuwa Read Replicas w zależności od obciążenia.
Migracja jest prosta, bo Aurora MySQL jest kompatybilna z MySQL. Można użyć snapshotu RDS do stworzenia klastra Aurora.
Aurora Serverless
Aurora Serverless to wersja Aurora, w której nie musisz zarządzać instancjami. Zamiast wybierać rozmiar instancji (db.r5.large, db.r5.xlarge itd.), definiujesz minimalne i maksymalne ACU (Aurora Capacity Units), a Aurora sama skaluje się w górę i w dół.
Kiedy Aurora Serverless jest idealna?
- Nieprzewidywalne obciążenie - nie wiesz, ile ruchu będzie
- Sporadyczne użycie - baza jest aktywna kilka godzin dziennie
- Dev/test environments - nie chcesz płacić za instancję 24/7
- Nowe aplikacje - nie znasz jeszcze profilu obciążenia
Aurora Serverless v2 (aktualna wersja) skaluje się w przyrostach 0.5 ACU i może skalować się praktycznie natychmiastowo. Może też obsługiwać produkcyjne obciążenia.
Aurora Global Database pozwala na replikację bazy do 5 dodatkowych regionów AWS z opóźnieniem poniżej 1 sekundy. Przypadki użycia:
- Disaster recovery - jeśli cały region padnie, możesz promować region secondary do primary
- Niższa latencja odczytów - użytkownicy w Europie czytają z regionu europejskiego, użytkownicy w USA z regionu US
Failover na inny region trwa około 1 minuty. Na egzaminie Aurora Global Database pojawia się w kontekście cross-region disaster recovery dla relacyjnych baz danych.
- RDS to zarządzana baza relacyjna z 6 silnikami, automatycznymi backupami i patchowaniem
- Multi-AZ zapewnia high availability z synchroniczną replikacją i automatycznym failoverem
- Read Replicas skalują odczyty z asynchroniczną replikacją, mogą być cross-region
- Aurora to cloud-native silnik AWS, kompatybilny z MySQL/PostgreSQL, z 6 kopiami danych w 3 AZ
- Aurora Serverless automatycznie skaluje compute, idealna do zmiennych obciążeń
- Aurora Global Database replikuje bazę do 5 regionów z opóźnieniem poniżej 1 sekundy
Firma potrzebuje relacyjnej bazy danych, która automatycznie przełączy się na zapasową instancję w razie awarii. Co włączysz?
Czym Aurora różni się od standardowego RDS MySQL?
Startup nie wie, ile ruchu będzie miała jego nowa aplikacja. Potrzebuje bazy relacyjnej, która sama się skaluje. Co polecisz?