Qual instância usar?

[Filipe Martins]

Bom dia comunidade! 

Estou desenvolvendo uma ferramenta que derá contar com alguns picos de uso diário (algo em torno de 400 acessos/requisições simultânea). Irei utilizar AWS para hospeda-la, qual instância me recomendam? Devo separar o banco de dados? A Plataforma não pode contar com instabilidade de maneira alguma durante esses picos.

Front/Backend em Django e Banco de Dados PostgreSQL

[Filipe Cifali]

Procure pela família T, "burstable", se você não tem a mínima idéia de consumo, talvez seja melhor optar por algum serviço com uso de Fargate, ECS ou EKS com Fargate para não se preocupar com o provisionamento.

Agora, "não pode contar com instabilidade" é besteira, crie o sistema para não só contar, como sobreviver a instabilidade, auto-scaling só funciona depois que você entende o comportamento da aplicação e pode configurar ele corretamente, nada nunca vai sobreviver a essa idéia.

E sim, separe o banco em um RDS, e pense sobre multi-az ou mesmo sobre cluster do banco, a depender do que você quer atingir de SLA.

--
Você recebeu essa mensagem porque está inscrito no grupo "Django Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para django-brasi...@googlegroups.com.
Para ver esta conversa, acesse https://groups.google.com/d/msgid/django-brasil/9700eda9-4b6e-4d3d-a288-b447fb0444b9n%40googlegroups.com.

--

[ ]'s

Filipe Cifali Stangler

[Rodrigo Otavio Passos Ferreira]

Dificil mensurar antes de ver o uso..

Tem muita escrita no banco? consultas pesadas? pensou em usar filas pra evitar perdas nesses momentos de grande volume? 

Se quiser ter uma métrica mais confiável, sugiro que faça uns testes de carga (https://locust.io/ é uma boa ferramenta pra isso), com algumas VM's ou Docker com recursos limitados pra ver como se comporta em alta carga. Pra não superdimensionar e gastar mais nem ficar na mão gastando mto pouco.

 

Para ver esta conversa, acesse https://groups.google.com/d/msgid/django-brasil/CAB5KUKuQm6r5SB7562JVKM9ERNjBrDgU2dDSinirQObwauje1Q%40mail.gmail.com.

[Flávyo Henrique]

Por mais que pareça grande a quantidade de requisição não é um número alto.

O que vai definir o tipo de instância, é o que a sua aplicação consome/faz, por exemplo, se ela faz uso intenso de rede, precisa procurar uma instância que dá mais throughout alto e uma rede mais rápida, se usa mais memória uma com acesso mais rápido, se usa muito disco, uma com um disco de leitura mais rápido.

Recomendo ler sobre os tipos de instância da aws e fazer um teste de stress da sua aplicação antes de colocar em produção, senão sabe por onde começar, usa instância da classe T que são de propósito geral e vai testando a que mais se adequa a você.

Sobre não cair a aplicação, vc precisa de um loadbalancer, ele vai ficar monitorando e escalando a sua aplicação de acordo com o que vc precisa, só precisa configurar ele certinho.

Dependendo do que a sua aplicação faz, como ela foi programada, uma única instância da classe T4 já vai atender 400 requisição com folga, mais para ter alta disponibilidade nunca suba menos que 2 instância.

--

[Lauro Cesar de Oliveira]

Bom dia Filipe.

Sugiro antes de partir para um setup que possa doer no bolso, fazer um
profiling do teu frontend e comparar com o profiling do backend.

Assim terá uma idéia mais ou menos exata do custo de cada requisição,
inclusive já possivelmente apontando os bottlenecks.

Eu faria o seguinte, para início de conversa:

- Rodaria um teste paralelo de 400 reqs, usando playwright com
tracing configurado para gerar screenshots e snapshots (vai criar um
trace.zip no final)
- Faria o servidor web reportar o seu status via server-status (apenas
para monitorar a disponibilidade)
- durante o teste com o playwright, iria consultar o server-status a
cada xx segundos

Com esse teste básico tu já terias os números para decidir qual instância usar.

Bom, espero ter dado uma luz ai, pois fica difícil recomendar qual a
instância sem saber realmente qual a carga da tua aplicação.

Sucesso ai, e qualquer coisa estamos aqui para ajudar.

On Tue, Feb 4, 2025 at 9:07 AM Filipe Martins <fmar...@gmail.com> wrote:
>