Tytuł oryginału: Site Reliability Engineering: How Google ...

Tytuł oryginału: Site Reliability Engineering: How Google Runs Production Systems

Tłumaczenie: Tomasz Walczak

ISBN: 978-83-283-3730-5

© 2017 Helion SA

Authorized Polish translation of the English edition of Site Reliability Engineering ISBN 9781491929124 © 2016 Google, Inc.

This translation is published and sold by permission of O'Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher.

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.

Wydawnictwo HELIONul. Kościuszki 1c, 44-100 GLIWICEtel. 32 231 22 19, 32 230 98 63e-mail: [email protected]: http://helion.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku!Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/sireenMożesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

Printed in Poland.

• Kup książkę• Poleć książkę • Oceń książkę

• Księgarnia internetowa• Lubię to! » Nasza społeczność

http://helion.pl/rt/sireen

http://helion.pl/rf/sireen

http://helion.pl/ro/sireen

http://helion.pl

p://ebookpoint.pl/r/4CAKF

5

Spis treści

Przedmowa .............................................................................................................. 13

Wstęp ....................................................................................................................... 15

Część I. Wprowadzenie ......................................................................... 23

1. Wprowadzenie .......................................................................................................... 25Zarządzanie usługami przez administratorów systemów 25Podejście do zarządzania usługami w Google’u — Site Reliability Engineering 26Założenia podejścia SRE 29Koniec początku 34

2. Środowisko produkcyjne w Google’u z perspektywy SRE ............................................. 35Sprzęt 35Oprogramowanie „organizujące” pracę sprzętu 37Inne systemy oprogramowania 40Infrastruktura dla oprogramowania 40Nasze środowisko programistyczne 41Shakespeare — przykładowa usługa 42

Część II. Zasady .................................................................................... 45

3. Akceptowanie ryzyka ................................................................................................ 47Zarządzanie ryzykiem 47Pomiar ryzyka związanego z usługą 48Tolerancja ryzyka dla usługi 50Uzasadnienie stosowania budżetu błędów 54

Poleć książkęKup książkę



6 Spis treści

4. Poziomy SLO ............................................................................................................. 59Terminologia związana z poziomem usług 59Wskaźniki w praktyce 62Cele w praktyce 65Umowy w praktyce 68

5. Eliminowanie harówki .............................................................................................. 69Definicja harówki 69Dlaczego ograniczenie harówki jest korzystne? 71Co kwalifikuje się jako prace inżynieryjne? 72Czy harówka zawsze jest czymś złym? 72Wniosek 74

6. Monitorowanie systemów rozproszonych .................................................................. 75Definicje 75Po co monitorować? 76Wyznaczanie rozsądnych oczekiwań względem monitorowania 77Symptomy a przyczyny 78Monitorowanie czarnoskrzynkowe i białoskrzynkowe 79Cztery złote sygnały 79Uwzględnianie wartości skrajnych (lub narzędzia pomiarowe i sprawność) 81Określanie odpowiedniej szczegółowości pomiarów 81Tak proste jak to możliwe, ale nie prostsze 82Łączenie opisanych zasad 82Monitorowanie długoterminowe 83Wnioski 86

7. Ewolucja automatyzacji w Google’u ........................................................................... 87Wartość automatyzacji 87Wartość dla zespołów SRE w Google’u 89Przypadki zastosowania automatyzacji 90Wyautomatyzuj się z pracy — automatyzuj WSZYSTKO! 93Łagodzenie problemów — stosowanie automatyzacji do uruchamiania klastrów 95Borg — narodziny komputera na skalę hurtowni 101Podstawową cechą jest niezawodność 102Zalecenia 103

8. Inżynieria udostępniania ......................................................................................... 105Rola inżyniera udostępniania 105Filozofia 106Ciągłe budowanie i wdrażanie 108Zarządzanie konfiguracją 111Wnioski 112




Spis treści 7

9. Prostota ...................................................................................................................115Stabilność a elastyczność systemu 115Cnota nudy 116Nie oddam mojego kodu! 116Wskaźnik „negatywne wiersze kodu” 117Minimalne interfejsy API 117Modułowość 117Udostępnianie prostych zmian 118Prosty wniosek 118

Część III. Praktyki ............................................................................... 119

10. Praktyczne alarmy na podstawie szeregów czasowych ..............................................123Powstanie systemu Borgmon 124Narzędzia pomiarowe w aplikacji 125Zbieranie eksportowanych danych 126Przechowywanie danych w obszarze szeregów czasowych 126Sprawdzanie reguł 129Alarmy 132Podział systemu monitorowania 133Monitorowanie czarnoskrzynkowe 134Zarządzanie konfiguracją 135Dziesięć lat później… 136

11. Dyżury na wezwanie ................................................................................................139Wprowadzenie 139Życie inżyniera dyżurnego 140Zrównoważone dyżury 141Poczucie bezpieczeństwa 142Unikanie nieodpowiedniego obciążenia operacyjnego 144Wnioski 145

12. Skuteczne rozwiązywanie problemów ......................................................................147Teoria 148Praktyka 150Wyniki negatywne to magia 156Studium przypadku 158Ułatwianie rozwiązywania problemów 162Wnioski 162




8 Spis treści

13. Reagowanie kryzysowe ........................................................................................... 163Co robić, gdy w systemie wystąpi awaria? 163Kryzys wywołany testami 164Sytuacje kryzysowe spowodowane zmianami 165Sytuacje kryzysowe spowodowane procesem 167Dla każdego problemu istnieje rozwiązanie 169Wyciągaj wnioski z przeszłości i nie powtarzaj tych samych błędów 170Wnioski 170

14. Zarządzanie incydentami ........................................................................................ 173Niezarządzane incydenty 173Anatomia niezarządzanego incydentu 174Aspekty procesu zarządzania incydentami 175Zarządzany incydent 176Kiedy ogłaszać incydent? 177Podsumowanie 178

15. Kultura analizy zdarzeń — wyciąganie wniosków z niepowodzeń ............................ 179Filozofia analizy zdarzeń w Google’u 179Współpracuj i dziel się wiedzą 181Wprowadzanie kultury analizy zdarzeń 182Wnioski i wprowadzane usprawnienia 184

16. Śledzenie przestojów .............................................................................................. 185Escalator 185Outalator 186

17. Testowanie niezawodności ...................................................................................... 191Rodzaje testów oprogramowania 192Tworzenie środowiska testowania i środowiska budowania 198Testowanie w dużej skali 199Wnioski 210

18. Inżynieria oprogramowania w SRE ........................................................................... 211Dlaczego inżynieria oprogramowania w zespołach SRE ma znaczenie? 211Studium przypadku. Auxon — wprowadzenie do projektu i przestrzeń problemowa 213Planowanie przepustowości na podstawie celów 215Wspomaganie inżynierii oprogramowania w SRE 223Wnioski 227




Spis treści 9

19. Równoważenie obciążenia na poziomie frontonu .....................................................229Moc nie jest rozwiązaniem 229Równoważenie obciążenia z użyciem systemu DNS 230Równoważenie obciążenia na poziomie wirtualnych adresów IP 232

20. Równoważenie obciążenia w centrum danych ..........................................................235Scenariusz idealny 236Identyfikowanie problematycznych zadań — kontrola przepływu i „kulawe kaczki” 237Ograniczanie puli połączeń za pomocą tworzenia podzbiorów 239Reguły równoważenia obciążenia 244

21. Obsługa przeciążenia ...............................................................................................251Pułapki związane z „liczbą zapytań na sekundę” 251Limity na klienta 252Ograniczanie liczby żądań po stronie klienta 253Poziom krytyczności 255Sygnały poziomu wykorzystania 256Obsługa błędów przeciążenia 257Obciążenie wynikające z połączeń 260Wnioski 261

22. Radzenie sobie z awariami kaskadowymi ..................................................................263Przyczyny awarii kaskadowych i projektowanie z myślą o ich uniknięciu 264Zapobieganie przeciążeniu serwerów 268Powolny rozruch i pusta pamięć podręczna 276Warunki wywołujące awarie kaskadowe 279Testowanie pod kątem awarii kaskadowych 280Pierwsze kroki w obliczu awarii kaskadowych 283Uwagi końcowe 285

23. Zarządzanie krytycznym stanem — zapewnianie niezawodnościza pomocą konsensusu w środowisku rozproszonym .................................................287Uzasadnienie uzgadniania konsensusu — niepowodzenie koordynacji systemówrozproszonych 289Jak działa konsensus w środowisku rozproszonym? 291Wzorce architektury systemu związane z konsensusem w środowisku rozproszonym 292Wydajność uzgadniania konsensusu w środowisku rozproszonym 297Wdrażanie rozproszonego systemu opartego na konsensusie 305Monitorowanie rozproszonych systemów uzgadniania konsensusu 312Wnioski 314




10 Spis treści

24. Okresowe szeregowanie prac w środowisku rozproszonym za pomocą crona ............. 315cron 315Prace crona a idempotencja 316cron w dużej skali 317Budowanie crona w Google’u 318Podsumowanie 325

25. Potoki przetwarzania danych .................................................................................. 327Początki wzorca projektowego „potok danych” 327Początkowy wpływ big data na prosty wzorzec potoku danych 327Wyzwania związane ze wzorcem „okresowo uruchamiany potok danych” 328Problemy powodowane przez nierównomierny podział pracy 328Wady okresowo uruchamianych potoków w środowiskach rozproszonych 329Wprowadzenie do systemu Workflow Google’a 332Etapy wykonywania w systemie Workflow 334Zapewnianie ciągłości biznesowej 335Podsumowanie i uwagi końcowe 336

26. Integralność danych — wczytywanie tego, co zostało zapisane ............................... 337Ścisłe wymagania z zakresu integralności danych 338Cele zespołów SRE w Google’u w zakresie integralności i dostępności danych 342Jak zespoły SRE Google’a radzą sobie z problemami z integralnością danych? 346Studia przypadków 357Ogólne zasady SRE stosowane w obszarze integralności danych 363Wnioski 365

27. Niezawodne udostępnianie produktów w dużej skali ............................................... 367Inżynieria koordynowania udostępniania 368Konfigurowanie procesu udostępniania 370Tworzenie listy kontrolnej udostępniania 373Wybrane techniki niezawodnego udostępniania 377Powstawanie zespołu LCE 381Wnioski 384

Część IV. Zarządzanie ..........................................................................385

28. Szybkie przygotowywanie inżynierów SRE do dyżurów i innych zadań ...................... 387Zatrudniłeś nowych inżynierów SRE. Co dalej? 387Początkowe pouczające doświadczenia — argument na rzecz przewagi strukturynad chaosem 389Rozwój świetnych ekspertów od inżynierii odwrotnej i improwizatorów 393




Spis treści 11

Pięć praktyk dla przyszłych dyżurnych 395Dyżury i inne zadania — rytuał przejścia i ciągłe uczenie się 400Końcowe myśli 401

29. Radzenie sobie z zakłóceniami ..................................................................................403Zarządzanie obciążeniem operacyjnym 404Czynniki wpływające na sposób zarządzania zakłóceniami 404Niedoskonałe maszyny 405

30. Angażowanie inżyniera SRE w celu wyeliminowania przeciążenia operacyjnego ........411Etap 1. Poznaj usługę i kontekst 412Etap 2. Przedstawianie kontekstu 414Etap 3. Motywowanie do zmian 415Wnioski 417

31. Komunikacja i współpraca w zespołach SRE ...............................................................419Komunikacja — spotkania produkcyjne 420Współpraca w ramach zespołów SRE 423Studium przypadku z obszaru współpracy w zespołach SRE — Viceroy 425Współpraca z zespołami innymi niż SRE 429Studium przypadku — przeniesienie DFP do F1 430Wnioski 432

32. Zmiany w modelu angażowania się zespołów SRE .....................................................433Zaangażowanie zespołów SRE — co, jak i dlaczego? 433Model PGP 434Model angażowania się zespołów SRE 434Przeglądy gotowości produkcyjnej — prosty model oparty na PGP 436Ewolucja prostego modelu opartego na PGP — wczesne zaangażowanie 439Zmiany w rozwoju usług — frameworki i platforma SRE 441Wnioski 446

Część V. Wnioski ................................................................................. 447

33. Lekcje z innych branż ...............................................................................................449Poznaj naszych branżowych weteranów 450Testowanie gotowości i odporności na katastrofy 451Kultura analizy zdarzeń 454Eliminowanie powtarzalnej pracy i kosztów operacyjnych dzięki automatyzacji 456Ustrukturyzowane i racjonalne podejmowanie decyzji 457Wnioski 459

34. Podsumowanie ........................................................................................................461




12 Spis treści

A Tabela dostępności .................................................................................................. 465

B Zbiór dobrych praktyk dotyczących usług produkcyjnych .......................................... 467

C Przykładowy dokument ze stanem incydentu .......................................................... 473

D Przykładowa analiza zdarzenia ................................................................................ 475

E Lista kontrolna LCE .................................................................................................. 479

F Przykładowe notatki ze spotkania produkcyjnego .................................................... 481

Bibliografia ............................................................................................................. 483

Skorowidz ............................................................................................................... 494




251

ROZDZIAŁ 21.

Obsługa przeciążenia

Autor: Alejandro Forero CuervoRedakcja: Sarah Chavis

Unikanie przeciążenia to cel reguł równoważenia obciążenia. Jednak niezależnie od tego, jak wydajnesą te reguły, ostatecznie niektóre części systemu staną się przeciążone. Płynna obsługa takich sytuacjijest nieodzowna, jeśli chcesz zarządzać niezawodnym systemem serwerowym.

Jedną z możliwości obsługi przeciążenia jest zwracanie odpowiedzi awaryjnych, które nie są tak precy-zyjne jak zwykłe lub zawierają mniej danych, ale są łatwiejsze do obliczenia. Oto przykład:

Zamiast przeszukiwać cały zbiór danych w celu zapewnienia najlepszych dostępnych wynikówdla zapytania do wyszukiwarki, można uwzględniać tylko niewielki procent potencjalnie odpo-wiednich danych.

Można korzystać z lokalnej kopii wyników, która nie zawsze jest w pełni aktualna, ale jest mniejkosztowna w użyciu niż posługiwanie się standardowym magazynem danych.

Jednak przy skrajnym przeciążeniu usługa może nie radzić sobie nawet z wyznaczaniem i udostęp-nianiem odpowiedzi awaryjnych. Na takim etapie jedyną możliwością do natychmiastowego zasto-sowania jest zwracanie błędów. Jednym ze sposobów na złagodzenie skutków tej sytuacji jest równo-ważenie ruchu między centrami danych w taki sposób, aby żadne centrum nie otrzymywało więcejżądań, niż jest w stanie przetworzyć. Na przykład jeśli w centrum danych działa 100 zadań zapleczai każde z nich potrafi przetworzyć do 500 żądań na sekundę, to algorytm równoważenia obciążenianie powinien pozwalać na przekazywanie do tego centrum więcej niż 50 tys. zapytań na sekundę. Jed-nak nawet to ograniczenie może okazać się niewystarczające do uniknięcia przeciążenia, jeśli systemdziała na dużą skalę. Ostatecznie najlepiej jest tak budować klienty i zadania zaplecza, by płynnie ra-dziły sobie z ograniczeniami zasobów. Gdy to możliwe, należy przekierowywać ruch, w razie koniecz-ności zwracać wyniki awaryjne, a gdy wszystko inne zawiedzie, bezpośrednio obsługiwać błędy zwią-zane z zasobami.

Pułapki związane z „liczbą zapytań na sekundę”Różne zapytania mogą mieć bardzo zróżnicowane wymagania co do zasobów. Koszt zapytania możesię różnić w zależności od arbitralnych czynników, takich jak kod klienta, który je zgłasza (w usługach




252 Rozdział 21. Obsługa przeciążenia

o wielu klientach), a nawet pora dnia (np. użytkownicy firmowi i prywatni lub interaktywny ruchgenerowany przez użytkowników końcowych i ruch z operacji wsadowych).

Przekonaliśmy się o tym na własnej skórze. „Zapytania na sekundę” lub statyczne cechy żądań uważa-ne za przybliżenie ilości zużywanych zasobów (np. „ile kluczy wczytuje żądanie”) to często małoprzydatne miary do modelowania przepustowości. Nawet jeśli w danym okresie używana miara dajedobre efekty, może się to zmienić. Czasem zmiany następują stopniowo, jednak nieraz zachodzągwałtownie (np. nowa wersja oprogramowania nagle sprawia, że niektóre funkcje z pewnych żądańwymagają znacznie mniej zasobów). Taki „ruchomy cel” jest niezbyt przydatną miarą do użytkuw ramach projektowania i implementowania równoważenia obciążenia.

Lepszym rozwiązaniem jest pomiar przepustowości bezpośrednio na poziomie dostępnych zasobów.Załóżmy, że dla danej usługi w określonym centrum danych zarezerwowanych jest 500 rdzeni proce-sora i 1 TB pamięci. Oczywiście znacznie lepiej jest modelować przepustowość centrum danych bezpo-średnio za pomocą tych liczb. Często mówimy o koszcie żądania, posługując się znormalizowaną miarązajmowanego czasu procesora (z uwzględnieniem różnic w sprawności różnych architektur procesorów).

W większości sytuacji (choć zdecydowanie nie we wszystkich) dobrze sprawdza się proste używanieobciążenia procesorów jako wskaźnika zapotrzebowania na zasoby. Wynika to z następującychpowodów:

W platformach z odzyskiwaniem pamięci duże obciążenie pamięci w naturalny sposób przekładasię na większe wykorzystanie procesorów.

W innych platformach można udostępniać pozostałe zasoby w taki sposób, że bardzo mało praw-dopodobne jest wyczerpanie się ich przed zajęciem całej mocy procesorów.

W sytuacjach, gdy zapewnienie nadmiarowej ilości zasobów innych niż procesor jest zbyt kosztowne,przyglądamy się osobno poszczególnym zasobom w trakcie analizowania ich zużycia.

Limity na klientaJednym z aspektów radzenia sobie z przeciążeniem jest określanie, co zrobić w przypadku globalnegoprzeciążenia. W idealnym świecie, gdzie zespoły starannie koordynują udostępnianie swoich produk-tów z właścicielami powiązanych usług zaplecza, globalne przeciążenie nigdy nie następuje, a usługizaplecza zawsze zapewniają przepustowość wystarczającą do obsługi klientów. Niestety, nie żyjemyw idealnym świecie. W praktyce globalne przeciążenie zdarza się stosunkowo często (zwłaszczaw usługach wewnętrznych, z których nieraz korzystają liczne klienty wielu zespołów).

Gdy globalne przeciążenie wystąpi, bardzo ważne jest, by usługa zwracała odpowiedzi o błędach tylkodo niewłaściwie pracujących klientów. Nie powinno to wpływać na pozostałe klienty. Aby to osiągnąć,właściciele usługi zapewniają przepustowość na podstawie poziomu zużycia zasobów wynegocjo-wanego z klientami i według tego definiują limity dla klientów.

Na przykład jeśli usłudze zaplecza przydzielono na świecie 10 tys. procesorów (w różnych centrachdanych), limity dla klientów mogą wyglądać tak:

Gmail może zużywać do 4000 s czasu procesora na sekundę.

Kalendarz może zużywać do 4000 s czasu procesora na sekundę.




Ograniczanie liczby żądań po stronie klienta 253

Android może zużywać do 3000 s czasu procesora na sekundę.

Google+ może zużywać do 2000 s czasu procesora na sekundę.

Wszyscy pozostali użytkownicy mogą zużywać do 500 s czasu procesora na sekundę.

Zauważ, że te liczby mogą w sumie przekroczyć 10 tys. procesorów przydzielonych tej usłudze zaple-cza. Właściciel usługi opiera się na tym, że mało prawdopodobne jest, by wszyscy klienci jednocześnieosiągnęli limit zużycia zasobów.

Globalne informacje o poziomie zużycia zasobów agregujemy globalnie w czasie rzeczywistym dlawszystkich zadań zaplecza. Na podstawie tych danych zmieniamy limity dla poszczególnych zadańzaplecza. Dokładne omawianie systemu wykonującego to zadanie wykracza poza zakres rozdziału.Napisaliśmy jednak dużo kodu do realizowania tego procesu w zadaniach zaplecza. Ciekawą częściąukładanki jest obliczanie w czasie rzeczywistym zasobów (zwłaszcza czasu procesora) wykorzystywa-nych przez każde żądanie. Jest to skomplikowane przede wszystkim w serwerach, w których nie mazaimplementowanego modelu „jeden wątek na żądanie”, gdzie pula wątków obsługuje przychodząceróżne części wszystkich żądań, używając nieblokujących interfejsów API.

Ograniczanie liczby żądań po stronie klientaGdy klient przekroczy limit, zadanie zaplecza powinno szybko odrzucać żądania z założeniem, żezwrócenie błędu „klient przekroczył limit” wymaga znacznie mniej zasobów niż przetworzenie żąda-nia i zwrócenie poprawnej odpowiedzi. Jednak nie we wszystkich usługach jest to prawdą. Na przykładprawie równie kosztowne jest odrzucenie żądania wymagającego prostego wyszukania danych w pa-mięci RAM (kiedy to koszt obsługi protokołu żądań i odpowiedzi jest znacznie wyższy niż koszt wyge-nerowania odpowiedzi) co przyjęcie i obsłużenie go. Nawet w sytuacjach, gdy odrzucenie żądań po-zwala zaoszczędzić dużo zasobów, żądania i tak zużywają zasoby. W takich sytuacjach zadaniezaplecza może stać się przeciążone również wtedy, gdy większość czasu procesora jest przeznaczana naodrzucanie żądań!

Rozwiązaniem problemu jest ograniczanie żądań po stronie klienta1. Gdy klient wykrywa, że dużaczęść żądań z ostatniego czasu została odrzucona z powodu błędów „przekroczenia limitu”, zaczynaautoregulację i ogranicza ilość generowanego wychodzącego ruchu. Żądania powodujące przekrocze-nie ograniczenia są blokowane lokalnie i nawet nie trafiają do sieci.

Ograniczanie żądań po stronie klienta zaimplementowaliśmy za pomocą techniki, którą nazwaliśmyadaptacyjnym ograniczaniem. Każde zadanie klienckie przechowuje następujące informacje na tematostatnich dwóch minut pracy:

requests

Liczba żądań, które próbowała zgłosić warstwa aplikacji (po stronie klienta, powyżej systemuadaptacyjnego ograniczania).

accepts

Liczba żądań zaakceptowanych przez zadanie zaplecza. 1 Zob. np. narzędzie Doorman (https://github.com/youtube/doorman) — kooperatywny rozproszony system ogranicza-

nia żądań po stronie klienta.





W normalnych warunkach obie te wartości są sobie równe. Gdy zadanie zaplecza zaczyna odrzucaćżądania, wartość accepts spada poniżej wartości requests. Klienty mogą kontynuować zgłaszanieżądań do zadania zaplecza do momentu, gdy requests jest K razy większe niż accepts. Po dojściudo tego poziomu klient zaczyna autoregulację i nowe żądania są odrzucane na poziomie lokalnym(czyli po stronie klienta) z prawdopodobieństwem wyrażonym w równaniu 21.1.

)1

,0max(requests

acceptsKrequests

Równanie 21.1. Prawdopodobieństwo odrzucenia żądania klienta

Gdy klient sam zaczyna odrzucać żądania, wartość requests stale przekracza wartość accepts. Choćwydaje się to sprzeczne z intuicją, to ponieważ lokalnie odrzucane żądania nie są przekazywane do za-dania zaplecza, jest to rozwiązanie preferowane. Gdy szybkość przekazywania żądań przez aplikacjędo klienta rośnie (względem szybkości, z jaką zadanie zaplecza je akceptuje), chcemy zwiększaćprawdopodobieństwo odrzucania nowych żądań.

W usługach, w których koszt przetwarzania żądań jest bardzo bliski kosztowi ich odrzucenia, pozwa-lanie na zużywanie połowy zasobów tego zadania na odrzucanie żądań może być nieakceptowalne.W takiej sytuacji rozwiązanie jest proste — należy zmodyfikować stosowany do wartości acceptsmnożnik K (równy 2) we wzorze na prawdopodobieństwo odrzucenia żądania klienta (równanie 21.1).Dzięki temu:

zmniejszenie mnożnika powoduje bardziej agresywne adaptacyjne ograniczanie;

zwiększenie mnożnika zmniejsza agresywność adaptacyjnego ograniczania.

Na przykład zamiast włączania autoregulacji klienta, gdy requests = 2 * accepts, można zastosowaćautoregulację na poziomie requests = 1.1 * accepts. Obniżenie wartości modyfikatora do 1,1 oznacza,że tylko jedno żądanie zostanie przez zadanie zaplecza odrzucone na każdych 10 zaakceptowanych.

Ogólnie preferujemy stosowanie mnożnika 2. Pozwalając na dotarcie do zadania zaplecza większejliczby żądań, niż zgodnie z oczekiwaniami jest to dopuszczalne, marnujemy więcej zasobów tegozadania, ale też przyspieszamy przekazywanie informacji o stanie z zadania zaplecza do klientów.Jeśli zadanie zaplecza zdecyduje się zakończyć odrzucanie żądań od zadań klienckich, czas do wykryciatej zmiany stanu przez wszystkie zadania klienckie będzie wtedy krótszy.

Odkryliśmy, że adaptacyjne ograniczanie dobrze się sprawdza w praktyce i prowadzi do stabilnegopoziomu liczby żądań na ogólnym poziomie. Nawet w sytuacji wysokiego przeciążenia zadania zaple-cza odrzucają tylko jedno żądanie na każde żądanie obsłużone. Ważną zaletą tego podejścia jest to, żedecyzja jest podejmowana przez zadanie klienckie wyłącznie na podstawie lokalnych informacji i sto-sunkowo prostej implementacji. Nie występują tu dodatkowe zależności ani kary w postaci wzrostuopóźnienia.

Dodatkową kwestią jest to, że ograniczanie żądań po stronie klienta może się nie sprawdzać w klien-tach, które bardzo rzadko kierują żądania do zadań zaplecza. Wtedy wgląd każdego klienta w stanzadań zaplecza jest znacznie słabszy, a próby zwiększenia go są zwykle kosztowne.




Poziom krytyczności 255

Poziom krytycznościPoziom krytyczności to następne pojęcie, które uznaliśmy za niezwykle przydatne w kontekście glo-balnych limitów i ograniczania żądań. Żądanie skierowane do zadania zaplecza otrzymuje jeden z czte-rech możliwych poziomów krytyczności (od najbardziej do najmniej krytycznego):

CRITICAL_PLUS

Zarezerwowany dla najbardziej krytycznych żądań, których niepowodzenie skutkuje poważnymiproblemami widocznymi dla użytkowników.

CRITICAL

Jest to poziom domyślny dla żądań zgłaszanych przez prace produkcyjne. Te żądania powodująskutki widoczne dla użytkowników, ale ich wpływ jest mniej poważny niż na poziomie CRITICAL_PLUS. Usługi powinny zapewniać wystarczającą przepustowość dla całego oczekiwanego ruchu

z poziomów CRITICAL i CRITICAL_PLUS.

SHEDDABLE_PLUS

Dotyczy ruchu, dla którego oczekiwana jest częściowa niedostępność. Jest to poziom domyślnydla prac wsadowych, które mogą ponawiać żądania po upływie minut, a nawet godzin.

SHEDDABLE

Dotyczy ruchu, dla którego oczekiwana jest częsta częściowa niedostępność i okazjonalna pełnaniedostępność.

Stwierdziliśmy, że te cztery wartości są wystarczające do uwzględnienia prawie każdej usługi. Wie-lokrotnie dyskutowaliśmy nad propozycjami dodatkowych wartości, ponieważ pozwoliłyby oneprecyzyjniej klasyfikować żądania. Jednak definiowanie dodatkowych wartości wymagałoby więcejzasobów do obsługi różnych systemów uwzględniających poziomy krytyczności.

Krytyczność potraktowaliśmy jako pełnoprawny aspekt systemu RPC i ciężko pracowaliśmy, aby zin-tegrować ją z wieloma mechanizmami kontrolnymi, tak by można było uwzględniać ją w ramachreagowania na przeciążenie. Oto przykłady:

Gdy klient przekroczy globalny limit, zadanie zaplecza odrzuca żądania z danego poziomukrytyczności tylko wtedy, jeśli odrzuca już żądania z wszystkich niższych poziomów (opisanewcześniej obsługiwane przez nasz system limity dla klientów można też ustawiać dla poziomówkrytyczności).

Gdy samo zadanie jest przeciążone, szybciej zaczyna odrzucać żądania o niższym poziomiekrytyczności.

System adaptacyjnego ograniczania przechowuje statystyki osobno dla każdego poziomukrytyczności.

Poziom krytyczności żądania jest niezależny od wymagań związanych z opóźnieniem, a tym samymod obowiązującego dla sieci poziomu jakości usług (ang. Quality of Service — QoS). Na przykładgdy system wyświetla wyniki wyszukiwania lub sugestie w trakcie wpisywania zapytania w wyszuki-warce, z obsługi żądań można łatwo zrezygnować (jeśli system jest przeciążony, niewyświetlaniewyników jest akceptowalne), natomiast wymagania związane z opóźnieniem są tu zwykle wysokie.





Znacznie rozbudowaliśmy też nasz system RPC, aby poziom krytyczności był przekazywany auto-matycznie. Jeśli zadanie zaplecza otrzymuje żądanie A i w ramach jego przetwarzania zgłasza żądaniaB i C do innych zadań zaplecza, żądania B i C będą domyślnie miały ten sam poziom krytycznościco żądanie A.

W przeszłości w wielu systemach w Google’u powstały doraźne poziomy krytyczności, często niekom-patybilne między usługami. Dzięki ustandaryzowaniu i przekazaniu poziomów krytyczności w ra-mach systemu RPC obecnie możemy w spójny sposób ustawiać je w określonych punktach. To dajenam pewność, że przeciążone zależne zadania będą respektować poziomy krytyczności, odrzucającruch, niezależnie od tego, jak głęboko w stosie wywołań RPC działają. Dlatego staramy się ustawiaćpoziom krytyczności jak najbliżej przeglądarek lub klientów mobilnych (zwykle we frontonachHTTP, które generują zwracany kod w HTML-u) i zmieniać go tylko w specjalnych sytuacjach, gdyma to sens w określonym punkcie stosu.

Sygnały poziomu wykorzystaniaNasza implementacja ochrony przed przeciążeniem na poziomie zadania jest oparta na poziomiewykorzystania. W wielu sytuacjach jest to tylko miara stopnia obciążenia procesorów (czyli aktualneobciążenie procesorów podzielone przez łączną moc procesorów zarezerwowaną dla danego zadania).Czasem jednak uwzględniamy też wskaźniki takie jak to, jaka część zarezerwowanej pamięci jestobecnie używana. Gdy poziom wykorzystania zbliża się do ustalonego progu, zaczynamy odrzucaćżądania na podstawie ich poziomu krytyczności (dla wyższej krytyczności próg wykorzystania jestwyższy).

Używane przez nas sygnały poziomu wykorzystania są oparte na lokalnym stanie zadania (ponieważcelem sygnałów jest ochrona zadań). Stosujemy różne sygnały. Najczęściej przydatny sygnał jestoparty na „obciążeniu” w procesie, określanym przy użyciu systemu nazywanego przez nas średnimobciążeniem wątków wykonawczych.

Aby ustalić średnie obciążenie wątków wykonawczych, zliczamy aktywne wątki procesu. Określenie„aktywne” oznacza tu wątki, które aktualnie działają lub są gotowe do pracy i czekają na wolny pro-cesor. Wartości „wygładzamy”, stosując wykładniczą funkcję zaniku, i zaczynamy odrzucać żądania,gdy liczba aktywnych wątków przekracza liczbę procesorów dostępnych dla zadania. To oznacza, żewszystkie przychodzące żądania o bardzo wysokim stopniu rozgałęzienia (generują one bardzo dużąliczbę krótkich operacji) powodują bardzo krótki skok obciążenia, który jednak zostaje w większościukryty dzięki wygładzaniu. Jeśli jednak operacje nie są krótkie (obciążenie wtedy rośnie i pozostajewysokie przez dłuższy czas), zadanie zacznie odrzucać żądania.

Choć średnie obciążenie wątków wykonawczych okazało się bardzo przydatnym sygnałem, nasz sys-tem potrafi uwzględnić dowolne sygnały poziomu wykorzystania potrzebne dla konkretnego zada-nia zaplecza. Możemy np. posłużyć się szczytowym wykorzystaniem pamięci (określa on, że zużyciepamięci w zadaniu zaplecza wzrosło ponad standardowe parametry operacyjne) jako innym sygnałempoziomu wykorzystania. System można też skonfigurować tak, by łączył wiele sygnałów i odrzucałżądania, które skutkują przekroczeniem sumarycznego (lub cząstkowego) docelowego progu.




Obsługa błędów przeciążenia 257

Obsługa błędów przeciążeniaOprócz zapewnienia płynnej obsługi obciążenia długo analizowaliśmy też to, jak klienty powinnyreagować po otrzymaniu odpowiedzi o błędzie związanym z obciążeniem. W przypadku takich błę-dów rozróżniamy dwie sytuacje.

Przeciążony jest duży podzbiór zadań zaplecza w centrum danych

Jeśli system równoważenia obciążenia między centrami danych działa w idealny sposób (czylipotrafi przekazywać informacje o stanie i natychmiast reagować na zmiany w ruchu), ta sytuacjanigdy nie występuje.

Przeciążony jest niewielki podzbiór zadań zaplecza w centrum danych

Ta sytuacja jest zwykle powodowana niedoskonałością mechanizmów równoważenia obciążeniaw centrum danych. Na przykład zadanie mogło niedawno otrzymać bardzo kosztowne żądanie.W takiej sytuacji wysoce prawdopodobne jest, że centrum danych dzięki innym zadaniom mamożliwość obsługiwania żądań.

Gdy przeciążony jest duży podzbiór zadań zaplecza, nie należy ponawiać zgłoszeń, a błędy powinnybyć przekazywane aż do nadawcy (błąd należy więc zwrócić użytkownikowi końcowemu). Jednakznacznie częściej przeciążona jest tylko niewielka część zadań. Wtedy preferowaną reakcją jest na-tychmiastowe ponowienie żądania. Nasz system równoważenia obciążenia między centrami danychzwykle próbuje przekierować ruch od klientów do najbliższych dostępnych centrów danych z zada-niami zaplecza. Czasem najbliższe centrum danych jest znacznie oddalone (najbliższe dostępne zada-nie zaplecza dla klienta może się znajdować na innym kontynencie), jednak przeważnie udajenam się usytuować klienty blisko powiązanych zadań zaplecza. Dzięki temu dodatkowe opóźnieniewynikające z ponowienia żądania (to tylko kilka wymian komunikatów w sieci) jest pomijalne.

Z perspektywy reguł równoważenia obciążenia próby ponawiania żądań są nieodróżnialne od nowychżądań. Oznacza to, że nie stosujemy bezpośrednio kodu do upewniania się, że ponowione żądanietrafi do innego zadania zaplecza. Polegamy na wysokim prawdopodobieństwie, że ponowna próbatrafi do innego zadania z powodu dużej liczby zadań zaplecza w podzbiorze. Upewnianie się, że wszyst-kie ponawiane żądania trafiają do innych zadań, zwiększałoby złożoność interfejsów API w więk-szym stopniu, niż jest to tego warte.

Nawet gdy zadanie zaplecza jest tylko w niewielkim stopniu przeciążone, żądania klienta są częstolepiej obsługiwane, jeśli zadanie zaplecza na równych zasadach i szybko odrzuca ponawiane i noweżądania. Odrzucone żądanie można natychmiast ponowić, kierując je do innego zadania zaplecza,w którym dostępne mogą być wolne zasoby. Efekt traktowania w zadaniach zaplecza ponawianychi nowych żądań w ten sam sposób jest taki, że ponawianie żądań w innych zadaniach pozwala w natu-ralny sposób równoważyć obciążenie. Jest ono przekierowywane do zadań, które mogą być lepiejdostosowane do ich obsługi.

Decydowanie o ponowieniu żądaniaGdy klient otrzymuje odpowiedź z błędem „przeciążone zadanie”, musi zdecydować, czy ponowićżądanie. Stosujemy kilka mechanizmów pozwalających uniknąć ponawiania żądań, gdy znaczna częśćzadań w klastrze jest przeciążona.





Po pierwsze, stosujemy budżet ponowień dla żądania na poziomie trzech prób. Jeśli żądanie już trzyrazy spowodowało błąd, pozwalamy na zwrócenie błędu do nadawcy żądania. Wynika to z następują-cego rozumowania: jeśli żądanie już trzykrotnie trafiło do przeciążonego zadania, jest stosunkowomało prawdopodobne, że następna próba pomoże; w takiej sytuacji zapewne całe centrum danychjest przeciążone.

Po drugie, stosujemy budżet ponowień dla klienta. Każdy klient śledzi odsetek ponowień żądań. Żąda-nie jest ponawiane tylko wtedy, gdy ta wartość wynosi poniżej 10%. Wynika to z tego, że gdy przecią-żony jest stosunkowo niewielki podzbiór zadań, ponawianie powinno być potrzebne stosunkoworzadko.

W ramach konkretnego przykładu (najgorszego scenariusza) załóżmy, że centrum danych akcep-tuje niewielką ilość żądań, a dużą ich część odrzuca. Niech X będzie łączną liczbą żądań przekaza-nych do centrum danych przez kod kliencki. Z powodu liczby potrzebnych ponowień liczba żądańznacznie wzrośnie — do poziomu niewiele niższego niż 3X. Choć ograniczyliśmy liczbę żądań spowo-dowanych ponowieniami, trzykrotny wzrost jest znaczący (zwłaszcza gdy koszt odrzucenia żądaniajest wysoki w porównaniu z kosztem jego przetworzenia). Jednak uwzględnienie budżetu ponowieńdla klienta (odsetek ponowień na poziomie 10%) w ogólnym przypadku zmniejsza ten wzrost do 1,1X,co stanowi znaczną poprawę.

Trzecie podejście polega na tym, że klienty umieszczają w metadanych żądania liczbę prób. Przypierwszej próbie licznik ma wartość 0 i jest zwiększany po każdym ponowieniu żądania aż do osiągnię-cia wartości 2, kiedy to wyczerpanie budżetu ponowień dla żądania powoduje zaprzestanie dalszychprób. Zadania zaplecza przechowują histogramy tych wartości z niedawnej historii. Gdy zadanie za-plecza musi odrzucić żądanie, sprawdza te histogramy, aby ustalić prawdopodobieństwo, że innezadania zaplecza też są przeciążone. Jeśli histogramy wskazują na dużą liczbę ponowień (co oznacza,że inne zadania zaplecza też zapewne są przeciążone), zwracany jest błąd „przeciążone, nie ponawiać”zamiast standardowego błędu „zadanie jest przeciążone”, który skutkuje ponowną próbą.

Rysunek 21.1 przedstawia liczbę prób dla każdego żądania w określonym zadaniu zaplecza w różnychprzykładowych sytuacjach. Wartości te dotyczą przesuwanego okna obejmującego 1000 początkowychżądań (nie licząc ponowień). Dla uproszczenia budżet ponowień dla klienta jest tu ignorowany(w wynikach zakładamy, że uwzględniany jest tylko budżet ponowień w wysokości trzech próbna żądanie). Ponadto zastosowanie podzbiorów mogłoby nieco zmienić uzyskane wartości.

Większe z naszych usług mają zwykle postać dużych stosów systemów, które z kolei mogą być zależneod siebie. W takiej architekturze żądania powinny być ponawiane tylko w warstwie bezpośrednionad warstwą, która je odrzuca. Gdy uznajemy, że danego żądania nie można obsłużyć i nie należy goponawiać, zgłaszamy błąd „przeciążone, nie ponawiać” i unikamy w ten sposób kombinatorycznejeksplozji ponawianych prób.

Przyjrzyj się przykładowi z rysunku 21.2 (w praktyce nasze stosy są często dużo bardziej złożone).Wyobraź sobie, że fronton bazy danych jest obecnie przeciążony i odrzuca żądania. W tej sytuacji:

Zadanie zaplecza B spróbuje ponowić żądanie zgodnie z opisanymi wskazówkami.




Obsługa błędów przeciążenia 259

Rysunek 21.1. Histogramy liczby prób w różnych warunkach

Jednak gdy zadanie zaplecza B wykryje, że żądanie do frontonu bazy danych nie może zostaćobsłużone (np. w wyniku trzykrotnego odrzucenia prób), musi zwrócić do zadania zaplecza Aalbo błąd „przeciążone, nie ponawiać”, albo odpowiedź awaryjną (przy założeniu, że można wy-generować częściowo przydatną odpowiedź nawet po nieudanym żądaniu do frontonu bazydanych).

Zadanie zaplecza A ma dokładnie te same możliwości w stosunku do żądania otrzymanego odfrontonu i wykonuje analogiczne operacje.

Rysunek 21.2. Stos zależności

Ważne jest to, że nieudane żądanie do frontonu bazy danych powinno być ponawiane tylko przezzadanie zaplecza B, czyli warstwę bezpośrednio nad tym frontonem. Ponawianie prób przez wielewarstw prowadzi do eksplozji kombinatorycznej.





Obciążenie wynikające z połączeńObciążenie wynikające z połączeń to ostatni czynnik, o którym warto wspomnieć. Czasem uwzględ-niamy tylko obciążenie zadań zaplecza spowodowane bezpośrednio otrzymywanymi żądaniami (jestto jeden z problemów z podejściami, w których model obciążenia jest oparty na zapytaniach na se-kundę). Jednak skutkuje to ignorowaniem kosztów procesora i pamięci związanych z dużą liczbąpołączeń. Nieuwzględniany jest też koszt szybkiego przełączania połączeń. W małych systemach teproblemy są pomijalne, jednak szybko stają się problematyczne w działających na bardzo dużą skalęsystemach wywołań RPC.

Wcześniej wspomnieliśmy już, że nasz protokół RPC wymaga okresowego sprawdzania stanu przeznieaktywne klienty. Gdy połączenie jest nieużywane przez ustalony czas, klient zamyka połączenieTCP i nawiązuje połączenie UDP na potrzeby sprawdzania stanu. Niestety, to rozwiązanie jest pro-blematyczne, gdy bardzo duża liczba zadań klienckich zgłasza bardzo niewielką liczbę żądań. Spraw-dzanie stanu za pomocą połączeń może wtedy wymagać więcej zasobów niż sama obsługa żądań.Techniki takie jak staranne dostosowanie parametrów połączeń (np. znaczne zmniejszenie częstotli-wości sprawdzania stanu) lub nawet dynamiczne tworzenie i zamykanie połączeń pozwalają znaczniepoprawić sytuację.

Obsługa skoków liczby żądań nawiązania nowych połączeń to drugi problem. Widzieliśmy tegotypu skoki w rozbudowanych pracach wsadowych, które tworzyły jednocześnie bardzo dużą liczbęroboczych zadań klienckich. Konieczność jednoczesnego nawiązywania i utrzymywania dużej liczbynowych połączeń może łatwo przeciążyć grupę zadań zaplecza. Według naszych doświadczeń istniejekilka strategii pomagających zmniejszyć to obciążenie:

Przekazanie obciążenia do algorytmu równoważenia obciążenia między centrami danych (odpo-wiedzialnego za podstawowe równoważenie obciążenia na bazie wykorzystania klastrów, a niewedług samej liczby żądań). W takiej sytuacji obciążenie z żądań jest przekazywane do innychcentrów danych o wolnej przepustowości.

Zobowiązanie klienckich prac wsadowych do stosowania odrębnego zestawu zadań zapleczapełniących funkcję pośredników prac wsadowych. Takie zadania jedynie przekazują w kontrolo-wany sposób żądania do podstawowych zadań zaplecza i dostarczają odpowiedzi od nich doklientów. Dlatego zamiast komunikacji „klient wsadowy zadanie zaplecza” mamy sekwencję„klient wsadowy pośrednik prac wsadowych zadanie zaplecza”. Wtedy gdy bardzo dużapraca rozpoczyna działanie, wpływa to tylko na pośrednika prac wsadowych, który chroni pod-stawowe zadania zaplecza (i klienty o wyższym priorytecie). Pośrednik pełni tu funkcję bezpiecz-nika. Inna zaleta stosowania pośrednika jest taka, że zwykle ogranicza to liczbę połączeń z zada-niem zaplecza. Może to skutkować usprawnieniem równoważenia obciążenia dla zadań zaplecza(zadania pośredniczące mogą korzystać z większych podzbiorów i często nawet mieć lepszy wglądw stan zadań zaplecza).




Wnioski 261

WnioskiW rozdziałach tym i 20. omówiliśmy, jak za pomocą różnych technik (deterministycznego określaniapodzbiorów, algorytmu rotacyjnego z wagami, ograniczania żądań po stronie klienta, limitów dlaklientów itd.) rozdzielać w stosunkowo równomierny sposób obciążenie między zadania w centrumdanych. Jednak te mechanizmy wymagają przekazywania stanu w systemie rozproszonym. Choćw ogólnych sytuacjach rozwiązania te działają całkiem dobrze, w rzeczywistych aplikacjach zdarzająsię scenariusze, w których te mechanizmy okazują się niedoskonałe.

Dlatego uważamy za bardzo istotne zapewnianie ochrony poszczególnych zadań przed przeciążeniem.Ujmijmy to prosto: zadanie zaplecza z zasobami pozwalającymi na obsługę określonego poziomuruchu powinno radzić sobie z ruchem na tym poziomie bez istotnych zmian opóźnień niezależnieod tego, jak dużo dodatkowego ruchu jest do niego kierowane. Wynika z tego, że zadanie zaplecza niemoże zawodzić i ulegać awarii z powodu obciążenia. Te stwierdzenia powinny być prawdziwe dlaokreślonego poziomu ruchu — w przybliżeniu większego niż dwukrotność, a nawet do dziesięciokrot-ności obciążenia, jakie zadanie potrafi obsłużyć za pomocą przydzielonych mu zasobów. Akceptujemyto, że istnieje poziom, powyżej którego system zaczyna się załamywać, i że dalsze podnoszenie tegoprogu może być stosunkowo trudne.

Najważniejsze jest, by poważnie traktować warunki prowadzące do pogorszenia pracy systemu. Jeśli tewarunki są ignorowane, wiele systemów zaczyna działać bardzo źle. Gdy praca się nawarstwia, a zada-nia zaczynają wyczerpywać pamięć i ulegać awarii (lub zużywają prawie cały czas procesora na migo-tanie pamięci), opóźnienie rośnie, ponieważ żądania są odrzucane, a zadania współzawodniczą o zaso-by. Jeśli się tym nie zajmiesz, awaria części systemu (np. jednego zadania zaplecza) może doprowadzićdo awarii innych komponentów. Grozi to wyłączeniem całego systemu lub dużej jego części. Wpływtego rodzaju awarii kaskadowych może być tak poważny, że w każdym systemie działającym w dużejskali niezwykle istotna jest ochrona przed taką sytuacją (zob. rozdział 22.).

Często popełnianym błędem jest zakładanie, że przeciążone zadanie zaplecza powinno odrzucać i prze-stać przyjmować cały ruch. Takie podejście byłoby niezgodne z celem, jakim jest stabilne równowa-żenie obciążenia. W praktyce chcemy, by zadanie zaplecza nadal obsługiwało jak największą częśćruchu, ale tylko po uwolnieniu przepustowości. Dobrze działające zadanie zaplecza wspomaganeprzez solidne reguły równoważenia obciążenia powinno akceptować tylko te żądania, które potrafi ob-służyć; pozostałe żądania należy odrzucać.

Choć posiadamy wiele narzędzi do implementowania skutecznego równoważenia obciążenia i ochro-ny przed przeciążeniem, uniwersalne rozwiązanie nie istnieje. Równoważenie obciążenia często wy-maga dogłębnego zrozumienia systemu i semantyki używanych w nim żądań. Techniki opisane w tymrozdziale ewoluowały wraz z potrzebami stawianymi przez wiele systemów Google’a i zapewnenadal będą się zmieniać wraz z naturą naszych systemów.




494 Skorowidz

Skorowidz

Aadekwatność, 98administrator systemu

zarządzanie usługami, 25agregowanie

alarmów, 187pomiarów, 63

akceptowanie ryzyka, 47aktualizacje procesu, 279alarmy, 83, 132alerty, 40algorytm

kontrolowanego opóźnienia, 270rotacyjny, 244

z wagami, 248z wyborem jednostki, 246

wyborupodzbiory deterministyczne, 242podzbiory losowe, 240

analizadanych, 188przyczyn źródłowych, 120wydajności, 302zdarzeń, 120, 179, 395, 454, 475

chronologia incydentu, 477usprawnienia, 184w Google’u, 179wnioski, 476wprowadzanie kultury, 182

zgłoszeń, 409anatomia niezarządzanego incydentu, 174archiwa, 341automatyzacja, 87, 456

awarie na wielką skalę, 104hierarchia klas, 92oszczędność czasu, 89

platforma, 88skalowanie, 87system zarządzania klastrem, 101szybsze działania, 89szybsze naprawy, 88uruchamianie klastrów, 95zastosowania, 90

Auxon, 217implementacja, 219przyciąganie użytkowników, 220

awarie, 163, 470częściowe, 321kaskadowe, 263

czynniki, 279przeciążenie serwerów, 268przyczyny, 264rozwiązywanie problemu, 283testowanie, 280

powodowane sprawdzaniem stanu, 283

Bbezpieczeństwo, 142, 452big data, 327błędna interpretacja statystyk, 64błędy

przeciążenia, 257w konfiguracji, 96

Borgmonalarmy, 132powstanie systemu, 124przechowywanie danych, 126reguły, 129system monitorowania, 124zarządzanie konfiguracją, 135zbieranie danych, 126




Skorowidz 495

budowanie, 108crona, 318

budżet błędów, 54, 57, 468kształtowanie, 55usługi, 30

Ccele

definiowanie, 65wybór, 66

centrum danych, 235changelist, CL, 41chronologia incydentu, 477ciągłe

budowanie i wdrażanie, 108uczenie się, 400

ciągłość biznesowa, 335cron, 315

rozbudowana infrastruktura, 317uruchamianie dużej instalacji, 324w Google’u, 318zwiększone wymagania, 318

czas wymiany komunikatów, 238

Ddebugowanie Shakespeare’a, 152decydowanie o niepowodzeniu, 467definicja

celów, 65celów SLO, 468harówki, 69

deskryptory plików, 266DevOps, 29DiRT, Disaster and Recovery Testing, 145, 451DNS, 230dobre praktyki, 467dokumentacja, 398

stanu incydentu, 176, 473dostęp do dysku, 304dostępność, 29

danych, 342DSR, Direct Server Return, 234duża liczbą odczytów, 300dystrakcje, 406dyżurny, 395dyżury, 141, 400, 408dzienniki, 152dzierżawa dla kworum, 300

Eeksplozja oprogramowania, 117eksportowanie zmiennych, 125elastyczność systemu, 115eliminowanie

harówki, 69obciążenia, 284powtarzalnej pracy, 456przeciążenia operacyjnego, 411szkodliwego ruchu, 285

Escalator, 185etykiety, 127ewolucja prostego modelu opartego na PGP, 439

FFast Paxos

analizowanie wydajności, 302FIFO, first-in, first-out, 270format BLOB, 340formy wsparcia, 435frameworki, 442fronton, 229

Ggenerowanie reguł, 125GFS, Google File System, 38, 96Gmail, 84GRE, Generic Routing Encapsulation, 234GTape, 357

Hharówka, 45, 69

definicja, 69obliczanie, 71ograniczenie, 71

hierarchia testów tradycyjnych, 193

IICS, Incident Command System, 175idempotencja, 316idempotentne eliminowanie niespójności, 97identyfikowanie

problematycznych zadań, 237źródeł problemów, 412źródła stresu, 412




496 Skorowidz

improwizacja, 394incydent, 177informacje

o anulowaniu, 275o limicie czasu, 274

infrastruktura dla oprogramowania, 40instalacja duża crona, 324integracja, 373integralność danych, 337

dostępność danych, 342dwadzieścia cztery rodzaje błędów, 346trudności z utrzymywaniem, 345wybór strategii, 339wymagania, 338zasady SRE, 363

interfejsy API, 117interpretacja statystyk, 64inżynier dyżurny, 140inżynieria, 29

koordynowania udostępniania, 368odwrotna, 393odwrotna usługi produkcyjnej, 394oprogramowania, 211

budowanie kultury, 224docieranie do celu, 225

udostępniania, 45, 105ciągłe budowanie i wdrażanie, 108hermetyczny proces budowania, 107model samoobsługowy, 106wymuszanie polityk i procedur, 107wysoka szybkość, 106zarządzanie konfiguracją, 111

inżynierowie SREangażowanie, 411branżowi weterani, 450dyżurni, 395dyżury, 389kolejność poznawania systemu, 390komunikacja, 420rozwój, 393shadowing dyżurnych, 399skład zespołu, 424techniki szkoleniowe, 388ukierunkowanie pracy, 392współpraca, 423współpraca z zespołami, 429zadania, 389

JJIT, Just-in-Time, 277JVM, Java Virtual Machine, 381

Kkolejki, 269kompetencja, 98komunikacja, 420konfiguracja

Borgmona, 135procesu udostępniania, 370

konsensus, 297w środowisku rozproszonym, 291

kontrola przepływu, 237wyników pomiarów, 67

konwergencja, 371kopie

pełne, 345przyrostowe, 345zapasowe, 341, 349, 352

kosztyobsługi zapytań, 245operacyjne, 444

kryzys wywołany testami, 164kształtowanie budżetu błędów, 55kulawe kaczki, 237kultura analizy

bez obwiniania, 30zdarzeń, 182, 454

Lliczba

replik, 305zapytań na sekundę, 251

lider, 320LIFO, last-in, first-out, 270limity

czasu, 274na klienta, 252

listakontrolna LCE, 479kontrolna udostępniania, 371zmian, 41

lokalizacja replik, 306




Skorowidz 497

Łłączenie żądań w porcje, 303

Mmaszyny RSM, 293metody

kolejkowania, 270przywracania, 349

miękkie usuwanie, 347minimalne interfejsy API, 117modelACID, 288

angażowania się zespołów, 434oparty na PGP, 436PGP, 434wczesnego zaangażowania, 440

budowanie i implementacja, 440etap projektowania, 440udostępnianie, 440

zaangażowania oparty na wspólnejodpowiedzialności, 445

modułowość, 117monitorowanie, 29, 31, 40, 119, 469

alarmy, 132białoskrzynkowe, 79czarnoskrzynkowe, 79, 134długoterminowe, 83podział systemu, 133problemów w okresowo uruchamianych

potokach, 330reguły, 83rozproszonych systemów, 312system Borgmon, 124systemów rozproszonych, 75szczegółowość pomiarów, 81wartości skrajne, 81wykorzystanie szeregów czasowych, 124złote sygnały, 79

motywowanie do zmian, 415MTBF, Mean Time Between Failure, 192, 205MTTF, Mean Time to Failure, 31MTTR, Mean Time to Repair, 31, 88, 192MTU, Maximum Transmission Unit, 234Multi-Paxos, 298MVC, Model-View-Controller, 332MVP, Minimum Viable Product, 221myślenie statystyczne i porównawcze, 393

Nnarzędzia pomiarowe, 125narzędzie Auxon, 217niebezpieczne oprogramowanie, 201niedostępność usługi, 267niekontrolowane usuwanie danych, 359nieliniowe skalowanie, 412niepowodzenia, 179nierównomierny podział pracy, 328niezarządzane incydenty, 173niezawodna obsługa

kolejek, 296komunikatów, 296

niezawodnemaszyny RSM, 293replikowane magazyny danych, 294udostępnianie, 377udostępnianie produktów, 367

niezawodność, 15, 102, 191, 316notatki ze spotkania produkcyjnego, 481

Oobciążenie, 230, 235, 308

operacyjne, 144wynikające z połączeń, 260

obliczanie harówki, 71obserwator, 321obsługa

blokad, 40błędów przeciążenia, 257przeciążenia, 251zapytań, 245żądań, 42

ochrona przed niebezpiecznym oprogramowaniem,201

odciążanie, 270odrzucanie ruchu, 284ogłaszanie incydentu, 177ograniczanie

harówki, 71liczby żądań, 253puli połączeń, 239zakłóceń, 409

okresowe szeregowanie prac, 315okresowo uruchamiany potok, 329określanie

nazw, 126wymagań, 454




498 Skorowidz

opóźnienie, 29, 98, 274dwumodalne, 276w sieci, 301

Outalator, 186agregowanie alarmów, 187tagi, 188widok incydentu, 187widok kolejek, 186

Ppamięć, 38, 266Paxos, 292

zastosowanie, 319planowane zmiany, 280planowanie

przepustowości, 29, 32, 121, 213, 374, 470na podstawie celów, 215

wprowadzania produktu, 376platformy flag funkcji, 378podejmowanie decyzji, 457podejście SRE, 29podzbiory, 239

deterministyczne, 242losowe, 240

podziałpracy, 328systemu monitorowania, 133

pomiarkontrolowanie wyników, 67określanie szczegółowości, 81ryzyka, 48

ponawianieprób, 271żądania, 257

poprzedniki celu, 216potoki

okresowo uruchamiane, 329przetwarzania danych, 327wieloetapowe, 328

powtarzalność, 87powtarzanie błędów, 170poziom

krytyczności, 255wykorzystania, 256

poziomy SLO, 59poznawanie usługi i kontekstu, 412prace inżynieryjne, 72

problem„pędzącego stada”, 330„rozszczepienia mózgu”, 290

problemy, 147, Patrz także rozwiązywanieproblemów

procesrozwiązywania problemów, 148rozwoju oprogramowania, 376udostępniania, 370zarządzania incydentami, 175

procesor, 265procesy certyfikacji, 453produkt, 122prognozowanie zapotrzebowania, 32progresywne wprowadzanie usług, 467protokół

SNMP, 126TFTP, 169

przechowywaniedanych, 126historii przestojów, 170stanu, 323

przeciążenie, 251, 257, 380, 470operacyjne, 144, 411serwera, 264, 268

przedstawianie kontekstu, 414przeglądy gotowości produkcyjnej, 436przełączanie awaryjne, 290przenośna przepustowość, 452przepływ komunikatów, 298przepustowość, 213, 470

obciążenia, 308przestoje, 185

usługi, 61przywracanie

danych, 356z systemu GTape, 357

publiczne nagradzanie ludzi, 183pusta pamięć podręczna, 276

QQoS, Quality of Service, 169QPS, queries per second, 43, 60, 264

RRapid, 109raporty, 189




Skorowidz 499

reagowanie w przypadku awarii, 29, 31, 120reguły, 129

równoważenia obciążenia, 244zgłaszania alarmów, 132

rejestrowanie wskaźników, 62rekurencyjny podział obowiązków, 175replikacja, 351

liczba, 305lokalizacja, 306

replikowane magazyny danych, 294restartowanie serwerów, 283retencja, 346rola inżynierów LCE, 369rozgałęzienia, 108rozkład obciążenia zadań, 236rozproszony przepływ danych i procesów, 336rozruch, 276rozwiązywanie problemów, 147, 169

awarie kaskadowe, 283badanie, 151diagnoza, 153dzienniki, 152ocena sytuacji, 150typowe pułapki, 149upraszczanie i przyspieszanie, 162ustalanie przyczyn symptomu, 154w praktyce, 150

rozwój produktów, 121równoważenie obciążenia, 308

reguły, 244system DNS, 230w centrum danych, 235wirtualne adresy IP, 232

RSM, Replicated State Machine, 293RTT, round-trip time, 230, 238ryzyko, 47

określanie tolerancji, 50, 53pomiar, 48zarządzanie, 47

Sserwery pośredniczące, 302shadowing dyżurnych, 399sieci, 39skalowanie, 87, 345

obciążenia roboczego, 300skład zespołu, 424SLA, service level agrement, 45, 61SLI, service level indicators, 59

SLO, service level objective, 45, 60, 67SLO usługi, 30SNMP, Simple Network Management Protocol, 126SOA, Service-Oriented Architecture, 100spotkanie produkcyjne, 420

notatki, 481sprawdzanie

reguł, 129stanu, 283

sprawność, 29, 33, 246sprzęt, 35

oprogramowanie, 37SRE, Site Reliability Engineering, 15stabilność systemu, 115stabilny lider, 303stan

incydentu, 473po awarii, 145przepływu, 405, 406

standaryzacja wskaźników, 64stopniowa degradacja, 270stos, 278studium przypadku

App Engine, 158Auxon, 213błędne algorytmy, 291niekontrolowane usuwanie danych, 359problem „rozszczepienia mózgu”, 290przełączanie awaryjne, 290przeniesienie DFP do F1, 430przywracanie z systemu GTape, 357Viceroy, 425

sygnały poziomu wykorzystania, 256symulacje, 453system

Borgmon, 124DNS, 230Escalator, 185GTape, 357Rapid, 109Workflow, 332

systemyoprogramowania, 40

elastyczność, 115stabilność, 115

przywracania danych, 343rozproszone, 75tworzenia kopii zapasowych, 343zarządzania klastrami, 101




500 Skorowidz

sytuacje kryzysowespowodowane procesem, 167spowodowane zmianami, 165

szereg czasowy, 123, 126szkolenia, 453szybkie

udostępnianie produktu, 46wprowadzanie zmian, 30

Śśledzenie

przestojów, 185analizy danych, 188Escalator, 185Outalator, 186

stanu prac crona, 319średni czas

do wystąpienia awarii, 31między awariami, 192naprawy, 31, 192

środowiskobudowania, 198produkcyjne, 35

próbkowanie, 208zarządzanie konfiguracją, 204

programistyczne, 41rozproszone, 287

cron, 315konsensus, 289, 291, 305monitorowanie systemów uzgadniania

konsensusu, 312obsługa kolejek i komunikatów, 296okresowe szeregowanie prac, 315okresowo uruchamiany potok, 329usługi koordynacji i blokowania, 294wrażanie systemu, 305wybór lidera, 294wydajność uzgadniania konsensusu, 297, 301

testowania, 198

Ttabela dostępności, 465tagi, 188techniki

skutecznej pracy, 424szkoleniowe, 388

terminy zakończenia testów, 204

test produkcyjny usługi DNS, 96testowanie

gotowości, 451klientów, 282niekrytycznych zadań zaplecza, 282niezawodności, 191odporności na katastrofy, 451pod kątem awarii kaskadowych, 280skalowalnych narzędzi, 200systemu, 193zarządzania katastrofami, 202

testy, 108, 121dymne, 194integracyjne, 193, 207jednostkowe, 193kanarkowe, 196konfiguracji, 195obciążeniowe, 196, 380proaktywne, 170produkcyjne, 194regresyjne, 194sprawności, 194statystyczne, 203w dużej skali, 199w środowisku produkcyjnym, 96

TFTP, Trivial File Transfer Protocol, 169tolerancja ryzyka, 53

dla usługi, 50tryb

awaryjny, 284operacyjny, 412

twierdzenie CAP, 288tworzenie

dokumentacji, 398listy kontrolnej udostępniania, 373pakietów, 109podzbiorów, 239środowiska testowania, 198

Uudostępnianie, 105

działania klientów, 375konfigurowanie procesu, 370lista kontrolna, 371, 373nowości, 372procesy i automatyzacja, 375produktów w dużej skali, 367prostych zmian, 118




Skorowidz 501

rodzaje błędów, 374techniki, 377zależności zewnętrzne, 376

uniwersalne wsparcie, 445uporządkowanie danych, 43upraszczanie, 371uruchamianie klastrów, 95, 100usługa

Bigtable, 84Shakespeare, 42, 285

usługibudżet błędów, 30, 54cele, 60dla konsumentów, 50docelowy poziom dostępności, 50, 53globalny planowany przestój, 61infrastrukturalne, 53kandydujące do wczesnego zaangażowania, 439koordynacji i blokowania, 294koszty, 51, 53kształtowanie budżetu błędów, 55obliczanie ryzyka, 48obsługi blokad, 40poziom SLO, 56produkcyjne

dobre praktyki, 467rodzaje awarii, 53rodzaje niepowodzeń, 51tolerancja ryzyka, 50, 53umowy, 61wskaźniki, 59, 62wyznaczone oczekiwania, 67zmiany w rozwoju, 441

ustalanie przyczyn symptomu, 154utrata danych, 343utrzymywanie integralności danych, 345uzgadnianie konsensusu, 297

VViceroy, 425VIP, virtuae IP address, 232

Wwartość automatyzacji, 87wątki, 266wczesne

wykrywanie, 353zaangażowanie, 439

wdrażanie, 110rozproszonego systemu, 305

wektory, 127wirtualne adresy IP, 232wnioski, 447Workflow, 332

etapy wykonywania, 334gwarancje poprawności, 334

wprowadzanie zmian, 279wskaźnik

MTTR, 192poziomu usługi, 59

wskaźniki, 62agregowanie pomiarów, 63rejestrowanie, 62standaryzacja, 64

wspomaganie inżynierii oprogramowania, 223wybór

celów, 66lidera, 294podzbioru, 239

wyczerpanie zasobów, 265wydajność, 29, 33, 302

uzgadniania konsensusu, 301wykrywanie niespójności, 96wymagania w chmurze, 341wyniki negatywne eksperymentu, 156wzorce architektury systemu, 292wzorzec projektowy

model – widok – kontroler, 332obciążenie w kształcie pasków, 331okresowo uruchamiany potok danych, 328potok danych, 327

wzrost organiczny, 280

Zzaangażowanie zespołów, 433zakłócenia, 403zależności między zasobami, 267zamknięcie procesu, 279zapewnianie

ciągłości biznesowej, 335zasobów, 33

zapobieganie przeciążeniu serwerów, 268zapytania na sekundę, 43zarządzanie, 385

incydentami, 173anatomia niezarządzanego incydentu, 174aspekty procesu, 175




502 Skorowidz

zarządzaniecentrum dowodzenia, 176dokumentacja, 176incydenty niezarządzane, 173ogłaszanie, 177przekazanie zadania, 176rekurencyjny podział obowiązków, 175

katastrofami, 202kolejkami, 269konfiguracją, 111

środowiska produkcyjnego, 204krytycznym stanem, 287maszynami, 37niezawodnością usługi, 57obciążeniem operacyjnym, 404ryzykiem, 47usługami, 25, 26zakłóceniami, 404zmianą, 29, 32

zarządzany incydent, 176zasady, 45

zastosowanieautomatyzacji, 90Paxosa, 319

zbieranie eksportowanych danych, 126zespół

eksploatacji, 25rozwoju produktu, 25LCE, 381

lista kontrolna, 382problemy, 383

SRE, 419, 433, 463, 471zadania, 29

zgłoszenie problemu, 150, 408zmiany w rozwoju usług, 441zreplikowany dziennik, 306zwiększanie ilości zasobów, 283

Żżądania na sekundę, 264




http://program-partnerski.helion.pl

Tytuł oryginału: Site Reliability Engineering: How Google ...

Documents

Transcript of Tytuł oryginału: Site Reliability Engineering: How Google ...