Filozofia inżynierii: Werner Vogels

Najważniejsze wnioski

• Jego definiującą zasadą jest to, że wszystko zawodzi nieustannie, więc projektuje się pod kątem awarii, a nie przeciwko niej. Jako CTO Amazona od 2005 roku Werner Vogels przekuł dosadną obserwację – przy odpowiedniej skali awaria komponentów jest stała i statystycznie gwarantowana – w doktrynę projektową: należy założyć, że każdy dysk, serwer, łącze sieciowe i zależność ulegną awarii, oraz budować systemy, które pozostają dostępne poprzez awarię, zamiast udawać, że można jej zapobiec.¹⁶
• Jest współautorem artykułu o Dynamo, który był pionierem idei stojących za nowoczesnym NoSQL. „Dynamo: Amazon’s Highly Available Key-value Store” (SOSP 2007) połączył spójne haszowanie, zegary wektorowe, luźne kworum, członkostwo oparte na gossip oraz spójność ostateczną w jednym zawsze zapisywalnym magazynie, a także bezpośrednio wpłynął na Cassandrę, Riak, Voldemort oraz własny DynamoDB Amazona.²³
• Jest czołowym ewangelistą spójności ostatecznej. Jego esej „Eventually Consistent” jasno przedstawił kompromis między dostępnością a spójnością: gdy sieć ulega podziałowi – a przy skali tak się stanie – trzeba dokonać wyboru, a Dynamo wybrało pozostanie dostępnym i szybkie osiągnięcie zbieżności zamiast blokowania aż do zgody każdej repliki.⁴⁷
• Dał kulturze inżynierskiej zdanie „you build it, you run it” (budujesz to, utrzymujesz to). W rozmowie z 2006 roku opisał model Amazona, w którym programiści są właścicielami swoich usług na produkcji – definiują je, budują i eksploatują – oraz dowodził, że przydzielenie budowniczym dyżuru na pagerze i kontaktu z klientem jest tym, co napędza jakość.⁵

Zasada

„Wszystko zawodzi, nieustannie.” – Werner Vogels, CTO Amazona, o projektowaniu niezawodnych systemów rozproszonych⁶

Większość inżynierii optymalizuje pod kątem przypadku, w którym wszystko działa. Buduje się szczęśliwą ścieżkę, obsługuje kilka błędów, które da się wyobrazić, i wydaje. Ten instynkt przetrwa dokładnie do momentu działania na dużą skalę – i wtedy zdradza. Gdy uruchamia się setki tysięcy maszyn, „rzadkie” przestaje być rzadkie. Awaria dysku, która zdarza się raz na trzy lata na napęd, zdarza się gdzieś we flocie co kilka minut. Łącze sieciowe gubiące jeden pakiet na milion gubi miliony pakietów dziennie. Najsłynniejsze zdanie Vogelsa kompresuje to do czterech słów: wszystko zawodzi nieustannie.⁶ Awaria nie jest wyjątkiem, który należy obejść inżynieryjnie; przy skali jest to stan ustalony, pod który trzeba projektować.

Wynikająca z tego zasada jest odwróceniem tej zwyczajowej. Skoro nie da się zapobiec awarii – a przy skali w sposób dowodliwy nie da się – to zapobieganie jej jest błędnym celem. Właściwym celem jest pozostawanie dostępnym podczas awarii. Należy więc założyć, że każdy komponent umrze, i projektować tak, aby każda pojedyncza śmierć była do przeżycia: replikować dane między maszynami, aby utrata jednej była niewidoczna, rozprzęgać usługi za interfejsami API, aby awaria zależności degradowała funkcję zamiast obalać system, oraz minimalizować zasięg rażenia każdej usterki, by nie mogła pociągnąć całości w dół. System nie jest budowany po to, by unikać przypadku awarii; jest budowany tak, by przypadek awarii był nudny.¹⁶

Jest też druga połowa zasady i to ona urzeczywistnia pierwszą: nie da się mieć doskonałej spójności i doskonałej dostępności jednocześnie, gdy sieć może ulec podziałowi, więc trzeba wybrać – a Vogels wybrał dostępność. Gdy podział sieci odcina repliki od siebie nawzajem, system może albo odmówić odpowiedzi do czasu, aż wszyscy się zgodzą (spójny, lecz niedostępny), albo dalej odpowiadać tym, co ma, i pogodzić to później (dostępny, lecz na krótko niespójny). Dla koszyka zakupowego Amazona odmowa odpowiedzi była nie do przyjęcia – koszyk, który odrzuca „dodanie do koszyka” podczas podziału, to koszyk, który traci sprzedaż.⁴ Dynamo zatem zawsze przyjmuje zapis i pozwala replikom osiągnąć zbieżność później. Kosztem jest niewielkie okno, w którym różne repliki mogą zwracać różne odpowiedzi; nagrodą jest system, który nigdy nie mówi klientowi „nie”. Ten kompromis – pozostawanie dostępnym i szybkie osiąganie zbieżności zamiast blokowania aż do zgody wszystkich – to spójność ostateczna, a Vogels poświęcił karierę dowodzeniu, że jest to właściwy kompromis przy skali.⁴⁷

Kontekst

Werner Vogels urodził się 3 października 1958 roku w Ermelo w Holandii.¹ Jego droga do informatyki nie była konwencjonalną prostą linią wiodącą przez czołowy uniwersytet. Studiował informatykę na The Hague University of Applied Sciences, kończąc ją w 1989 roku, a dopiero później uzyskał doktorat z informatyki na Vrije Universiteit Amsterdam – jego rozprawa z 2003 roku, „Scalable Cluster Technologies for Mission Critical Enterprise Computing”, była prowadzona przez Henriego Bala i Andrew Tanenbauma, przy czym ten drugi należy do fundamentalnych postaci dziedziny w zakresie systemów rozproszonych i systemów operacyjnych.¹ Warto zachować w pamięci szczegół, że doktorat nastąpił po latach realnej pracy nad systemami, a nie ją poprzedził; teoria dogoniła praktykę.

Najbardziej formacyjny rozdział nadszedł na Cornell University, gdzie w latach 1994-2004 był pracownikiem naukowym zajmującym się skalowalnymi, niezawodnymi systemami korporacyjnymi.¹ Na Cornell przebywał wewnątrz grupy systemów rozproszonych Kena Birmana – linii stojącej za Isis i niezawodną komunikacją grupową, dorobku, który zadawał pytanie, jak zbiór maszyn może się porozumieć, pozostać spójnym i działać dalej, gdy jego członkowie zawodzą i wracają do działania. Współzałożył firmę Reliable Network Solutions wraz z Birmanem i Robbertem van Renesse, pełniąc w niej funkcję VP i CTO.¹ To jest intelektualna gleba, w której wyrósł Vogels: nie „jak powstrzymać maszyny przed awarią”, lecz „jak grupa maszyn pozostaje poprawna i dostępna podczas awarii swoich członków”. Gdy później powiedział, że wszystko zawodzi nieustannie, nie improwizował – formułował założycielską przesłankę tradycji niezawodnych systemów rozproszonych, wewnątrz której spędził dekadę.

Dołączył do Amazona we wrześniu 2004 roku jako dyrektor ds. badań nad systemami, został mianowany CTO w styczniu 2005 roku i dodał tytuł VP w marcu 2005 roku – rolę, którą pełni od tamtej pory, kierując kierunkiem technologicznym w całej firmie.¹ Jego przybycie zbiegło się z latami, gdy Amazon wynajdywał nowoczesną chmurę: system magazynowy Dynamo został zbudowany i opisany w tym okresie, Amazon Web Services uruchomił swoje fundamentalne usługi, a Vogels stał się publicznym głosem zasad architektonicznych leżących pod tym wszystkim – projektować pod kątem awarii, rozprzęgać za pomocą usług, przyjąć spójność ostateczną oraz powierzyć osobom budującym usługę odpowiedzialność za jej eksploatację.²⁴⁵

Dzieło

„Wszystko zawodzi nieustannie”: projektowanie pod kątem awarii i spójność ostateczna

Należy zacząć tutaj, ponieważ jest to zasada przekuta w inżynierię. Doktryna ma dwa ruchy. Pierwszym jest projektowanie pod kątem awarii: traktować każdy komponent jako coś, co ulegnie awarii, i sprawić, by system przetrwał jego utratę. Oznacza to redundancję (replikować tak, aby dowolna kopia mogła zniknąć), rozprzęganie (usługi rozmawiają przez API, aby chora zależność degradowała się z wdziękiem, a nie kaskadowo) oraz ograniczenie zasięgu rażenia (podzielić system tak, aby usterka została uwięziona w małej komórce, zamiast się rozprzestrzeniać).¹⁶ Sprawdzianem projektu nie jest „czy działa, gdy wszystko jest zdrowe”, lecz „co się dzieje, gdy ten element umiera w najgorszym możliwym momencie” – a odpowiedź musi brzmieć „system dalej obsługuje”.

Drugim ruchem jest ten, który czyni wysoką dostępność możliwą przy skali: spójność ostateczna. Obserwacja CAP Erica Brewera mówi, że gdy sieć ulega podziałowi, system rozproszony nie może być jednocześnie doskonale spójny i w pełni dostępny – jednego musi się wyrzec.⁷ „Eventually Consistent” Vogelsa czyni ten wybór wyraźnym i definiuje alternatywę precyzyjnie: w ramach spójności ostatecznej „system magazynowy gwarantuje, że jeśli nie zostaną dokonane nowe aktualizacje obiektu, to ostatecznie wszystkie dostępy zwrócą ostatnio zaktualizowaną wartość”.⁴ Słowo ostatecznie to cały kompromis. System, który kładzie nacisk na dostępność, „może zawsze przyjąć zapis, lecz w pewnych warunkach odczyt nie odzwierciedli wyniku niedawno ukończonego zapisu”.⁴ Przez krótkie, ograniczone okno dwie repliki mogą się różnić – lecz żadna nigdy nie odmawia odpowiedzi. Zbieżność dokonuje się w tle, a użytkownik nigdy nie zostaje zablokowany.

Dlaczego ma to znaczenie jako inżynieria: model myślowy bazy danych u większości programistów jest tym jednomaszynowym, gdzie zapis jest natychmiast widoczny dla każdego kolejnego odczytu, ponieważ istnieje tylko jedna kopia. Ten model nie przetrwa skali, ponieważ jedna kopia to pojedynczy punkt awarii, a jedna maszyna to pułap przepustowości. W chwili replikacji – której trzeba dokonać, aby być dostępnym – dziedziczy się pytanie, co widzi czytający, gdy kopie nadrabiają zaległości. Wkładem Vogelsa było upieranie się, że nie jest to błąd do ukrycia, lecz wymiar projektowy do świadomego wyboru, oraz danie inżynierom słownictwa – read-your-writes, odczyty monotoniczne, spójność sesji – by wybierać dokładnie tyle spójności, ile faktycznie potrzebuje dane obciążenie, zamiast płacić wszędzie za najsilniejszą gwarancję.⁴

Artykuł o Dynamo i ruch NoSQL

Zasada ma kanoniczny artefakt: „Dynamo: Amazon’s Highly Available Key-value Store”, którego Vogels był współautorem i który opublikowano na SOSP 2007, najważniejszym forum systemów operacyjnych w dziedzinie.² Dynamo było odpowiedzią Amazona na konkretne, brutalne wymaganie – koszyk zakupowy musiał przyjmować zapisy zawsze, nawet podczas podziałów centrów danych i awarii dysków, ponieważ niedostępny koszyk bezpośrednio traci przychody.²³ Tradycyjne relacyjne bazy danych, dostrojone do silnej spójności, nie mogły tego obiecać podczas podziału. Amazon zbudował więc magazyn, który wymienił spójność na dostępność i spisał dokładnie, jak.

Dynamo to katalog technik systemów rozproszonych złożonych w jeden zawsze zapisywalny, zdecentralizowany system, a wpływ artykułu bierze się z tego, jak czysto je rozłożył.²³ Spójne haszowanie dzieli dane między węzłami, aby pierścień mógł rosnąć lub się kurczyć bez przetasowywania wszystkiego – „przyrostowa, prawdopodobnie liniowa skalowalność”.³ Zegary wektorowe śledzą przyczynową historię każdej wartości, aby współbieżne zapisy mogły być wykrywane, a nie po cichu gubione. Luźne kworum i przekazanie z podpowiedzią utrzymują system zapisywalnym nawet, gdy część replik jest nieosiągalna, parkując zapisy u tymczasowego zastępcy do czasu powrotu prawowitego węzła. Anty-entropia z drzewami Merkle pozwala replikom sprawnie odnajdywać i naprawiać różnice. Członkostwo oparte na gossip pozwala węzłom poznawać się nawzajem i wykrywać awarie bez centralnego koordynatora – projekt jest celowo symetryczny i zdecentralizowany, tak że „każdy węzeł w Dynamo powinien mieć ten sam zestaw obowiązków co jego rówieśnicy”, co oznacza, że nie ma wyróżnionego węzła, którego śmierć byłaby katastrofalna.³ Każdy z tych wyborów służy temu samemu panu: pozostawaniu dostępnym, gdy coś zawodzi.

Amazon nigdy nie udostępnił kodu Dynamo, lecz to artykuł wykonał pracę – stał się jednym z najbardziej wpływowych artykułów systemowych swojej dekady, intelektualnym zalążkiem ruchu NoSQL.³ Apache Cassandra, Riak i Project Voldemort wywodzą swoje pozbawione lidera, ostatecznie spójne projekty bezpośrednio z niego.³ A nazwa przetrwała komercyjnie w Amazon DynamoDB, który jest zbudowany na zasadach Dynamo, choć podjął inne decyzje inżynierskie pod maską (replikacja z jednym liderem zamiast czystego modelu bez lidera z Dynamo).³ Lekcja płynąca z wpływu Dynamo sama warta jest odnotowania: przewagą konkurencyjną Amazona nie był kod, lecz jasność. Wyjaśniając precyzyjnie, których gwarancji się wyrzekli i dlaczego, nauczyli całe pokolenie inżynierów, jak rozumować o tym kompromisie.

AWS, orientacja na usługi i „you build it, you run it”

Dynamo to system magazynowy; głębszym wkładem Vogelsa jest ten architektoniczny i kulturowy. Platforma Amazona jest zbudowana jako siatka niezależnych usług, które rozmawiają wyłącznie przez API – bez współdzielonych baz danych sięganych zza kurtyny, bez ukrytego sprzężenia.⁵ Ta dyscyplina ma znaczenie dla awarii: gdy usługi są rozprzężone za twardymi interfejsami, zawodząca degraduje konkretną funkcję, którą zasila, zamiast korumpować dane lub blokować wątki wszystkiego, co jej dotknęło. Orientacja na usługi to ograniczenie zasięgu rażenia wyrażone jako architektura. To także to, co umożliwiło AWS – gdy systemy wewnętrzne są czystymi, adresowalnymi przez API usługami, wystawienie ich światu zewnętrznemu jako produktów jest naturalnym kolejnym krokiem.

Połowa kulturowa to zdanie, dla którego Vogels jest cytowany równie często, co dla „wszystko zawodzi nieustannie”: „you build it, you run it” (budujesz to, utrzymujesz to). W rozmowie z 2006 roku z Jimem Grayem opisał model Amazona, w którym każda usługa jest własnością od początku do końca zespołu, który ją tworzy: „Każda usługa ma przypisany zespół, a ten zespół jest całkowicie odpowiedzialny za usługę – od określenia funkcjonalności po jej architekturę, zbudowanie i eksploatację”.⁵ A uzasadnienie dotyczyło wprost jakości poprzez własność: „You build it, you run it. Wprowadza to programistów w kontakt z codzienną eksploatacją ich oprogramowania. Wprowadza ich również w codzienny kontakt z klientem”.⁵ Nie ma muru, przez który można by przerzucić kod; inżynier, który napisał usługę, nosi za nią pager. Efektem jest ciasna pętla sprzężenia zwrotnego – osoba najbardziej zdolna naprawić kruchość to osoba, która czuje jej ból o 3 nad ranem, a osoba, która zaprojektowała funkcję, słyszy skargę klienta bezpośrednio. Własność nie jest tu hasłem działu HR; to mechanizm niezawodności. Zespół, który eksploatuje to, co buduje, projektuje pod kątem awarii, ponieważ awaria budzi jego.

Ewangelizacja chmury: zasięg rażenia, komórki i dobrze zaprojektowane systemy

Czwarty dorobek Vogelsa to mniej pojedynczy artefakt, a bardziej rola pełniona w sposób ciągły: przez dwie dekady był architektem-ewangelistą, który skodyfikował, jak budować na chmurze, a nie tylko jak budować chmurę.¹⁶ Powracające motywy to zasada zastosowana w coraz większym zakresie. Minimalizować zasięg rażenia: dzielić systemy na niezależne komórki, aby usterka, wadliwe wdrożenie lub zatrute żądanie zostały zawężone do wycinka klientów, a nie do wszystkich. Rozprzęgać agresywnie: przedkładać asynchroniczne, luźno sprzężone usługi z jawnymi kontraktami nad ciasne synchroniczne łańcuchy, gdzie jedna powolna zależność blokuje całą ścieżkę wywołania. Automatyzować odzyskiwanie, a nie je dokumentować: instrukcja postępowania wymagająca człowieka nie wykonuje się, gdy człowiek śpi. Przyjąć awarię jako wejście testowe, celowo wstrzykując usterki, aby udowodnić, że system je przeżywa, zamiast mieć nadzieję, że tak będzie. Każde z tych podejść to „wszystko zawodzi nieustannie” przekute w praktykę operacyjną – spójne przesłanie, powtarzane na wystąpieniach, w tekstach i w drugiej rozmowie z ACM lata później, że odporność jest własnością projektowaną od pierwszej linii, a nie warstwą dodawaną po tym, jak demonstracja zadziała.⁶

Metoda

Czytając wszerz Dynamo, spójność ostateczną, orientację na usługi oraz „you build it, you run it”, powracają te same zobowiązania. Metoda Vogelsa to mniej hasło, a bardziej zestaw stałych nawyków.

Należy projektować najpierw pod przypadek awarii. Przy skali awaria jest stanem ustalonym, a nie wyjątkiem, więc pytanie nigdy nie brzmi „czy to działa”, lecz „co się dzieje, gdy każdy kawałek tego umiera”.⁶ Lekcja przenosi się daleko poza skalę Amazona: nie należy pisać szczęśliwej ścieżki i dołatywać obsługi błędów – należy najpierw wyliczyć tryby awarii i pozwolić, by działająca ścieżka wyłoniła się z systemu, który już je przeżywa. To bramka dowodowa zastosowana do niezawodności – „działa na demonstracji” nie jest dowodem; „pozostaje dostępny, gdy zabijam węzeł w trakcie żądania” to ten sam standard samonaprawy, który Radia Perlman wbudowała w sieci ponownie osiągające zbieżność bez człowieka w pętli.

Należy wybierać swoją spójność, a nie ją dziedziczyć. Najgłębszym ruchem w Dynamo jest odrzucenie domyślnego założenia, że każdy odczyt musi widzieć każdy wcześniejszy zapis. Vogels czyni spójność pokrętłem ustawianym pod obciążenie – silnym tam, gdzie poprawność tego wymaga, ostatecznym tam, gdzie bardziej liczy się dostępność – i jest precyzyjny co do tego, którą gwarancję system faktycznie zapewnia.⁴⁷ Dyscyplina polega na dokładnym wiedzeniu, na czym opiera się deklaracja spójności, i na nigdy niepłaceniu za gwarancję, której obciążenie nie potrzebuje. To ta sama precyzja co do poprawności, którą Leslie Lamport wniósł do czasu rozproszonego: nie zakładać własności, lecz zdefiniować ją dokładnie i wiedzieć, kiedy obowiązuje.

Należy rozprzęgać, aby ograniczyć zasięg rażenia. Niezależne usługi za twardymi API oznaczają, że awaria zostaje uwięziona tam, gdzie się zdarza, zamiast kaskadować.⁵ Stałym nawykiem jest rysowanie granic tak, aby najgorszy przypadek był zdegradowaną funkcją, nigdy zaś powalonym systemem – pytanie o każdą zależność „gdy to zawiedzie, jak duża jest dziura?” i czynienie dziury małą. To architektoniczna postać minimalnego godnego produktu: najczystsza granica to ta, która robi dokładnie swoje zadanie i zawodzi samotnie.

Należy sprawić, by budowniczowie byli właścicielami eksploatacji. „You build it, you run it” przydziela osobom projektującym usługę pager za nią, zamykając pętlę między kruchością a osobą zdolną ją naprawić.⁵ Lekcja głosi, że ból operacyjny to najuczciwszy istniejący sygnał jakości – zespół odizolowany od produkcji niedoinwestuje w odporność, ponieważ koszt kruchości spada na kogoś innego. Własność jest mechanizmem niezawodności, czyli jakość to jedyna zmienna przekutą w schemat organizacyjny: jedynym sposobem zagwarantowania jakości jest sprawienie, by budowniczy poczuł konsekwencję jej braku.

Należy wyjaśniać kompromis otwarcie. Wpływ Dynamo nie wziął się z jego kodu – który nigdy nie został udostępniony – lecz z artykułu, który wprost wyłożył, których gwarancji się wyrzeczono i dlaczego.²³ Nawykiem jest uczynienie rozumowania czytelnym: nazwać kompromis, uzasadnić wybraną stronę i nauczyć następnego inżyniera rozumować o nim, zamiast bezmyślnie kopiować wynik. Jasność co do dlaczego jest tym, co pozwala projektowi przeżyć swojego autora – ta sama dyscyplina wyjaśniania, która sprawiła, że artykuły Perlman i Lamporta dawały się nauczać dekady później.

Łańcuch wpływów

Kto go ukształtował

Ken Birman i tradycja niezawodnych systemów rozproszonych z Cornell. Dekada Vogelsa na Cornell, wewnątrz grupy Birmana oraz linii Isis i niezawodnej komunikacji grupowej, jest źródłem jego założycielskiej przesłanki.¹ Centralne pytanie tej tradycji – jak grupa maszyn pozostaje poprawna i dostępna, gdy jej członkowie zawodzą i wracają do działania – to dokładnie pytanie, na które odpowiada „wszystko zawodzi nieustannie”. Nie ukuł hasła; przeformułował pierwszą zasadę swojej dziedziny dla planetarnej publiczności. (Wpływ formacyjny)

Andrew Tanenbaum i akademia systemów rozproszonych. Jego doktorat na Vrije Universiteit był częściowo prowadzony przez Tanenbauma, jednego z fundamentalnych nauczycieli dziedziny w zakresie systemów operacyjnych i rozproszonych.¹ Ugruntowanie widać: Dynamo czyta się jak działającą syntezę kanonu systemów rozproszonych – spójne haszowanie, zegary wektorowe, kworum, gossip – złożoną przez kogoś, kto znał literaturę na wylot. (Wpływ formacyjny)

Eric Brewer i kompromis CAP. Argumentacja Vogelsa za spójnością ostateczną opiera się wprost na obserwacji CAP, że system tolerujący podziały musi wymieniać spójność na dostępność.⁴⁷ Brewer ujął niemożliwość; Vogels zoperacjonalizował wybór przy skali Amazona i uczynił z „wybierz dostępność i osiągnij zbieżność” szanowaną wartość domyślną. (Wpływ bezpośredni)

Kogo ukształtował

Cały ruch NoSQL. Artykuł o Dynamo jest bezpośrednim przodkiem Cassandry, Riak i Voldemort oraz imiennikiem DynamoDB – pozbawiony lidera, ostatecznie spójny wzorzec projektowy rozpropagował się z jednego artykułu z 2007 roku do warstwy danych całego pokolenia systemów.³

Architektura cloud-native i kultura DevOps. „You build it, you run it” stało się jedną z założycielskich idei nowoczesnego DevOps – pełna własność usługi, dyżurujący programiści i rozpuszczenie muru dev/ops wywodzą się bezpośrednio z modelu, który Vogels opisał w 2006 roku.⁵

Całe pokolenie architektów chmury. Poprzez zasady projektowe AWS i swoją nieustanną ewangelizację „projektować pod kątem awarii”, „minimalizować zasięg rażenia” oraz „rozprzęgać za pomocą usług” stały się domyślnym słownictwem, którego inżynierowie używają do rozumowania o budowaniu niezawodnych systemów w chmurze.⁶

Nić przewodnia

Vogels jest zwornikiem skali operacyjnej w tej serii – postacią, która wzięła teorię systemów rozproszonych i uruchomiła ją na planetarnej liczbie maszyn. Leslie Lamport dał systemom rozproszonym ich fundamenty: jak precyzyjnie definiować czas, uporządkowanie i konsensus oraz jak utrzymać system poprawnym, gdy uczestnicy zawodzą lub zachowują się arbitralnie. Vogels to, jak wyglądają te fundamenty, gdy muszą obsłużyć koszyk zakupowy w Czarny Piątek – te same pytania o spójność i awarię, odpowiadane nie na tablicy, lecz pod realnym obciążeniem, z realnym przychodem zależnym od pozostania dostępnym.⁴ A Radia Perlman zbudowała sieci, które traktują przypadek awarii jako centrum projektu, lecząc się same bez człowieka w pętli; Vogels zbudował usługi na dokładnie tym instynkcie, jedną warstwę wyżej w stosie – replikować, rozprzęgać, ograniczać zasięg rażenia i pozwolić systemowi osiągnąć zbieżność samodzielnie. Tam, gdzie Lamport mówi zdefiniuj poprawność i udowodnij, że przeżywa awarię, a Perlman mówi zbuduj to tak, by leczyło się samo, Vogels mówi: wszystko zawodzi nieustannie, więc przestań próbować temu zapobiegać – projektuj tak, by system pozostawał dostępny prosto poprzez awarię, i pozwól budowniczym, którzy go eksploatują, poczuć każdą rysę. (Most serii)

Co z tego biorę

Lekcja, którą zachowuję od Vogelsa, to traktowanie awarii jako przypadku normalnego, a nie wyjątku. Mój instynkt, jak u większości budujących, każe pisać ścieżkę, w której wywołanie się udaje, zależność odpowiada, dysk tam jest – a potem doczepić try/catch, gdy już to działa. „Wszystko zawodzi nieustannie” jest reprymendą: przy jakiejkolwiek realnej skali awaria nie jest rzadkim zdarzeniem przytrafiającym się mojemu systemowi, lecz stałym warunkiem, w którym mój system żyje. Gdy więc buduję teraz coś – zadanie synchronizacji, klienta API, konsumenta kolejki – staram się wychodzić od „co umiera i czy reszta dalej obsługuje, gdy to się dzieje?”, zamiast docierać tam na końcu. Uczciwą wersją „działa” nie jest zielona demonstracja; to zabicie zależności w trakcie żądania i obserwowanie, jak system degraduje się z wdziękiem, zamiast się przewracać. System, który przeżywa tylko szczęśliwą ścieżkę, to system, którego projektowania nie ukończyłem.

Druga lekcja głosi, że dostępność i spójność to kompromis, którego muszę dokonać celowo. Kuszące jest chcieć obu – aby każdy odczyt widział każdy zapis i aby system nigdy nie mówił nie – a dla pojedynczej maszyny da się to mieć. W chwili, gdy cokolwiek replikuję, ten komfort znika, a dyscyplina Vogelsa każe wybierać stronę celowo dla każdego obciążenia, zamiast z przyzwyczajenia domyślnie sięgać wszędzie po najsilniejszą gwarancję. Większość tego, co buduję, nie potrzebuje, by odczyt natychmiast odzwierciedlał najnowszy zapis; potrzebuje, by nigdy nie odmawiać klientowi. Spójność ostateczna przeformułowała to dla mnie ze strasznego kompromisu w precyzyjne narzędzie: nazwać dokładnie, jak nieaktualny może tolerować bycie czytający, kupić dostępność tym luzem i przestać płacić za gwarancję, której funkcja nigdy nie potrzebowała. Umiejętnością nie jest zawsze sięganie po najsilniejszą obietnicę – lecz wiedza o tym, której obietnicy praca faktycznie wymaga.

FAQ

Co oznacza „wszystko zawodzi nieustannie”?

To dokonana przez Wernera Vogelsa kompresja okupionej trudem lekcji o skali: gdy eksploatuje się dostatecznie wiele maszyn, awaria komponentów przestaje być rzadkim wyjątkiem, a staje się stałym, statystycznie gwarantowanym warunkiem.⁶ Tryb awarii dostatecznie rzadki, by zignorować go na jednym serwerze, zdarza się gdzieś w dużej flocie nieustannie. Praktyczną konsekwencją jest odwrócenie normalnej inżynierii: zamiast próbować zapobiec awarii, zakłada się, że każdy dysk, serwer, łącze i zależność ulegną awarii, oraz projektuje się systemy, które pozostają dostępne poprzez awarię – za pomocą redundancji, rozprzęgania i ograniczonego zasięgu rażenia – tak aby każda pojedyncza usterka była do przeżycia i, najlepiej, niewidoczna.¹⁶

Czym jest artykuł o Dynamo?

„Dynamo: Amazon’s Highly Available Key-value Store” to artykuł SOSP z 2007 roku, współautorstwa Vogelsa, opisujący system magazynowy, który Amazon zbudował, aby utrzymać usługi takie jak koszyk zakupowy zapisywalnymi nawet podczas awarii i podziałów sieci.²³ Połączył spójne haszowanie do partycjonowania, zegary wektorowe do śledzenia współbieżnych zapisów, luźne kworum i przekazanie z podpowiedzią do pozostawania dostępnym podczas awarii, anty-entropię z drzewami Merkle do naprawy oraz gossip do zdecentralizowanego członkostwa – wszystko w służbie zawsze przyjmowania zapisu i godzenia go później. Amazon nigdy nie udostępnił kodu, lecz artykuł stał się fundamentalny dla ruchu NoSQL, wpływając bezpośrednio na Cassandrę, Riak, Voldemort oraz Amazon DynamoDB.³

Czym jest spójność ostateczna?

Spójność ostateczna to złagodzony model spójności, który Vogels propagował i zdefiniował w eseju „Eventually Consistent”: „jeśli nie zostaną dokonane nowe aktualizacje obiektu, to ostatecznie wszystkie dostępy zwrócą ostatnio zaktualizowaną wartość”.⁴ W systemie replikowanym zapis może dotrzeć do części replik wcześniej niż do innych, więc przez krótkie okno różne repliki mogą zwracać różne odpowiedzi – lecz żadna nigdy nie odmawia żądania. System pozostaje dostępny i osiąga zbieżność w tle, zamiast blokować aż do zgody każdej repliki. To strona dostępności kompromisu CAP: gdy sieć ulega podziałowi, system może być spójny (odmówić odpowiedzi do zgody wszystkich) albo dostępny (odpowiedzieć tym, co ma, i pogodzić później), a spójność ostateczna wybiera dostępny.⁴⁷

Co oznacza „you build it, you run it”?

„You build it, you run it” to opis Vogelsa, z rozmowy ACM Queue z 2006 roku, modelu pełnej własności usługi w Amazonie: zespół, który buduje usługę, jest „całkowicie odpowiedzialny za usługę – od określenia funkcjonalności po jej architekturę, zbudowanie i eksploatację”.⁵ Nie ma muru między rozwojem a operacjami – inżynierowie, którzy napisali kod, noszą za niego pager. Vogels dowodził, że „wprowadza to programistów w kontakt z codzienną eksploatacją ich oprogramowania” oraz „w codzienny kontakt z klientem”, a wynikająca z tego pętla sprzężenia zwrotnego jest tym, co napędza jakość.⁵ Idea stała się jedną z założycielskich zasad nowoczesnej kultury DevOps.

Źródła