Voici un article sur la stack technique choisie et le processus de développement lors de la création du site communautaire coréen (zod.kr).
À la suite d’une grosse erreur d’un site concurrent, le trafic a afflué à un niveau 10 fois supérieur aux prévisions, faisant tomber le serveur avant qu’il ne soit restauré.
Régime drastique des ressources pour optimiser les coûts liés au trafic.
Ci-dessous, le résumé généré par Grok 3.
Partage de l’expérience de développement en solo de la communauté IT zod.kr, y compris le processus d’optimisation pour réduire les coûts serveur.
- Contexte de développement : retour au développement web après 3 ans, et à PHP après 7 ans. Transition vers un rôle de développeur full stack.
- Stack du service : Rhymix (CMS), Oracle Cloud Free Tier (au début), Cloudflare (sécurité), Bunny.net (CDN), Naver Cloud (e-mail).
- Serveur initial : Oracle Free Tier (24 Go de RAM, ARM 4 cœurs, 150 Go de stockage). Choisi pour ses 4 To de trafic gratuit, mais après l’ouverture, un trafic imprévu 10 fois supérieur a provoqué la déconnexion du lecteur réseau et l’effondrement du serveur.
- Migration du serveur : migration d’urgence vers Vultr. Réouverture provisoire après 30 heures de travail sans sommeil.
- Problème de trafic :
- Cloudflare Argo (0,1 $/Go) entraînait une dépense quotidienne de 20 $, soit environ 1 million de wons par mois.
- Passage à Bunny.net, réduisant les coûts à environ 15 à 20 % du niveau précédent.
- 27 000 à 30 000 visiteurs quotidiens, d’où la nécessité d’optimiser le trafic.
- Efforts d’optimisation :
- Réduction du poids des icônes (Iconoir) et de la webfont (Pretendard).
- Minimisation des scripts/styles inline et suppression des commentaires HTML.
- Application du lazyload, faisant baisser le trafic Bunny.net de 68-88 Go à 44-46 Go.
- Blocage des bots et mise en place d’une whitelist API, économisant 3 à 4 Go.
- Résultats :
- Trafic de pointe Cloudflare passé de 211 Go à 12 Go, avec une baisse du trafic total de 57 %.
- Réduction des coûts de 70 à 80 % (de 26 $/jour à 3,48 $).
- Leçon retenue : Cloudflare est très utile quand il est bien utilisé, mais peut devenir nocif dans le cas contraire. Cette expérience a rappelé l’importance de la gestion du trafic.
13 commentaires
Je pensais que c’était du Next.js...
Je développe aussi modestement en solo, et comme j’utilise Vercel, le coût est ce qui m’inquiète le plus.
J’ai bien lu votre retour. J’ai aussi découvert un CDN que je ne connaissais pas. Je m’y référerai de temps en temps.
zod, c’est le labo des trucs inutiles.. ?
C’est une communauté que j’utilise beaucoup, et justement je réfléchissais récemment à faire tourner une communauté fermée pour des groupes de joueurs, donc ce retour d’expérience était intéressant. Je ne pensais pas que vous étiez seul à gérer tout ça, c’est impressionnant.
Je suis vraiment très curieux de savoir comment vous avez réussi à attirer des gens au tout début. C’est impressionnant.
Je me souviens qu’au moment du lancement, une controverse sur l’exploitation avait éclaté sur un site traitant d’un sujet similaire, ce qui avait naturellement attiré des utilisateurs.
Le fait d’utiliser Rhymix était intéressant, et le fait de fournir une API à Algumon l’était aussi.
Algumon a vraiment fait quelque chose. J’ai découvert un bon site.
J’ai bien lu. Même avec Cloudflare, les coûts de trafic réseau restent donc élevés ?
Il y a des points communs avec la stack présentée dans cet article : Comment gérer 80 To de trafic et 5 M de pages vues avec 500 000 wons par mois (400 $)
C'est impressionnant,
si on utilise une technologie comme
fetch, j'ai l'impression qu'on pourrait réduire un peu plus le trafic, non ? Est-ce que ce n'est pas possible ?En quoi
fetchpermet-il de réduire le trafic ?Ah, probablement de l’Ajax.
Je ne connais pas très bien le web non plus, mais à chaque fois qu’on passe sur un autre onglet, il recharge complètement le HTML.
Il me semble qu’il existe aussi une méthode pour ne récupérer que les données des parties modifiées.
Bon courage jusqu’au jour où vous deviendrez la communauté hardware n°1 !