Zarządzanie schematami za pomocą Skeema

Uwaga: ten post pochodzi od zespołu inżynierskiego SendGrid. Więcej takich postów o inżynierii technicznej znajdziesz w naszym blogu technicznym.

Zarządzanie schematem bazy danych rozciąga się od dzikiego zachodu, który każdy może „zrobić na żywo” w procesie produkcyjnym, po wieloetapowy, wielozespołowy proces przeglądu, w którym tylko jedna naznaczona osoba może dotknąć produkcyjnej bazy danych.

W miarę jak dane zawarte w relacyjnych bazach danych stają się coraz bardziej wartościowe dla firmy, a dostępność bazy danych staje się ważniejsza dla biznesu, pojawiają się bariery dla potencjalnych zmian w schemacie.

Na początku administratorzy bazy danych (DBA) stali się strażnikami bazy danych w celu ochrony bazy danych przed złymi rzeczami. Jednak posiadanie starej szkoły DBA między programistami a bazą danych ich aplikacji może spowodować znaczne spowolnienie cyklu życia aplikacji, stworzyć silosy rozwoju i operacji oraz generować tarcia między zespołami.

W dzisiejszym świecie zorientowanym na tworzenie mikrousług, programiści muszą być w stanie samodzielnie zarządzać zmianami w schemacie bazy danych, ponieważ są to ich dane i to oni są ostatecznie odpowiedzialni za wydajność i czas pracy aplikacji. DBA i zespoły operacyjne muszą zapewnić odpowiednie narzędzia i porady, aby pomóc zespołom programistów stać się właścicielami ich baz danych.

Jak zarządzamy schematem

Nasz obecny proces zarządzania schematami wykorzystuje pojedyncze repozytorium Git do przechowywania początkowego schematu dla wszystkich naszych klastrów baz danych i zawiera wszystkie późniejsze zmiany tego schematu w miarę wprowadzania zmian/tworzenia i porzucania poszczególnych tabel:

• Deweloper dokonuje zmiany schematu lokalnie i generuje instrukcję alter/create/drop i dodaje ją jako żądanie ściągnięcia do gałęzi integracji.
• Zestaw biletów Jira dla zespołu Data Operations jest tworzony w celu przeglądania i stosowania zmian schematu w naszych środowiskach testowych/pomostowych i produkcyjnych.
• Członek zespołu Data Operations przegląda żądaną zmianę i stosuje zmianę w środowisku testowym/pomostowym oraz łączy PR z gałęzią integracji.
• Deweloper, który wysłał żądanie, testuje zmianę w naszych środowiskach testowych/pomostowych i zatwierdza zmianę, która ma zostać wypchnięta do środowiska produkcyjnego.
• Na koniec Data Operations scala gałąź integracji z wzorcem i stosuje zmianę schematu w środowisku produkcyjnym.

Biorąc pod uwagę wartość danych przechowywanych w naszych bazach danych i pragnienie, aby te bazy danych działały dobrze przez cały czas, zdecydowaliśmy się na tę bizantyjską sekwencję wydarzeń, aby chronić się przed nami samymi.

Ochrona bazy danych to jedno, ale ten proces wprowadza kilka przeszkód w dokonywaniu zmian w schemacie w niezawodny i wydajny sposób:

• Przeglądanie i wprowadzanie zmian w schemacie odbywa się dwa razy w tygodniu i może łatwo zostać wykolejone, ponieważ wiele zespołów pracuje na różnych bazach danych w tym samym repozytorium Git, a każdy polega na kimś z zespołu ds. operacji na danych, który przegląda i wprowadza zmiany w różnych środowiskach.
• Posiadanie jednego repozytorium dla wszystkich schematów relacyjnych baz danych może prowadzić do trudnych procesów wydawniczych. Zmiana jednego schematu, który jest gotowy do produkcji, nie może przejść do produkcji, jeśli istnieją inne zmiany schematu, które nie są gotowe do wypchnięcia do produkcji, ale znajdują się w fazie przygotowania i czekają na dodatkowe testy.
• Zespół Data Operations, który jest małym zespołem, staje się wąskim gardłem, próbując zarządzać tym, która zmiana może, a kiedy nie może przejść do produkcji i kiedy. Konflikty w harmonogramie i dostępność personelu mogą naprawdę spowolnić wydawanie nowych funkcji lub poprawek w bieżących aplikacjach.
• Ręcznie wprowadzamy te zmiany w systemach produkcyjnych za pomocą komentarzy w pull requestach i biletach Jira; czasami kopiuj wklej może się nie udać.

Wejdź do Skeema (i kilku pomocników)

Aby usunąć te przeszkody w procesie, uczynić zmiany schematu mniej podatnymi na błędy ludzkie, umożliwić programistom zarządzanie schematem własnej aplikacji i potencjalnie zwiększyć szybkość opracowywania, zespół Data Operations włożył wiele wysiłku w automatyzację i usprawnienie zarządzania schemat bazy danych.

Zautomatyzowaliśmy stosowanie zmian schematu od rozwoju lokalnego do produkcji, korzystając z naszych istniejących narzędzi, Git, Buildkite CI i pt-online-schema-change, z dodatkiem jeszcze jednego, Skeema.

Pomysł polega na podzieleniu naszego monolitycznego repozytorium schematów DB na pojedyncze repozytoria schematów, po jednym na klaster bazy danych, i umożliwienie programistom dokonywania własnych zmian w schemacie w znanym im środowisku. Chcemy również mieć rozsądne barierki, aby pomóc programistom w szukaniu dodatkowej pomocy przy dokonywaniu dużych, złożonych lub potencjalnie destrukcyjnych zmian w schemacie.

Skeema to narzędzie CLI, które zarządza schematem MySQL w sposób deklaratywny przy użyciu SQL.

Może generować język definicji danych (DDL) dla każdej tabeli w bazie danych i eksportować DDL do lokalnego systemu plików w celu integracji z repozytorium śledzenia za pośrednictwem Git. Skeema może porównywać pliki SQL w repozytorium Git z działającą bazą danych MySQL i wyświetlać te różnice jako instrukcje DDL.

Można go również skonfigurować tak, aby używał narzędzia pt-online-schema-change firmy Percona i sformatował niezbędne polecenie pt-online-schema-change, aby dopasować działający schemat bazy danych MySQL do schematu zdefiniowanego w repozytorium Git.

Skeema jest również w stanie zarządzać schematem w kilku środowiskach, takich jak lokalne, testowe i produkcyjne, z różnymi konfiguracjami w każdym. I wreszcie, można go łatwo dostosować do przepływu pracy opartego na żądaniach ściągnięcia.

Utworzenie indywidualnych repozytoriów schematów bazy danych MySQL spowoduje rozbicie naszego obecnego monolitycznego repozytorium Git schematu db i umożliwi deweloperom w osobnych zespołach zarządzanie schematem MySQL aplikacji we własnym repozytorium zamiast repozytorium współdzielonym (schemat db).

Posiadanie osobnego repozytorium dla każdego schematu bazy danych zapewni większą autonomię zespołowi programistycznemu aplikacji. Eliminuje to potrzebę koordynowania wszystkich zmian schematu w sztywnym harmonogramie i umożliwia przeniesienie zmian do produkcji zgodnie z życzeniem zespołu aplikacyjnego.

Istotnym elementem automatyzacji tego procesu jest potok CI Buildkite. Stworzyliśmy potok, który:

• Sprawdza błędy składni SQL
• Tworzy testowy serwer MySQL z wykorzystaniem aktualnej gałęzi master schematu bazy danych i testuje zastosowanie zmian w pull requestie (PR)
• Sprawdź różnice i zastosuj zmiany PR do naszego testowego środowiska MySQL
• Sprawdź różnice i zastosuj zmiany PR w naszym środowisku pomostowym i wygeneruj statystyki tabeli ze środowiska produkcyjnego

Statystyki wyjściowe produkcji to rozmiar tabeli na dysku i szacowana liczba wierszy. Te statystyki mogą pomóc w ustaleniu, czy zmiana schematu może spowodować pewien poziom przerwy w świadczeniu usług i może wymagać specjalnej obsługi. Gdy PR zostanie scalony z masterem, potok buildkite sprawdza różnice między gałęzią master a tym, co jest uruchomione w produkcji.

Jeśli różnice są oczekiwanymi zmianami z PR, programista może odblokować ten ostatni krok, a Skeema zastosuje zmiany do produkcyjnego klastra bazy danych MySQL. Każdy z tych kroków jest krokiem blokującym, który wymaga zatwierdzenia przez zespół inżynierów odpowiedzialny za żądaną zmianę przed przejściem do następnego kroku.

Jeśli chodzi o poręcze, skonfigurowaliśmy Skeema, aby domyślnie nie zezwalać na destrukcyjne zmiany schematu w produkcji.

Destrukcyjne zmiany są dozwolone w naszych środowiskach testowych i pomostowych.

Skonfigurowaliśmy również Skeema, aby używał pt-online-schema-change do wprowadzania zmian w schemacie. Jest to to samo narzędzie do zmiany schematu, które zespół DataOps jest zaznajomiony i jest używany w SendGrid od wielu lat. Opracowaliśmy zestaw rozsądnych opcji zmiany schematu pt-online, aby wycofać zmiany, jeśli replikacja zostanie opóźniona lub aktywne wątki w bazie danych staną się nadmierne.

Skeema skonfigurowana w ten sposób eliminuje potencjalne błędy związane z ręcznymi czynnościami aplikacji i ręcznym kodowaniem poleceń zmiany schematu pt-online przez członków zespołu DataOps.

Dzięki dodaniu programistycznych barier ochronnych poszczególne zespoły mogą być odpowiedzialne za zarządzanie schematami baz danych MySQL oraz stosowanie tych zmian w środowiskach przedprodukcyjnych i produkcyjnych z zachowaniem względnego bezpieczeństwa. W przypadku trafienia poręczy zmiana schematu nie powiedzie się i zostanie wycofana. Przyczyny niepowodzenia zmiany schematu są wyprowadzane do dzienników kompilacji w celu dodatkowego przeglądu.

Umożliwienie programistom wprowadzania zmian od lokalnego testowania na laptopie do produkcji znacznie zwiększa autonomię programistów i własność bazy danych, która obsługuje ich aplikację. Automatyzacja i integracja Skeema z naszym procesem zarządzania bazą danych MySQL z łatwością obejmuje około dziewięćdziesiąt procent naszych ogólnych zadań związanych z zarządzaniem zmianami schematu.

Większość zmian schematu dotyczy dodawania kolumn, zmiany pól wyliczenia, zmiany wartości domyślnych i dodawania indeksów. Pozostałe dziesięć procent zmian schematu dotyczy szczególnych przypadków dużych tabel, bardzo aktywnych baz danych lub tabel partycjonowanych. W tym poście Skeema nie zajmuje się jeszcze wprowadzaniem zmian w schemacie do partycjonowanych tabel, ale słyszałem, że jest to często żądany dodatek, a twórca Skeema aktywnie prosi o pomoc w implementacji tej funkcji.

Połączenie Git, pt-online-schema-change, Skeema i potoku CI Buildkite zapewnia niezawodny, powtarzalny, programistyczny proces zmian schematów bazy danych MySQL. Umożliwia programistom bezpieczne zarządzanie schematem baz danych i kontrolowanie szybkości wdrażania funkcji i poprawek w środowisku produkcyjnym.

Uwzględnienie odpowiednich barier ochronnych w plikach konfiguracyjnych dla zmiany schematu Skeema i pt-online zapewnia deweloperom wdrażającym zmiany schematu miarę pewności siebie i daje cenne informacje zwrotne na temat możliwych sposobów kontynuowania zmiany schematu, jeśli te bariery zostaną trafione.

Zespół Data Operations pozostaje dostępny, aby pomóc pozostałym dziesięciu procentom przypadków, w których nie można zastosować tego procesu, i będzie pracował nad dodatkowymi narzędziami, aby usprawnić ten proces w przyszłości.