Zagadnienia dotyczące planowania pojemności

Podstawowe planowanie pojemności rozpoczyna się od pewnych prostych obliczeń, ale istnieją czynniki, które mogą komplikować proces. Oprócz prostych bieżących i przewidywanych liczb użycia należy również uwzględnić następujące kwestie:

• Limity i kwoty usługi
• Ograniczenia kosztów
• Nieefektywność kodu i konfiguracji
• Zależności

W tej lekcji dowiesz się, jak te zagadnienia mogą mieć wpływ na planowanie pojemności i jak rozwiązać każdy z nich.

Limity i kwoty usługi

Istnieje tendencja do postrzegania przetwarzania w chmurze jako nieograniczonego zasobu. W porównaniu z tradycyjnymi modelami serwerów/centrów danych pojemność chmury wydaje się być nieskończona. Chmura oferuje zupełnie nowy poziom skali. Jednak podobnie jak wszystko inne, ma pewne ograniczenia. Planowanie pojemności obejmuje zrozumienie, kiedy osiągniesz te limity usług.

Podczas przeglądania systemu i jego architektury należy zrozumieć limity używanych usług w chmurze. Na przykład domyślnie w Azure można mieć maksymalnie 1000 maszyn wirtualnych na zestaw dostępności maszyn wirtualnych. Ten limit maszyn wirtualnych może wydawać się być większy niż wystarczający, jeśli dopiero zaczynasz pracę. Jednak po osiągnięciu tego limitu nie można aprowizować więcej maszyn wirtualnych, co może spowodować awarię.

Podobnie domyślnie możesz mieć 250 kont magazynu na subskrypcję na region (ten limit można zwiększyć za pośrednictwem żądania pomocy technicznej). Te limity są przykładami limitów miękkich, które można zwiększyć. Jednak niektóre usługi mają maksymalne limity, które można znaleźć pod poniższym linkiem.

Limity subskrypcji Azure, limity usług, przydziały i ograniczenia

Te limity i limity przydziału są czymś, co należy znać i monitorować. Przyjrzyjmy się sposobom, aby to zrobić.

Portal Azure

Możesz zobaczyć przydziały usług i swoją pozycję względem tych limitów w sekcji Zużycie + kwoty pod Subskrypcje —> Ustawienia w okienku nawigacji. Możesz filtrować według kategorii usług, takiej jak sieć/środowisko obliczeniowe i region Azure. Pokazuje, gdzie znajdujesz się w odniesieniu do limitów.

Za pośrednictwem kodu

Możesz użyć punktu końcowego Usage - List dla dowolnej usługi Azure, aby uzyskać informacje o bieżącym użyciu zasobów oraz limity zasobów obliczeniowych w ramach subskrypcji, jak pokazano w tym obciętym przykładzie. Sprawdź dokumentację interfejsu API REST Azure aby uzyskać najnowszą stabilną wersję interfejsu API.

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2024-07-01
{ 
    "currentValue": 12,
    "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/westeurope/usages/virtualMachines",
    "limit": 25000, 
    "name": { 
        "localizedValue": "Virtual Machines",
        "value": "virtualMachines" 
    }, 
    "unit": "Count" 
}

Widać, że bieżąca liczba używanych maszyn wirtualnych wynosi 12 względem limitu 25 000. Niektóre limity można zwiększyć za pośrednictwem żądania pomocy technicznej, dlatego upewnij się, że wiesz wcześniej, kiedy zbliżasz się do progu.

Ograniczenia kosztów

Skalowanie nie polega tylko na rzucaniu większej ilości zasobów na problem. Ważne jest, aby organizacja zrozumiała koszt środowiska chmury i że dodanie większej liczby zasobów zwykle równa się większemu kosztowi. Pamiętaj o tym koszcie i współpracuj z zespołami finansowymi, aby upewnić się, że masz umowę na temat bieżących i przewidywanych wydatków na chmurę.

Należy prognozować koszty zarówno podczas początkowego projektowania systemów, jak i podczas regularnego przeprowadzania przeglądów już uruchomionych systemów. Azure oferuje narzędzia, które mogą ci pomóc:

• Zaplanuj koszt środowiska przy użyciu kalkulatora Azure.
• Przejrzyj bieżące i przewidywane miesięczne wydatki w portalu Azure.
• Konfigurowanie budżetów w Microsoft Cost Management. To narzędzie umożliwia sprawdzenie kosztów w różnych zakresach, w tym grupy zarządzania, grupy zasobów i subskrypcji.

Nieefektywność kodu i konfiguracji

Czasami kierowanie większej ilości zasobów może rozwiązać problem, ale kosztuje to pieniądze. Czasami skalowanie nie jest rozwiązaniem lub nie jest kompletnym rozwiązaniem. W niektórych przypadkach może się okazać, że konieczność skalowania jest w rzeczywistości problemem spowodowanym nieprawidłowym kodowaniem lub konfiguracją.

Możesz potencjalnie zaoszczędzić pieniądze i czas, wyszukując najpierw usterki przed skalowaniem zasobów. Oto kilka przykładów tego podejścia:

• Jeśli masz źle zaprojektowaną bazę danych z gorącymi partycjami, takimi jak używanie tylko jednej partycji w ogromnej bazie danych NoSQL, jest wolna niezależnie od tego, jak bardzo ją skalujesz.
• Jeśli masz nieefektywne zapytania do bazy danych, popraw ich wydajność, zanim dodasz więcej zasobów do bazy danych. Czasami dodanie odpowiedniego indeksu do bazy danych na podstawie typowych zapytań może obniżyć koszty 100x.
• Jeśli limity czasu są niepoprawnie ustawione, połączenia z bazą danych mogą być przeciążone z powodu ponownych prób wynikających z niespójnych limitów czasu między serwerem a bazą danych. W takim przypadku należy naprawić ustawienia przed skalowaniem bazy danych.
• Jeśli kod dewelopera jest nieefektywny, czy możesz napisać bardziej wydajny kod, aby rozwiązać ten problem? Być może kod nie zwalnia pamięci, kiedy to możliwe, więc używasz większych maszyn wirtualnych pamięci, gdy nie jest to konieczne. Takie poprawki mogą zapewnić znaczne oszczędności kosztów.

Zależności

Zmiany, które są potrzebne do rozwiązania niektórych problemów opisanych w tym module, często mają zależności od deweloperów aplikacji. Niektóre rozwiązania i najlepsze rozwiązania zalecane tutaj wymagają współpracy między Tobą i tymi deweloperami, aby się to stało.

Możesz nie być w stanie zaimplementować wszystkich tych zaleceń całkowicie samodzielnie. Jeśli jednak rozumiesz system w chmurze i jego możliwości i cechy, możesz stać się czynnikiem umożliwiającym zmianę w ulepszaniu systemów oraz ich skalowalności i niezawodności.