Handel internetowy jest dostępny 24 godziny na dobę 7 dni w tygodniu – niezależnie od ograniczeń, wprowadzanych w niektórych krajach (np. zakaz handlu w niedziele). Według licznych badań przeprowadzonych na e-konsumentach – to właśnie całodobowa dostępność sklepów internetowych oraz portalów aukcyjnych jest najbardziej decydującą kwestią, na podstawie której konsumenci decydują się na wirtualny koszyk zamiast wizyty w centrum handlowym.

Wysokie oczekiwania klientów przekładają się na wysokie oczekiwania niezawodności rozwiązań w branży e-commerce. Z takimi oczekiwaniami w 2018 roku zgłosił się do nas klient przygotowujący rozwiązanie „Menedżera wysyłek” dla jednego z największych portali aukcyjnych na świecie.

Wysoka dostępność aplikacji

Słowa Williama Jamesa „Łańcuch jest tak mocny, jak jego najsłabsze ogniwo” idealnie oddają specyfikację wyzwania, przed jakim stanęliśmy. Bez względu na to, jak bardzo bezawaryjna jest aplikacja – potrzebuje ona do działania maksymalnie odpornej na awarię infrastruktury.

Projektując architekturę skrojoną pod potrzeby klienta oraz specyficzne wymagania branży e-commerce postawiliśmy na sprawdzone rozwiązania, dzięki którym możemy spełnić wyśrubowane wymagania. Architektura softwarowa została oparta na niezawodności prywatnej chmury All for One Managed Cloud, opartej na dwóch bliźniaczych centrach przetwarzania danych, ponieważ już na poziomie sprzętowym ważne było zapewnienie wysokiej dostępności oraz maksymalnego bezpieczeństwa.

Odwrócone proxy

Serwery aplikacyjne, będące najważniejszą częścią każdego działającego środowiska, są bardzo częstymi obiektami ataków hakerskich. W obecnych czasach jako standard uznaje się „chowanie” aplikacji za odwróconym proxy.

Aby spełnić wszystkie wymagania klienta zdecydowaliśmy się na zastosowanie sprawdzonego rozwiązania Nginx. Ten serwer www idealnie spełnia rolę odwróconego proxy, dzięki czemu klient, łączący się do naszej usługi, nie łączy się bezpośrednio do serwera aplikacyjnego – tylko do proxy, które przyjmuje zapytanie klienta, a następnie w jego imieniu przesyła zapytanie do serwera aplikacyjnego. Otrzymana odpowiedź jest przekazywana z powrotem do klienta. W efekcie nasze odwrócone proxy znacznie poprawia stopień bezpieczeństwa środowiska czy jego wydajność, udostępniając cały wachlarz mechanizmów, jakie możemy zaimplementować w zależności od specyfikacji aplikacji, które mogą zapewnić dodatkowe filtrowanie ruchu (Web Application Firewall), czy odciążyć serwer aplikacyjny na przykład z odszyfrowywania ruchu szyfrowanego (SSL Offloading).

Reverse proxy jako jeden z elementów naszego środowiska musiał zostać zaimplementowany z naciskiem na wysoką dostępność. Posiadając już doświadczenie w klastrowaniu rozwiązania nginx, zdecydowaliśmy na uruchomienie rozwiązania jako dwuwęzłowy klaster active-active z dwoma pływającymi adresami IP.

Taka architektura spełnia założenia load balancingu, dzięki czemu oprócz odporności klastra na awarię jednego węzła dodatkowo rozkładamy obciążenie pomiędzy dwie maszyny, co skutkuje zwiększoną wydajnością oraz większą odpornością na ataki typu DoS.

Lata doświadczeń ze sklastrowanym reverse proxy nauczyły nas radzenia sobie z wyzwaniami stawianymi przy budowaniu takich rozwiązań. Jednym z głównych problemów było utrzymywanie spójnej konfiguracji pomiędzy poszczególnymi węzłami w klastrze. Obecnie stosujemy autorskie rozwiązanie bazujące na wykorzystaniu narzędzia Ansible, dzięki któremu administracja klastrem stała się niezwykle prosta i efektywna.

Baza danych

Jak w przypadku większości aplikacji tego typu – wybór dostawcy aplikacji padł na bazę danych MySQL. W związku z tym stanęliśmy przed nie lada wyzwaniem zaimplementowania mechanizmów wysokiej dostępności dla bazy z delfinem w logo.

Z pomocą przyszło nam rozwiązanie Percona XtraDB Cluster. Okazało się, że możliwości klastra od Percona idealnie zaspokajają potrzeby nasze oraz naszego klienta. Oprócz zapewnienia naszej priorytetowej potrzeby, czyli wysokiej dostępności oraz skalowalności rozwiązanie to udostępniło nam wiele możliwości na poprawę bezpieczeństwa oraz wydajności tworzonego środowiska. W pierwszej kolejności skupiliśmy się na uruchomieniu load balancingu dla naszego klastra. Dzięki zastosowanym mechanizmom możemy dynamicznie zarządzać rolami poszczególnych węzłów klastra, odciążając lub dociążając poszczególne węzły w zależności od potrzeb serwera aplikacyjnego.

W temacie bezpieczeństwa kluczowym mechanizmem, który został przez nas wdrożony, był mechanizm szyfrowania baz danych. Funkcjonalność ta została narzucona nam przez specyfikację klienta, dla którego bezpieczeństwo było kwestią równie ważną, jak wysoka dostępność aplikacji. Rozwiązanie Percona XtraDB Cluster udostępnia wszystkie wymagane przez klienta mechanizmy.

Kolejnym wyzwaniem budowanego rozwiązania było wyeliminowanie możliwości wystąpienia zjawiska split-brain’u. Przy niewielkich klastrach (składających się z kilku węzłów) istnieje duże prawdopodobieństwo wystąpienia wspomnianego problemu. Aby uchronić się przed tym zjawiskiem, z pomocą przyszło nam rozwiązania Percona Galera Arbitrator. Dzięki wprowadzeniu do klastra arbitra, możemy uniknąć split-brain’u nawet w środowisku dwuwęzłowym, co zmniejsza ryzyko wystąpienia awarii.

Backup & Recovery

Pomimo założenia, że architektura klastra jest wysoko dostępna, konieczne było opracowanie dedykowanej polityki backupu bazy danych. Wykorzystaliśmy tu rozwiązanie Percona XtraBackup for MySQL. Narzędzie integruje się bez najmniejszych problemów z Percona XtraDB Cluster. Zastosowana polityka kopii zapasowej pozwala na wykonywanie kopii zapasowej nie obciążając węzłów bazodanowych, a zastosowane metody pozwalają na odtworzenie bazy danych do dowolnego punktu w czasie.

Procedurę backupu skomplikował fakt wdrożonego szyfrowania bazy danych. Na szczęście narzędzia Percona zapewniają wsparcie w procesie kopii oraz odtworzenia szyfrowanych baz danych. Dzięki temu sama kopia zapasowa również zawiera zaszyfrowane dane.

W celu upewnienia się, że proces kopii zapasowej działa poprawnie, wykonujemy cykliczne testy odtworzeniowe polegające na zasymulowaniu konieczności odtworzenia systemów produkcyjnych z backupu. Takie testy wykonywane okresowo (lub na życzenie klienta) pozwalają upewnić się, czy tworzona kopia odtwarza się poprawnie, czy proces odtworzenia systemów nie ma wad oraz czy czas uruchomienia systemów po awarii nie przekracza czasu określonego w umowie.

Monitoring oraz administracja

Zastosowane rozwiązania technologiczne wymagały indywidualnego podejścia do monitoringu dostępności usług. Podstawowy monitoring został zaimplementowany w systemie Nagios, dzięki czemu środowisko jest monitorowane 24/7. Monitoring dostępności systemów/usług został dodatkowo rozszerzony w systemie Zabbix o dodatkowe zbieranie szczegółowych danych dotyczących działania systemu operacyjnego, bazy danych czy serwera aplikacyjnego. Dzięki dostępowi do danych historycznych w prosty sposób mamy możliwość zauważenia niepokojących anomalii w działaniu środowiska i zareagowanie na nie zanim spowodują realny problem.

Kolejnym systemem, który wspiera monitorowanie środowiska jest Graylog – system scentralizowanego logowania. Wykorzystanie scentralizowanego systemu logowania w środowisku stało się konieczne ze względu na sklastrowane proxy. Brak takiego rozwiązania powodował problem w korelacji logów dostępu do aplikacji, ponieważ każdy węzeł posiadał oddzielny log. Dzięki Graylogowi problem oddzielnego logowania został rozwiązany. Oprócz tego, że logi dostępne są teraz w jednym miejscu, skorzystaliśmy z innych dobrodziejstw systemu centralnego logowania, jakim są m.in. rozbudowane funkcjonalności statystyczne, szybki system przeszukiwania logów oraz możliwość alertowania w przypadku odnotowania w logu niepożądanych wpisów.

Powyższe systemy w nieopisany sposób pomagają administratorom w codziennej pracy, centralizując istotne dane oraz przyspieszając wykrywanie potencjalnych problemów. Przygotowane po wdrożeniu systemów procedury zarządzania środowiskiem minimalizują ryzyko popełnienia błędu ludzkiego podczas rutynowych czynności administracyjnych. Również na uwagę zasługuje fakt, że większość prac administracyjnych – nawet tych wymagających restartów usług może być wykonywana bez generowania niedostępności systemów (minimalizowanie częstotliwości okien serwisowych). Zarówno klaster SQL, jak i klaster reverse proxy – oba systemy są odporne na wyłączenie pojedynczych węzłów do tego stopnia, że dla użytkownika końcowego taka czynność nie jest odczuwalna podczas czerpania przyjemności z możliwości „buszowania” po wirtualnym sklepie o dowolnej porze dnia czy nocy.