Latem tradycyjnie zmniejsza się zarówno aktywność kupiecką, jak i intensywność zmian w infrastrukturze projektów internetowych, mówi nam Kapitan Oczywistość. Po prostu dlatego, że nawet informatycy, zdarza się, idą na urlop. I CTO również. Tym gorzej tym, którzy pozostają na stanowisku, ale teraz nie o tym: może właśnie dlatego lato to najlepszy okres na spokojne przemyślenie obecnego schematu rezerwacji i opracowanie planu jego ulepszenia. W tym pomoże wam doświadczenie Egora Andriejewa z , o którym opowiedział na konferencji .
Podczas budowy miejsc rezerwowych, przy rezerwowaniu jest kilka pułapek, w które można wpaść. A wpadać w nie absolutnie nie można. Zawodzi nas w tym, jak i w wielu innych sprawach, perfekcjonizm i… lenistwo. Staramy się zrobić wszystko idealnie, a idealnie robić nie trzeba! Należy wykonać tylko określone rzeczy, ale zrobić je poprawnie, doprowadzić do końca, aby działały prawidłowo.
Failover nie jest jakąś fajną zabawką „żeby było”; to rzecz, która powinna zrobić dokładnie jedno — zmniejszyć czas przestoju, aby serwis, firma, traciły mniej pieniędzy. We wszystkich metodach rezerwacji proponuję myśleć w następującym kontekście: gdzie są pieniądze?
Pierwsza pułapka: kiedy budujemy duże niezawodne systemy i zajmujemy się rezerwacją — zmniejszamy liczbę awarii. To straszne złudzenie. Kiedy zajmujemy się rezerwacją, liczba awarii prawdopodobnie wzrasta. A jeśli zrobimy wszystko poprawnie, to łącznie zmniejszymy czas przestoju. Awarii będzie więcej, ale będą występować z mniejszymi kosztami. Cóż, czym jest rezerwacja? — to komplikacja systemu. Każda komplikacja to źle: pojawia się więcej śrubek, więcej kół zębatych, jednym słowem, więcej elementów — a zatem większe ryzyko awarii. I one naprawdę się zepsują. I będą się psuć częściej. Prosty przykład: powiedzmy, że mamy jakiś serwis, z PHP, MySQL. I pilnie trzeba go zarezerwować.
Cóż, bierzemy drugą platformę i budujemy identyczny system… Złożoność wzrasta dwukrotnie — mamy dwa byty. A ponadto nakładamy pewną logikę przenoszenia danych z jednej platformy na drugą — czyli replikację danych, kopiowanie statycznych zasobów i tak dalej. Otóż, logika replikacji — zazwyczaj bywa bardzo skomplikowana, a zatem łączna złożoność systemu może być nie 2, a 3, 5, 10 razy większa.
Druga pułapka: gdy budujemy naprawdę duże, skomplikowane systemy, fantazjujemy, co chcemy osiągnąć na końcu. Voilà: chcemy uzyskać super niezawodny system, który działa całkowicie bez przestojów, przełącza się w pół sekundy (a najlepiej całkowicie natychmiastowo) i zaczynamy urzeczywistniać nasze marzenia. Ale tutaj też jest niuans: im krótszy czas przełączenia, tym bardziej skomplikowana staje się logika systemu. Im bardziej skomplikowaną logikę musimy stworzyć, tym częściej system będzie się psuł. I można wpaść w bardzo nieprzyjemną sytuację: na wszelkie sposoby staramy się zmniejszyć czas przestoju, a w rzeczywistości tylko wszystko komplikujemy, a kiedy coś idzie nie tak, czas przestoju ostatecznie będzie dłuższy. Często łapiemy się na myśli: lepiej byłoby nie rezerwować. Lepiej, żeby działał jeden system z jasnym czasem przestoju.
Jak można z tym walczyć? Trzeba przestać okłamywać się, przestać się łudzić, że teraz zbudujemy statek kosmiczny, a raczej realistycznie zrozumieć, ile projekt może trwać. I na podstawie tego maksymalnego czasu będziemy wybierać, jakimi metodami faktycznie zwiększymy niezawodność naszego systemu.
Nadszedł czas na „historie z życia”…, oczywiście.
Przykład numer jeden
Wyobraź sobie stronę wizytówkową fabryki rur nr 1 w mieście N. Na niej dużymi literami napisano — FABRYKA RUR NR 1. Nieco niżej znajduje się slogan: „Nasze rury — najbardziej okrągłe rury w N”. A poniżej numer telefonu dyrektora generalnego i jego imię. Rozumiemy, że trzeba rezerwować — to bardzo ważna sprawa! Zaczynamy się zastanawiać, z czego to się składa. Html-statystyka — czyli para zdjęć, na których dyrektor, właściwie, przy stole w wannie z partnerem omawia jakąś kolejną transakcję. Zaczynamy myśleć o czasie przestoju. Do głowy przychodzi: leżeć tam trzeba pięć minut, nie więcej. I pojawia się pytanie: a ile z tej naszej strony było sprzedaży w ogóle? Ile, ile? Co znaczy „zero”? A to znaczy: ponieważ wszystkie cztery transakcje w ubiegłym roku dyrektor zrealizował przy tym samym stole, z tymi samymi ludźmi, z którymi chodzą do wanny i siedzą przy stole. I rozumiemy, że nawet jeśli strona poleży dzień — nic strasznego się nie wydarzy.
Biorąc pod uwagę dane wejściowe, mamy dzień na zrealizowanie tej historii. Zaczynamy myśleć o schemacie rezerwacji. Wybieramy najidealniejszy schemat rezerwacji dla tego przykładu: rezerwacja w ogóle nie jest potrzebna. Cała ta sprawa jest stawiana przez każdego administratora w pół godziny z przerwami. Ustawienie serwera webowego, wrzucenie plików — wszystko. To będzie działać. Nie trzeba niczego pilnować, nie ma niczego, na co trzeba by poświęcać szczególna uwagę. Czyli wniosek z przykładu numer jeden jest dość oczywisty: usługi, które nie wymagają rezerwacji — rezerwować nie trzeba.
Przykład numer dwa
Blog firmowy: wyspecjalizowani pracownicy piszą tam wiadomości, oto braliśmy udział w takiej a nie innej wystawie, a oto wypuściliśmy kolejny nowy produkt, i tak dalej. Załóżmy, że to standardowy PHP z WordPressem, niewielka baza danych i trochę statyki. Oczywiście znowu przychodzi do głowy, że nie można leżeć w żadnym wypadku — „nie więcej niż pięć minut!”, to wszystko. Ale pomyślmy dalej. Co ten blog robi? Przyciąga odwiedzających z Yandexa, z Google'a na jakieś zapytania, korzystając z ruchu organicznego. Fajnie. A jak to się ma do sprzedaży? Oświecenie: niezbyt. Ruch reklamowy trafia na główną stronę, która jest na innej maszynie. Zaczynamy myśleć o schemacie rezerwacji bloga. Tak naprawdę, potrzeba kilku godzin, aby go uruchomić, i byłoby dobrze się do tego przygotować. Rozsądnie byłoby wziąć maszynę w innym centrum danych, zainstalować na niej środowisko, to znaczy serwer www, PHP, WordPress, MySQL i pozostawić to w trybie uśpienia. W momencie, gdy zrozumiemy, że wszystko się zepsuło, musimy zrobić dwie rzeczy — przywrócić kopię zapasową mysql o pojemności 50 MB, co zajmie minutę, oraz przywrócić pewną ilość obrazków z kopii zapasowej. To też nie jest nic strasznego. W ten sposób w pół godziny wszystko uruchamiamy. Żadnych replikacji, ani, nie daj Boże, automatycznego przełączenia awaryjnego. Wniosek: to, co możemy szybko przywrócić z kopii zapasowej — nie trzeba rezerwować.
Przykład numer trzy, bardziej złożony
Sklep internetowy. PHP z lekko modyfikowanym open heart, MySQL z solidną bazą. Sporo statyki (w końcu w sklepie internetowym są piękne obrazy HD i tym podobne), Redis do zarządzania sesjami i Elasticsearch do wyszukiwania. Zaczynamy myśleć o czasie przestoju. I tutaj, oczywiście, oczywiste jest, że dzień bezproblemowego działania sklepu internetowego nie może być osiągnięty. Im dłużej leży, tym więcej pieniędzy tracimy. Czas przyspieszyć. A jak bardzo? Uważam, że jeśli przez godzinę będziemy mieli przestój, to nikt nie oszaleje. Tak, coś stracimy, ale zacznijmy działać — będzie tylko gorzej. Określamy schemat dopuszczalnego przestoju do godziny.
Jak to wszystko można zarezerwować? Samochód jest potrzebny w każdym przypadku: godzina to dość mało. Mysql: tutaj już potrzebna jest replikacja, żywa replikacja, ponieważ w ciągu godziny 100 GB do zrzutu prawdopodobnie się nie wciśnie. Statyczne pliki, obrazki: znów, w ciągu godziny 500 GB może nie zdążyć się załadować. Lepiej od razu kopiować obrazki. Redis: tu jest ciekawiej. W Redisie przechowywane są sesje – po prostu wziąć i pogrzebać go nie możemy. Bo to nie skończy się dobrze: wszyscy użytkownicy zostaną wylogowani, koszyki będą opróżnione i tak dalej. Ludzie będą musieli na nowo wprowadzać swoje loginy i hasła, a wielu może się zniechęcić i nie dokończyć zakupu. Znowu, konwersja spadnie. Z drugiej strony, Redis jest aktualny, z ostatnimi zalogowanymi użytkownikami, zapewne też nie jest potrzebny. Dobrym kompromisem jest wziąć Redis i przywrócić go z kopii zapasowej, z wczorajszej, lub, jeśli robisz to co godzinę, – sprzed godziny. Na szczęście, przywrócenie go z kopii zapasowej to skopiowanie jednego pliku. A najciekawsza historia to Elasticsearch. Kto kiedykolwiek uruchamiał replikację MySQL? Kto kiedykolwiek uruchamiał replikację Elasticsearch? I komu to działało później poprawnie? Chodzi mi o to: widzimy w naszym systemie pewną jednostkę. Wydaje się użyteczna – ale jest skomplikowana.
Trudne w tym sensie, że nasi koledzy inżynierowie nie mają doświadczenia w pracy z tym. Albo mają negatywne doświadczenia. Albo rozumiemy, że to dość nowa technologia z pewnymi niuansami lub niedoróbkami. Myślimy… Ech, elastic też jest spory, jego odzyskiwanie z kopii zapasowej trwa długo, co robić? Rozumiemy, że elastic w naszym przypadku jest używany do wyszukiwania. A jak sprzedaje nasz sklep internetowy? Zgłaszamy się do marketerów, pytamy, skąd ludzie w ogóle przychodzą. Odpowiadają: „90% przychodzi bezpośrednio z Yandex Market w kartę produktu”. I albo kupują, albo nie. W związku z tym wyszukiwanie jest potrzebne dla 10% użytkowników. A utrzymywanie replikacji elastic'a, szczególnie między różnymi centrami danych w różnych strefach, wiąże się z naprawdę wieloma niuansami. Jaki jest wyjście? Bierzemy elastic na zarezerwowanej platformie i nic z nim nie robimy. Jeśli sprawa się przedłuży, to kiedyś może go jeszcze uruchomimy, ale to niepewne. Właściwie, podsumowując, nasze wnioski są w miarę podobne: usługi, które nie wpływają na pieniądze, ponownie, nie rezerwujemy. Aby schemat pozostał prostszy.
Przykład numer cztery, jeszcze trudniejszy.
Integrator: sprzedaż kwiatów, wezwanie taksówki, sprzedaż towarów, w ogóle, cokolwiek. Poważna sprawa, która działa 24/7 dla dużej liczby użytkowników. Z pełnym, interesującym stosem, gdzie są ciekawe bazy, rozwiązania, duże obciążenie i co najważniejsze, nie może leżeć dłużej niż 5 minut, bo to boli. Nie tylko dlatego, że ludzie nie kupią, ale dlatego, że zauważą, że to urządzenie nie działa, będą zawiedzeni i mogą w ogóle nie wrócić po raz drugi.
Okej. Pięć minut. Co z tym zrobimy? W takim przypadku poważnie, za wszystkie pieniądze budujemy prawdziwą zapasową platformę, z replikacją wszystkiego i wszędzie, a może nawet zautomatyzujemy maksymalnie przełączenie na tę platformę. I oprócz tego nie zapomnijmy zrobić jednej ważnej rzeczy: napisać regulamin przełączenia. Regulamin, nawet jeśli wszystko jest zautomatyzowane, może być bardzo prosty. Z serii „uruchomić ten skrypt ansible”, „w route 53 zaznaczyć tę opcję” itd. — ale to powinien być jakiś konkretny, dokładny wykaz działań.
Wydaje się, że wszystko jest jasne. Przełączenie replikacji to trywialne zadanie, albo przełączy się samo. Zmiana nazwy domeny w DNS to te same zagadnienia. Problem polega na tym, że kiedy taki projekt pada, zaczyna się panika, a nawet najbardziej doświadczeni admini mogą dać się jej ponieść. Bez jasnej instrukcji „otwórz terminal, wejdź tutaj, adres naszego serwera to wciąż ten” ciężko jest wytrzymać 5 minut przeznaczonych na reanimację. A ponadto, korzystając z tego regulaminu, łatwo jest odnotować wszelkie zmiany w infrastrukturze i w odpowiedni sposób zmienić regulamin.
Ale jeśli system rezerwacji jest bardzo złożony i w pewnym momencie popełnimy błąd, możemy równie dobrze unieruchomić naszą rezerwową lokalizację, a dodatkowo dane obydwu lokalizacji przeistoczą się w paździerz — to będzie naprawdę smutne.
Przykład numer pięć, całkowity hardcore
Międzynarodowa usługa z setkami milionów użytkowników na całym świecie. Wszystkie strefy czasowe, jakie tylko istnieją, highload na najwyższych obrotach, nie możemy sobie pozwolić na przestoje. Minuta — i będzie smutno. Co robić? Rezerwować, znowu w pełnym wymiarze. Zrobiliśmy wszystko to, o czym mówiłem w poprzednim przykładzie, a nawet trochę więcej. Idealny świat, a nasza infrastruktura — to w pełni pojęcie DevOps IaaC. Czyli wszystko jest w git, a ty tylko naciskasz przycisk.
Czego brakuje? Tylko jednego — szkoleń. Bez nich się nie da. Wydaje się, że wszystko jest idealne, że wszystko mamy pod kontrolą. Naciskamy przycisk, wszystko się dzieje. Nawet jeśli tak jest — a wiemy, że tak nie bywa — nasz system współpracuje z jakimiś innymi systemami. Przykładowo, to DNS z Route 53, magazyn S3, integracja z jakimiś API. Nie będziemy w stanie przewidzieć wszystkiego w tym teoretycznym eksperymencie. A dopóki rzeczywiście nie pociągniemy za dźwignię — nie dowiemy się, czy to działa, czy nie.
Na tym pewnie kończymy. Nie bądźcie leniwi i nie przesadzajcie. Niech uptime będzie z wami!
Źródło: habr.com
