Spójność danych mikro serwisów po Disaster Crash Recovery

0

Jak bezpiecznie odtworzyć dane w kilku usługach jednocześnie, przy założeniu, że każdy z nich ma osobną bazę danych, dla większej zabawy załóżmy, że są one różne (SQL, NoSQL itd.)

Problem:
Specyfika biznesu nie pozwala na utratę żadnych danych (RPO=0).

Architektura (SAGA)
Klient wysyła żądanie do usługi A, która zapisuje je ze stanem PENDING, oraz potwierdza otrzymanie żądania, wysyła do kolejnych serwisów B, C, które wykonują zapisy w swoich bazach danych i informują A o dokonaniu zapisu. A zapisuje potwierdzenia i ustawia stan CONFIRMED po otrzymaniu kompletu.

Z jakiegoś powodu, wszystko idzie w cholerę i konieczne jest odtworzenie kopii zapasowych. Jak zapewnić, że dane będą spójne po odtworzeniu?

6
  1. Zbierać wszystko co przychodzi jako eventy
  2. Jak potrzebujesz odtworzyć dane, to robisz replay eventów
  3. Profit!

Dzięki temu w ogóle nie obchodzi cię czy masz tam bazę danych i jaką, bo załadowaniem danych i odtworzeniem stanu zajmą się serwisy, tak jak robią to "normalnie". Ty tylko robisz taki trochę fast-forward całej historii swiata.

0

Zaletą jest prostota i kompletne nie przejmowanie się danymi w drodze. Muszę jeszcze policzyć ile taki forward historii świata będzie trwać / kosztować, ale z drugiej strony traktuję to jako ostateczną ostateczność (mam jeszcze instant replication). Sprawdzę na ile wszystkie bazy wspierają przywracanie do określonego momentu w czasie i coś pokombinować.

1

@shalom a to nie będzie tak, że np. taki backup po roku będzie się odtwarzał np. tydzień? Bo rozumiem, że każdy event musi być ponownie przetworzony przez mikroserwisy, czyli tracimy podstawową zaletę odtwarzania z backupu - bulk load. Także co w przypadku, kiedy zmieniła się logika serwisu i eventy są inaczej zapisywane w bazie?

0

@abrakadaber: Tak, to jest problem, ale teoretycznie - skaluję poziomo całą infrastrukturę, limitem są poszczególne bazy danych i ew. inne usługi typu kolejki.

2
  1. Czy potrzebujesz strong consistency? Czy potrzebujesz niskiego czasu odpowiedzi?

Rozwiązanie z replayem eventow jest dobre ale trzeba sie troche napracowac zeby to dobrze dzialalo - np. musisz wprowadzic snapshoty (inaczej patrz komentarz @somekind), deterministyczne maszyny stanów itd. Fast-forward to zazwyczaj nie problem jak już masz snapshoty np. dzienne, co wiecej pewnie bedziesz mial secondary ktora w razie crashu przejmie rolę primary i bedzie kontynuować.

Do tego dojdą typowe problemy rozproszonego systemu i przesyłania wiadomości, tutaj zazwyczaj albo musisz mieć idempotency albo porozumiewać się odpowiednim protokołem (np. FIXem).

Także co w przypadku, kiedy zmieniła się logika serwisu i eventy są inaczej zapisywane w bazie?

Nic, robimy snapshoty i nie wprowadzamy zmian w trakcie dnia które nie są kompatybilne wstecz, jeżeli już musimy hotfixa wprowadzić to hotfix musi uwzględnić replay.
Generalnie problemy podobne jak przy typowym trzymaniu stanu, z ta różnica że nic nam nie znika: "co zrobić jak już mamy syf w bazie danych?"

Ogólnie nie polecam jeżeli masz mały i niedoświadczony zespół. Transakcje w rozproszonych systemach to duży temat, szczególnie jak nie możesz wszystkiego synchronicznie zrobić z jakiegoś powodu.

0

taki backup po roku będzie się odtwarzał np. tydzień?

W praktyce masz pewnie jakiś backup wczesniejszy niż rok temu i możesz robic replay od tej chwili :)

Także co w przypadku, kiedy zmieniła się logika serwisu i eventy są inaczej zapisywane w bazie?

jw.

0

Tylko backup migawkowy niestety psuję całą koncepcję. Wtedy musisz przywrócić stan wszystkich uS, a nie tylko przepuścić cały event log przez system. Drugie pytanie jest prostsze - nie zmieniasz logiki, dodajesz nową i zmieniasz typ eventu. API też trzeba wersjonować.

0

Tylko backup migawkowy niestety psuję całą koncepcję.

Nie jest konieczny, ale jeśli ktoś się boi ze replay eventów zajmie długi czas (albo logika obsługi niektórych eventów uległa zmianie po drodze) to inaczej się nie da.

1

Nie wiem czy takie disaster recovery, to powinieneś patrzeć technicznie, czy raczej ze strony biznesowej, tj. istotne jest wznowienie działalności operacyjnej jak najszybciej się da, tak by minimalizować straty wynikające z przestoju biznesu. np. Katastrofa = Pociąg się wykoleił => dany odcinek jest nieprzejezdny i jest masa innych problemów, które wymagają potraktowania z innym priorytetem, np.

  • ratowanie rannych
  • udrożnienie odcinka
  • posprzątanie terenu

Co do problemu z odtwarzaniem wielu komponentów. Na myśl przychodzi mi Restore & Recovery.

  1. Restore = odtworzenie backupu wszystkich baz do "ostaniego commita"
  2. Recovery = identyfikacja procesów typu "pending" i ich ponowne wykonanie, ale..
  • serwisy powinny oferować tryb "bypass" tak by przetworzenie operacji nie miało konsekwencji biznesowych (bo jak np. zjeść ciastko, które zostało już zjedzone? wysłać paczkę, która została już wysłana itd.),
  • lub wspierać idempotentność

Jeśli serwisy nie posiadają odpowiednich operacji wspierających takie recovery, to pozostaje rozwiązanie klasy "data integration" & "data reconciliation".

Dla każdego procesu biznesowego (saga w nomenklaturze serwisów?) można zaprojektować proces kompensacyjny, który dostanie eventa typu "RecoveryNeeded" i ponowi operacje, które zawiodły.

Ogólne rozwiązanie problemu w sposób zautomatyzowany wydaje mi się co najmniej bardzo trudne, bo patrząc tylko technicznie, nie wiadomo jakie będą konsekwencje biznesowe.

0

@yarel: Mam wymagania biznesowe, dotyczące SLA. Rozwiązuję je poprzez regiony active-passive. Bazy danych aktualnie replikowane są do drugiego regionu (instant replication), więc nie boję się za bardzo utraty danych. Scenariusz przed jakim chcę się zabezpieczyć, to zdarzenia typu on sam napisał drop table .... Więc z jednej strony scenariusz dość katastroficzny, z drugiej jeżeli się już przydarzy, to trudno - przekroczymy zakładane SLA.

1

@piotrpo: rozumiem, w takiej sytuacji chyba lepiej stosować profilaktykę niż leczyć chorobę :) Przed wszystkimi zdarzeniami się nie uchronimy, niektórym możemy zapobiegać, np. drop table -> nie dajemy użytkownikom uprawnień do takich działań (rozumiem, że to tylko taki poglądowy przypadek, ale listując inne przypadki, które są problematyczne, można też dobrać rozwiązania i zmniejszyć ryzyko katastrofy).

Co do samych mikro serwisów, to widzę, że stosunkowo niedawno pojawił się koncept BAC theorem (Backup/Availability/Consistency). Przyjemnie mi się czytało

1

Profilaktykę mogę stosować do tego co przewidzę. Wszystkiego nie jestem w stanie zabezpieczyć. Bardzo za to nie chcę wyjść na debila jak stanie się coś nieprzewidzianego, więc wolę mieć przygotowane "coś", co pokryje te wpadki, którym profilaktyka nie dała rady.

1 użytkowników online, w tym zalogowanych: 0, gości: 1