Preparar-se para o crescimento

Concluído

Já deve ter ouvido dizer que a preparação é a chave para o sucesso. Este ditado é especialmente verdadeiro em relação ao crescimento suave, bem-sucedido e confiável.

Uma das maiores vantagens da computação na cloud é a sua capacidade de dimensionamento. Essa capacidade levou alguns à suposição errônea de que não há necessidade de se preparar ou planejar o crescimento na nuvem porque ela tem escala infinita.

É verdade que muito provavelmente há recursos mais do que suficientes na cloud para satisfazer as necessidades da sua aplicação. No entanto, há algumas razões pelas quais ainda é importante para você entender suas necessidades de capacidade:

  • Embora existam provavelmente muitos recursos na cloud para satisfazer as suas necessidades, nem todos os serviços que consome são dimensionados automaticamente ou são inerentemente dimensionáveis. Assim, você precisa estar ciente dos limites de serviço e saber quando precisará escalar serviços e recursos.

  • Os recursos da nuvem podem ser ilimitados, mas o seu orçamento provavelmente não é. Você tem que considerar o custo, e seus amigos no departamento financeiro querem saber seu gasto previsto na nuvem.

Planear um crescimento orgânico

O crescimento orgânico no mundo empresarial refere-se ao processo através do qual as organizações expandem a sua própria capacidade, contando com recursos e competências intrínsecas para fomentar um crescimento mais lento e natural.

A primeira coisa que deve fazer quando tenta planear a capacidade na cloud à medida que a sua empresa cresce organicamente é mapear os requisitos de recursos atuais aos componentes maiores da sua aplicação.

Cenário: Crescimento orgânico

Vamos voltar à arquitetura que revisamos no início deste módulo. Tailwind Traders está prestes a lançar um novo produto inovador, e está antecipando um crescimento dramático como resultado. Apenas para lembrá-lo, aqui está como é o diagrama de arquitetura deles.

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

Para começar a planear a capacidade, tem de identificar os componentes maiores. Neste exemplo, isso inclui:

  • Cluster do Azure Kubernetes Service
  • Aplicativo de recompensas em execução no Serviço de Aplicativo do Azure
  • Várias bases de dados, tais como Cosmos DB, Azure SQL, etc.

Para cada um destes grandes componentes, é necessário conhecer a utilização atual do recurso para o ajudar a planear uma utilização futura. Vamos analisar o uso de recursos para um desses grandes componentes.

Medir a capacidade no Cosmos DB

No Cosmos DB, o armazenamento é medido em gigabytes e dimensionado automaticamente, embora você ainda precise estar ciente das medições por motivos de custo.

A taxa de transferência é pré-provisionada e você usa uma métrica chamada Unidades de Solicitação para medir essa taxa de transferência. As unidades de solicitação (RUs) são uma mistura de memória, CPU e IOPS, oferecendo uma única métrica pela qual você pode planejar a capacidade. Você provisiona RUs em incrementos de 100 RUs por segundo.

Todas as operações de base de dados são medidas em RU. As leituras são simples: 1 KB de leitura é uma única unidade de solicitação. Outras operações são calculadas com base em vários fatores, como tamanho do item, consistência de dados, padrões de consulta e assim por diante.

Quando você cria o perfil do seu aplicativo, cada resposta do Cosmos DB contém o cabeçalho de cobrança de solicitação, informando exatamente quantos RUs essa solicitação usou. Você pode comparar o número de RUs que estão sendo usados com o número que são provisionados para verificar se você tem capacidade atual mais do que suficiente.

É bom correlacionar a sua utilização de recursos com uma métrica empresarial, por exemplo, utilizadores ativos mensais ou receitas. Essa correlação ajuda você a planejar a capacidade com base em como você espera que o negócio cresça. Pode obter estas métricas de capacidade no Azure Monitor. Compreender o uso de recursos do sistema ajuda você a saber quando precisará aumentar a escala e quais serão seus custos ao longo do tempo.

Vamos ser concretos e olhar para os dados do uso do Cosmos DB pela Tailwind Traders. Aqui está um gráfico de seu uso.

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, os utilizadores da Tailwind Traders estão a aumentar a uma média de 2500 utilizadores ativos mensais (MAUs) com uma base de utilizadores atual de 10 000.

Se olharmos para o armazenamento, podemos ver que seu banco de dados está usando 300 GB dos 5 TB disponíveis (6%). Está a crescer 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, está em 300/1000 e crescendo a 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 nossas métricas de recursos de sistemas, sabemos quando provavelmente teremos que escalar nossa taxa de transferência e também quais serão nossos custos ao longo do tempo.

Agora podemos produzir um gráfico que nos ajuda com o planejamento de 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, então precisamos escalar antes disso. Uma outra perceção interessante é que eles poderiam até reduzir seu banco de dados do Cosmos DB agora, pois não estão usando nem perto da capacidade pré-provisionada.

Planear um crescimento inorgânico

No exemplo anterior, você estava planejando o crescimento orgânico. O crescimento inorgânico resulta de fatores externos e não de um aumento das próprias atividades comerciais da empresa. Em vez de ser uma progressão natural, tende a envolver um aumento mais súbito e maior em termos de utilização.

Às vezes, você realmente não sabe com antecedência sobre um aumento no tráfego, usuários e assim por diante. Em antecipação a esses casos, você precisa construir seu sistema para ser o mais escalável possível automaticamente, e falhar graciosamente quando isso não for possível. Abordaremos isso mais adiante neste módulo.

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

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

Cenário: Crescimento inorgânico

Vejamos outra situação hipotética como exemplo de planeamento para o 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 esperam que isso direcione mais 5000 usuários para seu site de vendas.

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

Você sabe, pelo cenário anterior, que para 2500 usuários você precisa de aproximadamente 50 GB de armazenamento e 100 RUs. Pode agora utilizar esses dados e determinar se está pronto para este evento. Se pudermos esperar 5000 usuários, isso exigirá 100 GB de armazenamento e 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 do evento. Essas capacidades são dimensionadas automaticamente para você, então não há nenhuma preocupação aqui, exceto para entender os novos custos, que serão abordados mais tarde.

Você também pode prever que seus RUs só atingem 50% da capacidade após o evento. Então, eles não têm preocupações em termos de capacidade do Cosmos DB para este evento.

No entanto, haverá um impacto nos custos.

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 vai custar um extra de US $ 25 / mês. O preço da taxa de transferência permanece o mesmo que os clientes pagam pelas RUs provisionadas, e eles já têm mais do que o suficiente. A conclusão é que este evento de marketing provavelmente aumentará sua conta do CosmosDB em US$ 25.

Verifique o seu conhecimento

1.

Quando uma empresa expande a sua própria capacidade de uma forma mais natural e previsível, chama-se:

2.

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

3.

Qual das seguintes opções não é uma métrica de negócio com a qual deve correlacionar a utilização dos seus recursos ao planear a capacidade?