zod.kr: retrospectiva tras 4 meses de desarrollo y 2 meses en producción - servidores y servicio
(ake.kr)Este es un texto sobre el stack tecnológico elegido y el proceso de desarrollo al crear el sitio comunitario nacional (zod.kr).
Ante una situación en la que, por un gran error de un sitio competidor, llegó 10 veces más tráfico de lo esperado, el servidor colapsó y luego tuvo que ser restaurado.
Dieta de recursos para optimizar los costos de tráfico.
A continuación, el resultado resumido con Grok 3.
Comparto la experiencia de desarrollar por mi cuenta la comunidad de TI zod.kr. Incluye el proceso de optimización para reducir el costo del servidor.
- Contexto de desarrollo: regreso al desarrollo web después de 3 años y al desarrollo con PHP después de 7 años. Transición a desarrollador full stack.
- Stack del servicio: Rhymix(CMS), Oracle Cloud Free Tier (inicialmente), Cloudflare (seguridad), Bunny.net (CDN), Naver Cloud (correo electrónico).
- Servidor inicial: Oracle Free Tier (24 GB de RAM, 4 núcleos ARM, 150 GB de almacenamiento). Se eligió por los 4 TB gratuitos de tráfico, pero tras la apertura, un tráfico inesperado de 10 veces lo previsto provocó desconexiones del disco de red y el colapso del servidor.
- Migración del servidor: migración de emergencia a Vultr. Apertura temporal tras 30 horas de trabajo sin dormir.
- Problema de tráfico:
- Con Cloudflare Argo ($0.1 por GB), el gasto era de $20 al día, con una proyección de 1 millón de wones al mes.
- Cambio a Bunny.net para reducir el costo a entre 15% y 20% del nivel anterior.
- Entre 27 mil y 30 mil visitantes diarios, lo que hizo evidente la necesidad de optimizar el tráfico.
- Esfuerzos de optimización:
- Reducción del peso de los íconos (Iconoir) y de la webfont (Pretendard).
- Minimización de scripts/estilos inline y eliminación de comentarios HTML.
- Aplicación de lazyload para reducir el tráfico de Bunny.net (68-88 GB → 44-46 GB).
- Bloqueo de bots e introducción de una whitelist de API para ahorrar entre 3 y 4 GB.
- Resultados:
- Tráfico pico en Cloudflare de 211 GB → 12 GB, con una reducción total del tráfico de 57%.
- Reducción de costos de 70% a 80% (de $26 al día → $3.48).
- Lección aprendida: Cloudflare puede ser muy útil si se usa bien, pero perjudicial si se usa mal. Aprendí la importancia de gestionar el tráfico.
13 comentarios
Pensé que sería Next.js...
Yo también desarrollo por mi cuenta, aunque sea a pequeña escala, y como uso Vercel, el costo es lo que más me preocupa.
Lo leí con mucho interés. También conocí un CDN que no sabía que existía. Lo tomaré como referencia de vez en cuando.
Entonces, ¿zod es el laboratorio de tonterías..?
Es una comunidad que uso mucho, y justo estaba pensando en montar una comunidad cerrada para algunos grupos de gaming, así que fue una reseña muy interesante. No imaginaba que fueras una sola persona, qué genial.
Tengo muchísima curiosidad por saber cómo lograron atraer gente al principio. Está increíble.
Recuerdo que, justo cuando se lanzó, surgió una controversia sobre la operación de un sitio que trataba un tema similar, y creo que eso por sí solo atrajo usuarios.
También fue interesante que usaran Rhymix y que ofrecieran una API a Algumon.
Alguien de Algumon hizo algo acá. Conocí un buen sitio gracias a esto.
Lo leí bien. Aun usando Cloudflare, ¿los costos de tráfico de red siguen siendo caros?
Hay algunos puntos similares al stack que aparece en este artículo: Cómo procesar 80 TB de tráfico y 5M de pageviews con 500,000 wones al mes ($400)
Está genial,
si se usa una tecnología como
fetch, parecería que se podría reducir un poco más el tráfico, ¿o eso no es posible?¿Por qué
fetchayuda a reducir el tráfico?Ah, entonces será Ajax.
Yo tampoco conozco muy bien la parte web, pero cada vez que cambias a otra pestaña, vuelve a traer el HTML completamente desde cero.
Tengo entendido que también hay una forma de traer solo los datos de la parte que cambió.
¡Mucho ánimo hasta el día en que se conviertan en la comunidad de hardware número 1!