Umożliwianie skalowalności aplikacji

Teraz, gdy znasz podstawy przygotowywania się do wzrostu i wiesz o czynnikach, które należy wziąć pod uwagę podczas planowania pojemności, możesz podjąć wyzwanie związane z tworzeniem aplikacji tak skalowalnych, jak to możliwe.

Przeglądy architektury

Kluczowym punktem, który należy pamiętać, jest to, że należy regularnie wykonywać przeglądy architektury systemów.

Wiesz, że możesz stosować praktyki, takie jak infrastruktura jako kod, aby ulepszyć sposób wdrażania zasobów w chmurze. Regularnie aktualizujesz i ulepszasz kod aplikacji. Należy to zrobić tak samo z podstawowymi zasobami platformy.

Przeprowadzenie przeglądu architektury pomaga zidentyfikować obszary, które wymagają poprawy.

Centrum architektury Azure ma wiele zasobów, które ułatwiają tworzenie architektury aplikacji w chmurze i istnieje wiele zaleceń dotyczących skalowalności, które można znaleźć w przewodniku po architekturze aplikacji pod następującym linkiem:

Azure Architecture Center

Scenariusz: architektura firmy Tailwind Traders

Pierwszym krokiem jest ocena architektury i aplikacji — nie tylko w celu określenia, gdzie leżą jego słabe strony, ale także do rozpoznawania jego mocnych stron. Co z tym jest dobre?

Przyjrzyj się innemu scenariuszowi, który został wyświetlony w poprzedniej lekcji. Oto diagram architektury organizacji ponownie.

Aplikacja została rozłożona na mniejsze mikrousługi, a niektóre z tych usług znajdują się jako kontenery na Azure Kubernetes Service lub mogą być uruchomione na maszynach wirtualnych lub w usłudze App Service. Korzystają one również z niektórych z natury skalowalnych usług, takich jak Function Apps i Logic Apps.

Ta zmiana jest dobra, ale istnieją pewne ulepszenia, które sprawią, że aplikacja będzie bardziej skalowalna. Na przykład skoncentruj się teraz na usłudze Products. Na diagramie usługa produktu jest uruchomiona na platformie Kubernetes, ale zakładamy, że jest ona uruchomiona na maszynie wirtualnej w Azure. Koncepcje skalowania, prawdopodobnie z nieco inną implementacją, można zastosować do aplikacji niezależnie od tego, czy są one uruchomione na serwerach, usłudze App Service, czy w kontenerach.

Produkt działa obecnie na jednej maszynie wirtualnej połączonej z pojedynczą bazą danych Azure SQL. Należy włączyć tę maszynę wirtualną do skalowania poziomego. Można to zrobić przy użyciu zestawów skalowania maszyn wirtualnych Azure, które umożliwiają tworzenie i zarządzanie grupą identycznych maszyn wirtualnych o zrównoważonym obciążeniu. Ponieważ masz teraz więcej niż jedną maszynę wirtualną, musisz wprowadzić moduł równoważenia obciążenia do dystrybucji ruchu między maszynami wirtualnymi.

Zestawy skalowania maszyn wirtualnych

Stosując zestawy skalowania maszyn wirtualnych na pojedynczych maszynach wirtualnych, możesz uzyskać kilka korzyści:

• Skalowanie automatyczne można wykonywać na podstawie metryk hosta, metryk wewnętrznych, danych analitycznych aplikacji lub według harmonogramu.
• Można użyć Strefy dostępności (AZ), które są fizycznie oddzielnymi lokalizacjami w regionie Azure, z których każdy składa się z co najmniej jednego centrum danych. Dzięki obsłudze AZ można rozmieszczać maszyny wirtualne w wielu strefach dostępności, co sprawia, że aplikacja jest bardziej niezawodna i chroni ją przed awariami centrum danych. Nowe wystąpienia w zestawie skalowania są automatycznie równomiernie dystrybuowane między strefami AZ.
• Dodawanie modułu równoważenia obciążenia staje się łatwiejsze. Zestawy skalowania maszyn wirtualnych obsługują korzystanie z Azure Load Balancer dla podstawowej dystrybucji ruchu na poziomie warstwy 4. Obsługują także Azure Application Gateway do bardziej zaawansowanej dystrybucji ruchu L7 i terminacji SSL.

Przed wdrożeniem zestawów skalowania należy wziąć pod uwagę kilka ważnych czynników. Specyficznie:

• Unikaj lepkości, aby żaden klient nie był przywiązany do określonego zaplecza serwerowego.
• Usuń trwałe dane z maszyny wirtualnej i zapisz je w innym miejscu, na przykład w Azure Storage lub w bazie danych.
• Projektowanie pod kątem skalowania wewnętrznego. Ważne jest również, aby aplikacja mogła łatwo skalować w dół. Musi bezpiecznie obsługiwać nie tylko więcej wystąpień dodanych do puli serwerów obsługujących ruch, ale także nagłe zakończenie wystąpień w miarę spadku obciążenia. Aspekt skalowania w dół jest często pomijany.

Oddzielenie

Dodałeś więcej maszyn wirtualnych z zestawami skalowania. Skalowanie w poziomie to typowa odpowiedź na "musimy przeprowadzić skalowanie". Można jednak skalować tylko jedną metrykę, a ta odpowiedź może nie być odpowiednia dla wszystkich zadań wykonywanych przez usługę produktu.

W naszym scenariuszu usługa produktów ma funkcję: po przekazaniu obrazu produktu, transkoduje ten obraz i przechowuje go w kilku różnych rozmiarach dla miniatur, obrazów w katalogu i tak dalej. Przetwarzanie obrazów intensywnie obciąża procesor CPU, ale ogólne użycie intensywnie obciąża pamięć.

Przetwarzanie obrazów to zadanie asynchroniczne, które można podzielić na zadanie w tle. Można to zrobić, rozdzielając usługę przetwarzania obrazów, używając kolejki. Oddzielenie umożliwia niezależne skalowanie obu usług – jedną na pamięć (usługę produktu) i drugą (usługę przetwarzania obrazów) na procesorze CPU lub nawet długość kolejki, a inną skalę wykorzystać do odbierania tych komunikatów i przetwarzania obrazów.

Skalowanie za pomocą kolejek

Azure ma dwa typy rozwiązań dla kolejek:

• Azure Service Bus kolejki To bardziej zaawansowana oferta kolejkowania, która jest częścią szerszego produktu Azure Service Bus, oferująca pub/sub oraz bardziej zaawansowane wzorce integracji.
• Azure Storage Kolejki prosty interfejs kolejki oparty na protokole REST, zbudowany na Azure Storage. Oferuje niezawodne, trwałe komunikaty.

Twoje wymagania w tym scenariuszu są proste, więc można użyć kolejek usługi Azure Storage. Twój poziom produktu wcale nie musi być skalowany, ponieważ oddzieliłeś to zadanie w tle.

Cache w pamięci

Innym sposobem poprawy wydajności aplikacji jest zaimplementowanie pamięci podręcznej.

Teraz wiesz, że wydajność nie jest równa skalowalności dokładnie, ale poprawiając wydajność aplikacji, możesz zmniejszyć obciążenie innych zasobów. Ta poprawa oznacza, że skalowanie może nie być konieczne tak szybko.

Azure Managed Redis (dawniej Azure Cache for Redis) to zarządzana oferta Redis. Usługa Redis może być używana w wielu wzorcach i przypadkach użycia. W przypadku usługi produktu w tym scenariuszu prawdopodobnie zaimplementujesz wzorzec z wyciąganiem danych do pamięci podręcznej. W tym wzorcu elementy z bazy danych są ładowane do pamięci podręcznej zgodnie z potrzebami, dzięki czemu aplikacja będzie wydajniejsza i zmniejsza obciążenie bazy danych.

Usługa Redis może być również używana jako kolejka obsługi komunikatów, buforowanie zawartości internetowej lub buforowanie sesji użytkownika. Ten typ buforowania może być bardziej odpowiedni dla innych usług w systemie, takich jak usługa koszyka zakupów, gdzie można przechowywać dane koszyka zakupów na sesję w usłudze Redis zamiast używać pliku cookie.

Skalowanie bazy danych

Teraz, gdy zasoby obliczeniowe są bardziej skalowalne, przyjrzyj się bazie danych. W tym scenariuszu używasz Azure SQL Database, czyli zarządzanej oferty SQL Server z Azure.

Relacyjne bazy danych są trudniejsze do skalowania w poziomie niż nierelacyjne bazy danych. Pierwszą czynnością, którą można wykonać w celu skalowania bazy danych, jest skalowanie w górę rozmiaru bazy danych. Tę zmianę rozmiaru można łatwo wykonać, przy tylko krótkiej utracie łączności, za pomocą prostego wywołania API w Azure SQL lub suwaka w portalu.

Jeśli to powiększanie rozmiaru nie spełnia twoich wymagań, to w zależności od charakterystyki ruchu może być odpowiednie do poziomego skalowania odczytów do bazy danych, co pozwala na kierowanie ruchu odczytu do repliki.

Ta zmiana musi zostać zaimplementowana w kodzie. Intencję routingu należy określić, ustawiając atrybut ApplicationIntent w parametry połączenia bazy danych. Użyj ReadOnly, aby nawiązać połączenie z repliką lub ReadWrite z serwerem podstawowym.

Zalecaną metodą jest użycie tożsamości zarządzanych do uwierzytelniania, przechowywanie wszelkich niezbędnych konfiguracji w Azure Key Vault:

#Read Replica Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;Authentication=Active Directory Default;Encrypt=True;

#Primary Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;Authentication=Active Directory Default;Encrypt=True;

Ponieważ ta zmiana musi zostać zaimplementowana w kodzie, może nie być odpowiednim rozwiązaniem w danej sytuacji. Co jeśli każdy produkt i usługa potrzebują umiejętności odczytu i zapisu?

W takim przypadku możesz przyjrzeć się poziomemu skalowaniu Azure SQL Database przy użyciu fragmentowania.

Fragmentowanie bazy danych

Jeśli po skalowaniu w górę lub zaimplementowaniu replik do odczytu zasoby bazy danych nadal nie spełniają wymagań systemu, następną opcją jest fragmentowanie.

Fragmentowanie to technika dystrybucji dużych ilości danych o identycznej strukturze w wielu niezależnych bazach danych. Fragmentowanie (sharding) może być wymagane z różnych powodów. Na przykład:

• Łączna ilość danych jest zbyt duża, aby zmieścić się w ramach ograniczeń pojedynczej bazy danych.
• Przepływność transakcji ogólnego obciążenia przekracza możliwości pojedynczej bazy danych.
• Oddzielni klienci powinni znajdować się w różnych fizycznych bazach danych ze względów zgodności z przepisami (to wymaganie dotyczy mniej skalowania, ale jest inną sytuacją, w której używa się fragmentowania).

Aplikacja dodaje odpowiednie dane do odpowiedniego fragmentu, dzięki czemu system jest skalowalny poza ograniczeniami poszczególnych baz danych.

Azure SQL oferuje narzędzia elastycznej bazy danych Azure. Te narzędzia ułatwiają tworzenie, konserwowanie i wykonywanie zapytań podzielonych na fragmenty baz danych SQL w Azure na podstawie logiki aplikacji.