Latem zarówno aktywność zakupowa, jak i intensywność zmian w infrastrukturze projektów webowych tradycyjnie spadają – mówi nam Captain Obvious. Po prostu dlatego, że nawet specjaliści IT czasami wyjeżdżają na wakacje. I CTO też. Tym, którzy pozostają na stanowiskach, jest to tym trudniejsze, ale nie o to teraz chodzi: może dlatego lato to najlepszy okres, aby powoli zastanowić się nad istniejącym systemem rezerwacji i opracować plan jego ulepszenia. I doświadczenie Jegora Andreeva z o czym mówił na konferencji .
Tworząc witryny z kopiami zapasowymi, możesz wpaść na kilka pułapek. I absolutnie nie da się w nich dać złapać. A tym, co rujnuje nas w tym wszystkim, jak i w wielu innych sprawach, jest perfekcjonizm i… lenistwo. Staramy się robić wszystko, wszystko, wszystko doskonale, ale nie musimy tego robić idealnie! Trzeba tylko zrobić pewne rzeczy, ale robić je poprawnie, uzupełniać je tak, żeby działały prawidłowo.
Przełączanie awaryjne nie jest jakąś zabawną rzeczą; to jest rzecz, która powinna robić dokładnie jedno - skrócić przestoje, aby usługa, firma, straciła mniej pieniędzy. I we wszystkich metodach rezerwacji sugeruję myślenie w następującym kontekście: gdzie są pieniądze?
Pierwsza pułapka: budując duże, niezawodne systemy i stosując redundancję, zmniejszamy liczbę wypadków. To straszne błędne przekonanie. Wprowadzając zwolnienia, prawdopodobnie zwiększymy liczbę wypadków. A jeśli zrobimy wszystko dobrze, wspólnie skrócimy przestoje. Wypadków będzie więcej, ale będą one miały miejsce mniejszymi kosztami. Co to jest rezerwacja? - jest to komplikacja systemu. Każda komplikacja jest zła: mamy więcej trybów, więcej biegów, jednym słowem więcej elementów - a co za tym idzie, większe ryzyko awarii. I naprawdę pękną. I będą częściej pękać. Prosty przykład: załóżmy, że mamy stronę internetową z PHP i MySQL. I trzeba to pilnie zarezerwować.
Shtosh (c) Bierzemy drugą lokalizację, budujemy identyczny system... Złożoność staje się dwukrotnie większa - mamy dwa podmioty. Wdrażamy również pewną logikę przesyłania danych z jednej witryny do drugiej – czyli replikację danych, kopiowanie danych statycznych i tak dalej. Zatem logika replikacji jest zwykle bardzo złożona i dlatego całkowita złożoność systemu może być nie 2, ale 3, 5, 10 razy większa.
Druga pułapka: kiedy budujemy naprawdę duże, złożone systemy, fantazjujemy o tym, co ostatecznie chcemy uzyskać. Voila: chcemy uzyskać super niezawodny system, który działa bez przestojów, przełącza się w pół sekundy (lub jeszcze lepiej, natychmiast) i zaczynamy spełniać marzenia. Ale jest tu także niuans: im krótszy jest pożądany czas przełączania, tym bardziej złożona staje się logika systemu. Im bardziej złożoną logikę musimy stworzyć, tym częściej system się załamie. I możesz znaleźć się w bardzo nieprzyjemnej sytuacji: ze wszystkich sił staramy się ograniczać przestoje, ale tak naprawdę wszystko komplikujemy, a gdy coś pójdzie nie tak, przestoje się wydłużą. Tutaj często łapiesz się na myśleniu: cóż... lepiej nie robić rezerwacji. Byłoby lepiej, gdyby działał samodzielnie i ze zrozumiałymi przestojami.
Jak możesz z tym walczyć? Musimy przestać się okłamywać, przestać się pochlebiać, że teraz zbudujemy tu statek kosmiczny, ale odpowiednio zrozumieć, jak długo może czekać ten projekt. I przez ten maksymalny czas wybierzemy, jakich metod faktycznie będziemy używać, aby zwiększyć niezawodność naszego systemu.
Czas na „historie z w”… oczywiście z życia.
Przykład numer jeden
Wyobraźcie sobie witrynę wizytówkową dla Zakładu Walcowania Rur nr 1 w mieście N. Jest tam napisane wielkimi literami - ZAKŁAD Walcowania Rur nr 1. Tuż poniżej znajduje się hasło: „Nasze fajki to najbardziej okrągłe fajki w N.” A poniżej numer telefonu dyrektora generalnego i jego nazwisko. Rozumiemy, że konieczna jest rezerwacja – to bardzo ważna rzecz! Zacznijmy zastanawiać się, z czego się składa. Statyka HTML - czyli kilka zdjęć, na których dyrektor generalny tak naprawdę omawia ze swoją partnerką jakąś kolejną transakcję przy stole w łaźni. Zaczynamy myśleć o przestoju. Przychodzi mi na myśl: musisz tak leżeć przez pięć minut, nie dłużej. A potem pojawia się pytanie: ile ogółem sprzedaży dokonano na naszej stronie? Ile-ile? Co oznacza „zero”? A to oznacza: bo generał w zeszłym roku dokonał wszystkich czterech transakcji przy tym samym stole, z tymi samymi ludźmi, z którymi idzie do łaźni i siada przy stole. Rozumiemy, że nawet jeśli strona będzie siedzieć przez jeden dzień, nic strasznego się nie stanie.
Sądząc po informacjach wstępnych, jest dzień na opowiedzenie tej historii. Zacznijmy myśleć o planie zwolnień. I dla tego przykładu wybieramy najbardziej idealny schemat redundancji: nie używamy redundancji. Całość może poruszyć dowolny administrator w ciągu pół godziny z przerwami na papierosa. Zainstaluj serwer WWW, dodaj pliki – to wszystko. To będzie działać. Nie trzeba na nic zwracać uwagi, nie trzeba na nic zwracać szczególnej uwagi. Oznacza to, że wniosek z przykładu numer jeden jest dość oczywisty: usługi, których nie trzeba rezerwować, nie muszą być rezerwowane.
Przykład numer dwa
Blog firmowy: specjalnie przeszkoleni ludzie piszą tam wiadomości, braliśmy udział w takiej a takiej wystawie, ale wypuściliśmy kolejną nowość i tak dalej. Powiedzmy, że jest to standardowy PHP z WordPressem, małą bazą danych i odrobiną statyki. Oczywiście znowu przychodzi mi na myśl, że w żadnym wypadku nie należy się kłaść - „nie więcej niż pięć minut!” To wszystko. Ale pomyślmy dalej. Co robi ten blog? Ludzie przychodzą tam z Yandexu, z Google na podstawie niektórych zapytań, organicznie. Świetnie. Czy sprzedaż ma z tym coś wspólnego? Epifania: raczej nie. Ruch reklamowy trafia na stronę główną, która znajduje się na innej maszynie. Zacznijmy myśleć o schemacie rezerwacji. W dobrym tego słowa znaczeniu trzeba go podnieść za kilka godzin i dobrze byłoby się na to przygotować. Rozsądnie byłoby wziąć maszynę z innego data center, zrzucić na nią środowisko czyli serwer www, PHP, WordPress, MySQL i tam zostawić. W momencie, gdy zrozumiemy, że wszystko jest zepsute, musimy zrobić dwie rzeczy - rozłożyć zrzut mysql na 50 metrów, poleci tam za minutę i wyrzucić tam określoną liczbę zdjęć z kopii zapasowej. Tego również nie ma przez Bóg wie jak długo. Tak więc za pół godziny całość się podnosi. Żadnej replikacji, albo Bóg mi wybaczy, automatyczne przełączanie awaryjne. Wniosek: to, co możemy szybko wdrożyć z kopii zapasowej, nie wymaga tworzenia kopii zapasowej.
Przykład numer trzy, bardziej skomplikowany
Sklep internetowy. PHP z otwartym sercem jest trochę ulepszone, mysql z solidną podstawą. Dość dużo statyki (w końcu sklep internetowy ma piękne obrazy HD i tak dalej), Redis dla sesji i Elasticsearch dla wyszukiwania. Zaczynamy myśleć o przestoju. I tutaj oczywiście widać, że sklep internetowy nie może bezboleśnie leżeć przez jeden dzień. W końcu im dłużej leży, tym więcej pieniędzy tracimy. Warto przyspieszyć. Ile? Myślę, że jeśli położymy się na godzinę, nikt nie zwariuje. Tak, coś stracimy, ale jeśli zaczniemy ciężko pracować, będzie tylko gorzej. Definiujemy schemat dozwolonych przestojów na godzinę.
Jak to wszystko można zarezerwować? W każdym razie potrzebujesz samochodu: godzina czasu to dość mało. Mysql: tutaj potrzebujemy już replikacji, replikacji na żywo, bo za godzinę najprawdopodobniej nie zostanie dodane do zrzutu 100 GB. Statystyka, zdjęcia: znowu za godzinę 500 GB może nie mieć czasu na dodanie. Dlatego lepiej od razu skopiować zdjęcia. Redis: tutaj sprawy stają się interesujące. W Redis sesje są przechowywane – nie możemy ich po prostu zabrać i zakopać. Bo to nie będzie zbyt dobre: wszyscy użytkownicy zostaną wylogowani, ich koszyki zostaną opróżnione i tak dalej. Ludzie będą zmuszeni do ponownego wprowadzenia swojej nazwy użytkownika i hasła, a wiele osób może wyłamać się i nie dokończyć zakupu. Ponownie liczba konwersji spadnie. Z drugiej strony Redis jest bezpośrednio aktualny, a ostatnio zalogowani użytkownicy prawdopodobnie również nie są potrzebni. A dobrym kompromisem jest wzięcie Redisa i przywrócenie go z kopii zapasowej z wczoraj lub, jeśli robisz to co godzinę, sprzed godziny. Na szczęście przywrócenie go z kopii zapasowej oznacza skopiowanie jednego pliku. A najciekawsza historia to Elasticsearch. Kto kiedykolwiek zajmował się replikacją MySQL? Kto kiedykolwiek podjął się replikacji Elasticsearch? A u kogo to później normalnie działało? Mam na myśli to, że widzimy pewną jednostkę w naszym systemie. Wydaje się to przydatne, ale jest skomplikowane.
Złożony w tym sensie, że nasi koledzy inżynierowie nie mają doświadczenia w pracy z nim. Lub jest negatywne doświadczenie. Albo rozumiemy, że jest to wciąż dość nowa technologia z niuansami lub surowością. Myślimy... Cholera, gumka też jest zdrowa, przywrócenie jej z kopii zapasowej też zajmuje dużo czasu, co mam zrobić? Rozumiemy, że gumka w naszym przypadku służy do wyszukiwania. Jak sprzedaje się nasz sklep internetowy? Idziemy do marketerów i pytamy, skąd pochodzą ludzie. Odpowiadają: „90% z Yandex Market trafia bezpośrednio na kartę produktu”. I albo to kupią, albo nie. Dlatego wyszukiwanie jest potrzebne 10% użytkowników. A utrzymanie elastycznej replikacji, zwłaszcza pomiędzy różnymi centrami danych w różnych strefach, ma naprawdę wiele niuansów. Które wyjście? Bierzemy gumkę z zarezerwowanej strony i nic z nią nie robimy. Jeśli sprawa będzie się przeciągać, zapewne kiedyś ją poruszymy, ale nie jest to pewne. Właściwie wniosek jest taki sam, plus lub minus: znowu nie rezerwujemy usług, które nie wpływają na pieniądze. Aby schemat był prostszy.
Przykład numer cztery, jeszcze trudniejszy
Integrator: sprzedaż kwiatów, zamawianie taksówki, sprzedaż towarów w ogóle, wszystko. Poważna rzecz, która działa 24 godziny na dobę, 7 dni w tygodniu dla dużej liczby użytkowników. Z pełnoprawnym ciekawym stackiem, gdzie są ciekawe podstawy, rozwiązania, duże obciążenie i co najważniejsze, leżenie na dłużej niż 5 minut boli. Nie tylko i nie tylko dlatego, że ludzie nie będą kupować, ale dlatego, że zobaczą, że to nie działa, zdenerwują się i mogą w ogóle nie wrócić.
OK. Pięć minut. Co zamierzamy z tym zrobić? W tym przypadku my, podobnie jak dorośli, wykorzystujemy wszystkie pieniądze, aby zbudować prawdziwą witrynę kopii zapasowych, z replikacją wszystkiego, a może nawet maksymalnie zautomatyzować przejście do tej witryny. A poza tym trzeba pamiętać o jednej ważnej rzeczy: a właściwie napisać regulamin zamiany. Przepisy, nawet jeśli wszystko masz zautomatyzowane, mogą być bardzo proste. Z serii „uruchom taki a taki skrypt ansible”, „kliknij takie a takie pole wyboru na trasie 53” i tak dalej - ale to musi być jakaś dokładna lista akcji.
I wszystko wydaje się jasne. Przełączanie replikacji jest trywialnym zadaniem, w przeciwnym razie przełączy się samo. Przepisanie nazwy domeny w DNS pochodzi z tej samej serii. Kłopot w tym, że gdy taki projekt się nie powiedzie, zaczyna się panika, na którą podatni mogą być nawet najsilniejsi, brodaci admini. Bez jasnej instrukcji „otwórz terminal, przyjdź, adres naszego serwera nadal jest taki” trudno jest dotrzymać 5-minutowego limitu czasu przeznaczonego na reanimację. No i dodatkowo, korzystając z tych przepisów, łatwo jest na przykład odnotować pewne zmiany w infrastrukturze i odpowiednio zmienić przepisy.
No cóż, jeśli system rezerwacji jest bardzo skomplikowany i w pewnym momencie popełniliśmy błąd, to możemy zniszczyć naszą witrynę zapasową, a dodatkowo zamienić dane w dynię na obu stronach - będzie to całkowicie smutne.
Przykład numer pięć, kompletny hardcor
Międzynarodowa usługa z setkami milionów użytkowników na całym świecie. Wszystkie strefy czasowe są, duże obciążenie przy maksymalnej prędkości, w ogóle nie można się położyć. Minuta - i będzie smutno. Co robić? Rezerwacja ponownie, zgodnie z pełnym programem. Zrobiliśmy wszystko, o czym mówiłem w poprzednim przykładzie i trochę więcej. Idealny świat, a nasza infrastruktura jest zgodna ze wszystkimi koncepcjami devops IaaC. Oznacza to, że wszystko jest w git i wystarczy nacisnąć przycisk.
Czego brakuje? Jeden - ćwiczenia. Bez nich nie jest to możliwe. Wydaje się, że u nas wszystko jest idealnie, generalnie mamy wszystko pod kontrolą. Naciskamy przycisk, wszystko się dzieje. Nawet jeśli tak jest – a rozumiemy, że tak się nie dzieje – nasz system współdziała z jakimiś innymi systemami. Na przykład jest to dns z trasy 53, pamięć s3, integracja z jakimś API. W tym spekulatywnym eksperymencie nie będziemy w stanie wszystkiego przewidzieć. Dopóki nie pociągniemy za przełącznik, nie będziemy wiedzieć, czy to zadziała, czy nie.
To chyba wszystko. Nie bądź leniwy i nie przesadzaj. I niech dyspozycyjność będzie z Tobą!
Źródło: www.habr.com