Dlaczego w erze chmury wciąż trzymamy w serwerowniach te monolityczne maszyny typu IBM Power? Czy nie taniej byłoby przepisać wszystko na mikroserwisy i rozproszyć na tysiące tanich instancji x86?
Pytanie o sens utrzymywania serwerów typu IBM Power w erze chmury pojawia się regularnie podczas dyskusji o modernizacji infrastruktury. Na pierwszy rzut oka migracja na mikroserwisy lub tanie instancje x86 wydaje się oczywistym wyborem kosztowym. Jednak dla osób znających wyzwania związane z transakcjami w systemach bankowych, zarządzaniu łańcuchem dostaw (Supply Chain) czy systemach ERP, odpowiedź jest zupełnie inna. To nie jest kwestia sentymentu do „starego żelaza”, ale fundamentalnego wyboru między dwiema filozofiami, które rządzą światem baz danych: kwasem (ACID) a zasadą (BASE). Zrozumienie tej informatycznej „chemii” to jedyny sposób, by uniknąć eksplozji w środowisku produkcyjnym.
ACID to fundament bezpieczeństwa
W świecie systemów transakcyjnych termin ACID jest synonimem niezawodności. Jego twórcy Theo Härder i Andreas Reuter w swojej pracy Principles of Transaction-Oriented Database Recovery uznali, że bazy danych muszą przejść swoisty „acid test” (próbę kwasową), co jest nawiązaniem do historycznej metody weryfikacji autentyczności złota. W IT oznacza to test bezlitosny, który system musi zaliczyć, abyśmy mogli powierzyć mu pieniądze klientów. Model ten opiera się na czterech filarach:
Atomowość (Atomicity): Wszystko albo nic Transakcja musi zostać wykonana w całości albo wcale. Nie ma miejsca na stany pośrednie.
- Scenariusz awarii: Wyobraźmy sobie przelew bankowy bez atomowości. System zdejmuje 1000 zł z konta nadawcy, ale ułamek sekundy później następuje awaria serwera, zanim środki zostaną dopisane do konta odbiorcy.
- Skutek: Po restarcie system uznaje operację obciążenia za wykonaną, ale uznania już nie. Pieniądze po prostu znikają z systemu, nie ma ich ani nadawca, ani odbiorca. Atomowość gwarantuje, że w takiej sytuacji system wykona „rollback” i cofnie pierwszą operację, jakby nigdy nie miała miejsca.
Spójność (Consistency): Strażnik reguł To często błędnie rozumiany element. Nie chodzi tu o zgodność ze stanem faktycznym w świecie rzeczywistym (baza nie wie, czy przelew jest „słuszny”), ale o żelazną zgodność z wewnętrznymi regułami bazy danych (np. typy danych, klucze obce).
- Scenariusz awarii: Baza ma regułę, że saldo nie może być ujemne. Bez wymuszenia spójności, w wyniku błędu aplikacji, baza mogłaby przyjąć operację wypłaty 200 zł z konta, na którym jest tylko 100 zł.
- Skutek: Powstaje logiczny chaos. Mamy ujemne saldo tam, gdzie system go nie przewiduje, lub dwóch użytkowników z tym samym identyfikatorem. Dane stają się technicznie „brudne” i nieprzetwarzalne przez dalsze procesy.
Izolacja (Isolation): Iluzja wyłączności Każda transakcja odbywa się w separacji, nawet przy setkach równoległych procesów. System udaje, że przetwarza zapytania jedno po drugim.
- Scenariusz awarii: Dwie osoby jednocześnie klikają „Kup teraz” na ostatni dostępny bilet do kina. Bez izolacji system sprawdza dostępność dla obu procesów w tej samej milisekundzie i obu zwraca status „wolne”.
- Skutek: Sprzedano dwa bilety na to samo miejsce (tzw. Race Condition). W bankowości prowadzi to do sytuacji, w której raporty finansowe generowane w trakcie dnia uwzględniają dane z transakcji, które za chwilę zostaną wycofane.
Trwałość (Durability): Zapis wykuty w kamieniu Gwarancja, że po potwierdzeniu operacji dane są fizycznie bezpieczne i przetrwają awarię zasilania.
- Scenariusz awarii: Wpłatomat przyjmuje gotówkę i wyświetla komunikat „Zaksięgowano”, ale dane znajdują się tylko w ulotnej pamięci RAM serwera. Sekundę później następuje restart maszyny.
- Skutek: Klient ma fizyczne potwierdzenie wpłaty, ale w bazie danych nie ma po niej śladu. Trwałość wymusza kosztowną operację fizycznego zapisu na dysk przed wysłaniem potwierdzenia do klienta.
Serwery typu IBM Power i mainframe wciąż w grze?
Spełnienie wszystkich czterech wymogów ACID jest niezwykle kosztowne obliczeniowo. Izolacja wymaga blokowania rekordów, a trwałość wymusza czekanie na wolne operacje I/O dysku. To sprawia, że systemy ACID słabo skalują się horyzontalnie (trudno utrzymać ten rygor, gdy dane są rozrzucone na 1000 tanich serwerów).
Tutaj wchodzi rola architektury IBM Power. W obliczu twierdzenia CAP (które mówi, że system rozproszony nie może gwarantować jednocześnie Spójności, Dostępności i Odporności na awarię sieci), banki zawsze wybierają Spójność kosztem Dostępności. Wolimy, żeby system bankowy na chwilę przestał odpowiadać, niż żeby pokazał nieprawdziwe saldo. Maszyny klasy mainframe i Power są projektowane do skalowania wertykalnego (do pojedynczej VM/LPARa można przydzielić dużą ilość zasobów CPU i RAM a architektura pozwala na ekstremalną wydajność I/O dysków) potrafią obsłużyć gigantyczny wolumen transakcji w jednym, spójnym środowisku pamięci, minimalizując narzut związany z synchronizacją, który zabiłby wydajność rozproszonego klastra x86 przy takim reżimie spójności.
Nie tylko bankowość
Choć bankowość jest koronnym przykładem, model ACID jest równie krytyczny w systemach zarządzania łańcuchem dostaw (Supply Chain) oraz systemach ERP.
Wyobraźmy sobie wielki, zautomatyzowany magazyn firmy farmaceutycznej lub motoryzacyjnej. Operacja przesunięcia palety z towarem z „Lokalizacji A” do „Lokalizacji B” to klasyczna transakcja, która musi być atomowa. Jeśli system zdejmie towar ze stanu w punkcie A, ale z powodu awarii nie dopisze go w punkcie B, powstaje „towar widmo”, fizycznie istnieje, ale system go nie widzi. Równie kluczowa jest tu izolacja. W przypadku części o krytycznym znaczeniu (np. silniki lotnicze), nie możemy dopuścić do sytuacji, w której ten sam unikalny numer seryjny części zostanie przypisany do dwóch różnych zleceń serwisowych jednocześnie. W takich środowiskach „przybliżona wiedza” o stanie magazynowym jest bezwartościowa. Inżynierowie utrzymujący te systemy wybierają architekturę IBM Power, ponieważ koszt przestoju linii produkcyjnej z powodu niespójności danych często przewyższa koszty samej infrastruktury.
BASE to odpowiedź na skalę Internetu
Kiedy jednak wychodzimy poza systemy krytyczne i wchodzimy w świat gigantów e-commerce (Amazon, Google), priorytety się odwracają. Tutaj kluczowa jest skala. Wymóg obsługi milionów użytkowników wymusił rezygnację ze sztywnego ACID na rzecz modelu BASE (Zasada), akronimu będącego technologicznym żartem z „kwasu” i oznaczającego:
Basically Available (Zasadniczo dostępne): System zawsze odpowiada na żądanie użytkownika, nawet jeśli część infrastruktury uległa awarii lub dane są niekompletne. Priorytetem jest utrzymanie „życia” systemu, a nie poprawność odpowiedzi.
- Scenariusz awarii: Wyobraźmy sobie awarię części klastra bazy danych w sklepie internetowym podczas Black Friday. W modelu ACID sklep musiałby wstrzymać sprzedaż, by nie dopuścić do niespójności stanów magazynowych.
- Skutek: W modelu BASE system przełącza się w tryb przetrwania. Klient widzi produkt jako „Dostępny” (korzystając z lokalnej kopii danych lub cache), mimo że w rzeczywistości towar mógł się wyprzedać 5 minut temu. Sklep woli zaryzykować konieczność późniejszego anulowania zamówienia („przepraszamy, pomyłka magazynowa”), niż wyświetlić klientowi stronę błędu 503 i stracić pewny ruch na stronie.
Soft State (Stan miękki): Stan systemu jest płynny i może ulegać zmianie bez jakiejkolwiek interakcji ze strony użytkownika, wynikając jedynie z upływu czasu i procesów synchronizacji w tle.
- Scenariusz: Użytkownik wrzuca produkt do koszyka w aplikacji mobilnej i minimalizuje ją, nie wykonując żadnej akcji. W międzyczasie w tle, węzeł do którego podpięty jest telefon, otrzymuje z opóźnieniem informację od reszty klastra, że sesja wygasła lub cena uległa zmianie.
- Skutek: Mimo że użytkownik nie kliknął żadnego przycisku, zawartość jego koszyka lub cena zmienia się „sama z siebie” po ponownym otwarciu aplikacji. W systemach ACID stan jest „twardy” (zmienia się tylko na wyraźne żądanie transakcji), w BASE stan ewoluuje, dążąc do spójności, co sprawia wrażenie, że dane są „miękkie” i niestabilne w krótkim okresie.
Eventual Consistency (Spójność Ostateczna): To serce tego modelu. Nie gwarantujemy spójności „tu i teraz”. Obiecujemy jedynie, że jeśli przestaniemy wprowadzać zmiany, to po pewnym czasie wszystkie serwery na świecie uzgodnią jedną wersję prawdy.
- Scenariusz: Popularny influencer publikuje post na portalu społecznościowym. W pierwszej sekundzie post widzi 1000 osób i klika „Lubię to”. Użytkownik w Polsce widzi pod postem liczbę „5 lajków”, a użytkownik w USA widzi „300 lajków”.
- Skutek: Każdy użytkownik operuje na innej wersji rzeczywistości. System nie blokuje licznika dla każdej aktualizacji (co zabiłoby wydajność), lecz pozwala na tymczasowe „kłamstwo”. Dopiero po chwili (gdy serwery „wyplotkują” między sobą zmiany) wszyscy zobaczą tę samą liczbę. W bankowości taka sytuacja (widzenie innego salda w zależności od serwera) byłaby niedopuszczalna, w social media jest standardem.
W social media opóźniony licznik to tylko drobna niedogodność. W bankowości czy systemach ERP taka ostateczna spójność jest nieakceptowalna.
Inżynieryjny pragmatyzm ponad dogmaty
Decyzja o wyborze między ACID a BASE powinna wynikać z analizy wymagań biznesowych, a nie z przyzwyczajeń technologicznych zespołu. Jeśli projektujesz system księgowy, inwentaryzację magazynu czy procesowanie płatności, model ACID pozostaje bezkonkurencyjny, ponieważ koszt błędu lub niespójności danych jest tu nieakceptowalny. Żadna elastyczność nie zrekompensuje braku pewności co do stanu salda na rachunku. Platformy takie jak IBM Power doskonale wspierają ten model, oferując moc obliczeniową niezbędną do szybkiego przetwarzania złożonych, blokujących się transakcji.
Z kolei model BASE jest naturalnym wyborem dla analityki big data, systemów cache’owania czy agregatorów treści, gdzie pojedynczy zgubiony rekord czy kilkusekundowe opóźnienie w synchronizacji nie powoduje strat finansowych. W takich przypadkach narzut związany z blokowaniem zasobów i wymuszaniem natychmiastowej spójności byłby marnotrawstwem zasobów obliczeniowych i wąskim gardłem dla użytkownika końcowego.
Najskuteczniejszą strategią we współczesnym IT, zwłaszcza w bankowości i e-commerce, staje się architektura hybrydowa. Jest ona odpowiedzią na potrzeby dzisiejszego rynku, gdzie wymagamy od siebie aptekarskiej precyzji (ACID), podczas gdy klienci oczekują natychmiastowej dostępności 24/7 (BASE). W praktyce oznacza to budowę systemów dwuwarstwowych:
Rdzeń (Core): Oparty na solidnych, relacyjnych bazach danych uruchomionych na niezawodnych serwerach IBM Power. Tutaj odbywa się „księgowanie prawdy”, operacje finansowe, stany magazynowe i dane krytyczne, które muszą być spójne i trwałe, niezależnie od kosztów wydajnościowych.
Brzeg (Edge): Warstwa obsługi klienta oparta na lekkich bazach NoSQL (BASE). Dane z rdzenia są replikowane do tej warstwy w modelu „eventual consistency”. Klient, logując się do aplikacji mobilnej, korzysta z szybkiej kopii danych (widok BASE), co gwarantuje mu błyskawiczny czas reakcji i ciągłość działania nawet przy dużym obciążeniu.
Taki podział ról pozwala nam „zjeść ciastko i mieć ciastko”: spełniamy rygorystyczne wymogi audytorów dzięki ACID w sercu systemu, jednocześnie oferując klientom zwinność i responsywność, jakiej nauczyli się od gigantów technologicznych. Efektywna architektura to taka, która nie walczy z tym dualizmem, ale wykorzystuje mocne strony obu tych światów.
źródła:
https://www.ibm.com/docs/en/iis/11.7.0?topic=transactions-transaction-properties
https://pasksoftware.com/acid-vs-base
https://pl.wikipedia.org/wiki/ACID
https://danieljeziorski.pl/pojecia-acid-oraz-base-w-kontekscie-baz-danych-nosql
https://en.wikipedia.org/wiki/CAP_theorem
https://cs-people.bu.edu/mathan/reading-groups/papers-classics/recovery.pdf