Przygotowanie do wzrostu
Prawdopodobnie wiesz, że przygotowanie jest kluczem do sukcesu. To powiedzenie jest szczególnie prawdziwe w odniesieniu do płynnego, udanego, niezawodnego wzrostu.
Jedną z największych zalet chmury obliczeniowej jest możliwość skalowania. Ta zdolność doprowadziła do błędnego założenia, że nie ma potrzeby przygotowania ani zaplanowania wzrostu w chmurze, ponieważ ma nieskończoną skalę.
Jest to prawda, że w chmurze istnieje najprawdopodobniej znacznie więcej zasobów, niż wymaga aplikacja. Istnieje jednak kilka powodów, dla których nadal ważne jest zrozumienie potrzeb związanych z pojemnością:
Mimo że w chmurze istnieje prawdopodobnie duża ilość zasobów, które spełniają Twoje potrzeby, nie wszystkie używane usługi są automatycznie skalowane lub są z natury skalowalne. W związku z tym należy pamiętać o limitach usług i wiedzieć, kiedy będzie konieczne skalowanie usług i zasobów w górę.
Zasoby w chmurze mogą być nieograniczone, ale budżet prawdopodobnie nie jest. Musisz wziąć pod uwagę koszty, a twoi przyjaciele w dziale finansów chcą znać przewidywane wydatki na chmurę.
Planowanie pod kątem wzrostu organicznego
Wzrost organiczny w świecie biznesowym dotyczy procesu, w którym organizacje rozszerzają swoją własną wydajność, polegając na zasobach i umiejętnościach wewnętrznych, aby napędzać wolniejszy, naturalniejszy wzrost.
Pierwszym krokiem, który należy wykonać w celu zaplanowania pojemności w chmurze w miarę organicznego wzrostu firmy, jest zamapowanie bieżących wymagań dotyczących zasobów dla większych składników w aplikacji.
Scenariusz: Wzrost organiczny
Wróćmy do architektury, która została omówiona na początku tego modułu. Firma Tailwind Traders ma na celu uruchomienie innowacyjnego nowego produktu i przewiduje w rezultacie dramatyczny wzrost. Aby przypomnieć, oto jak wygląda ich diagram architektury.
Aby rozpocząć planowanie pojemności, należy zidentyfikować większe składniki. W tym przykładzie, który obejmuje:
- Klaster usługi Azure Kubernetes Service;
- Aplikacja Rewards uruchomiona w usłudze aplikacja systemu Azure Service
- różne bazy danych, takie jak Cosmos DB, Azure SQL i podobne.
Dla każdego z tych dużych składników należy poznać bieżące użycie zasobów, aby ułatwić planowanie użycia w przyszłości. Przyjrzyjmy się użyciu zasobów dla jednego z tych dużych składników.
Mierzenie pojemności w usłudze Cosmos DB
W usłudze Cosmos DB magazyn jest mierzony w gigabajtach i skaluje się automatycznie, chociaż nadal trzeba pamiętać o pomiarach ze względów kosztów.
Przepływność jest wstępnie aprowizowana i używasz metryki o nazwie Jednostki żądań, aby zmierzyć tę przepływność. Jednostki żądań (RU) to kombinacja pamięci, procesora CPU i liczby operacji we/wy na sekundę, zapewniając pojedynczą metrykę, za pomocą której można zaplanować pojemność. Aprowizujesz jednostki RU w przyrostach 100 jednostek RU na sekundę.
Każda operacja bazy danych jest mierzona w jednostkach RU/s. Odczyty są proste: odczyt 1 KB jest pojedynczą jednostką żądania. Inne operacje są obliczane na podstawie kilku czynników, takich jak rozmiar elementu, spójność danych, wzorce zapytań itd.
Podczas profilowania aplikacji każda odpowiedź z usługi Cosmos DB zawiera nagłówek opłaty za żądanie, informując o dokładnie liczbie jednostek RU używanych przez żądanie. Możesz porównać liczbę jednostek RU używanych do liczby aprowizowanej, aby sprawdzić, czy masz więcej niż wystarczającą bieżącą pojemność.
Dobrym sposobem jest skorelowanie użycia zasobów z metryką biznesową, taką jak Aktywni użytkownicy miesięcznie lub Przychody. Ta korelacja pomaga zaplanować pojemność w zależności od tego, jak oczekujesz rozwoju firmy. Te metryki pojemności można pobrać w usłudze Azure Monitor. Zrozumienie użycia zasobów systemu pomaga wiedzieć, kiedy trzeba będzie skalować w górę i jakie koszty będą w czasie.
Przyjrzyjmy się konkretnym danym z użycia usługi Cosmos DB przez firmę Tailwind Traders. Oto wykres użycia.
W tym przykładzie firma Tailwind Traders odnotowuje średni przyrost o 2500 aktywnych użytkowników miesięcznie (MAU) z bieżącą bazą użytkowników na poziomie 10 000.
Jeśli spojrzymy na magazyn, możemy zobaczyć, że ich baza danych używa 300 GB dostępnego rozmiaru 5 TB (6%). Rośnie o 1% lub 50 GB/miesiąc.
Z perspektywy przepływności znajduje się on na poziomie 300/1000 i rośnie o 10%/miesiąc:
Teraz, gdy rozumiemy nasze metryki zasobów systemów, wiemy, kiedy prawdopodobnie będziemy musieli skalować przepływność, a także jakie będą koszty w czasie.
Teraz możemy utworzyć wykres, który pomaga nam w planowaniu pojemności.
Teraz wiemy, że w maju osiągniemy pojemność jednostek RU w naszej bazie danych, więc musimy przeprowadzić skalowanie wcześniej. Jedną z innych interesujących informacji jest to, że mogą nawet skalować bazę danych Cosmos DB w dół teraz, ponieważ nie używają nigdzie w pobliżu wstępnie aprowizowanej pojemności.
Planowanie pod kątem wzrostu nieorganicznego
W poprzednim przykładzie planowaliśmy wzrost organiczny. Wzrost nieorganiczny powstaje ze względu na czynniki zewnętrzne, a nie z powodu wzrostu w zakresie własnej działalności firmy. Nie jest to naturalny postęp. Zamiast tego ten proces obejmuje bardziej gwałtowny, większy wzrost użycia.
Czasami naprawdę nie wiesz z wyprzedzeniem o wzroście ruchu, użytkowników itd. W oczekiwaniu na takie przypadki należy utworzyć system tak skalowalny, jak to możliwe automatycznie i bezpiecznie zakończyć się niepowodzeniem, gdy nie jest to możliwe. W dalszej części tego modułu omówimy ten problem.
W innych przypadkach, podobnie jak w przypadku nadchodzącego uruchomienia produktu, możesz doświadczyć nieorganicznego wzrostu, dla którego można zaplanować i przygotować. Jeśli twoje zespoły współpracują ze sobą w zakresie inżynierii, produktu, marketingu i finansów, i wiesz, jak uzyskać wzorce użycia zasobów i wzrostu. Możesz podjąć rozsądny wysiłek, aby przewidzieć wpływ tych zdarzeń na wymagania dotyczące zasobów i odpowiednio wdrożyć zmiany.
Uzyskanie tego prawa jest specyficzne dla twojej organizacji i konkretnego zdarzenia. Możesz nie zawsze dostać to dobrze, ale jest tak przygotowany, jak można być daje head start.
Scenariusz: Wzrost nieorganiczny
Przyjrzyjmy się innej hipotetycznej sytuacji jako przykładu planowania wzrostu nieorganicznego. Istnieje nadchodzące wydarzenie marketingowe na potrzeby wprowadzenia innowacyjnego nowego produktu o wysokim profilu w firmie Tailwind Traders. Oczekuje się, że będzie to 5000 kolejnych użytkowników w swojej witrynie sprzedaży.
Korzystając z danych z poprzedniego przykładu wzrostu organicznego i korelując je, miejmy nadzieję, z przyczyną, do metryki biznesowej uzyskanej od zespołów produktu/marketingu (na przykład liczby użytkowników). Można zacząć planować wzrost nieorganiczny.
Wiesz w poprzednim scenariuszu, że dla 2500 użytkowników potrzebujesz około 50 GB miejsca do magazynowania i 100 jednostek RU. Możesz teraz użyć tych danych i określić, czy wszystko zostało przygotowane do wydarzenia. Jeśli możemy oczekiwać 5000 użytkowników, będzie to wymagało 100 GB miejsca do magazynowania i 200 RU/s.
Widzimy, że pojemność magazynu jest większa niż wystarczająca dla wzrostu oczekiwanego od zdarzenia. Te pojemności są skalowane automatycznie, więc nie ma tu obaw, z wyjątkiem zrozumienia nowych kosztów, które są rozwiązywane później.
Można również przewidzieć, że ich jednostki RU osiągną tylko 50% pojemności po zdarzeniu. W związku z tym nie mają obaw dotyczących pojemności usługi Cosmos DB dla tego zdarzenia.
Jednak wydarzenie będzie miało wpływ na koszty.
Widać, że 100 GB dodatkowego miejsca do magazynowania będzie kosztować dodatkowe 25 USD miesięcznie. Cena przepływności pozostaje taka sama, jak klienci płacą za aprowizowane jednostki RU i mają już więcej niż wystarczająco dużo. Najważniejsze jest to, że to wydarzenie marketingowe prawdopodobnie zwiększy swój rachunek za usługę CosmosDB o 25 USD.