Este é um texto sobre a stack tecnológica escolhida e o processo de desenvolvimento ao criar o site de comunidade nacional zod.kr.
Com um grande erro de um site concorrente, entrou 10 vezes mais tráfego do que o esperado, o servidor caiu e depois foi restaurado.
Dieta de recursos para otimizar os custos de tráfego.
Abaixo está o resultado resumido pelo Grok 3.
Compartilho a experiência de desenvolver sozinho a comunidade de TI zod.kr. Inclui o processo de otimização para reduzir os custos de servidor.
- Contexto de desenvolvimento: retorno ao desenvolvimento web após 3 anos e ao desenvolvimento em PHP após 7 anos. Transição para desenvolvedor full stack.
- Stack do serviço: Rhymix (CMS), Oracle Cloud Free Tier (inicialmente), Cloudflare (segurança), Bunny.net (CDN), Naver Cloud (e-mail).
- Servidor inicial: Oracle Free Tier (24 GB de RAM, 4 núcleos ARM, 150 GB de armazenamento). A escolha foi feita pelos 4 TB gratuitos de tráfego, mas após a abertura houve 10 vezes mais tráfego do que o esperado, o que causou desconexão do drive de rede e colapso do servidor.
- Migração de servidor: migração emergencial para a Vultr. Reabertura temporária após 30 horas de trabalho sem dormir.
- Problema de tráfego:
- Com o Cloudflare Argo (US$ 0,1 por GB), o gasto chegou a US$ 20 por dia, com projeção de cerca de 1 milhão de won por mês.
- Mudança para Bunny.net, reduzindo o custo para 15% a 20% desse valor.
- Com 27 mil a 30 mil visitantes por dia, ficou clara a necessidade de otimização de tráfego.
- Esforços de otimização:
- Redução do tamanho dos ícones (Iconoir) e da webfont (Pretendard).
- Minimização de scripts/estilos inline e remoção de comentários HTML.
- Aplicação de lazyload, reduzindo o tráfego da Bunny.net de 68–88 GB para 44–46 GB.
- Bloqueio de bots e adoção de whitelist de API, economizando 3–4 GB.
- Resultado:
- Pico de tráfego no Cloudflare caiu de 211 GB para 12 GB, com redução total de 57% no tráfego.
- Redução de 70% a 80% nos custos (de US$ 26 por dia para US$ 3,48).
- Lição: Cloudflare pode ser muito útil se bem utilizado, mas um problema se mal usado. Foi uma lição sobre a importância do gerenciamento de tráfego.
13 comentários
Achei que fosse Nextjs...
Eu também desenvolvo sozinho, de forma modesta, e como uso a Vercel, o custo acaba sendo a minha maior preocupação.
Li com bastante interesse. Também acabei conhecendo um CDN que eu não conhecia. Vou consultar de vez em quando como referência.
Se é zod, então é o Laboratório de Gambiarras..?
É uma comunidade que uso bastante, e como recentemente eu estava pensando em tocar alguma comunidade fechada para grupos de jogos, foi um relato bem interessante. Não imaginei que fosse uma pessoa só, muito legal.
Fiquei muito, muito curioso para saber como vocês conseguiram atrair as pessoas no começo. Muito legal.
Lembro que, na época do lançamento, acabou atraindo usuários espontaneamente porque surgiu uma polêmica sobre a gestão de um site que tratava de um tema parecido.
Foi interessante ver o uso do Rhymix e também o fato de fornecer uma API para o Algumon.
Então era isso que o Algumon estava aprontando. Conheci um ótimo site.
Li com atenção. Mesmo com Cloudflare, os custos de tráfego de rede ainda são caros, né?
Há alguns pontos parecidos com a stack mostrada neste texto: Como lidar com 80 TB de tráfego e 5M de pageviews por US$ 400 (500 mil won) por mês
Muito legal,
Usando uma tecnologia como
fetch, parece que daria para reduzir um pouco mais o tráfego; isso não é possível?Por quais motivos o
fetchajuda a reduzir o tráfego?Ah, deve ser Ajax mesmo.
Eu também não entendo muito da parte web, mas percebi que, toda vez que você muda para outra aba, ele busca um HTML completamente novo.
Pelo que eu sei, também existe um jeito de trazer só os dados da parte que mudou.
Até o dia em que se tornar a comunidade de hardware nº 1, vamos em frente!