Fablo a awarie w Amazon Web Services (AWS)
2011-04-26
Klienci pytają nas, czy niedawne awarie w Amazon AWS w jakiś sposób wpływają na działanie Fablo.
AWS jest podzielone na pięć regionów geograficznych. Awarie miały miejsce w regionie US-EAST-1 (Virginia), gdzie mamy naszą instalację testową. Nasze serwery produkcyjne obsługujące klientów są uruchomione w regionie EU-WEST-1 (Irlandia), niedawne problemy więc naszych klientów w żaden sposób nie dotknęły.
Dodatkowo, w każdym z regionów istnieje kilka tzw. „stref dostępności”, z których każda jest fizycznie odrębną instalacją. Przykładowo, w US-EAST-1 są cztery takie strefy. Nawet wydarzenia takie jak pożar, awaria zasilania, czy odcięcie łączności powinny dotykać tylko jednej ze stref dostępności, nigdy wszystkich. Ostatnie awarie dotyczyły tylko dwóch z czterech stref dostępności.
Niedawne problemy były związane głównie z usługą EBS (Elastic Block Store), którą zawsze uważaliśmy za problematyczną. Fablo nigdy nie używało i nie używa EBS do niczego istotnego. Awaria dotknęła za to wielu popularnych serwisów sieciowych opartych na bazach SQL — które najwygodniej się instaluje właśnie na wolumenach EBS. Nasze systemy są projektowane tak, by nie korzystać z bazy SQL.
Awarie w Amazon AWS zdarzają się bardzo rzadko, ale w praktyce w każdym odpowiednio dużym systemie muszą się takowe wydarzyć. Dlatego mamy na takie okazje przygotowane procedury. Całą instalację produkcyjną Fablo jesteśmy w stanie odtworzyć automatycznie. W ten właśnie sposób jest budowana i stawiana instalacja testowa — automatycznie od zera do działającej infrastruktury. Jesteśmy więc gotowi, w razie poważniejszych awarii, uruchomić całą produkcyjną infrastrukturę w dowolnym regionie (i dowolnej strefie dostępności) Amazon AWS i przekierować tam obsługę zapytań. Operacja taka trwa około godziny, co jest wyjątkowo krótkim czasem — nieosiągalnym w przypadku poważniejszych awarii własnych serwerowni.
Dla najbardziej wymagających klientów jesteśmy w stanie zaoferować obsługę z pełną redundancją — równocześnie w dwóch strefach dostępności lub nawet w dwóch regionach geograficznych.
Jesteśmy zdania, że dla oprogramowania zaprojektowanego do pracy w „chmurze” (jak nasze) można oferować znacznie lepsze warunki niezawodności niż dla tradycyjnych rozwiązań.
Warto też dodać, że wiele osób naiwnie myśli, że do „chmury” można przenieść ich obecne architektury bez żadnej modyfikacji. Uruchamianie aplikacji z MySQL albo PostgreSQL na serwerach AWS z wolumenami EBS pozornie działa… aż do pierwszego problemu.
W jaki sposób Fablo radzi sobie z ulotnością dysków bez EBS? Replikacja do innego regionu (czy nawet poza AWS)?
EBS jest o tyle przyjemne, że przeżywa śmierć maszyny. Nie jest oczywiście wystarczające jako jedyny sposób zapewnienia trwałości danych (nic nie jest wystarczająco dobre jeśli jest *jedynym* zabezpieczeniem), ale ma też swoje miejsce. Być może ephemeral storage jest lepszy dla żywej bazy (robiliście jakieś testy wydajnościowe? Z tego, co czytałem, EBS możę być nawet szybszy), ale EBS jako podstawa dla zapasowego slave'a, albo na /home maszyny dla developerów, nie wydaje się być takim złym pomysłem. No i atomiczne snapshoty do backupów lub klonowania bazy danych – to jest miłe.
Nitpick: niby regiony są podzielone na niezależne strefy dostępności, ale jedna z niespodzianek przy wielkanocnej awarii polegała na tym, że problemy dotyczyły wszystkich stref dostępności w us-east-1 (nawet jeśli źródłowe problemy były tylko w dwóch z czterech stref, API dotyczące z EBS w pozostałych dwóch było przeciążone, a odtwarzanie backupów z S3 działało okrutnie wolno nawet w us-west).
"Uruchamianie aplikacji z MySQL albo PostgreSQL na serwerach AWS z wolumenami EBS pozornie działa… aż do pierwszego problemu." – chyba, że się to zrobi porządnie (warm standby przez replikację do osobnego regionu, i/lub backupy kopiowane do innego regionu czy do S3, zależnie od rodzaju danych, posiadanych środków i wymaganego czasu wyjścia z awarii). Da się. A bazy NoSQL-owe też mają swoje za uszami - osobiście wciąż trochę się ich boję do zastosowań produkcyjnych przy obciążeniu większym od średnio uczęszczanego CMSa.
Maciek: Fablo mało w ogóle używa dysków :-)
A tak serio — zindeksowane dane z których inicjalizują się serwery API są trzymane w S3, które ma znakomicie lepszą semantykę i niezawodność niż EBS. Owszem, zrzucamy obecnie na EBS log redisa (AOF, append only file), ale pewnie i od tego odejdziemy — równocześnie dane są przesyłane do drugiego redisa na zewnątrz. A ponieważ tak zbudowaliśmy Fablo, że ruch do/z redisa jest niewielki (zapytania nawet go nie dotykają!), nie jest to problemem.
A co do Twojego komentarza na temat baz SQL w AWS -- oczywiście, da się to zrobić dobrze. Miałem na myśli naiwność tych, którzy po prostu uruchamiają bazę na wolumenie EBS i uważają, że chmura załatwi resztę. To tak jak trzymać swoje dane na jednym dysku :-)