Jak przetrwać w świecie SQL w XXI wieku: chmury, Kubernetes i PostgreSQL multimaster.

Cześć, użytkownicy Habr. Dziś rozpoczynają się zajęcia w pierwszej grupie kursu „PostgreSQL”. W związku z tym chcemy opowiedzieć o tym, jak przebiegał otwarty webinar dotyczący tego kursu.

W kolejnym otwartym lekcji porozmawialiśmy o wyzwaniach, przed którymi stanęły bazy danych SQL w erze chmur i Kubernetes. A przy okazji omówiliśmy, jak bazy danych SQL przystosowują się i mutują pod wpływem tych wyzwań.

Webinar poprowadził Walerij Bezrukow, Menedżer ds. Realizacji Praktyki Google Cloud w EPAM Systems.

Kiedy drzewa były małe…

Na początek przypomnijmy sobie, jak wyglądał wybór systemów zarządzania bazami danych na końcu XX wieku. Jednak nie będzie to trudne, ponieważ wybór SGBD w tamtych czasach zaczynał i kończył się Oracle.

Na końcu lat 90-tych - na początku lat 2000-nych, w zasadzie nie było specjalnego wyboru, jeśli chodzi o przemysłowe skalowalne Bazy Danych. Tak, istniały IBM DB2, Sybase i kilka innych baz danych, które pojawiały się i znikały, ale ogólnie rzecz biorąc, były mało zauważalne w porównaniu do Oracle. W związku z tym umiejętności inżynierów tamtych czasów były w taki czy inny sposób związane z tym jedynym wyborem, który istniał.

Oracle DBA musiał umieć:

• instalować Oracle Server z dystrybucji;
• konfigurować Oracle Server:

• init.ora;
• listener.ora;

— tworzyć:

• przestrzenie tabel;
• schematy;
• użytkowników;

— wykonywać kopie zapasowe i odzyskiwanie;
— monitorować;
— walczyć z nieoptymalnymi zapytaniami.

Jednocześnie od Oracle DBA nie wymagano szczególnie:

• umiejętności wyboru optymalnego SGBD lub innej technologii przechowywania i przetwarzania danych;
• zapewnienia wysokiej dostępności i poziomej skalowalności (to nie zawsze było pytanie dla DBA);
• dobrej znajomości dziedziny, infrastruktury, architektury aplikacji, systemu operacyjnego;
• wykonywania ładowania i pobierania danych, migracji danych między różnymi SGBD.

Generalnie, jeśli mówimy o wyborze w tamtych czasach, przypomina to wybór w radzieckim sklepie na końcu lat 80-tych:

Nasz czas

Od tego czasu, oczywiście, drzewa urosły, świat się zmienił, a teraz wygląda to tak:

Zmienili się również rynek SGBD, co dobrze widać w świeżym raporcie firmy Gartner:

I tutaj nie można nie zauważyć, że swoją niszę zajęły chmury, których popularność rośnie. Jeśli przeczytamy ten sam raport firmy Gartner, zobaczymy następujące wnioski:

1. Wielu klientów znajduje się na drodze do migracji aplikacji do chmury.
2. Nowe technologie pojawiają się najpierw w chmurze i nie ma pewności, że kiedykolwiek przeniosą się do infrastruktury lokalnej.
3. Model cenowy oparty na zasadzie pay-as-you-go stał się powszechny. Wszyscy chcą płacić tylko za to, z czego korzystają, co jest już nie tylko trendem, ale po prostu stwierdzeniem faktu.

Co teraz?

Dziś wszyscy jesteśmy w chmurze. Pojawiające się pytania to pytania wyboru. A ten jest ogromny, nawet jeśli mówi się tylko o wyborze technologii baz danych w wersji On-premises. Mamy też usługi zarządzane i SaaS. W ten sposób wybór z każdym rokiem staje się coraz bardziej skomplikowany.

Obok pytań wyboru działają także ograniczające czynniki:

• cena. Wiele technologii wciąż kosztuje pieniądze;
• umiejętności. Jeśli mówimy o oprogramowaniu open-source, pojawia się kwestia umiejętności, ponieważ darmowe oprogramowanie wymaga od osób, które je wdrażają i obsługują, wystarczającej kompetencji;
• funkcjonalność. Nie wszystkie usługi dostępne w chmurze i budowane, powiedzmy, nawet na bazie Postgresa, mają te same funkcje, co PostgreSQL On-premises. To istotny czynnik, który należy znać i rozumieć. Co więcej, ten czynnik staje się ważniejszy niż znajomość jakichkolwiek ukrytych możliwości danej bazy danych.

Czego oczekują teraz od DA/DE:

• dobrego zrozumienia dziedziny oraz architektury aplikacji;
• umiejętności właściwego wyboru odpowiedniej technologii baz danych w zależności od postawionego zadania;
• umiejętności doboru optymalnej metody realizacji wybranej technologii w kontekście istniejących ograniczeń;
• umiejętności wykonywania przenoszenia i migracji danych;
• umiejętności wdrażania i obsługi wybranych rozwiązań.

Poniższy przykład oparty na GCP demonstrates how the choice of a particular data technology is structured depending on its structure:

Zwróć uwagę, że w schemacie nie ma PostgreSQL, ponieważ kryje się on pod terminologią Cloud SQL. A kiedy wchodzimy do Cloud SQL, musimy znów dokonać wyboru:

Należy zauważyć, że ten wybór nie zawsze jest jasny, dlatego programiści aplikacji często kierują się intuicją.

Podsumowując:

1. Im dalej, tym bardziej aktualne staje się pytanie wyboru. A nawet jeśli spojrzeć tylko na GCP, usługi zarządzane i SaaS, to pewne wzmianki o RDBMS pojawiają się dopiero na czwartym kroku (a tam Spanner obok). Dodatkowo, wybór PostgreSQL pojawia się w ogóle na piątym kroku, a obok jeszcze MySQL i SQL Server, czyli Bardzo dużo opcji, ale trzeba dokonać wyboru.
2. Nie można zapominać o ograniczeniach w obliczu pokus. Głównie wszyscy chcą Spanner, ale jest on drogi. W efekcie typowe zapytanie wygląda mniej więcej tak: „Proszę zróbcie nam Spanner, ale w cenie Cloud SQL, przecież jesteście profesjonalistami!”

Co robić?

Nie roszcząc sobie pretensji do jedynej prawdy, powiedzmy tak:

Należy zmienić podejście do nauczania:

• uczenie tak, jak w przeszłości DBA, nie ma sensu;
• wiedza o jednym produkcie obecnie już nie wystarcza;
• a znajomość dziesięciu na poziomie jednej — jest niemożliwa.

Należy znać nie tylko produkt, ani nawet nie ile, ale:

• przypadki jego zastosowania;
• różne metody wdrażania;
• zalety i wady każdej z metod;
• analogiczne i alternatywne produkty, aby podejmować świadomy i optymalny wybór, a nie zawsze w imię znanego produktu.

A także należy umieć migrować dane i rozumieć podstawowe zasady integracji z ETL.

Przykład z życia

W niedawnej przeszłości musiałem stworzyć backend dla aplikacji mobilnej. W momencie rozpoczęcia pracy nad nią backend był już opracowany i gotowy do wdrożenia, a zespół deweloperski spędził na tym projekcie około dwóch lat. Przy tym postawiono następujące zadania:

• zbudować CI/CD;
• przeprowadzić przegląd architektury;
• uruchomić to wszystko w eksploatacji.

Sama aplikacja była mikrousługowa, a kod w Python/Django został opracowany od podstaw i od razu w GCP. Jeśli chodzi o grupę docelową, zakładano, że będą dwa regiony — USA i EU, a ruch rozkładano za pomocą Global Load Balancer. Wszystkie obciążenia i obliczenia działały w Google Kubernetes Engine.

Jeśli chodzi o dane, to były 3 struktury:

• Cloud Storage;
• Datastore;
• Cloud SQL (PostgreSQL).

Może pojawić się pytanie, dlaczego wybrano Cloud SQL? Mówiąc szczerze, takie pytanie w ostatnich latach wywołuje pewną niezręczność — odnosi się wrażenie, że ludzie zaczęli wstydzić się baz relacyjnych, ale mimo to nadal aktywnie je stosują ;-).

Jeśli chodzi o nasz przypadek, Cloud SQL został wybrany z następujących powodów:

1. Jak wspomniano, aplikacja była rozwijana przy użyciu Django, a w niej istnieje model mapowania trwałych danych z bazy SQL na obiekty Python (Django ORM).
2. Sam framework wspierał wystarczająco ograniczoną listę DBMS:

• PostgreSQL;
• MariaDB;
• MySQL;
• Oracle;
• SQLite.

W związku z tym PostgreSQL wybrano z tej listy raczej intuicyjnie (no nie wybiera się w końcu Oracle).

Czego brakowało:

• aplikacja była wdrożona tylko w 2 regionach, a w planach pojawił się 3. (Azja);
• Baza danych znajdowała się w regionie północnoamerykańskim (Iowa);
• ze strony klienta pojawiły się obawy dotyczące możliwych opóźnień w dostępie z Europy i Azji oraz zakłóceń w obsłudze w przypadku awarii bazy danych.

Pomimo że Django może działać z wieloma bazami danych jednocześnie i dzielić je na operacje odczytu i zapisu, zapisy w aplikacji nie były liczne (ponad 90% to odczyt). W ogólnym zarysie, jeśli można by stworzyć replikę odczytu głównej bazy w Europie i Azji,byłoby to kompromisowym rozwiązaniem. A co jest w tym trudnego?

Trudność polegała na tym, że klient nie chciał rezygnować z korzystania z zarządzanych usług i Cloud SQL. Możliwości Cloud SQL w chwili obecnej są ograniczone. Cloud SQL obsługuje Wysoką dostępność (HA) i Replikę odczytu (RR), ale sama RR obsługiwana jest tylko w jednym regionie. Tworząc bazę danych w regionie amerykańskim, nie można stworzyć repliki odczytu w europejskim regionie za pomocą Cloud SQL, mimo że PostgreSQL to umożliwia. Korespondencja z pracownikami Google do niczego nie doprowadziła i zakończyła się obietnicami w stylu „wiemy o problemie i pracujemy nad nim, pewnego dnia ta kwestia zostanie rozwiązana”.

Jeśli wymienić możliwości Cloud SQL w punktach, to wyglądałoby to mniej więcej tak:

1. Wysoka dostępność (HA):

• w ramach jednego regionu;
• poprzez replikację dyskową;
• nie używane są mechanizmy PostgreSQL;
• możliwe automatyczne i ręczne zarządzanie — failover/failback;
• przy przełączaniu bazy danych jest niedostępna przez kilka minut.

2. Replika odczytu (RR):

• w ramach jednego regionu;
• hot standby;
• replikacja strumieniowa PostgreSQL.

Co więcej, jak to zwykle bywa, przy wyborze technologii zawsze natrafia się na jakieś ograniczenia: klient nie chciał mnożyć zasobów i korzystać z IaaS, poza GKE;:

• klient nie chciał rozwijać usług self service PostgreSQL/MySQL;
• no i w ogóle, Google Spanner byłby odpowiedni, gdyby nie jego cena, chociaż z nim Django ORM nie może pracować, a tak to rzecz dobra.
• Biorąc pod uwagę sytuację, klient zadał pytanie na zaś:

„Czy możecie stworzyć coś podobnego, żeby działało jak Google Spanner, ale jeszcze współpracowało z Django ORM?” Opcja rozwiązania nr 0

Pierwsze, co przyszło mi do głowy:

pozostać w ramach CloudSQL;

• wbudowanej replikacji między regionami nie będzie w żadnej formie;
• встроенной репликации между регионами не будет ни в каком виде;
• spróbować połączyć replikę z istniejącym Cloud SQL by PostgreSQL;
• gdzieś i w jakiś sposób uruchomić instancję PostgreSQL, ale przynajmniej nie ruszać mastera.

Niestety, okazało się, że nie da się tego zrobić, ponieważ nie ma dostępu do hosta (przebywa on w zupełnie innym projekcie) — pg_hba i tak dalej, a dodatkowo nie mamy dostępu jako superuser.

Opcja rozwiązania nr 1

Po kolejnych przemyśleniach i biorąc pod uwagę wcześniejsze okoliczności, tok myślenia nieco się zmienił:

• wciąż próbujemy pozostać w ramach CloudSQL, ale przechodzimy na MySQL, ponieważ Cloud SQL by MySQL ma external master, który:

— jest proxy dla zewnętrznego MySQL;
— wygląda jak instancja MySQL;
— został stworzony do migracji danych z innych chmur lub On-premises.

Ponieważ konfiguracja replikacji MySQL nie wymaga dostępu do hosta, w zasadzie wszystko działało, ale było bardzo niestabilne i niewygodne. A kiedy poszliśmy dalej, stało się wręcz przerażające, ponieważ całą strukturę rozwijaliśmy z użyciem terraform, a nagle okazało się, że external master nie jest wspierany przez terraform. Tak, Google ma CLI, ale z jakiegoś powodu wszystko działało jakby losowo — raz się tworzyło, raz nie. Może dlatego, że CLI zostało zaprojektowane do migracji danych z zewnątrz, a nie do replikacji.

Właściwie na tym stało się jasne, że Cloud SQL w ogóle nie pasuje. Jak się mówi, zrobiliśmy wszystko, co mogliśmy.

Opcja rozwiązania nr 2

Ponieważ nie udało się pozostać w ramach Cloud SQL, próbowaliśmy sformułować wymagania dotyczące kompromisowego rozwiązania. Wymagania okazały się następujące:

• działanie w Kubernetes, maksymalne wykorzystanie zasobów i możliwości Kubernetes (DCS, …) oraz GCP (LB, …);
• brak balastu w postaci mnóstwa zbędnych rzeczy w chmurze, takich jak HA proxy;
• możliwość uruchomienia w głównym regionie HA PostgreSQL lub MySQL; w pozostałych regionach — HA z RR głównego regionu plus jej kopia (dla niezawodności);
• multi master (nie chcieliśmy się z nim łączyć, ale nie było to bardzo istotne)

.
W wyniku tych wymagań na horyzoncie w końcu pojawiły się odpowiednie opcje DBMS i otaczające technologieMySQL Galera;:

• CockroachDB;
• Narzędzia PostgreSQL
• — pgpool-II;

:
— Patroni.
MySQL Galera

Technologia MySQL Galera została opracowana przez firmę Codership i stanowi plugin dla InnoDB. Cechy:

multi master;

• synchronizowana replikacja;
• odczyt z dowolnego węzła;
• zapis na dowolny węzeł;
• wbudowany mechanizm HA;
• istnieje Helm chart od Bitnami.
• есть Helm chart от Bitnami.

CockroachDB

Z opisu wynika, że jest to niesamowity projekt open source, napisany w Go. Głównym uczestnikiem jest Cockroach Labs (założona przez byłych pracowników Google). Ta relacyjna baza danych została stworzona jako rozproszona (z poziomym skalowaniem 'out of the box') i odporna na awarie. Jej twórcy z firmy postawili sobie za cel 'połączenie bogactwa funkcjonalności SQL z poziomą dostępnością, znaną z rozwiązań NoSQL'.

Miłym dodatkiem jest wsparcie dla protokołu PostgreSQL.

Pgpool

To nakładka na PostgreSQL, tak naprawdę nowy byt, który przejmuje wszystkie połączenia i je przetwarza. Ma własny load balancer i parser, licencjonowany na zasadach BSD. Oferuje szerokie możliwości, ale wygląda trochę niepokojąco, ponieważ obecność nowego bytu mogłaby stać się źródłem dodatkowych przygód.

Patroni

To ostatnia rzecz, na którą rzuciłem okiem, i, jak się okazało, nie bez powodu. Patroni to open source'owe narzędzie, które w zasadzie jest demonem w Pythonie, umożliwiającym automatyczną obsługę klastrów PostgreSQL z różnymi typami replikacji i automatycznym przełączaniem ról. Okazało się to bardzo interesujące, ponieważ dobrze integruje się z Kubernetes i nie wprowadza nowych bytów.

Co ostatecznie wybraliśmy

Wybór nie był łatwy:

1. CockroachDB — super, ale straszne;
2. Technologia MySQL Galera została opracowana przez firmę Codership i stanowi plugin dla InnoDB. Cechy: — też niezłe, używane w wielu miejscach, ale MySQL;
3. Pgpool — zbyt wiele zbędnych bytów, całkiem kiepska integracja z chmurą i K8s;
4. Patroni — doskonała integracja z K8s, brak zbędnych bytów, dobrze integruje się z GCP LB.

Tak więc wybór padł na Patroni.

Wnioski

Przyszedł czas na krótkie podsumowanie. Tak, świat infrastruktury IT uległ znacznym zmianom, a to dopiero początek. Jeśli kiedyś chmury były tylko innym typem infrastruktury, to teraz wszystko jest inaczej. Co więcej, innowacje w chmurach pojawiają się na bieżąco i będą się pojawiać, a być może będą się pojawiać tylko w chmurach, a następnie, siłami startupów, będą przenoszone do On-premises.

Jeśli chodzi o SQL, to SQL będzie żył. Oznacza to, że PostgreSQL i MySQL trzeba znać i umieć z nimi pracować, ale jeszcze ważniejsze jest umieć je poprawnie stosować.

Źródło: habr.com