Mikroserwis a Cloud DB

Mamy, dajmy na to, 3 dobrze wydzielone mikroserwisy. 1 potrzebuje storagu w SQL, drugi w bazie documentowej - nosql, 3 - nie potrzebuje storagu.

Normalnie każdy mikroserwis powinien mieć fizycznie wydzieloną bazę danych, ale załóżmy że jesteśmy 'nowocześni' i chcemy mieć Google Clouda...

Rozumiem, że 'po staremu' każdy mikroserwis wewnątrz będzie miał 'logikę' odpowiedzialną za connection do bazy i obsługę tabelek, jsonów itp.

Ale czy musimy mieć instancje Cloud SQL, Cloud Datastore per każdy mikroserwis (i środowisko - Dev, stage...). Czy może wystarczy jedna współdzielona instacja Cloud SQL/Datastore per środowisko (tj. stage, prod) i każdy mikroserwis 'wali' do prywatnego schematu na bazie...

Klasycznie często się robiło w gołym SQL tak że jeden serwer obsługiwał wiele apek. Po prostu każda apka miała użytkownika + własną bazę, więc nie mogły nawzajem do siebie zaglądać.

Cloud SQL od Googla to po prostu hostowany serwer bazy danych np. MySQL więc działa to tak samo jak wcześniej, tylko że teraz oni robią za ciebie fixy security czy martwią się o RAM. Tak samo możesz tworzyć bazy danych i użytkowników (loginy).

Do setna, wylicz ile mocy obliczeniowej potrzebujesz. Zdecyduj jakie mają być wymagania reliability (najlepiej brać serwer + follower replikę, tak żeby zrobić safe failover jakby się coś z serwerem stało). Wybierz typ instancji (np. 4 core'y czy 64 core'y, przy bazie danych najważniejsze to dysk i RAM). Przelicz koszta. Zrób PowerPointa z porównaniem kilku opcji i niech szef zaklepie.

Do tego wybierz też plan backupów. Generalnie dopóki jest izolacja między aplikacjami nie ma znaczenia czy te bazy siedzą na jednym serwerze czy na kilku.

czyli generalnie logiczne wydzielenie baz danych nie łamie koncepcji czystych mikroserwisów?
Wydaje mi się, że idealnie gdyby każdy mikroserwis miał fizycznie wydzieloną instancje db z repliką.

Jedna współdzielona fizycznie (a rozdzielona logicznie), nawet od wspanialego Googla może być przeciażona przez jakis jeden mikroserwis, co rzutuje na kolejne. Failover replica załatwi pewnie problem z dostepnoscia, ale czy dalej nie bedzie to waskie gardlo przy skalowaniu systemu?

Dobre pytanie, na które ja Ci nie odpowiem. Jako inżynier musisz wyliczyć ile zasobów będziesz potrzebował, i jaki będzie koszt. Czasami okaże się że faktycznie powinno być jak piszesz ale koszt będzie nie do zaakceptowania. Generalnie jak masz dużo danych to raczej unikałbym SQLa lub szedł w rozwiązanie SQL + Cache (np. Redis). Za tego typu porady ludzie kasują po 25k na fakturę...

Podstawowa sprawa to to ile danych chcesz tam trzymać. SQLe skalują się tylko wertykalnie (mocniejszy serwer). Bazy rozproszone typu Cassandra skalują się horyzontalnie, ale nie jest to automatyczne. Dodanie node do Cassandry to ciężka operacja która wiąże się z przesłaniem sporej ilości danych. W sumie byłem świadkiem sytuacji gdzie dodanie nowego node'a (węzła) do mocno obciążonej bazy zabiło Cassandre.

CAP Theorem ogranicza to co jest możliwe.

Chmurowe "produkty bazodanowe" są bardziej ciekawe pod tym względem. Przykładowo https://cloud.google.com/spanner mówi że ma infinite scaling. Niestety nigdy z nim nie pracowałem.

Generalnie zawsze możesz wykupić support od dostawcy chmury i tam już Ci doradzą i podpowiedzą jakie są rozwiązania.

SQLe skalują się tylko wertykalnie (mocniejszy serwer). Bazy rozproszone typu Cassandra skalują się horyzontalnie, ale nie jest to automatyczne.

No chyba nie do końca

konradino898 napisał(a):

czyli generalnie logiczne wydzielenie baz danych nie łamie koncepcji czystych mikroserwisów?

Wydaje mi się, że idealnie gdyby każdy mikroserwis miał fizycznie wydzieloną instancje db z repliką.

Jedna współdzielona fizycznie (a rozdzielona logicznie), nawet od wspanialego Googla może być przeciażona przez jakis jeden mikroserwis, co rzutuje na kolejne. Failover replica załatwi pewnie problem z dostepnoscia, ale czy dalej nie bedzie to waskie gardlo przy skalowaniu systemu

Jeśli serwisy odizolujesz od siebie w taki sposób, że każdy będzie wiedział tylko o swojej bazie i żadna nie będzie współdzielona to gdzie widzisz problem w tym czy one znajdują się fizycznie na jednym serwerze czy nie? Jeśli któryś z nich będzie zbyt mocno obciążać serwer to możesz jego bazę postawić na osobnym serwerze lub wyskalować jak tylko chcesz.

konradino898 napisał(a):

Normalnie każdy mikroserwis powinien mieć fizycznie wydzieloną bazę danych, ale załóżmy że jesteśmy 'nowocześni' i chcemy mieć Google Clouda...

Nie do końca moim zdaniem. Każdy micro service powinien mieć swoje dane na wyłączność. Czy użyjesz do tego osobnych maszyn, osobnych baz danych, schematów itd. - dla mnie ok. Jak chcesz mieć jedną instancję serwera, to dobrym pomysłem jest podział na osobne bazy danych w jego ramach. W razie czego łatwiej przenieść na inną maszynę

Rozumiem, że 'po staremu' każdy mikroserwis wewnątrz będzie miał 'logikę' odpowiedzialną za connection do bazy i obsługę tabelek, jsonów itp.

Część serwisów może korzystać wyłącznie z API innych serwisów.

Ale czy musimy mieć instancje Cloud SQL, Cloud Datastore per każdy mikroserwis (i środowisko - Dev, stage...). Czy może wystarczy jedna współdzielona instacja Cloud SQL/Datastore per środowisko (tj. stage, prod) i każdy mikroserwis 'wali' do prywatnego schematu na bazie...

Środowiska powinny być moim zdaniem izolowane w 100%:

• Połączenia pomiędzy środowiskami obniżają bezpieczeństwo (dodatkowe wektory ataku)
• Łatwo o pomyłkę chciałam napisać select a napisałam delete i on nie zapytał, albo "wyłączę ten serwer, będzie taniej".
• Infrastruktura obecnie to również część deploymentu (Infastructure as a Code).

Zwiększanie liczby serwerów baz zwiększa ci izolację serwisów, ale sprawia, że monitoring, serwisowanie, replikacje itd. robią się bardziej upierdliwe. Oczywiście dochodzą do tego koszty.

A po co Tobie cloud sql? Masz jakiś szczególny powód, oprócz tego, że znam?

Jak już jesteś w GCP'ie i wdrażasz serwisy w GCP'ie i rozważasz datastore / firestore - to świetny wybór bo obsługuje za Ciebie multitenancy (dla mikroserwisów), skalowanie, skonfigurowanie całego monitoringu, autentykacje, zasady bezpieczeństwa - nie będziesz musiał sam tego ręcznie robić.

Bez konkretnych powodów nie pchałbym się z gcpowskich zarządzalnych usług w kierunku cloud sql'a.

@0xmarcin Spanner to jest enterprise kombajn, który jest niesamowicie drogi w GCP'ie w porównaniu do innych baz danych. Bez wymogów "system critical" to będzie przerost formy nad treścią.