Gorące partycje w Azure Blob Storage: wykrywanie, monitorowanie i łagodzenie skutków

Azure Blob Storage dystrybuuje dane na partycje, aby zapewnić skalowalną wydajność. Gdy ruch koncentruje się na jednej partycji, może ona stać się wąskim gardłem — stan ten jest określany jako gorąca partycja. Ten artykuł wyjaśnia, czym są gorące partycje, jak je rozpoznawać na podstawie metryk Azure Monitor i dzienników zasobów oraz jakie kroki możesz podjąć, aby równomierniej rozłożyć obciążenie i zmniejszyć błędy ograniczania zasobów.

Zrozum partycje gorące

Azure Blob Storage automatycznie rozdziela dane między partycjonami, aby skalować wydajność i przepustowość. Gdy pojedyncza partycja otrzymuje znacznie więcej ruchu niż pozostałe, staje się gorącą partycją. Gorąca partycja występuje, gdy duża liczba żądań odczytu, zapisu lub aktualizacji trafia do tej samej partycji, co ogranicza zdolność usługi do efektywnego równoważenia obciążenia. W rezultacie żądania doświadczają zwiększonego opóźnienia, ograniczania i błędów limitu czasu, dopóki obciążenie nie zostanie redystrybuowane lub wzór dostępu nie zostanie zoptymalizowany. Schematy partycjonowania lub nazewnictwa, które koncentrują ruch na niewielkim podzbiorze danych zamiast rozpraszać żądania na wiele partycji, często powodują gorące partycje.

Objawy i wpływ gorących przegrod

Gdy partycja pamięci masowej staje się gorąca, nie jest już w stanie przetwarzać żądań tak efektywnie. W miarę jak partycja zbliża się do limitów skalowalności, Azure Storage zaczyna ograniczać żądania, aby chronić usługę i utrzymać niezawodność dla innych obciążeń. Aplikacje klienckie doświadczają zwiększonych opóźnień, zmniejszonej przepustowości oraz awarii żądań przejściowych.

Do typowych objawów aktywnej partycji należą:

  • Odpowiedzi HTTP 503 (Server Busy) wskazujące, że partycja tymczasowo nie jest w stanie obsłużyć kolejnych żądań.
  • Odpowiedzi HTTP 500 (Operation Timeout) występujące, gdy realizacja żądań trwa zbyt długo, ponieważ partycja jest silnie obciążona.
  • Zwiększone opóźnienia żądań, nawet w przypadku żądań, które ostatecznie kończą się powodzeniem.
  • Automatyczne ponawianie prób przez klientów, co może dodatkowo zwiększyć ruch i przedłużyć problemy z wydajnością, jeśli wielu klientów ponawia próby jednocześnie.
  • Zmniejszona przepustowość, gdzie aplikacja przetwarza mniej operacji na sekundę niż oczekiwano, mimo wystarczającej ogólnej pojemności konta pamięci.

Gorące partycje często powstają w wyniku wzorców dostępu koncentrujących ruch na jednej partycji. Typowe przykłady obejmują sekwencyjne nazwy obiektów blob, obciążenia obejmujące wyłącznie dopisywanie oraz schematy kluczy partycjonowania, które kierują nieproporcjonalnie duży ruch do jednej partycji. Gdy obciążenie nie jest równomiernie rozłożone, dotknięta partycja osiąga swoje limity przed resztą konta pamięci, tworząc wąskie gardło wpływające na wydajność aplikacji.

W wielu zastosowaniach pierwszym sygnałem gorącej partycji jest połączenie rosnącego opóźnienia, rosnącej częstotliwości powtórek oraz rosnącej liczby błędów 503 lub 500 w okresach dużego zapotrzebowania.

Wykrywaj błędy throttlingu za pomocą metryk i logów zasobów Azure Monitor

Azure Storage ogranicza żądania, gdy dane obciążenie przekracza cele skalowalności konta lub partycji pamięci. Zwykle można zaobserwować ograniczanie przepustowości w postaci odpowiedzi HTTP 503 (Serwer zajęty) lub 500 (Przekroczono limit czasu operacji). Biblioteki klienta usługi Azure Storage często automatycznie ponawiają żądania objęte ograniczaniem przepustowości, dlatego monitorowanie jest niezbędne, aby wykryć takie ograniczanie, zanim zacznie ono znacząco wpływać na wydajność aplikacji.

Użyj metryk Azure Monitor do identyfikacji błędów throttlingu

Aby wykryć ograniczanie przepustowości, przeanalizuj metryki Azure Monitor dla konta magazynu. Metryka Transactions , w połączeniu z wymiarem ResponseType , zapewnia wgląd w wyniki żądań pamięci masowej i pomaga zidentyfikować awarie związane z throttlingiem.

Metryki do identyfikacji throttlingu

Poniższe metryki Azure Monitor są przydatne przy badaniu throttlingu:

Metric Purpose
Transakcje Mierzy liczbę żądań przetwarzanych przez usługę przechowywania danych. Użyj wymiaru ResponseType do identyfikowania żądań objętych ograniczaniem przepustowości.
Dostępność Pokazuje procent udanych wniosków. Spadek dostępności może wskazywać na ograniczanie lub inne niepowodzenia żądań.
Opóźnienie E2E w przypadku pomyślnego wykonania Mierzy opóźnienie żądania na całej ścieżce, w tym przetwarzanie w sieci i po stronie klienta. Wzrosty mogą wskazywać na ponowne próby spowodowane ograniczaniem przepustowości.
Opóźnienie serwera przy udanych operacjach Mierzy czas potrzebny na przetwarzanie żądań przez usługę magazynową. Porównanie tej metryki z opóźnieniem end-to-end (E2E) może pomóc odróżnić opóźnienia po stronie usługi od ponowień żądań po stronie klienta.

Typowym przejawem ograniczania jest wzrost opóźnień, któremu towarzyszy zwiększenie liczby odpowiedzi związanych z ograniczaniem oraz spadek dostępności.

Użyj wymiaru ResponseType do identyfikowania ograniczania przepustowości

Wymiar ResponseType jest głównym narzędziem do identyfikacji warunków ograniczania w metrykach Azure Monitor. Istotne wartości obejmują:

Wartość typu odpowiedzi Description
ServerBusyError Usługa przechowywania danych zwracała HTTP 503, ponieważ przekroczono cel skalowalności.
ClientThrottlingError Żądanie zostało ograniczone z powodu limitu przepustowości, zanim dotarło do usługi magazynu.
ClientAccountRequestThrottlingError Przekroczono limity liczby żądań na poziomie konta.
Błąd ograniczania przepustowości konta klienta Przekroczono limity przepustowości konta.
Sukces z ograniczaniem przepustowości Początkowo żądanie podlegało ograniczeniu, ale ostatecznie powiodło się po ponowieniach.

Śledzenie tych wartości na przestrzeni czasu może pomóc w identyfikacji przejściowych skoków dławienia, a także utrzymujących się problemów ze skalowalnością.

Użyj wymiarów, aby precyzyjnie określić źródło przepustnienia

Wymiary metryk w usłudze Azure Monitor mogą pomóc zidentyfikować obciążenie odpowiedzialne za ograniczanie przepustowości:

Wymiar Purpose
Typ odpowiedzi Określa konkretny stan ograniczenia przepustowości lub błąd.
ApiName Identyfikuje operację objętą ograniczaniem przepustowości, taką jak PutBlob, GetBlob lub ListBlobs.
Typ geograficzny Rozróżnia ruch do punktów końcowych pierwotnych i wtórnych w georedundantnych kontach pamięci masowej.
Authentication Pomaga określić, czy throttling jest powiązany z konkretną metodą uwierzytelniania.

Na przykład, jeśli throttling występuje głównie podczas PutBlob operacji, obciążenie może być intensywne pod względem zapisu. Jeśli konkretna operacja API wykazuje podwyższone tempo ograniczania wydajności, wysiłki optymalizacyjne mogą skupić się na tej operacji, a nie na całej aplikacji.

Analizowanie dzienników zasobów usługi Azure Monitor

Podczas gdy metryki wskazują obecność throttlingu, logi zasobów Azure Monitor dostarczają szczegółów na poziomie żądań, które pomagają zdiagnozować przyczynę źródłową. Dzienniki zasobów rejestrują zarówno udane, jak i nieudane żądania, w tym throttling, timeout, autoryzację oraz błędy związane z siecią.

W przypadku Azure Blob Storage rekordy są dostępne w tabeli StorageBlobLogs po wysłaniu dzienników zasobów do przestrzeni roboczej Log Analytics.

Przeszukuj dzienniki zasobów pod kątem zdarzeń ograniczania przepustowości

Przed uruchomieniem tych zapytań upewnij się, że dzienniki zasobów są przesyłane do przestrzeni roboczej Log Analytics.

Użyj języka zapytań Kusto (KQL), aby zidentyfikować żądania zwracające typowe kody statusu związane z ograniczaniem limitu:

StorageBlobLogs
| where StatusCode in (500, 503)
| summarize RequestCount = count() by OperationName, StatusCode, bin(TimeGenerated, 15m)
| order by TimeGenerated desc

Rozszerzyć to zapytanie, grupując wyniki według operacji, typu uwierzytelnienia, adresu IP dzwoniącego lub tożsamości aplikacji, aby zidentyfikować obciążenie generujące ograniczone żądania. Dzienniki zasobów są szczególnie przydatne do określenia, czy dławienie występuje głównie w obrębie konkretnej aplikacji, operacji lub przedziału czasowego.

Warunki alarmowe dla ograniczania

Utwórz alerty usługi Azure Monitor dla:

  • Powtarzające się wystąpienia błędu ServerBusyError w transakcjach.
  • Wzrost wartości typu odpowiedzi związanych z ograniczaniem ograniczeń.
  • Spadki w metryce dostępności poniżej akceptowalnego progu.
  • Zwiększenia opóźnień korelujące ze zdarzeniami dławienia.
  • Nagłe wzrosty liczby żądań zbliżające się do limitów skalowalności pamięci masowej.
  1. Monitoruj metrykę Transakcji i podziel wyniki według Typu odpowiedzi.
  2. Zwracaj uwagę na wzrost liczby typów odpowiedzi związanych z throttlingiem, takich jak ServerBusyError i ClientThrottlingError.
  3. Użyj wymiaru ApiName do identyfikacji dotkniętych operacji.
  4. Skoreluj zdarzenia ograniczania przepustowości ze zmianami Dostępności, opóźnienia E2E dla operacji zakończonych powodzeniem oraz opóźnienia serwera dla operacji zakończonych powodzeniem.
  5. Użyj logów zasobów Azure Monitor, aby określić, które żądania, operacje lub aplikacje generują ograniczony ruch.
  6. Skonfiguruj alerty tak, aby wykrywać problemy z dławieniem, zanim wpłyną one na użytkowników.

Łącząc metryki, wymiary i logi zasobów Azure Monitor, możesz szybko wykryć warunki ograniczania obciążenia, zidentyfikować źródło nadmiernego zapotrzebowania i podjąć działania naprawcze, zanim wydajność aplikacji spadnie.

Ogranicz gorące partycje

Aby zapobiec gorącym partycjom, rozmieszczaj żądania równomiernie między partycjami i zapewnij, że aplikacje odpowiednio reagują podczas throttlingu.

Stosuj efektywne schematy podziału i nazewnictwa

Zaprojektuj klucze partycji, nazwy obiektów blob i inne identyfikatory tak, aby żądania były rozkładane na wiele partycji. Unikaj sekwencyjnych lub tylko dodawanych wzorców nazewnictwa, które kierują większość żądań do tej samej partycji. Zobacz Optymalizacja partycji blobów i schematów nazewnictwa.

Użyj strategii wykładniczego wydłużania odstępów między ponowieniami

Jeśli żądania są ograniczane i zwracają błędy 503 (Server Busy) lub 500 (Operation Timeout), ponów żądania, stosując strategię wykładniczego wydłużania odstępów między ponownymi próbami. Takie podejście zmniejsza presję na dotkniętą partycję i daje Azure Storage czas na zrównoważenie obciążenia lub regenerację po tymczasowych skokach zapotrzebowania.

Mechanizm ponawiania prób z wykładniczo rosnącym opóźnieniem jest najbardziej istotny w przypadku aplikacji niestandardowych, które uzyskują dostęp do usługi Azure Storage przy użyciu bibliotek klienckich usługi Azure Storage, zestawów SDK lub interfejsów API REST. Wiele usług usługi firmy Microsoft, aplikacji zarządzanych i klientów zewnętrznych już implementuje odpowiednią logikę powtórek, więc możesz nie potrzebować niczego dodatkowego. Jeśli tworzysz aplikację niestandardową, upewnij się, że polityki powtórek są włączone i skonfigurowane zgodnie z najlepszymi praktykami Azure Storage. Zobacz dowolny z następujących artykułów:

Unikaj nagłych wzrostów liczby żądań

Wprowadzając nowe obciążenie, uruchamiając testy wydajności lub przetwarzając duże ilości danych, stopniowo zwiększ liczbę żądań, zamiast od razu generować szczytowy ruch. Azure Storage automatycznie równoważy obciążenie między partycjami w miarę zmian zapotrzebowania, ale nagłe skoki ruchu mogą tymczasowo przeciążyć partycję i spowodować ograniczanie przepustowości, dopóki usługa nie zdąży się dostosować.

Następne kroki

Szczegółowe wskazówki dotyczące implementacji można znaleźć w następstwie:

  • Last updated on