Tworzenie aplikacji w chmurze jest przyjemne, łatwe i bez problemowe. Jeśli czujesz w tym zdaniu jakiś niezdrowy marketing to dobrze:) Chmura nie zwalnia z obowiązku myślenia i projektowania architektury zgodnie z rekomendacjami usługi.
Jeśli czytałeś mój wpis na https://blogs.msdn.com/architekcichmury, to zdążyłeś poznać kilka usług, przy pomocy których możesz zbudować własną aplikację. Teraz pokażę Ci jakie błędy popełniłem, gdy tworzyłem swoje pierwsze rozwiązania.
Na początek pokażę Ci 5 błędów, które popełniłem korzystając z App Service Environment.
App Service Environment zajmuję się już ponad 18 mce, w tym czasie usługa mocno ewoluowała. A więc co musisz wiedzieć kiedy korzystasz z ASE?
- Po pierwsze App Service Environment w swojej konstrukcji różni się od App Service.
Jak chcesz zrozumieć różnicę rzuć okiem na ten wpis. Pojawiają się koncepcje Worker Pool’i, inaczej działają App Service Plan’y – słowem jest kilka różnic. Dlaczego jest to ważne? Bo nie możesz zwiększyć swojego App Service Plan o ile wcześniej nie przygotowałeś sobie wolnych instancji (nodów) w Worker Pool’i, w której leży Twój plan. Druga rzecz… W ASE (inaczej niż w AppService) w ramach Front End Pooli mamy dedykowane nody (instancje) dla potrzeb Load Balancera. Na starcie tworzone są dwa nody wielkość P2 i jest minimum. Jeśli jednak zaczniesz skalować samo ASE, warto zwrócić uwagę na obciążenie Front End Pooli. Jeśli jest znaczne, może się okazać, że Twój backend jest wydajny ale już Twój Load Balancer nie. Czas więc go wyskalować.
- Zanim stworzysz ASE, stwórz VNET. Zawsze umieszczaj ASE w dedykowanym VNET, przygotowanym tylko dla niego.
Jedną z przewag ASE nad AppService jest to, że mamy dedykowaną sieć, w ramach której dowolnie możemy filtrować ruch. Ma to jednak swoje konsekwencje. Otóż, tworzona sieć musi:
- Być dedykowana tylko do ASE
- Musi zagwarantować min. 55 dostępnych adresów bo tyle maksymalnie instancji możemy mieć w ASE
- Powinna mieć adresację inną niż sieć dla pozostałych ASE jeśli planujesz kiedyś dostęp do wszystkich sieci przez VPN czy Express Route
Portal domyślnie i uparcie zawsze proponuje jedną konfigurację sieciową, lepiej stwórz swoją sieć i tam wrzucaj ASE. Będziesz miał pełną kontrolę. I najważniejsze: na dziś nie możemy raz stworzonego ASE przenieść do innej sieci. Taki urok, „taki feature” rzekłby klasyk więc tym bardziej trzeba planować to z głową, bynajmniej nie w chmurach.
- Czy Twoje ASE ma być dostępne z Internetu? Jeśli nie, stwórz ASE z tzw. ILB czyli Internal Load Balancerem, który nie ma publicznego adresu IP.
Jeśli budujesz apkę dla pracowników swojej firmy to zapewne publiczny adres IP nie jest Ci potrzebny. Całe rozwiązanie może być dostępny tylko przez VPN albo Express Route. Jeśli tak, wybierz ILB i stwórz prywatne rozwiązanie w chmurze publicznej. Po utworzeniu ASE nie da się tego zmienić.
- Skalowanie App Service Environment w porównaniu z App Service jest WOLNE.
Skalować ASE możesz „w górę” i „wszerz” czyli albo dodając instancję albo zwiększając poziom usługi. O ile w samym App Service instancje dodajesz szybciej, niż odświeży się portal o tyle w App Service Environment może to potrwać do 45 min. Dokumentacja mówi o 3 godzinach ale to jest sytuacja skrajna. Jak sobie z tym radzić? Klasycznie..:) Jeśli znasz zachowanie swojej aplikacji to wiesz ile instancji i kiedy potrzebujesz. Jeśli nie wiesz, no cóż, musisz się nieco przeskalować i badać zachowanie użytkowników. Żeby dobrze to ocenić, warto zrobić Load Testy, do czego świetnie w chmurze nadaje się usługa VSTS.
- Skalowanie w górę czyli zmiana wielkość instancji (np. z P1 na P3) może trwać DŁUGO.
Nie będę Cię zanudzał jak ASE zorganizowane jest „na dole”, zresztą kto chciałby o tym słuchać. Ważna informacja dla Ciebie jest taka:
- Jeśli w Twojej Worker Pooli masz 5 instancje wielkości P1 i zapragnąłeś mieć 5 instancji P2, to…
- Absolutnie nie skaluj wszystkich z P1 na P2 chyba, że masz ok. 10 godzin.
- Szybciej będzie zmniejszyć ilość instancji do 1, zamienić ją na P2, i zwiększyć na 5 instancji niż zmienić wszystkie instancje od razu na wielkość P2.
Nie pomyliłeś się – im więcej instancji tym skalowanie ich na wyższy poziom usługi zajmie więcej czasu i szybciej będzie tak, jak zaproponowałem.
I na dziś tyle. Nie popełniaj moich błędów. Zaplanuj swoje wdrożenie lepiej niż Joker.
