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 platformy 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:
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 w usłudze Azure Kubernetes Service lub mogą być uruchomione na maszynach wirtualnych lub w usłudze App Service. Używasz niektórych z natury skalowalnych usług, takich jak Funkcje 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 na platformie 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 Database. Należy włączyć tę maszynę wirtualną do skalowania w poziomie. Można to zrobić przy użyciu zestawów skalowania maszyn wirtualnych platformy Azure, które umożliwiają tworzenie grupy identycznych maszyn wirtualnych o zrównoważonym obciążeniu i zarządzanie nimi. 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żywać Stref dostępności (AZ), które są niezależnymi autonomicznymi centrami danych w ramach regionu Azure. 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 usługi Azure Load Balancer do podstawowej dystrybucji ruchu warstwy 4. Obsługują one również usługę Azure Application Gateway dla 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 usłudze 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 zadanie. Pobiera obraz produktu, a następnie ten obraz jest przesyłany. Transkoduje ten obraz i przechowuje go w kilku różnych rozmiarach: jako miniatury, obrazy w katalogu itd. 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 oferuje dwa typy kolejek:
- Kolejki Azure Service Bus Bardziej zaawansowana oferta kolejkowania, która jest częścią szerszego produktu Azure Service Bus, oferuje wzorce integracji pub/sub i zaawansowane funkcje.
- Kolejki Azure Storage Prosty interfejs kolejki oparty na protokole REST na bazie usługi Azure Storage. Oferuje niezawodne, trwałe komunikaty.
Wymagania w tym scenariuszu są proste, więc możesz 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.
Usługa Azure Cache for Redis to zarządzana oferta usługi 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.
Redis może być również używany jako kolejka wiadomości do buforowania treści webowych lub do buforowania 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 bazy danych Azure SQL Database, która jest zarządzaną ofertą programu SQL Server z platformy 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 przestoju wynoszącym średnio mniej niż cztery sekundy. Za pomocą prostego wywołania interfejsu API w usłudze Azure SQL lub za pomocą suwaka w portalu.
Jeśli to dostosowanie rozmiaru nie spełnia Twoich wymagań, to w zależności od charakterystyki ruchu, może być odpowiednie skalowanie poziome dla operacji odczytu w bazie danych. Umożliwia kierowanie ruchu odczytu do repliki odczytu.
Notatka
W przypadku usługi Azure SQL, jeśli używasz warstw Premium lub Krytyczne dla działania firmy, skalowanie odczytu w poziomie jest domyślnie włączone. Nie można jej włączyć w warstwach podstawowa lub Standardowa.
Ta zmiana musi zostać zaimplementowana w kodzie. Oto jak to zrobić.
#Azure SQL Connection String
#Master Connection String
ApplicationIntent=ReadWrite
#Read Replica Connection String
ApplicationIntent=ReadOnly
#Full Example
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;
Zaktualizuj atrybut ApplicationIntent w parametrach połączenia bazy danych, aby określić serwer, z którym chcesz nawiązać połączenie. Użyj ReadOnly, jeśli chcesz nawiązać połączenie z repliką lub ReadWrite, jeśli chcesz nawiązać połączenie z serwerem głównym.
Ponieważ to polecenie musi być zaimplementowane 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ę skalowaniu bazy danych SQL DB przy użyciu fragmentowania.
Fragmentowanie bazy danych
Jeśli po przeskalowaniu 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 będzie skalowalny poza ograniczeniami poszczególnych baz danych.
Usługa Azure SQL oferuje narzędzia usługi Azure Elastic Database. Te narzędzia ułatwiają tworzenie, konserwowanie i wykonywanie zapytań podzielonych na fragmenty baz danych SQL na platformie Azure na podstawie logiki aplikacji.