W jakiś sposób, historycznie rzecz biorąc, branża IT z dowolnego powodu dzieli się na dwa obozy warunkowe: tych, którzy są „za” i tych, którzy są „przeciw”. Co więcej, przedmiot sporów może być całkowicie dowolny. Który system operacyjny jest lepszy: Win czy Linux? Na smartfonie z Androidem lub iOS? Czy przechowywać wszystko w chmurach, czy umieścić w zimnej pamięci RAID i włożyć śruby do sejfu? Czy ludzie zajmujący się PHP mają prawo nazywać się programistami? Spory te mają czasami charakter wyłącznie egzystencjalny i nie mają podstaw innych niż interesy sportowe.
Tak się złożyło, że wraz z pojawieniem się kontenerów i całej tej ukochanej kuchni z dokerami i warunkowymi k8 rozpoczęły się debaty „za” i „przeciw” wykorzystaniu nowych możliwości w różnych obszarach backendu. (Zastrzegajmy z góry, że choć w tej dyskusji Kubernetes będzie najczęściej wskazywany jako orkiestrator, to wybór tego konkretnego narzędzia nie ma zasadniczego znaczenia. Zamiast tego możesz zastąpić dowolne inne, które wyda Ci się najwygodniejsze i znajome .)
I wydawałoby się, że będzie to prosty spór między dwiema stronami tego samego medalu. Równie bezsensowne i bezlitosne jak odwieczna konfrontacja Win vs Linux, w której gdzieś pośrodku istnieją adekwatni ludzie. Jednak w przypadku konteneryzacji nie wszystko jest takie proste. Zwykle w takich sporach nie ma dobrej strony, jednak w przypadku „używania” lub „nieużywania” kontenerów do przechowywania baz danych wszystko wywraca się do góry nogami. Bo w pewnym sensie rację mają zarówno zwolennicy, jak i przeciwnicy tego podejścia.
Jasna strona
Argumenty Jasnej Strony można krótko opisać jednym zdaniem: „Witajcie, 2k19 jest za oknem!” Brzmi to oczywiście jak populizm, ale jeśli zagłębisz się w sytuację szczegółowo, ma to swoje zalety. Uporządkujmy je teraz.
Załóżmy, że masz duży projekt internetowy. Mógł zostać początkowo zbudowany w oparciu o podejście mikroserwisowe, albo w pewnym momencie doszedł do tego drogą ewolucyjną – to w sumie mało istotne. Rozproszyłeś nasz projekt na osobne mikrousługi, skonfigurowałeś orkiestrację, równoważenie obciążenia i skalowanie. A teraz z czystym sumieniem popijacie mojito w hamaku podczas efektów habra zamiast podnosić upadłe serwery. Ale we wszystkich działaniach musisz być konsekwentny. Bardzo często konteneryzowana jest tylko sama aplikacja – kod. Co jeszcze mamy oprócz kodu?
Zgadza się, dane. Sercem każdego projektu są jego dane: może to być typowy DBMS - MySQL, Postgre, MongoDB lub pamięć używana do wyszukiwania (ElasticSearch), pamięć klucz-wartość do buforowania - na przykład redis itp. Obecnie nie jesteśmy porozmawiamy o błędnych opcjach implementacji backendu w przypadku awarii bazy danych z powodu źle napisanych zapytań, a zamiast tego porozmawiamy o zapewnieniu odporności tej samej bazy na błędy pod obciążeniem klienta. Przecież gdy konteneryzujemy naszą aplikację i pozwalamy jej na swobodne skalowanie w celu obsługi dowolnej liczby przychodzących żądań, to w naturalny sposób zwiększa to obciążenie bazy danych.
W rzeczywistości kanał dostępu do bazy danych i serwer, na którym ona działa, stają się uchem igielnym w naszym pięknym, kontenerowym backendie. Jednocześnie głównym motywem wirtualizacji kontenerów jest mobilność i elastyczność konstrukcji, co pozwala nam na możliwie najefektywniejsze organizowanie rozkładu obciążeń szczytowych na całej dostępnej nam infrastrukturze. Oznacza to, że jeśli nie konteneryzujemy i nie wdrażamy wszystkich istniejących elementów systemu w całym klastrze, popełniamy bardzo poważny błąd.
O wiele bardziej logiczne jest klastrowanie nie tylko samej aplikacji, ale także usług odpowiedzialnych za przechowywanie danych. Łącząc i wdrażając serwery WWW, które działają niezależnie i rozdzielają między siebie obciążenie w k8s, już rozwiązujemy problem synchronizacji danych - te same komentarze do postów, jeśli weźmiemy za przykład jakąś platformę medialną lub blogową. W każdym razie mamy wewnątrzklastrową, a nawet wirtualną reprezentację bazy danych jako usługę zewnętrzną. Pytanie jest takie, że sama baza danych nie jest jeszcze zgrupowana – serwery WWW rozmieszczone w kostce pobierają informacje o zmianach z naszej statycznej bazy danych bojowych, która obraca się osobno.
Czujesz haczyk? Używamy k8s lub Swarm do rozłożenia obciążenia i uniknięcia awarii głównego serwera WWW, ale nie robimy tego w przypadku bazy danych. Ale jeśli baza danych ulegnie awarii, cała nasza infrastruktura klastrowa nie będzie miała sensu – po co puste strony internetowe, które zwracają błąd dostępu do bazy danych?
Dlatego konieczne jest klastrowanie nie tylko serwerów WWW, jak to zwykle się robi, ale także infrastruktury bazodanowej. Tylko w ten sposób możemy zapewnić strukturę, która w pełni działa w jednym zespole, ale jednocześnie jest od siebie niezależna. Co więcej, nawet jeśli połowa naszego backendu „upadnie” pod obciążeniem, reszta przetrwa, a system synchronizacji baz danych między sobą w ramach klastra oraz możliwość nieograniczonego skalowania i wdrażania nowych klastrów pomogą szybko osiągnąć wymaganą pojemność - gdyby tylko w centrum danych były szafy.
Dodatkowo model bazy danych rozproszony w klastrach pozwala zabrać tę właśnie bazę danych tam, gdzie jest ona potrzebna; Jeśli mówimy o usłudze globalnej, to całkiem nielogiczne jest tworzenie klastra internetowego gdzieś w rejonie San Francisco i jednoczesne wysyłanie pakietów podczas uzyskiwania dostępu do bazy danych w regionie moskiewskim i z powrotem.
Ponadto konteneryzacja bazy danych pozwala na zbudowanie wszystkich elementów systemu na tym samym poziomie abstrakcji. Co z kolei sprawia, że możliwe jest zarządzanie tym właśnie systemem bezpośrednio z kodu, przez programistów, bez aktywnego udziału administratorów. Twórcy pomyśleli, że dla nowego podprojektu potrzebny będzie oddzielny system DBMS - to proste! napisałem plik yaml, przesłałem go do klastra i gotowe.
I oczywiście obsługa wewnętrzna jest znacznie uproszczona. Powiedz mi, ile razy zamykałeś oczy, gdy nowy członek zespołu wkładał ręce do bazy danych walki w celach zawodowych? Który tak naprawdę jest jedynym, który masz i który się teraz kręci? Oczywiście, wszyscy tu jesteśmy dorośli i gdzieś mamy świeżą kopię zapasową, a jeszcze dalej – za półką z babcinymi ogórkami i starymi nartami – kolejną kopię zapasową, może nawet w chłodni, bo już raz spaliło Ci się biuro. Ale mimo to każde wprowadzenie nowego członka zespołu z dostępem do infrastruktury bojowej i oczywiście do bazy danych bojowych jest wiadrem validolu dla wszystkich w okolicy. No cóż, kto go zna, nowicjusz, może ma skrzyżowane ręce? To przerażające, zgodzisz się.
Konteneryzacja, a właściwie rozproszona topologia fizyczna bazy danych Twojego projektu, pomaga uniknąć takich momentów sprawdzania poprawności. Nie ufasz nowicjuszowi? OK! Dajmy mu własny klaster do pracy i odłączmy bazę danych od pozostałych klastrów - synchronizacja tylko poprzez ręczne pushowanie i synchroniczną rotację dwóch kluczy (jeden dla lidera zespołu, drugi dla administratora). I wszyscy są szczęśliwi.
A teraz czas zmienić się w przeciwników klastrowania baz danych.
Ciemna strona
Argumentując, dlaczego nie warto kontenerować bazy danych i dalej uruchamiać ją na jednym centralnym serwerze, nie będziemy uciekać się do retoryki ortodoksyjnych i stwierdzeń w stylu „dziadkowie prowadzili bazy danych na sprzęcie i my też!” Zamiast tego spróbujmy wymyślić sytuację, w której konteneryzacja faktycznie przyniosłaby wymierne korzyści.
Zgadzam się, projekty, które naprawdę wymagają bazy w pojemniku, nie najlepszy operator frezarki może policzyć na palcach jednej ręki. W przeważającej części nawet użycie k8s lub samego Docker Swarm jest zbędne - dość często uciekają się do tych narzędzi ze względu na ogólny szum technologiczny i postawę „wszechmocnego” w osobie płci, aby wepchnąć wszystko do chmury i pojemniki. No bo teraz to jest modne i każdy to robi.
W co najmniej połowie przypadków użycie Kubernetisa lub po prostu Dockera w projekcie jest zbędne. Problem w tym, że nie wszystkie zespoły czy firmy outsourcingowe wynajęte do utrzymania infrastruktury klienta mają tego świadomość. Gorzej, gdy narzucone są kontenery, bo to kosztuje klienta określoną ilość monet.
Ogólnie panuje opinia, że mafia dokerów/kostek głupio miażdży klientów, którzy zlecają kwestie infrastruktury na zewnątrz. Przecież do pracy z klastrami potrzebujemy inżynierów, którzy potrafią to zrobić i ogólnie rozumieją architekturę wdrażanego rozwiązania. Opisaliśmy już kiedyś nasz przypadek w publikacji Republic – tam przeszkoliliśmy zespół klienta do pracy w realiach Kubernetis i wszyscy byli zadowoleni. I było przyzwoicie. Często „realizatorzy” K8s biorą zakładnika infrastruktury klienta - bo teraz dopiero oni rozumieją, jak tam wszystko działa, po stronie klienta nie ma specjalistów.
A teraz wyobraźmy sobie, że w ten sposób zlecamy nie tylko część serwerową, ale także utrzymanie baz danych. Powiedzieliśmy, że ChAD to serce, a utrata serca jest śmiertelna dla każdego żywego organizmu. Krótko mówiąc, perspektywy nie są najlepsze. Tak więc, zamiast robić szum wokół Kubernetisa, wiele projektów nie powinno po prostu zawracać sobie głowy normalną taryfą dla AWS, która rozwiąże wszystkie problemy z obciążeniem ich witryny/projektu. Ale AWS nie jest już modny, a popisy są warte więcej niż pieniądze – niestety także w środowisku IT.
OK. Być może projekt naprawdę wymaga klastrowania, ale jeśli w przypadku aplikacji bezstanowych wszystko jest jasne, to w jaki sposób możemy zorganizować przyzwoitą łączność sieciową dla klastrowej bazy danych?
Jeśli mówimy o bezproblemowym rozwiązaniu inżynierskim, jakim jest przejście na k8s, to naszym głównym problemem jest replikacja danych w klastrowej bazie danych. Niektóre systemy DBMS są początkowo dość lojalne wobec dystrybucji danych pomiędzy swoimi indywidualnymi instancjami. Wiele innych nie jest tak gościnnych. Dość często głównym argumentem przy wyborze DBMS do naszego projektu nie jest możliwość replikacji przy minimalnych kosztach zasobów i inżynierii. Zwłaszcza jeśli projekt nie był początkowo planowany jako mikroserwis, a po prostu ewoluował w tym kierunku.
Uważamy, że nie trzeba mówić o szybkości dysków sieciowych - są one wolne. Te. Nadal nie mamy realnej możliwości, jeśli coś się stanie, zrestartować instancję DBMS gdzieś, gdzie jest więcej, na przykład mocy procesora lub wolnej pamięci RAM. Bardzo szybko przekonamy się o wydajności podsystemu dysku wirtualnego. W związku z tym DBMS musi być przybity do jego osobistego zestawu maszyn znajdujących się w pobliżu. Lub trzeba jakoś oddzielnie schłodzić wystarczająco szybką synchronizację danych dla rzekomych rezerw.
Kontynuując temat wirtualnych systemów plików: Docker Volumes niestety nie są wolne od problemów. Ogólnie rzecz biorąc, w kwestii długotrwałego i niezawodnego przechowywania danych, chciałbym zadowolić się najprostszymi technicznie schematami. Dodanie nowej warstwy abstrakcji z systemu plików kontenera do systemu plików hosta nadrzędnego jest samo w sobie ryzykiem. Kiedy jednak działanie systemu wsparcia konteneryzacji napotyka również trudności w przesyłaniu danych pomiędzy tymi warstwami, wtedy jest to naprawdę katastrofa. W tej chwili wydaje się, że większość problemów znanych postępowej ludzkości została wyeliminowana. Ale rozumiesz, im bardziej złożony mechanizm, tym łatwiej się psuje.
W świetle tych wszystkich „przygód” znacznie bardziej opłacalne i łatwiejsze jest trzymanie bazy danych w jednym miejscu, a nawet jeśli zajdzie potrzeba konteneryzacji aplikacji, pozwolić jej działać samodzielnie i poprzez bramę dystrybucyjną otrzymywać jednoczesną komunikację z bazę danych, która będzie odczytywana i zapisywana tylko raz i w jednym miejscu. Takie podejście zmniejsza do minimum prawdopodobieństwo wystąpienia błędów i desynchronizacji.
Do czego zmierzamy? Co więcej, konteneryzacja baz danych jest właściwa tam, gdzie istnieje realna potrzeba. Nie możesz wypełnić bazy danych obejmującej całą aplikację i obracać nią tak, jakbyś miał dwa tuziny mikrousług – to nie działa w ten sposób. I trzeba to jasno zrozumieć.
Zamiast wyjścia
Jeśli czekasz na jasny wniosek „wirtualizacja bazy danych czy nie”, to Cię rozczarujemy: tutaj go nie będzie. Bo tworząc jakiekolwiek rozwiązanie infrastrukturalne, nie należy kierować się modą i postępem, ale przede wszystkim zdrowym rozsądkiem.
Są projekty, do których zasady i narzędzia dostarczane z Kubernetisem pasują idealnie i w takich projektach jest spokój przynajmniej w obszarze backendu. A są projekty, które nie wymagają konteneryzacji, ale normalnej infrastruktury serwerowej, bo zasadniczo nie da się ich przeskalować do modelu klastra mikrousługowego, bo upadną.
Źródło: www.habr.com