Aktualności AWS

Zarządzanie finansami w chmurze (CFM) jest fundamentalną częścią wędrówki każdego klienta do chmury. Niezależnie od tego, czy tworzysz aplikacje w sposób natywny w chmurze, migrujesz obciążenia robocze do chmury, czy rozszerzasz zastosowanie usług w chmurze, CFM może pomóc Ci osiągnąć pełną wartość biznesową związaną z przyjęciem chmury.

Na wiele lat przed udostępnieniem usługi Amazon Elastic Kubernetes Service (EKS) klienci zwrócili się do twórców, że chcą usługi, która uprości zarządzanie Kubernetes. Wielu z nich korzystało z samozarządzających się klastrów w Amazon Elastic Computer Cloud (EC2) i napotykało na wyzwania związane z aktualizacją, skalowaniem i utrzymaniem płaszczyzny sterowania Kubernetes. Kiedy EKS został uruchomiony w 2018 roku, miał na celu zmniejszenie obciążenia operacyjnego klientów, oferując zarządzaną płaszczyznę kontroli dla Kubernetes. Początkowo obejmowało to automatyczne aktualizacje, poprawki i kopie zapasowe, które często funkcjonują jako termin „undifferentiated heavy lifting”. Dlatego też autorzy przeanalizowali wolumeny danych, aby móc stworzyć płaszczyznę kontroli, która będzie działać dla zdecydowanej większości ich klientów.

Wiele organizacji posiada aplikacje, które wymagają programu Microsoft SQL Server do obsługi obciążeń relacyjnych baz danych: niektóre aplikacje mogą być oprogramowaniem własnościowym, którego dostawca upoważnia program Microsoft SQL Server do uruchamiania usługi bazy danych; inne aplikacje mogą być długoletnimi, lokalnymi aplikacjami, które zawierały Microsoft SQL Server, gdy były pierwotnie tworzone. Kiedy organizacje migrują aplikacje do AWS, często zaczynają od podejścia „lift-and-shift” i uruchamiają usługę bazy danych Microsoft SQL w Amazon Elastic Compute Cloud (Amazon EC2). Powodem takiego rozwiązania może być wybór tego, z czym są najbardziej zaznajomieni.

W momencie nieuchronnej awarii chcesz uniknąć pechowego wdrożenia. Dlatego też autorzy rozpoczną od krótkiej historii, która obrazuje cel tego artykułu. Zespół DevOps właśnie rozpoczął aktualizację bazy danych z planowanym 30-minutowym przestojem. Zespół zautomatyzował cały przepływ aktualizacji, uruchomił potok CI/CD bez interwencji człowieka, a aktualizacja przebiega płynnie. Następnie, po 20 minutach, potok utknął, a uaktualnienie nie postępuje. Okres konserwacji wygasł i klienci nie mogą dokonywać transakcji. Utworzyłeś zgłoszenie do pomocy technicznej, a inżynier AWS potwierdził, że uaktualnienie kończy się niepowodzeniem z powodu działającego incydentu AWS Health w regionie us-west-2. Inżynier polecił zespołowi DevOps dalsze monitorowanie strony status.aws.amazon.com pod kątem aktualizacji dotyczących rozwiązywania incydentów. Wydarzenie trwało przez trzy godziny, podczas których klienci nie mogli dokonywać transakcji. Po rozwiązaniu problemu zespół DevOps ponowił próbę uszkodzonego potoku i ta zakończyła się pomyślnie.

Projektowanie obciążeń w celu osiągnięcia celów w zakresie wytrzymałości może być działaniem równoważącym. Firmy projektujące wytrzymałość w chmurze często muszą ocenić wiele czynników, zanim będą mogły wybrać najbardziej optymalną architekturę dla swoich obciążeń. Example Corp posiada wiele aplikacji o różnej krytyczności, a każda z tych aplikacji ma inne potrzeby pod względem odporności, złożoności i kosztów. Mają wiele możliwości zaprojektowania swoich obciążeń pod kątem wytrzymałości i kosztów, ale która opcja najlepiej odpowiada ich potrzebom? Czy będą musieli dokonać poświęcenia, aby wprowadzić jeden nad drugim? Jak i dlaczego powinni wybierać jeden wzór, a nie inny?

Przenoszenie danych do i z usług AWS Storage można zautomatyzować i przyspieszyć dzięki AWS DataSync. Na przykład możesz użyć DataSync do migracji danych do AWS, replikacji danych w celu zapewnienia ciągłości biznesowej oraz przenoszenia danych do analizy i przetwarzania w chmurze. Możesz użyć DataSync do przesyłania danych do i z usług AWS Storage, w tym Amazon Simple Storage Service (Amazon S3), Amazon Elastic File System (Amazon EFS) oraz Amazon FSx. DataSync integruje się również z Amazon CloudWatch i AWS CloudTrail w celu rejestrowania, monitorowania i ostrzegania.

Zestawów tzw. rekordów weighted Amazon Route 53 można używać do dystrybucji żądań w replikach do odczytu. W strefie hostowanej Route 53 utwórz indywidualne zestawy rekordów dla każdego punktu końcowego DNS skojarzonego z replikami do odczytu i nadaj im taką samą wagę. Następnie kieruj żądania do punktu końcowego zestawu rekordów.

Aktualizacja: 8 września 2021 Amazon Elasticsearch Service został przemianowany na Amazon OpenSearch Service. Zobacz szczegóły. W miarę dojrzewania wiele aplikacji zaczyna rosnąć w złożoność, co utrudnia programistom utrzymywanie kodu lub dodawanie nowych funkcji. Może to prowadzić do aplikacji monolitycznych, w których programiści muszą wiedzieć więcej o całej architekturze, aby wprowadzić zmiany. Zazwyczaj powoduje to, że kod staje się mniej stabilny, a tempo rozwoju spada.

Organizacje budujące systemy na skalę korporacyjną wymagają skonfigurowania bezpiecznej i zarządzanej strefy docelowej (landing zone) w celu wdrażania i obsługi swoich systemów. Strefa docelowa to punkt wyjścia, z którego organizacja może szybko uruchamiać i wdrażać obciążenia i aplikacje, mając pewność co do bezpieczeństwa i środowiska infrastruktury, zgodnie z opisem w sekcji Czym jest strefa docelowa? Nationwide Building Society (Nationwide) jest największym na świecie towarzystwem budowlanym. Jest własnością 16 milionów członków i istnieje, aby służyć ich potrzebom. Towarzystwo jest jednym z największych dostawców kredytów hipotecznych, oszczędnościowych i bieżących w Wielkiej Brytanii, a także głównym dostawcą ISA, kart kredytowych, pożyczek osobistych, ubezpieczeń i inwestycji.

Wiele organizacji korzysta z baz danych do obsługi aplikacji o dużym znaczeniu. Posiadanie kompleksowej strategii ochrony tych baz danych jest podstawą do spełnienia umów dotyczących poziomu usług biznesowych (SLA). Optymalna strategia obejmuje wykorzystanie zarówno kopii zapasowych, jak i replikacji do ochrony baz danych w przypadku klęski żywiołowej, błędu ludzkiego lub zagrożenia cybernetycznego.

Autorzy mają przyjemność ogłosić, że Amazon Managed Service for Prometheus udostępnia teraz metryki użytkowania Amazon CloudWatch. Te metryki mogą pomóc w uzyskaniu lepszego wglądu w obszar roboczy Amazon Managed Service for Prometheus. Pora przyjrzeć się, jak możesz wykorzystać te nowe metryki użytkowania Prometheus w CloudWatch.

Ten artykuł zawiera przewodnik krok po kroku, jak monitorować skonteneryzowane obciążenie działające w Amazon EKS Anywhere przez publikowanie metryk w usłudze Amazon Managed Service dla Prometheus i używanie usługi Amazon Managed Grafana w celu wizualizacji.