Edytuj

Hałaśliwy antywzorzec sąsiada

Azure

Systemy wielodostępne współdzielą zasoby między dzierżawami. Ponieważ dzierżawy korzystają z tych samych zasobów udostępnionych, aktywność jednej dzierżawy może mieć negatywny wpływ na użycie systemu przez inną dzierżawę.

Opis problemu

Podczas tworzenia usługi, która ma być współużytkowana przez wielu klientów lub dzierżawców, można ją skompilować tak, aby była wielodostępna. Zaletą systemów wielodostępnych jest to, że zasoby można pulować i udostępniać między dzierżawami. Często skutkuje to niższymi kosztami i lepszą wydajnością. Jeśli jednak jedna dzierżawa korzysta z nieproporcjonalnej ilości zasobów dostępnych w systemie, ogólna wydajność systemu może ulec spadkowi. Problem z hałaśliwym sąsiadem występuje, gdy wydajność jednej dzierżawy jest obniżona z powodu działań innej dzierżawy.

Rozważmy przykładowy system wielodostępny z dwoma dzierżawami. Wzorce użycia dzierżawy A i wzorce użycia dzierżawy B pokrywają się, co oznacza, że w godzinach szczytu łączne użycie zasobów jest wyższe niż pojemność systemu:

Rysunek przedstawiający użycie zasobów dwóch dzierżaw. Dzierżawa A korzysta z pełnego zestawu zasobów systemowych, co oznacza, że dzierżawa B napotyka błędy.

Prawdopodobnie pierwszeństwo będzie pierwszeństwo niezależnie od tego, które żądanie dzierżawy dotarło jako pierwsze. Następnie druga dzierżawa będzie doświadczać głośnego problemu sąsiada. Alternatywnie, obie dzierżawy mogą znaleźć ich wydajność cierpi.

Problem z hałaśliwym sąsiadem występuje również nawet wtedy, gdy każda dzierżawa zużywa stosunkowo małe ilości pojemności systemu, ale zbiorcze użycie zasobów wielu dzierżaw powoduje wzrost ogólnego użycia:

Rysunek z 3 dzierżawami, z których każda zużywa mniej maksymalnej przepływności rozwiązania. W sumie trzy dzierżawy zużywają kompletne zasoby systemowe.

Może się tak zdarzyć, gdy masz wiele dzierżaw, które mają podobne wzorce użycia lub nie aprowizowaliśmy wystarczającej pojemności dla zbiorczego obciążenia systemu.

Jak rozwiązać ten problem

Głośne problemy sąsiadów są nieodłącznym zagrożeniem w systemach wielodostępnych i nie można całkowicie wyeliminować możliwości wpływu na hałaśliwy sąsiad. Istnieją jednak pewne kroki, które mogą podjąć zarówno klienci, jak i dostawcy usług, aby zmniejszyć prawdopodobieństwo hałaśliwych problemów z sąsiadami lub ograniczyć ich skutki, gdy są obserwowane.

Akcje, które mogą wykonywać klienci

Akcje, które mogą podjąć dostawcy usług

  • Monitoruj użycie zasobów dla systemu. Monitoruj zarówno ogólne użycie zasobów, jak i zasoby używane przez każdą dzierżawę. Skonfiguruj alerty w celu wykrywania skoków użycia zasobów, a jeśli to możliwe, skonfiguruj automatyzację w celu automatycznego rozwiązywania znanych problemów przez skalowanie w górę lub w poziomie.
  • Zastosuj nadzór nad zasobami. Rozważ zastosowanie zasad, które pozwalają uniknąć przeciążenia systemu przez jedną dzierżawę i zmniejszenia pojemności dostępnej dla innych osób. Ten krok może mieć formę wymuszania limitu przydziału za pomocą wzorca ograniczania przepustowości lub wzorca ograniczania szybkości.
  • Aprowizuj więcej infrastruktury. Ten proces może obejmować skalowanie w górę przez uaktualnienie niektórych składników rozwiązania lub może obejmować skalowanie w górę przez aprowizowanie dodatkowych fragmentów, jeśli postępujesz zgodnie ze wzorcem fragmentowania lub sygnaturami, jeśli postępujesz zgodnie ze wzorcem sygnatur wdrażania.
  • Umożliwia dzierżawcom zakup wstępnie aprowizowanej lub zarezerwowanej pojemności. Ta pojemność zapewnia dzierżawcom większą pewność, że rozwiązanie odpowiednio obsługuje ich obciążenie.
  • Wygładzanie użycia zasobów dzierżawców. Na przykład możesz wypróbować jedną z następujących metod:
    • Jeśli hostujesz wiele wystąpień rozwiązania, rozważ ponowne równoważenie dzierżaw między wystąpieniami lub sygnaturami. Rozważ na przykład umieszczenie dzierżaw z przewidywalnymi i podobnymi wzorcami użycia w wielu sygnaturach, aby spłaścić szczyty ich użycia.
    • Zastanów się, czy masz procesy w tle, czy obciążenia intensywnie korzystające z zasobów, które nie są wrażliwe na czas. Uruchamiaj te obciążenia asynchronicznie poza godzinami szczytu, aby zachować maksymalną pojemność zasobów dla obciążeń wrażliwych na czas.
  • Sprawdź, czy usługi podrzędne zapewniają mechanizmy kontroli w celu wyeliminowania problemów z hałaśliwymi sąsiadami. Na przykład w przypadku korzystania z platformy Kubernetes rozważ użycie limitów zasobników, a w przypadku korzystania z usługi Service Fabric rozważ użycie wbudowanych funkcji zapewniania ładu.
  • Ogranicz operacje, które mogą wykonywać dzierżawcy. Można na przykład uniemożliwić dzierżawcom wykonywanie operacji, które będą uruchamiać bardzo duże zapytania bazy danych, takie jak określenie maksymalnej liczby zwracanych rekordów lub limitu czasu zapytań. Ta akcja ogranicza ryzyko podejmowania działań przez dzierżawców, które mogą negatywnie wpłynąć na inne dzierżawy.
  • Zapewnienie systemu jakości usług (QoS). W przypadku stosowania QoS priorytet niektórych procesów lub obciążeń należy określić przed innymi. Dzięki uwzględnieniu funkcji QoS w projekcie i architekturze możesz mieć pewność, że operacje o wysokim priorytcie mają pierwszeństwo, gdy występuje presja na zasoby.

Zagadnienia do rozważenia

W większości przypadków poszczególne dzierżawy nie zamierzają powodować problemów z hałaśliwym sąsiadem. Pojedyncze dzierżawy mogą nawet nie mieć świadomości, że ich obciążenia powodują problemy z hałaśliwymi sąsiadami dla innych. Jednak istnieje również możliwość, że niektórzy dzierżawcy mogą wykorzystać luki w zabezpieczeniach składników udostępnionych w celu ataku na usługę pojedynczo lub przez przeprowadzenie ataku typu "rozproszona odmowa usługi" (DDoS).

Niezależnie od przyczyny ważne jest, aby traktować te problemy jako problemy z zarządzaniem zasobami oraz stosować limity przydziałów użycia, ograniczanie przepustowości i mechanizmy kontroli nadzoru, aby wyeliminować problem.

Uwaga

Upewnij się, że informujesz klientów o wszelkich ograniczeniach, które są stosowane, lub o wszelkich limitach przydziału użycia w usłudze. Ważne jest, aby niezawodnie obsługiwały żądania, które zakończyły się niepowodzeniem, i że nie są zaskoczeni żadnymi ograniczeniami ani limitami przydziału.

Jak wykryć problem

Z perspektywy klienta problem z hałaśliwym sąsiadem zwykle manifestuje się jako nieudane żądania serwera lub żądania, które wymagają długiego czasu. W szczególności, jeśli to samo żądanie powiedzie się w innym czasie i wydaje się kończyć się losowym niepowodzeniem, może wystąpić problem z hałaśliwym sąsiadem. Aplikacje klienckie powinny rejestrować dane telemetryczne w celu śledzenia współczynnika powodzenia i wydajności żądań do usług, a aplikacje powinny również rejestrować podstawowe metryki wydajności na potrzeby porównania.

Z perspektywy usługi problem z hałaśliwym sąsiadem może pojawić się na kilka sposobów:

  • Skoki użycia zasobów. Ważne jest, aby jasno zrozumieć normalne użycie zasobów punktu odniesienia oraz skonfigurować monitorowanie i alerty w celu wykrywania skoków użycia zasobów. Upewnij się, że uwzględnisz wszystkie zasoby, które mogą mieć wpływ na wydajność lub dostępność usługi. Te zasoby obejmują metryki, takie jak użycie procesora CPU serwera i pamięci, we/wy dysku, użycie bazy danych, ruch sieciowy i metryki, które są udostępniane przez usługi zarządzane, takie jak liczba żądań oraz syntetyczne i abstrakcyjne metryki wydajności, takie jak jednostki żądań usługi Azure Cosmos DB.
  • Błędy podczas wykonywania operacji dla dzierżawy. W szczególności poszukaj awarii, które występują, gdy dzierżawa nie korzysta z dużej części zasobów systemu. Taki wzorzec może wskazywać, że dzierżawa jest ofiarą głośnego problemu sąsiada. Rozważ śledzenie zużycia zasobów według dzierżawy. Na przykład w przypadku korzystania z usługi Azure Cosmos DB rozważ rejestrowanie jednostek żądań używanych dla każdego żądania i dodanie identyfikatora dzierżawy jako wymiaru do telemetrii, aby można było agregować użycie jednostek żądania dla każdej dzierżawy.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Został pierwotnie napisany przez następujących współautorów.

Główny autor:

  • John Downs | Główny inżynier klienta, fasttrack dla platformy Azure

Inni współautorzy:

Aby wyświetlić niepublice profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.