Table des Matières
Les problèmes de mise à l'échelle sont des problèmes qui surviennent quand un système ou une application ne peut pas gérer des quantités exponentiellement plus grandes de données ou de trafic utilisateur. Nous avons récemment écrit sur la façon dont le modèle freemium a failli causer l'implosion de notre entreprise en raison de tels problèmes de mise à l'échelle. C'est une histoire vraie sur les raisons pour lesquelles la mise à l'échelle d'une application n'est jamais aussi facile qu'il y paraît.
Construire un logiciel, c'est un peu comme être un moniteur de camp avec les yeux brillants et la queue touffue. Au début, les enfants sont déposés par leurs parents, un ou deux à la fois. Chaque enfant a une demande spéciale qui doit être traitée. L'un a beaucoup de bagages à ranger. Un autre est végétalien. Un autre veut juste faire du tir à l'arc et rien d'autre.
C'est bien.
Ensuite, des cars entiers d'enfants commencent à être déposés — tous en camp gratuit, mais tous ont des bagages, des contraintes alimentaires, des problèmes de planification. Pas amusant.
À la fin de la journée, le pauvre moniteur est épuisé.
Les logiciels et les moniteurs de camp ont tellement de points en commun.
La piste des bonnes intentions
- Écrivez votre application en Rails et utilisez Postgres — Tout est génial!
- Ajoutez un webhook simple pour Stripe dans Rails en tant que contrôleur dans l'application principale — On décolle!
- Commencez les calculs en arrière-plan — utilisez Sidekiq — Toujours génial!
- Jusqu'à ce qu'un client s'inscrive et envoie plus de 20 000 événements en 24 heures.
- Maintenant, ce simple webhook ralentit le tableau de bord principal
- Séparez le webhook dans son propre petit microservice — il fonctionne depuis des mois sans intervention…
- L'importation de données de Stripe par mois fonctionne très bien jusqu'à ce qu'un client s'inscrive avec 8 000 événements en une seule journée.
- Maintenant, nous devons importer par segment (2-3 jours de progression perdus)
- Dans le même temps, d'autres comptes s'inscrivent, nous avons besoin de plus de workers… pas de souci, augmentez-les!
- Mais attendez, les workers à mémoire élevée sur Heroku coûtent littéralement un bras, une jambe, un rein et le premier-né.
- Nous sommes une entreprise bootstrappée, nous ne pouvons pas nous permettre de dépenser cela. Il est temps de passer à AWS. C'est tout à fait raisonnable.
- Oups, maintenant télécharger les données pour les tests locaux devient presque impossible, ce qui ralentit le développement. Soupir.
- Problèmes de workers résolus.
- Oh, mais PG a un problème de limite de connexion à peine digne d'être mentionné…
- D'accord, lancez pgbouncer sur chaque machine
- Fantastique! Cela fonctionne, jusqu'à ce que ça ne marche plus — enfin, passez pgbouncer à sa propre machine — problèmes de connexion résolus
- Oh, mais entretemps, les requêtes sur le serveur DB tuent le CPU
- Dans ce cas, sortez une table à fort trafic dans sa propre base de données séparée
- Eh bien mon dieu, il y a des problèmes de limite de connexion avec la nouvelle base de données (répétition des leçons apprises précédemment)
- Oh, quelqu'un s'est inscrit avec 4 000 plans — tous nos workers par plan meurent.
- Entretemps, le matériel marketing dans l'application principale fonctionne très bien au départ
- Jusqu'à ce que le marketing fonctionne réellement et que des milliers de personnes viennent le regarder
- Ce qui tue le temps de réponse du tableau de bord principal pour les clients payants
- Ce qui signifie que nous devons rapidement diviser le site marketing et l'application en pièces séparées
- Et cela continue sans fin…
Nous n'aurions pas pu savoir tout cela au début. Bien sûr, nous aurions pu supposions le faire, mais nous n'aurions jamais lancé le produit en premier lieu parce que nous passerions l'éternité à optimiser pour une mise à l'échelle que nous n'avions pas.
Construire et, plus important encore, livrer un logiciel, c'est une question de compromis constant entre la progression et la stabilité présente.
Silicon Valley est remplie de tombes de startups qui n'ont jamais vraiment livré quoi que ce soit parce qu'elles étaient obsédées par la résolution de problèmes qu'elles n'avaient pas. Livrer, c'est mieux que mourir avant même de décoller. Et oui, je suis conscient que c'est une métaphore maladroite. Mais au moins je l'ai livrée. 🙂
