Przygotowanie do wzrostu

Prawdopodobnie słyszałeś powiedzenie, ż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 przetwarzania w chmurze jest możliwość skalowania. Ta zdolność doprowadziła niektórych do błędnego założenia, że nie ma potrzeby przygotowywania się ani planowania wzrostu zasobów w chmurze, gdyż ma ona nieskończoną skalę.

Prawdą jest, że w chmurze jest najprawdopodobniej więcej niż wystarczająca ilość zasobów, aby spełnić wymagania aplikacji. Istnieje jednak kilka powodów, dla których nadal ważne jest zrozumienie potrzeb związanych z pojemnością:

• Chociaż w chmurze jest prawdopodobnie wiele zasobów, które spełniają Twoje potrzeby, nie wszystkie usługi, które wykorzystujesz, skalują się automatycznie lub są z założenia 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 wzrostu organicznego

Organiczny wzrost w świecie biznesu odnosi się do procesu, w którym organizacje rozszerzają własną zdolność, opierając się na zasobach i umiejętnościach wewnętrznych, aby napędzać wolniejszy, bardziej naturalny wzrost.

Pierwszą rzeczą, którą należy wykonać podczas planowania pojemności w chmurze w miarę rozwoju firmy w sposób organiczny, jest zmapowanie 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 Azure App Service
• Różne bazy danych, takie jak Cosmos DB, Azure SQL i podobne.

Dla każdego z tych dużych składników musisz zrozumieć, jakie jest bieżące użycie zasobów, aby ułatwić planowanie przyszłego użycia. 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ść. Przydzielasz jednostki RU w przyrostach po 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ę używanych jednostek RU do liczby przypisanej, w celu upewnienia się, że bieżąca pojemność jest wystarczająca.

Dobrze jest skorelować użycie zasobów z metryką biznesową, taką jak miesięczni aktywni użytkownicy 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 rozszerzać skalę działania i jakie koszty będą na przestrzeni czasu.

Przyjrzyjmy się konkretnym danym z użycia usługi Cosmos DB przez firmę Tailwind Traders. Oto wykres użycia.

W tym przykładzie Tailwind Traders rośnie średnio o 2500 miesięcznych aktywnych użytkowników (MAU), mając bieżącą bazę użytkowników wynoszącą 10 000.

Jeśli przyjrzymy się przechowywaniu, możemy zobaczyć, że ich baza danych używa 300 GB z dostępnych 5 TB (6%). Rośnie o 1% lub 50 GB/miesiąc.

Z perspektywy przepustowości wynosi ona 300/1000 i rośnie o 10%miesięcznie.

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 teraz mogą nawet zmniejszyć skalę bazy danych Cosmos DB, ponieważ nie używają w pełni wstępnie ustalonej pojemności.

Planowanie wzrostu nieorganicznego

W poprzednim przykładzie planowaliśmy wzrost organiczny. Wzrost nieorganiczny wynika z czynników zewnętrznych, a nie wzrostu własnej działalności biznesowej firmy. Zamiast być naturalnym postępem, zwykle wiąże się to z nagłym i większym wzrostem użycia.

Czasami naprawdę nie wiesz z wyprzedzeniem o wzroście ruchu, użytkowników itd. Aby przygotować się na takie przypadki, należy zbudować system, który automatycznie będzie jak najbardziej skalowalny i w razie potrzeby bezpiecznie zakończy działanie. 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, na który możesz się przygotować i zaplanować. 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 zrobić coś dobrze, ale bycie jak najlepiej przygotowanym daje ci przewagę na starcie.

Scenariusz: Wzrost nieorganiczny

Przyjrzyjmy się innej hipotetycznej sytuacji jako przykładu planowania wzrostu nieorganicznego. Odbędzie się nadchodzące wydarzenie marketingowe z okazji wprowadzenia ważnego, innowacyjnego nowego produktu w firmie Tailwind Traders. Oczekują, że to przyciągnie 5000 kolejnych użytkowników do ich witryny sprzedażowej.

Korzystając z danych z poprzedniego przykładu wzrostu organicznego i korelując je, miejmy nadzieję, z przyczynowością, do metryki biznesowej, którą uzyskano od zespołów produktowych i marketingowych (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. Teraz możesz użyć tych danych i określić, czy jesteś gotowy do tego zdarzenia. 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ści magazynowe są więcej niż wystarczające dla wzrostu oczekiwanego w związku z wydarzeniem. Te pojemności są skalowane automatycznie, więc nie ma tu obaw, poza koniecznością zrozumienia nowych kosztów, które zostaną omówione później.

Można również przewidzieć, że ich jednostki RU osiągną jedynie 50% pojemności% po zdarzeniu. A więc nie mają obaw dotyczących pojemności usługi Cosmos DB na to wydarzenie.

Jednak będzie to miało wpływ na koszty.

Widać, że 100 GB dodatkowego miejsca do magazynowania będzie kosztować dodatkowe 25 USD miesięcznie. Cena przepustowości pozostaje taka sama, ponieważ klienci płacą za zaprovisionowane jednostki RU, a mają ich już więcej niż potrzeba. W skrócie, to wydarzenie marketingowe prawdopodobnie zwiększy ich rachunek za usługę CosmosDB o 25 USD.