-
Notifications
You must be signed in to change notification settings - Fork 401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vídeo de lançamento conseguiu derrubar a API (mais ou menos) 🤝 #826
Comments
Acho que realmente estamos com instabilidade no servidor devido a quantidade de acessos! Parece que chegamos no limite da Vercel para o plano utilizado, ou do DB. Precisamos analisar os logs para achar onde foi o gargalo! Mas é normal pelo tamanho que o Canal possui, sabia que algo assim poderia acontecer. |
Pior que se for se basear pela página Status, o site está saudável, com conexões ainda disponíveis e latência baixa:
|
@filipedeschamps consegue acessar o status direto do banco no painel de controle? Com certeza chegamos no limite lá! Podemos criar uma página estática explicando que o projeto está em fase de desenvolvimento etc... com talvez até um vídeo explicativo. Como uma SALA de espera até o número de conexões normalizar. Vai liberando os acessos conforme o fluxo do banco. Ou isso ou subir o plano do banco de dados 😅️ |
Subestimou o poder do canal 😅️ |
Esse é o preço do conhecimento hehehe. Mas acho que essa experiência traz insights valiosos que você pode adicionar no curso! Além disso, pode servir para definir uma métrica norte que guiará os próximos passos do projeto, para continuar algo viável. |
To pensando aqui em como conseguir tirar a API do ar sem afetar muito o site, pois se ela não está usável e só gerando custos, isso é uma situação ruim de se colocar. |
Vejo que tem algumas issues sendo abertas referente ao problema que está sendo discutido aqui, não seria melhor deixar está issue em pinned ? |
Quais são os serviços que estão sendo usados no momento? Digo qual serviço e para qual finalidade? Talvez possamos repensar algumas estratégias não ? |
Poderia colocar quais serviços e os valores pagos, para termos uma noção de custos com o projeto. |
Sobre o banco em São Paulo ou Norte da Virgínia... Em SP é o dobro do preço, né? Só que se mudar o local do banco, é melhor mudar também as lambdas da Vercel para a mesma região. No uso normal do sistema só seria perceptível um pequeno aumento na latência ao publicar ou votar nos conteúdos e no cadastro/login. Na navegação pelos conteúdos das primeiras páginas (relevantes ou recentes) não deve ser percebida nenhuma diferença por causa do cache na CDN da Vercel. Outra questão sobre o banco... Como está a utilização da instância nos últimos dias? Com as otimizações e com a proteção da Cloudflare, ainda é necessário manter essa instância com mais memória? Só mudou a quantidade de memória, né? Se estiver muito subutilizada, talvez compense voltar para a anterior. |
Vou colocar aproximadamente o que eu lembro e daí o @filipedeschamps complementa ou corrige se eu errar algo (valores mensais): Vercel = não sei como ficará com a parceria (era $40 antes do lançamento). Posso estar esquecendo de algo [Edit] Corrigi os valores do banco, pois tinha calculado com proxy |
Vou tabelar abaixo assim que confirmar com o @filipedeschamps atualizo os valores, tudo mensal?
|
Então são vocês que estão "afundando os demais que estão hospedado". Brincadeira a parte, sugiro uma campanha para apoiar a causa, seguido com uma boa explicação. Aviso seja dado no YouTube, Discord (não oficial), e-mail e no próprio Tabnews (com dialog se possível). [Tip] [Em tradução livre] Fonte: https://www.vercel-status.com/
|
Fiz uma publicação bem grande sobre o estado atual do TabNews e os próximos passos: https://www.tabnews.com.br/filipedeschamps/tabnews-atinge-1-5-milhoes-de-views-e-futuro-do-projeto-alerta-de-textao E conectado ao assunto sobre redução de custo, estava pensando: agora que temos rate-limit direto pela Cloudflare, será que vale a pena removermos a Upstash? Com a Upstash conseguimos fazer um rate-limit customizado por endpoint, coisa que nossa conta atual da Cloudflare não permite (só podemos criar 2 regras). Mas ao mesmo tempo, nossa regra na Cloudflare está com um limite que eu considero baixo e suficiente para barrar e cobrir ataques, sem deixar eles escalarem para um problema maior: Especulo que conseguimos baixar ainda mais e ainda assim fornecer uma API saudável para qualquer O que acham? |
Sobre não passar pelo Upstash todos os endpoints, acho que agora dá pra fazer isso tranquilamente! Mas não tem nenhum custo fixo e pagamos apenas conforme o uso, certo? Se for isso mesmo, poderia por enquanto manter os códigos e configurações apenas de stand-by para ser mais fácil de voltar a direcionar para o Redis algum endpoint que precisar de atenção especial. |
Nao daria para adicionar isso como feature toggle ? E caso precise , ligar ela ? |
Correto, o pagamento é conforme o uso 🤝 Sobre as variáveis de ambiente, podemos deixar lá total. Sobre a parte do código, como podemos fazer esse controle? O que acha de na variável |
@augustoresende conforme combinado, estou removendo os comentários aqui nessa issue, e caso queira conversar de forma privada em [email protected] para calibrarmos uma segunda publicação lá no TabNews, me coloco a 100% de disposição para lhe ajudar, inclusive eu ficaria extremamente feliz que isso acontecesse, combinado? 🤝 |
O middleware vai permanecer pegando todos os caminhos, certo? Talvez só adicionar algo assim, lá após o condicional que verifica o host: const listaDeCaminhosLimitados = []
if (!listaDeCaminhosLimitados.includes(request.nextUrl.pathname)) {
return NextResponse.next();
} E se for necessário voltar algum endpoint para o Upstash, é só adicionar no array. |
Hmm interessante, eu estava pensando em adicionar uma condicional aqui para verificar por aquela chave/feature flag: tabnews.com.br/infra/rate-limit.js Lines 7 to 11 in 9ab4433
Daí não precisaria mexer em código, seria só em variável de ambiente e forçar um novo deploy. [edit] mas também não vai dar certo, pois vamos aumentar o escopo do |
A |
No PR #1101 fiz uma sugestão de implementação. Retirei o Com isso, só para teste, essa versão está com rate-limit do Upstash também no caminho |
Daria para implementar esse carinha aqui : https://www.getunleash.io Assim vc tem um painel para ativar/desativar features. Tem plano free para Open Source S2 |
Legal esse serviço @CarlosZiegler, mas acho que é muito além do que o necessário para voltar a habilitar o rate-limit do Upstash em algum endpoint específico, se é que vamos precisar fazer isso. Talvez eu não tenha entendido a melhor maneira de utilizá-lo, pois teríamos que consultar ao Unleash em todas as requisições para verificar se é o caso ou não de passar pelo Upstash. Então, se entendi direito, vai aumentar o custo ou a latência, ou mesmo os dois. |
Então a ideia seria usa run variável de ambiente para ligar/desligar a feature de rate limit ou algo mais crítico, porém essa ferramenta ajuda em demais feature para caso aconteça um pico conseguir desligar features críticas ou algo nesse sentido, como consumo de uma determinada api ou desabilitar comentário etc... |
Turma, para dar um desfecho sobre o estorno da multa, a Vercel confirmou que não irá estornar e o patrocínio vale somente daqui para frente 🤝 |
Acompanho o projeto desde o início e gostaria de ter conseguido participar mais. Peço desculpas se esses pontos já foram discutidos anteriormente, mas dado o cenário atual, e mesmo considerando o patrocinio da Vercel, gostaria de deixar algumas sugestões, pensando na infraestrutura mais a longo prazo. Sobre o banco SQL - o AWS RDS é robusto (talvez o mais de todos serviços), porém tem algumas desvantagens principalmente quando usado com uma aplicação Serverless. Não sei exatamente como está configurado no caso do TabNews, mas independente disso, mesmo com tudo que a AWS lançou nos últimos anos (Aurora Serverless V2, RDS Proxy, etc), continua não sendo minha primeira opção. Minha sugestão aqui seria substituir por um serviço de banco SQL voltado para serverless, como o PlanetScale. Explico os motivos abaixo:
Hospedagem da API
Hospedagem Front-end Estou na torcida e gostaria de colaborar mais com o projeto, espero que essas sugestões possam ajudar de alguma maneira. Se entenderem que alguma delas faz sentido, certamente conseguirei me envolver mais pois é a minha área 🙂 |
@boemekeld muito legal ver você aqui de novo meu caro, ainda mais com um comentário sensacional como estes! Ontem eu abri o Draft da próxima Milestone e acredito que ficará melhor conversar por lá, pois ela é focada em Performance e Segurança: #1140 Então estou fechando esta issue aqui e MUITO OBRIGADO por todo mundo que participou desta aventura. Espero ter próximas aventuras assim vocês, pois é exatamente deste tipo de situação que os conhecimentos mais raros são acessados... fora que tudo fica mais gostoso quando são vocês que estão aqui 🤝 Por fim, este é o print das views dos últimos 30 dias e agora o projeto entrou num estágio natural e saudável de ficar mais calmo, onde teremos mais tranquilidade para ajustar o que precisa ser ajustado, para daí sim tentar conquistar o próximo crescimento, mas desta vez muito mais preparados 👍 💪 🎉 [edit] Pico de 1.8 milhões de views: |
Tudo parece que está funcionando como esperado, apesar da instância do banco que utilizamos não estar conseguindo dar conta, tanto por conta do número alto de conexões abertas consumindo o processamento, quanto a dificuldade de conseguir responder a request dentro de 60 segundos antes da lambda cortar a conexão.
A Vercel não está marcando ainda as visitas, mas olhando diretamente os logs, o pico de acesso achatou a parte anterior do gráfico:
[edit]
Em paralelo, para quem só está consumindo as páginas (que são estáticas), tudo está 100% 👍
The text was updated successfully, but these errors were encountered: