Optymalizacja obciążeń EC2 za pomocą Amazon CloudWatch

W grudniu 2020 AWS zapowiedziało dostępność gp3, wolumenów SSD Ogólnego Przeznaczenia dla Amazon Elastic Block Store (Amazon EBS), które umożliwiają klientom zapewnienie wydajności niezależnie od pojemności pamięci masowej i zapewniają do 20% niższą cenę za GB niż istniejące wolumeny.

Nowa wersja stanowi doskonałą okazję do posiadania odpowiedniego rozmiaru Twojej pamięci masowej dzięki wykorzystaniu wbudowanych możliwości monitorowania AWS. Jest to szczególnie istotne w przypadku obciążeń SQL, ponieważ istnieje wiele typów instancji i konfiguracji magazynu, które można wybrać dla SQL Server w AWS.

Wielu klientów pyta twórców o porady w przypadku wyboru „najlepszej” lub „odpowiedniej” konfiguracji pamięci masowej i instancji, nie istnieje jednak jedno rozwiązanie, które pasowałoby do wszystkich prawdopodobnych okoliczności. W tym artykule zostały omówione kluczowe techniki, które pozwalają na odpowiedni rozmiar obciążeń. Autorzy skupią się na odpowiednim rozmiarze SQL Server jako przykładowego obciążenia, ale techniki, które zademonstrują, mają zastosowanie w równym stopniu do każdej instancji Amazon EC2 z dowolnym systemem operacyjnym lub obciążeniem.

Pulpit nawigacyjny Amazon CloudWatch tworzy się i wykorzystuje, aby podkreślić wszelkie ograniczenia w przykładowej instancji. Korzystając z tego pulpitu nawigacyjnego, możesz upewnić się, że korzystasz z właściwego typu i rozmiaru instancji, a także właściwej konfiguracji wolumenu pamięci masowej. Analizowane wymiary to przepustowość sieci EC2, przepustowość Amazon EBS i IOPS oraz związek między rozmiarem instancji, a wydajnością Amazon EBS.

Pulpit nawigacyjny

Zlokalizowanie każdego odpowiedniego limitu zasobów i skonfigurowanie odpowiedniego monitorowania może okazać się trudne. Aby ułatwić to zadanie, twórcy stworzyli prosty skrypt w języku Python, który tworzy pulpit nawigacyjny CloudWatch wraz z odpowiednimi, wstępnie wybranymi danymi.

Skrypt pobiera listę identyfikatorów instancji jako dane wejściowe i tworzy pulpit nawigacyjny wraz ze wszystkimi odpowiednimi metrykami. Skrypt tworzy również adnotacje poziome na każdym wykresie, aby wskazać wartości maksymalne skonfigurowanej metryki. Na przykład, dla metryki Amazon EBS IOPS, adnotacja pokazuje maksymalna liczbę IOPS. To z kolei pomaga w identyfikacji „wąskiego gardła”.

Poświęć chwilę na uruchomienie skryptu przy użyciu jednej z opisanych poniżej metod. Następnie przejdziesz przez utworzony pulpit nawigacyjny wraz z każdym widgetem, a także poznasz kolejne kroki optymalizacji, które pozwolą Ci zwiększyć wydajność i obniżyć koszty obciążenia.

Tworzenie pulpitu nawigacyjnego za pomocą CloudShell

Na początek zaloguj się do AWS Management Console i załaduj AWS CloudShell.

Kiedy już zalogujesz się do CloudShell, musisz skonfigurować środowisko przy użyciu poniższego polecenia:

# Download the script locally

wget -L https://raw.githubusercontent.com/aws-samples/amazon-ec2-mssql-workshop/master/resources/code/Monitoring/create-cw-dashboard.py

# Prerequisites (venv and boto3)

python3 -m venv env # Optional

source env/bin/activate  # Optional

pip3 install boto3 # Required

Polecenia poprzedzające pobranie skryptu i skonfigurowanie środowiska CloudShell wraz z poprawnymi ustawieniami Pytona, aby możliwe było uruchomienie Twojego skryptu. Uruchom następujące polecenie, aby utworzyć pulpit nawigacyjny CloudWatch.

# Execute python3 create-cw-dashboard.py --InstanceList i-example1 i-example2 --region eu-west-1

W najprostszym przypadku musisz określić listę instancji, które Cię interesują (i-example1 oraz i-example2 w poprzednim przykładzie) oraz region, w którym te instancje są uruchomione (eu-west1 w poprzednim przykładzie). Szczegółowe instrukcje użytkowania znajdują się w pliku README. W danych wyjściowych do polecenia został umieszczony link do pulpitu nawigacyjnego CloudWatch.

Tworzenie pulpitu nawigacyjnego bezpośrednio z komputera lokalnego

Jeśli jesteś zaznajomiony z lokalnym uruchamianiem interfejsu AWS CLI i posiadasz zainstalowany język Python oraz pozostałe wymagania wstępne, możesz uruchomić te same polecenia co w poprzednim przykładzie CloudShell, ale ze środowiska lokalnego. Szczegółowe instrukcje użytkowania znajdują się w pliku README tutaj. Jeśli napotkasz jakiekolwiek problemy, zaleca się uruchomienie skryptu z CloudShell zgodnie z wcześniejszym opisem.

Badanie wskaźników

Po tym, jak skrypt został uruchomiony, przejdź do utworzonego pulpitu CloudWatch Dashboard. Bezpośrednie łącze do pulpitu nawigacyjnego CloudWatch jest dostarczane jako wyjście skryptu. Alternatywnie możesz przejść do CloudWatch w konsoli zarządzania AWS i wybrać pozycję Dashboards w menu, aby uzyskać dostęp do nowo utworzonego pulpitu CloudWatch Dashboard.

Warstwa sieci

Pierwszym widgetem CloudWatch Dashboard jest przepustowość sieci EC2 Network:

Automatyczna adnotacja tworzy czerwoną linię, która wskazuje maksymalną przepustowość, jaką może zapewnić Twoja instancja w Mb/s (megabitach na sekundę). Ta metryka jest ważna w trakcie uruchamiania obciążeń o wysokich wymaganiach dotyczących przepustowości sieci. W przykładzie SQL Server ma to dodatkowe znaczenie przy rozważaniu dodania instancji replik dla SQL Server, które dodatkowo obciążają sieć instancji.

W ogólnym ujęciu, jeśli Twoja instancja często osiąga 80% tego maksimum, powinieneś rozważyć wybór instancji o większej przepustowości sieci. Dla przykładu SQL można rozważyć zmianę architektury, aby zminimalizować użycie sieci. Na przykład, jeśli korzystałbyś z grupy o „zawsze włączonej rozproszonej dostępności”, rozłożonej na wiele stref i/lub regionów dostępności, możemy rozważyć użycie „grupy zawsze włączonej rozproszonej dostępności”, aby zmniejszyć ilość ruchu związanego z replikacją. Przed dokonaniem takiej zmiany poświęć trochę czasu na rozważenie wszelkich konsekwencji związanych z licencjonowaniem SQL.

Jeśli instancja zazwyczaj nie przekracza 10% wykorzystania sieci, metryka wskazuje, że sieć nie jest wąskim gardłem. W przypadku SQL, jeśli posiadasz niskie wykorzystanie sieci w połączeniu z wysokim wykorzystaniem przepustowości Amazon EBS, powinieneś rozważyć zoptymalizowanie wykorzystania pamięci przez instancję poprzez przeniesienie części użycia Amazon EBS na sieć – na przykład poprzez wdrożenie SQL jako Failover Cluster Instance ze współdzieloną pamięcią w Amazon FSx dla Windows File Server lub przenosząc magazyn kopii zapasowych SQL na Amazon FSx.

Warstwa przechowywania

Drugim widgetem pulpitu nawigacyjnego CloudWatch Dashboard jest ogólna przepustowość EC2 do Amazon EBS, co oznacza sumę przepustowości wszystkich podłączonych woluminów EBS.

Każdy typ i rozmiar instancji posiada inną przepustowość EBS, a skrypt automatycznie dodaje adnotacje do wykresu na podstawie specyfikacji instancji. Można zauważyć, że ta metryka jest intensywnie wykorzystywana podczas analizowania obciążeń SQL, które są zwykle uważane za obciążenia wymagające dużej ilości pamięci.

Jeśli znajdziesz punkty danych, które osiągają maksimum, tak jak ma to miejsce w poprzednim zrzucie ekranu, oznacza to, że obciążenie posiada wąskie gardło w warstwie magazynu. Sprawdźmy, czy możesz znaleźć wolumen EBS, które wykorzystuje całą tę przepustowość w następnej serii widgetów koncentrujących się na poszczególnych wolumenach EBS.

Oto winowajca. Z widgetem możesz zauważyć identyfikator i typ woluminu oraz maksymalną wydajność tego woluminu. Każdy wykres reprezentuje jeden z dwóch wymiarów wolumenu EBS: przepustowość i IOPS. Automatyczna adnotacja zapewnia wgląd w limity używanego woluminu. W tym przypadku używasz wolumenu gp3, skonfigurowanego z maksymalną przepustowością 750 Mb/s i 3000 IOPS.

Przyglądając się widgetowi, możesz zauważyć, że przepustowość osiąga pewne szczyty, ale są one mniejsze niż skonfigurowane maksimum. Biorąc pod uwagę poprzedni zrzut ekranu, który przedstawia, że ogólna przepustowość instancji Amazon EBS osiąga maksimum, można wywnioskować, że wolumen gp3 w tym przypadku nie jest w stanie osiągnąć maksymalnej wydajności. Taka sytuacja ma miejsce, ponieważ instancja, której nie używamy, nie posiada wystarczającej ogólnej przepustowości.

Pora na zmianę rozmiaru instancji, aby można było sprawdzić, czy to rozwiąże powstały problem. Zmieniając typy i rozmiary instancji lub woluminów, pamiętaj o ponownym uruchomieniu skryptu tworzenia pulpitu nawigacyjnego, aby zaktualizować progi. Zaleca się użycie tych samych parametrów skryptu, ponieważ ponowne uruchomienie skryptu z tymi samymi parametrami powoduje nadpisanie początkowego pulpitu nawigacyjnego i aktualizowanie adnotacji progów – dane metryk zostaną zachowane. Uruchomienie skryptu z innym parametrem nazwy pulpitu nawigacyjnego powoduje utworzenie nowego pulpitu nawigacyjnego i pozostawienie oryginalnego pulpitu nawigacyjnego. Mimo to progi w oryginalnym panelu nie zostaną zaktualizowane, co może prowadzić do nieporozumień.

Poniżej znajduje się widget dla wolumenu EBS po zwiększeniu rozmiaru instancji:

Widzimy, że wolumen EBS jest teraz w stanie bez problemu osiągnąć skonfigurowane maksimum. Przyjrzyjmy się również ogólnej przepustowości Amazon EBS dla większej instancji:

Możesz zauważyć, że instancja posiada teraz wystarczającą przepustowość EBS, aby obsłużyć skonfigurowaną wydajność wolumenu gp3 oraz posiadasz pewien zapas.

Teraz pora zamienić instancję z powrotem do oryginalnego rozmiaru i zamienić wolumen gp3 na wolumen Provisioned IOPS io2 z 45,000 IOPS, a następnie ponownie uruchomić skrypt, aby zaktualizować pulpit nawigacyjny. Uruchomienie intensywnego zadania IOPS na woluminie daje następujące efekty:

Jak widać, pomimo skonfigurowania 45 000 IOPS, wydaje się, że ogranicza się do około 15 000 IOPS. Patrząc na statystyki poziomu instancji, możemy zobaczyć odpowiedź:

Podobnie jak w przypadku poprzednich testów przepustowości, możesz zauważyć, że wydajność wolumenu io2 jest ograniczona przez rozmiar instancji. Ponownie zwiększ rozmiar swojej instancji i sprawdź, w jaki sposób zachowuje się wolumen, kiedy instancja została odpowiednio dobrana do jego obsługi:

Osiągamy teraz skonfigurowane limity wolumenu io2, czyli dokładnie to, czego chcieliśmy i spodziewaliśmy się zobaczyć. Limit IOPS na poziomie instancji nie ogranicza już wydajności wolumenu io2:

Korzystając z poprzednich kroków, możemy określić, gdzie znajdują się wąskie gardła pamięci masowej, a także sprecyzować, czy używamy odpowiedniego wolumenu EBS dla obciążenia. W swoich przykładach szukałeś wąskich gardeł i skalowałeś w górę, aby rozwiązać ten problem. Ten proces należy wykorzystać do określenia, gdzie zostały udostępnione zasoby w nadmiarze lub w niewystarczającym stopniu.

Jeśli widzimy wolumen, który nigdy nie osiąga maksymalnych wartości, dla których został skonfigurowany i który nie podlega żadnym innym wąskim gardłom, zwykle dochodzimy do wniosku, że dany wolumen może być odpowiednio dobrany do bardziej odpowiedniego wolumenu, który kosztuje mniej i lepiej pasuje do obciążenia pracą.

Przykładowo możesz zmienić wolumen EBS gp2 na wolumen EBS gp3 wraz z poprawnymi IOPS i przepustowością. EBS gp3 zapewnia przepustowość do 1000 Mb/s na wolumen i kosztuje 0,08 USD/GB (w porównaniu z 0.10 USD/GB dla gp2). Dodatkowo, w przeciwieństwie do gp2, wolumeny gp3 umożliwiają określenie zaopatrywanych operacji IOPS niezależnie od rozmiaru i przepustowości. Korzystając z opisanego powyżej procesu, możemy zidentyfikować, że wolumen gp2, io1 lub io2 można zamienić na bardziej opłacalny wolumen gp3.

Jeśli w trakcie tej analizy zaobserwujesz wolumen oparty na SSD o stosunkowo wysokim wykorzystaniu przepustowości, ale niskim zużyciu IOPS, powinieneś zbadać to dokładniej. Tańszy wolumen oparty na dysku twardym, taki jak wolumen st1 lub sc1, może być bardziej opłacalny przy zachowaniu wymaganego poziomu wydajności. Wolumeny Amazon EBS st1 zapewniają przepustowość do 500 MB/s i kosztują 0,045 USD za GB miesięcznie, a do tego często stanowią idealny typ wolumenu do wykorzystania na przykład w przypadku tworzenia kopii zapasowych SQL.

Dodatkowa optymalizacja przechowywania, którą możesz wdrożyć

Przenieś bazę danych TempDB do magazynu NVMe instancji – dane na wolumenie magazynu instancji SSD są zachowywane tylko przez okres istnienia skojarzonego z nim wystąpienia. Jest to idealne rozwiązanie dla magazynu TempDB, ponieważ gdy instancja zatrzymuje się i uruchamia, serwer SQL zapisuje dane na wolumenie EBS. Umieszczenie bazy danych TempDB w lokalnym magazynie wystąpień zwalnia powiązaną przepustowość Amazon EBS, zapewniając jednocześnie lepszą wydajność, ponieważ jest ona połączona z instancją.

Rozważ Amazon FSx for Windows File Server jako współdzieloną pamięć masową – tak jak opisano tutaj, Amazon FSx może zostać wykorzystany do przechowywania bazy danych SQL we współużytkowanej lokalizacji, umożliwiając korzystanie z SQL Server Failover Cluster Instance.

Warstwa obliczeniowa

Po skończeniu optymalizacji warstwy pamięci masowej odczekaj kilka dni i sprawdź ponownie metryki dotyczące zarówno Amazon EBS, jak i sieci. Użyj tych metryk w połączeniu z metrykami procesora i metrykami pamięci, aby wybrać odpowiedni typ wystąpienia, spełniający wymagania dotyczące obciążenia.

AWS oferuje blisko 400 typów instancji w różnych rozmiarach. Z perspektywy SQL ważne jest, aby wybrać instancje o wysokiej wydajności w jednym wątku, takie jak instancja z1d, ze względu na model SQL licencji na rdzeń. Instancje z1d zapewniają również magazyn instancji dla bazy danych TempDB.

Możesz także wypróbować AWS Compute Optimizer, który pomaga Ci automatycznie, polecając typy instancji przy użyciu systemów uczenia maszynowego w celu analizy historycznych danych o wykorzystaniu. Więcej szczegółów możesz znaleźć tutaj.

Twórcy zdecydowanie zalecają dokładnie przetestowanie aplikacji po wprowadzeniu jakichkolwiek zmian w konfiguracji.

Wnioski

Powyższy artykuł przedstawia kilka prostych i użytecznych technik umożliwiających uzyskanie wglądu w ważne metryki instancji, a także udostępnia skrypt, który znacznie upraszcza cały proces. Każde obciążenie działające w EC2 może skorzystać z tych technik. Twórcy odkryli, że są one szczególnie skuteczne przy identyfikowaniu praktycznych optymalizacji dla serwerów SQL Server, w przypadku których niewielkie zmiany mogą mieć korzystny wpływ na koszty, licencjonowanie i wydajność.