W czasach dzisiejszych, gdy biznesy często są globalne a działalność operacyjna większości przedsiębiorstw opiera się na systemy informatyczne, pojawiają się problemy z dostępnością danych czy serwisu ogółem. Zcentralizowane systemy jak najbardziej zdają egzaminy w większości przypadków, da się bez problemu używać z systemu uruchomionego w Europie będąc fizycznie w Australii czy na Hawajach, ale doświadczenie klientów z takimi systemami może być oceniane średnio – głównie za sprawą niskiej wydajności sieci. Choć o tzw latency rzędu maks 2s-3s można było kiedyś tylko pomarzyć – pamiętam jeszcze czasy dial-up i te długie minuty buforyzowania filmiku na youtube, – ale w dziś takie czasy odpowiedzi już są uznawane za mauvais ton.
Inżynierowie systemów informatycznych borykają się z problemamy wydajnościowymi chyba od udostępnienia pierwszych publicznych serwisów, czy to bankowych systemów transakcyjnych czy zwykłej strony internetowej. Często dla rzadko zmieniających się danych stosuje się cache, czy to na CDN, czy w web serwerze czy jakiś Redis lub podobny. Takie cache są ok, aż do momentu jak dane zaczną się zmieniać tak często że koszt aktualizacji cache jest większy od round-tripa do instancji bazy.
Jednym z rozwiązań problemu szybkości dostępu do danych w rozproszonym systemie informatycznym może być tzw sharding czy też replikacja bazy. Są to podobne do siebie zagadnienia pracy rozproszonej bazy danych, ale różnią się działaniem – sharding wykorzystuje się żeby rozdzielić fizycznie dane na różnych nodach, np. dane dt klientów z Australii trafiają do instancji bazy na serwerze w Australii a dane dt klientów z Polski do instancji znajdującej się fizycznie w Polsce. Choć dane te fizycznie są rozdzielone, ale wszystkie shardy tej bazy tworzą jedną rozproszoną bazę danych. Natomiast, replikację używa się głównie jako jedno z zabezpieczeń na wypadek awarii głównego node, różne systemy bazodanowe wspierają różne opcje replikacji gdzie większość stawia na architekturę jednego master-node (np. mongodb), są też bazy w których może być kilka master-node (milti-master, np. postgresql) – różnica jest taka, że mając jednego master-node możemy pisać dane tylko do niego, natomiast czytać możemy też z secondary-node, a mając architekturę multi-master możemy pisać i czytać z dowolnego node.
Każdy przypadek użycia powinien być osobno analizowany, którą opcję należy wybrać, biorąc pod uwagę przede wszystkim jak często dane są aktualizowane w bazie oraz sposób dostania się do danych z innego regionu czy availabilty zone (AZ).
Architekturę jednego master-node nie oznacza że nie da się przyspieszyć operację zapisu danych do bazy, ale sama architektura takiego rozwiązania komplikuje się. Załóżmy, że szybki rozwój działalności operacyjnej przedsiębiorstwa w Australii, Nowej Zelandii oraz na wschodnim wybrzeżu Stanów Zjednoczonych spowodowało obciążenie głównego DC firmy, klienty narzekają na niezbyt szybkie działanie, więc zarząd wydzielił budżet i kazał poprawić działanie autorskiego systemu informatycznego używanego przez klientów.
Po burzliwej naradzie, starsi eksperci IT zdecydowali że trzeba uruchomić nowy DC w Australii i w Stanach Zjednoczonych oraz uruchomić tam serwery aplikacyjne i rozproszyć bazę danych na trzy kontynenty. Wszystkie trzy DC (region) powiązali między sobą za pomocą VPN czy L2TP czy jeszcze czegoś do VLAN, uruchomili w nowych DC kontenery z mikroserwisami i za pomocą Cloudflare czy innego routingu przekierowali ruch do DC zgodnie z fizyczną obecnością klienta – klienci z Europy łączą się z polskim DC, klienci z Australii i Nowej Zelandii z australijskim DC a klienci z USA z DC uruchomionym w stanie Virginia. Poprawiło to czasy odpowiedzi serwerów, ale nie we wszystkich przypadkach, gdyż fizycznie trzeba było łączyć się z bazą z centralnego DC.
Oprogramowanie to korzysta z MongoDB, dlatego została podjęta decyzja o shardowaniu bazy na trzy DC na podstawie jakiś danych geograficznych, np kraju siedziby klienta, ale rozwiązanie dalej nie było idealne, gdyż centrala firmy w Polsce obsługując klientów z poza Europy miała problemy z wydajnością, gdyż trzeba było chodzić po dane na inny koniec świata. I tutaj MongoDB wjeżdża całe na biało z jego możliwością replikacji shard-node, czyli kopia shardu uruchomionego w Sydney została uruchomiona w Polsce i w NY, to samo z pozostałymi shardami, a oprogramowanie zaczęło czytać z lokalnych replik shardów z innych regionów. Dane w lokalnych replikach shardów z innych regionów czy innych AZ nie są aktualizowane in real-time, ale mechanizm synchronizacji w Mongo daje satysfakcjonujące rezultaty. Dodatkowo, w razie awarii głównego node w replice sharda, Mongo jest w stanie zabezpieczyć przepięcie na jego secondary-node czyli do innego regionu co znacząco zwiększa niezawodność systemu w całości.
Architektura multi-master node jest dostępna głównie w SQL baza danych, np Microsoft SQL Server czy PostgreSQL i może być wykorzystywana w opisanym wyżej przykładzie – np. Microsoft SQL Server ma Peer-to-Peer replikację, w której dane zapisane do jednego DC/regionu/AZ będą propagowane do innego DC/regionu/AZ i vice-versa. Ale najbardziej z możliwości replikacji w SQL Serverze mi się podoba to tzw Merge replication – gdy serwery nie są połączone stale między sobą a wykonują synchronizację danych w bazie raz na jakiś czas, wspaniała rzecz choć i jest ciężka w utrzymaniu – każda zmiana bazy (zmiana SP czy funkcji) wymaga zdjęcia replikacji i założenia jej ponownie po aktualizacji wszystkich serwerów, a to jest proces czasochłonny i potrafiący czasem się wywalić – pamiętam te długie noce deploymentu, a w szczególności gdy nad ranem założenie replikacji się wysypało a za 2h firma rozpoczyna pracę a bez tego nie może obsłużyć nowych zamówień…
Każdy system informatyczny potrzebujący rozproszenia potrzebuje swego unikalnego podejścia – co działa w jednym przypadku nie zawsze będzie działało w innym, dlatego każde prace dt rozproszenia systemu informatycznego po świecie wymagają szczegółowej analizy zarówno od strony biznesowej jak i technicznej żeby wybrać optymalną opcję. I takie projekty skalowania systemu prędzej czy później dotkną większość systemów, chyba że firma skupia się tylko na jednej lokalizacji i nie zamierza robić ekspansję zagranicą. A napewno multi-region deployment przyda się API wspierającym aplikacje mobilne dostępne w każdym zakątku świata.