Preparar-se para o crescimento

Concluído

Você provavelmente já ouviu falar de que a preparação é o segredo do sucesso. Esse ditado é especialmente verdadeiro em relação ao crescimento estável, bem-sucedido e confiável.

Uma das maiores vantagens da computação em nuvem é a capacidade de dimensionar. Essa habilidade levou algumas pessoas à suposição errada de que não há necessidade de preparar nem de planejar o crescimento na nuvem, pois ela tem escala infinita.

É verdade que provavelmente existem recursos mais do que suficientes na nuvem para atender às demandas de seu aplicativo. No entanto, há alguns motivos pelos quais ainda é importante que você entenda suas necessidades de capacidade:

  • Embora provavelmente haja muitos recursos na nuvem para atender às suas necessidades, nem todos os serviços que você consome são dimensionados automaticamente ou são inerentemente escalonáveis. Portanto, você precisa estar atento aos limites de serviço e saber quando vai precisar escalar os serviços e os recursos.

  • Os recursos da nuvem podem ser ilimitados, mas seu orçamento provavelmente não é. Você precisa considerar o custo, e suas amizades no departamento de finanças desejam conhecer a previsão dos seus gastos com a nuvem.

Planejar o crescimento orgânico

O crescimento orgânico no mundo comercial refere-se ao processo pelo qual as organizações expandem sua própria capacidade, contando com recursos intrínsecos e habilidades para impulsionar um crescimento mais lento e natural.

A primeira coisa que você deve fazer ao procurar planejar a capacidade na nuvem à medida que sua empresa cresce de maneira orgânica é mapear os requisitos de recursos atuais para os componentes maiores em seu aplicativo.

Cenário: Crescimento orgânico

Vamos voltar à arquitetura que analisamos no início deste módulo. A Tailwind Traders está prestes a iniciar um novo e inovador produto e está prevendo um crescimento drástico como resultado. Apenas como lembrete, aqui está a aparência do diagrama de arquitetura:

Full architecture diagram of applications with frontend, backend and other components.

Para iniciar o planejamento de capacidade, você precisa identificar os maiores componentes. Neste exemplo que inclui:

  • Cluster do Serviço de Kubernetes do Azure
  • Aplicativo Rewards em execução no Serviço de Aplicativo do Azure
  • Vários bancos de dados, como Cosmos DB, SQL do Azure e similares.

Para cada um desses grandes componentes, você precisa entender o que é o uso atual de recursos, que ajudará a planejar o uso futuro. Vamos examinar o uso de recursos para um desses componentes grandes.

Medir a capacidade em Cosmos DB

No Cosmos DB, o armazenamento é medido em gigabytes e é escalado automaticamente, embora você ainda precise estar ciente das medidas por razões de custo.

A taxa de transferência é previamente provisionada e você utiliza uma métrica chamada Unidades de Solicitação para medi-la. As RUs (Unidades de Solicitação) são uma combinação de memória, CPU e IOPS, fornecendo uma só métrica pela qual você pode planejar a capacidade. Você provisiona RUs em incrementos de 100 RUs por segundo.

Cada operação de banco de dados é medida em RU/s. As leituras são simples: 1 KB lido é uma Unidade de solicitação individual. Outras operações são calculadas com base em vários fatores, como o tamanho do item, a coerência de dados, os padrões de consulta etc.

Quando você analisa seu aplicativo, todas as respostas do Cosmos DB contêm o cabeçalho de custo de solicitação para informar exatamente quantas RUs foram usadas. Você pode comparar o número de RUs sendo usadas ao número provisionado para verificar se você tem mais do que a capacidade atual.

É bom correlacionar o uso de recursos a uma métrica comercial, como usuários ativos mensais ou receitas. Essa correlação ajuda você a planejar a capacidade de acordo com a forma como espera que a empresa cresça. Você pode recuperar essas métricas de capacidade em Azure Monitor. Entender o uso de recursos do sistema ajuda você a saber quando precisará realizar a escala vertical e quais serão os custos ao longo do tempo.

Vamos ser objetivos e examinar os dados da Tailwind Traders usando o Cosmos DB. Este é um grafo do uso deles.

Graph of usage over time with users on the Y axis and months on the X axis, graph shows 2530 users in July and rises until 10081 users in October

Neste exemplo, o Tailwind Traders está crescendo em uma média de 2.500 usuários ativos mensais (MAUs), com uma base de usuários atual de 10.000.

Se analisamos o armazenamento, podemos ver que o banco de dados deles está usando 300 GB dos 5 TB disponíveis (6%). Ele está crescendo a 1% ou 50 GB/mês.

Graph of storage over time with storage amounts on the Y axis and months on the X axis, graph shows two lines, one for storage at 151 in July and ending at 300 for October, the other for capacity which is flat at 5000 for all months

Do ponto de vista da taxa de transferência, ela está localizada em 300/1000 e crescendo em 10%/mês:

Graph of throughput over time with RUs on the Y axis and months on the X axis, graph shows two lines, one for storage at 0 in July and ending at 300 for October, the other for provisioned RUs which is flat at 1000 for all months

Agora que entendemos as métricas de recursos dos sistemas, sabemos quando provavelmente precisaremos expandir a taxa de transferência e quais serão os custos ao longo do tempo.

Agora podemos produzir um grafo que nos ajuda com o planejamento da capacidade.

Graph of RUs over time with RUs on the Y axis and months on the X axis. The graph shows two lines. One for storage at 0 in July and ending at 1000 next may. The other for capacity, which is flat at 1000 for all months. The two lines intersect at 1000 and there's an arrow emphasizing their intersection point.

Agora sabemos que em maio vamos atingir a capacidade de RUs em nosso banco de dados e, portanto, precisaremos escalá-lo antes disso. Outro insight interessante é que eles podem até reduzir o banco de dados do Cosmos DB nesse momento, pois não estão nem perto da capacidade previamente provisionada.

Planejar o crescimento inorgânico

No exemplo anterior, você estava planejando o crescimento orgânico. O crescimento inorgânico surge de fatores externos em vez de um aumento nas atividades comerciais da própria empresa. Em vez de ser uma progressão natural, ele tende a envolver um aumento mais repentino e maior no uso.

Às vezes, você realmente não sabe com antecedência sobre um aumento no tráfego, usuários e assim por diante. Para prevenir esses casos, você precisa criar seu sistema para ser o mais escalonável possível automaticamente e para falhar normalmente quando isso não for possível. Abordaremos isso mais tarde neste módulo.

Em outros momentos, assim como acontece com um próximo lançamento de produto, você pode enfrentar um crescimento inorgânico para o qual pode planejar e se preparar. Se as suas equipes trabalham juntas em engenharia, produto, marketing e finanças, e você sabe como obter os padrões de crescimento e uso de recursos. Você pode fazer um esforço razoável para prever o impacto desses eventos nos seus requisitos de recursos e implementar as alterações de acordo.

Acertar essa previsão é específico da sua organização e do evento em particular. Você pode nem sempre acertar, mas estar o mais preparado possível será uma vantagem.

Cenário: Crescimento inorgânico

Vamos analisar outra situação hipotética como exemplo de planejamento para crescimento inorgânico: Há um próximo evento de marketing para o lançamento de um novo produto inovador de alto perfil na Tailwind Traders. Eles estão esperando direcionar mais cinco mil usuários para o site de vendas.

Usando os dados do exemplo anterior de crescimento orgânico e correlacionando-os (esperamos que com causalidade) a uma métrica de negócios obtida das suas equipes de produto/marketing (por exemplo, número de usuários). Você poderá começar a planejar o crescimento inorgânico.

Você sabe, com base no cenário anterior, que, para 2.500 usuários, você precisa de aproximadamente 50 GB de armazenamento e 100 RUs. Agora você pode usar esses dados e determinar se está pronto para este evento. Se pudermos esperar cinco mil usuários, isso exigirá 100 GB de armazenamento de 200 RU/s.

Graph of storage usage over time with storage units on the Y axis and months on the X axis. The graph shows two lines. One for storage at 151 in July and ending at 400 in November, and the other for capacity that is flat at 5000 for all months. There's an arrow labeled with 'After marketing event' pointing at the November data point.

Podemos ver que as capacidades de armazenamento são mais do que suficientes para o crescimento esperado com o evento. Essas capacidades são escaladas automaticamente para você, ou seja, não há nenhuma preocupação, exceto entender os novos custos, que serão abordados mais tarde.

Você também pode prever que as RUs atingirão apenas 50% de capacidade após o evento. Portanto, eles não têm preocupações em termos de capacidade do Cosmos DB para esse evento.

No entanto, haverá um impacto no custo.

Bar Graph with three sets of bars: Storage, Throughput, and Total. The Y axis shows dollar amounts. For each set, there's a bar for before event (USD) and a bar for after event (USD). The values are 75 and 100 for Storage, 59.52 and 59.52 for Throughput, and 134.52 and 159.52 for total.

Você pode ver que os 100 GB de armazenamento extra custarão um adicional de US$ 25/mês. O preço da taxa de transferência permanece o mesmo que os clientes pagam por RUs provisionadas, e eles já têm mais do que o suficiente. Resumindo: esse evento de marketing provavelmente aumentará sua fatura do CosmosDB em US$ 25.

Verificar seu conhecimento

1.

Quando uma empresa expande a capacidade de modo mais natural e previsível, ela é chamada:

2.

Com o Cosmos DB, quais destas métricas são incorporadas em uma unidade de solicitação?

3.

Quais das opções a seguir não são uma métrica comercial que você deve correlacionar o uso de recursos ao planejar a capacidade?