Optymalizacja EC2 Workloads z Amazon CloudWatch

W grudniu 2020 r. firma AWS ogłosiła dostępność gp3, woluminów SSD nowej generacji 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 woluminy.

Nowa wersja zapewnia doskonałą okazję do odpowiedniego dopasowania rozmiaru warstwy pamięci masowej, wykorzystując wbudowane możliwości monitorowania AWS. Jest to szczególnie ważne w przypadku obciążeń SQL, ponieważ istnieje wiele typów instancji oraz konfiguracji przechowywania, które można wybrać dla SQL Server w AWS.

Wielu klientów prosi o poradę w wyborze „najlepszej” lub „właściwej” konfiguracji pamięci masowej i instancji, ale nie ma jednego rozwiązania, które pasowałoby do wszystkich warunków. W tym poście omówiono kluczowe techniki pozwalające na dobór optymalnego rozmiaru obciążeń. Skupiamy się na odpowiednim rozmiarze SQL Server jako przykładowym obciążeniu, ale techniki, które zademonstrujemy, mają zastosowanie w równym stopniu do każdej instancji Amazon EC2 z dowolnym systemem operacyjnym lub obciążeniem.

Tworzymy i używamy pulpitu nawigacyjnego Amazon CloudWatch, aby podkreślić wszelkie ograniczenia i wąskie gardła w naszej przykładowej instancji. Korzystając z naszego dashboard’u, możemy upewnić się, że używamy właściwego typu i rozmiaru instancji oraz właściwej konfiguracji pojemności woluminu. Wielkości, które analizujemy, to przepustowość sieci EC2, przepustowość Amazon EBS i IOPS, oraz związek między rozmiarem instancji a wydajnością Amazon EBS.

Dashboard

Zlokalizowanie każdego odpowiedniego limitu zasobów i skonfigurowanie właściwego monitorowania może być trudne. Aby uprościć to zadanie, AWS napisał prosty skrypt w języku Python, który tworzy pulpit nawigacyjny CloudWatch z odpowiednimi wstępnie wybranymi metrykami.

Skrypt pobiera listę identyfikatorów instancji jako dane wejściowe i tworzy dashboard 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 maksymalną liczbę IOPS. Pomaga nam to identyfikować tzw. wąskie gardła.

Poświęć chwilę na uruchomienie skryptu przy użyciu jednej z opisanych poniżej metod. Następnie przeprowadzimy Cię przez utworzony dashboard i każdy widżet oraz wyjaśnimy kolejne kroki optymalizacji, które pozwolą Ci zwiększyć wydajność i obniżyć koszty obciążenia.

Tworzenie pulpitu nawigacyjnego za pomocą CloudShell

Najpierw logujemy się do AWS Management Console i ładujemy AWS CloudShell.

Po zalogowaniu do CloudShell’a musimy skonfigurować nasze środowisko za pomocą poniższego polecenia:

Polecenia pobierają skrypt i konfigurują środowisko CloudShell z odpowiednimi ustawieniami Pythona, aby uruchomić nasz skrypt. Uruchom poniższe polecenie, aby utworzyć CloudWatch Dashboard.

W najprostszym przypadku wystarczy określić listę interesujących nas instancji (i-example1 i i-example2 w powyższym przykładzie) oraz Region, w którym te instancje są uruchomione (eu-west1 w powyższym przykładzie). Szczegółowe instrukcje użytkowania znajdują się w pliku README tutaj. W danych wyjściowych polecenia znajduje się link do pulpitu CloudWatch Dashboard.

Tworzenie Dashboard’u bezpośrednio z maszyny lokalnej

Jeśli jesteś zaznajomiony z lokalnym uruchamianiem interfejsu AWS CLI, masz zainstalowany język Python oraz twoje środowisko spełnia inne 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, zalecamy uruchomienie skryptu z CloudShell zgodnie z wcześniejszym opisem.

Badanie naszych metryk

Po uruchomieniu skryptu przejdź do utworzonego pulpitu CloudWatch Dashboard. Bezpośredni link do pulpitu nawigacyjnego CloudWatch jest dostarczane w danych wyjściowych skryptu. Alternatywnie możesz przejść do CloudWatch w konsoli AWS Management Console i wybrać pozycję menu Dashboards, aby uzyskać dostęp do nowo utworzonego pulpitu CloudWatch Dashboard.

Warstwa sieciowa

Pierwszym widżetem CloudWatch Dashboard jest przepustowość sieci EC2:

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 podczas uruchamiania obciążeń o wysokich wymaganiach dotyczących przepustowości sieci. W naszym przykładzie SQL Server ma to dodatkowe znaczenie przy rozważaniu dodania repliki instancji dla SQL Server, które dodatkowo obciążają sieć instancji.

Generalnie, jeśli Twoja instancja często osiąga 80% tego maksimum, powinieneś rozważyć wybór instancji o większej przepustowości sieci. W naszym przykładzie SQL możemy rozważyć zmianę naszej architektury, aby zminimalizować wykorzystanie sieci. Na przykład, jeśli używamy grupy „Always On Availability Group” rozłożonej na wiele stref i/lub regionów dostępności, możemy rozważyć użycie „Always On Distributed Availability Group”, aby zmniejszyć ilość ruchu związanego z replikacją. Przed dokonaniem takiej zmiany należy rozważyć wszelkie konsekwencje związane z implikacjami licencjonowania SQL.

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

Warstwa magazynująca

Drugim widżetem pulpitu CloudWatch 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 ma inną przepustowość Amazon 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 masowej.

Jeśli znajdziesz punkty danych, które osiągają maksimum, tak jak na powyższym wykresie, oznacza to, że obciążenie ma wąskie gardło w warstwie magazynowania. Zobaczmy, czy możemy znaleźć wolumin EBS, który wykorzystuje całą tę przepustowość w naszej następnej serii widżetów, które koncentrują się na poszczególnych woluminach EBS.

A oto winowajca. Z widżetu możemy zobaczyć ID i typ woluminu, oraz maksymalną wydajność dla tego woluminu. Każdy wykres reprezentuje jeden z dwóch wymiarów woluminu EBS: przepustowość i IOPS (Operations Per Second). Automatyczna adnotacja zapewnia wgląd w limity używanego woluminu. W tym przypadku używamy woluminu gp3, skonfigurowanego z maksymalną przepustowością 750 MB/s i 3000 IOPS.

Patrząc na widżet widzimy, że przepustowość osiąga pewne szczyty, ale są one mniejsze niż skonfigurowane maksimum. Biorąc pod uwagę poprzedni zrzut ekranu, który pokazuje, że ogólna przepustowość instancji Amazon EBS osiąga maksimum, możemy stwierdzić, że wolumin gp3 tutaj nie jest w stanie osiągnąć maksymalnej wydajności. Dzieje się tak, ponieważ instancja, której używamy, nie ma wystarczającej ogólnej przepustowości.

Zmieńmy rozmiar instancji, abyśmy mogli zobaczyć, czy to rozwiązuje nasz problem. Zmieniając typy i rozmiary instancji lub woluminów, pamiętaj o ponownym uruchomieniu skryptu tworzącego pulpit, aby zaktualizować progi. Zalecamy użycie tych samych parametrów skryptu, ponieważ ponowne uruchomienie skryptu z tymi samymi parametrami powoduje nadpisanie początkowego dashboard’u i aktualizowanie adnotacji progowych – dane metryk zostaną zachowane. Uruchomienie skryptu z innym parametrem nazwy dashboard’u powoduje utworzenie nowego pulpitu nawigacyjnego i pozostawienie oryginalnego pulpitu nawigacyjnego. Jednak progi w oryginalnym panelu nie zostaną zaktualizowane, co może prowadzić do zamieszania.

Oto widżet dla naszego woluminu EBS po zwiększeniu rozmiaru instancji:

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

Widzimy, że instancja ma teraz wystarczającą przepustowość Amazon EBS, aby obsłużyć skonfigurowaną wydajność naszego woluminu gp3, i mamy pewien zapas.

Teraz zamieńmy naszą instancję z powrotem do pierwotnego rozmiaru i zamieńmy nasz wolumin gp3 na wolumin Provisioned IOPS io2 z 45 000 IOPS, a następnie ponownie uruchomimy nasz skrypt, aby zaktualizować dashboard. Uruchomienie intensywnego pod względem IOPS zadania na woluminie skutkuje następującymi efektami:

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

Podobnie jak w przypadku wcześniejszych testów przepustowości, widzimy, że wydajność woluminu io2 jest ograniczona przez rozmiar instancji. Ponownie zwiększmy rozmiar naszej instancji i zobaczmy, jak zachowuje się wolumin, gdy instancja została odpowiednio dobrana do jej obsługi:

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

Korzystając z poprzednich kroków, możemy określić, gdzie znajdują się wąskie gardła pamięci masowej, a także możemy określić, czy używamy odpowiedniego typu woluminu EBS dla obciążenia. W naszych przykładach szukaliśmy wąskich gardeł i skalowaliśmy w górę, aby je rozwiązać. Proces ten powinien być stosowany do identyfikowania, gdzie zasoby zostały dobrane nadmiarowo lub niedostatecznie.

Jeśli widzimy wolumin, 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 wolumin może być odpowiednio dopasowany wielkością do bardziej odpowiedniego woluminu, który kosztuje mniej, oraz lepiej pasuje do obciążenia.

Możemy na przykład zmienić wolumin Amazon EBS gp2 na wolumin EBS gp3 z poprawnymi IOPS i przepustowością. EBS gp3 zapewnia przepustowość do 1000 MB/s na wolumin i kosztuje 0,08 USD/GB (w porównaniu z 0,10 USD/GB dla gp2). Ponadto, w przeciwieństwie do gp2, woluminy gp3 umożliwiają określenie parametru IOPS niezależnie od rozmiaru i przepustowości. Korzystając z opisanego powyżej procesu, możemy zidentyfikować, że wolumin gp2, io1 lub io2 można zamienić na bardziej opłacalny wolumin gp3.

Jeśli podczas naszej analizy zaobserwujemy wolumin oparty na SSD o stosunkowo wysokim wykorzystaniu przepustowości, ale niskim zużyciu IOPS, powinniśmy to dokładnie zbadać. Tańszy wolumin oparty na dysku twardym HDD, taki jak wolumin st1 lub sc1, może być bardziej opłacalny przy zachowaniu wymaganego poziomu wydajności. Woluminy Amazon EBS st1 zapewniają przepustowość do 500 MB/s i kosztują 0,045 USD za GB miesięcznie i często są idealnym typem woluminu do wykorzystania przykładowo w przypadku tworzenia kopii zapasowych SQL.

Dodatkowa optymalizacja pamięci masowej, którą możesz wdrożyć

Move the TempDB to Instance Store NVMe storage  — dane na woluminie magazynu instancji (instance store) SSD są zachowywane tylko przez okres istnienia skojarzonej z nią instancją. Jest to idealne rozwiązanie dla magazynu TempDB, ponieważ gdy instancja zatrzymuje się i uruchamia, SQL Server zapisuje dane na woluminie EBS. Umieszczenie bazy danych TempDB w lokalnym magazynie instancji zwalnia powiązaną przepustowość Amazon EBS, zapewniając jednocześnie lepszą wydajność, ponieważ jest ona lokalnie połączona z instancją.

Consider Amazon FSx for Windows File Server as a shared storage solution  — jak opisano tutaj, Amazon FSx może służyć do przechowywania bazy danych SQL we współużytkowanej lokalizacji, umożliwiając korzystanie z instancji SQL Server Failover Cluster Instance.

Warstwa obliczeniowa

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

AWS oferuje blisko 400 typów instancji w różnych rozmiarach. Z perspektywy SQL, wybór instancji o wysokiej wydajności jednowątkowej, takich jak instancja z1d, jest niezwykle ważny ze względu na model SQL licencji na rdzeń (license-per-core). Instancje z1d zapewniają również magazyn instancji dla bazy danych TempDB.

Możesz również wypróbować AWS Compute Optimizer, który pomaga, automatycznie polecając typy instancji przy użyciu uczenia maszynowego do analizowania historycznych danych o wykorzystaniu. Więcej szczegółów znajdziesz tutaj.

Zdecydowanie zalecamy dokładne przetestowanie aplikacji po wprowadzeniu jakichkolwiek zmian w konfiguracji.

Podsumowanie

W tym poście omówiono kilka prostych i przydatnych technik umożliwiających uzyskanie wglądu w ważne metryki instancji, a także udostępniono skrypt, który znacznie upraszcza ten proces. Każde obciążenie działające w EC2 może skorzystać z tych technik. Dowiedzieliśmy się, że są one szczególnie skuteczne w identyfikowaniu praktycznych optymalizacji dla serwerów SQL Server, w przypadku których niewielkie zmiany mogą mieć korzystny wpływ na koszty, licencjonowanie i wydajność.

źródło: AWS