Comment huit personnes font évoluer un projet à forte charge. Expérience Unsplash

Photo: Alex Smith | Unsplash

Bon après-midi

Je m'appelle Victor Pryazhnikov, je travaille au département Features de Badoo . La tâche principale de notre département est de développer les fonctionnalités que les utilisateurs de notre site et de nos applications voient. Lorsque je suis tombé sur un article du co-fondateur d'Unsplash, Luke Chesser, elle m'a intrigué par le fait qu'ils parviennent à développer un projet relativement important avec une très petite équipe. L'approche de l'auteur m'impressionne par son pragmatisme et m'a rappelé que vous n'êtes pas Google , j'ai donc décidé de le traduire.

L'une des choses les plus drôles dans le développement Unsplash est l'échelle et la popularité du produit.

Au cours d'une journée typique, notre API traite plus de 10 millions de demandes provenant de unsplash.com et des milliers d'applications tierces, des millions d'événements transitent par notre pipeline de traitement des données, 60 millions de mises à jour sont ajoutées à nos flux et nous servons 60 millions d'images.

Dans le même temps, notre équipe est relativement petite: deux designers, trois personnes travaillant avec le frontend, deux avec le backend et un ingénieur de données. Nous n'avons pas d'ingénieur DevOps distinct, et chaque membre de l'équipe passe la plupart de son temps à expérimenter et à développer de nouvelles fonctionnalités pour assurer le développement ultérieur du produit.

Bien que nous ayons déjà accompli beaucoup de choses avec Unsplash, nous sommes encore au tout début de son parcours en tant que produit et entreprise. Nous avons encore quelque chose à prouver, et cela signifie que toute l'équipe doit se concentrer sur la résolution des problèmes propres à Unsplash, et non ceux que toute autre entreprise a, comme l'organisation des calculs, la sécurité du réseau, la construction de l'infrastructure, la gestion dépendances, etc.

Au cours des trois dernières années, nous avons développé un ensemble de principes qui nous permettent de nous concentrer sur la croissance et d'éviter les problèmes d'échelle. Malheureusement pour ceux qui recherchent une solution miracle, elle ne sera pas là: c'est juste du bon sens et un ensemble de principes que nous avons empruntés aux autres.

1. Utilisez des solutions évidentes ennuyeuses

Ou soyez pragmatique.

Avant de se lancer dans l'introduction d'un nouvel outil, d'une base de données (RethinkDB, RocksDB, etc.), d'un nouveau modèle («tout est fonctionnel!»), Ou d'une nouvelle architecture («microservices, aide!»), Essayez toutes les options évidentes.

Du côté du backend, il y a très peu de problèmes qui ne peuvent pas être résolus assez efficacement en utilisant des outils standard et bien connus et des modèles éprouvés tels que la mise en cache, le traitement par lots, le traitement asynchrone et la préparation préliminaire des données nécessaires.

2. Concentrez-vous sur la résolution des problèmes des utilisateurs, pas sur la technologie

Unsplash est un produit, pas une entreprise technologique. Nous avons reçu beaucoup d'argent d'investisseurs pour nous concentrer sur la résolution des problèmes de notre produit et du marché, plutôt que d'essayer de réduire de 3% les coûts d'exploitation pour l'utilisation de technologies communes.
Nous passons notre temps à utiliser des technologies prêtes à l'emploi d'une manière qui aidera à résoudre les problèmes de nos utilisateurs et à accroître la communauté Unsplash. Ce sont des tâches uniques à Unsplash, et si nous parvenons à créer quelque chose de nouveau et de précieux, nous pouvons reporter l'optimisation à une date ultérieure, lorsque ces optimisations de 3% peuvent devenir la principale source de croissance.

Nos collègues potentiels qui ont entendu parler de l'échelle d'Unsplash et d'une petite équipe, de l'utilisation des images et de l'intelligence artificielle, des fonctionnalités futures, peuvent être déroutés par le fait que nous utilisons beaucoup de technologies, de services et de cadres prêts à l'emploi. Cela nous fait payer un peu plus en ce moment, mais cela nous permet de reporter le développement interne de ces technologies pendant un certain temps et de le remettre sur les épaules de nos futurs collègues.

Le processus d'élaboration du code, la configuration des serveurs, les dépendances du système, le traitement et l'analyse des données, le traitement et la personnalisation des images sont des exemples de domaines que nous avons choisis de ne pas nous concentrer sur nos ressources d'ingénierie, mais plutôt d'utiliser des services tiers prêts à l'emploi pour chacun d'eux.

3. Dépenser de l'argent pour résoudre des problèmes technologiques

Le revers de la médaille sur les problèmes liés aux produits est le coût supplémentaire de l'accès aux technologies standard et aux services tiers.

C'est devenu un peu une blague à l'intérieur de notre équipe. Ils disent que ma première réaction à tout problème sera la question: "Avez-vous essayé de le résoudre avec de l'argent?". Mais ce n'est pas une blague, mais l'une de mes approches préférées pour résoudre les problèmes.

L'optimisation des coûts associés à l'infrastructure et à la technologie est un problème tellement courant avec des solutions simples et répétitives qu'aucune entreprise de produits avec des investisseurs ne devrait s'en occuper jusqu'à ce qu'elle estime que la croissance de la métrique principale a cessé d'être sa priorité.

Lorsque nous dépensons de l'argent pour résoudre des problèmes technologiques, nous délions les mains de l'équipe, ce qui lui permet de se concentrer sur des problèmes complexes récurrents, comme trouver un moyen d'augmenter la taille de la base d'utilisateurs de 40% au cours du trimestre en cours.

---

Ce sont donc trois principes assez simples mais abstraits que nous suivons.

Mais à quoi ressemblent-ils dans la pratique?

Si vous regardez l'architecture Unsplash, vous verrez qu'elle est très simple et presque ennuyeuse (au moins par rapport aux normes de 2017).


Un diagramme simplifié des principales parties qui composent Unsplash

Dans la mesure du possible, nous utilisons Heroku pour simplifier la mise en page, la configuration, les tests, le support et la mise à l'échelle de nos applications principales. Heroku est une sorte de magie qui sépare les parties de l'application et du processus de développement afin que les membres de notre équipe n'aient pas besoin de la connaître pour développer et organiser des expériences.

Nous minimisons de manière agressive la quantité de code que nous écrivons pour la logique métier de l'application (zones violettes sur l'image). Lors de sa rédaction, nous utilisons activement des frameworks créés par d'autres personnes qui, en tant qu'experts dans leurs domaines, ont développé des solutions qui fonctionnent avec succès dans 95% de nos cas d'utilisation.

Nous utilisons activement Redis, Elasticsearch et Postgres dans la production. Dans le passé, nous avons essayé d'autres bases de données, mais nous y sommes toujours retournés, car nous sommes sûrs de comprendre comment elles se comportent sous charge.

Nous utilisons également activement les files d'attente de tâches, en traitant de manière asynchrone de nombreuses opérations, telles que la mise à jour, l'agrégation et la synchronisation des données entre différentes sources.

Pour le traitement des données, nous utilisons Snowplow , un cadre intégré ouvert écrit en Scala, qui élimine la nécessité pour notre équipe de penser à l'organisation de l'entrée et de la sortie, et non au traitement lui-même.

Nous utilisons également un ensemble complet de services de surveillance cloud, tels que Datadog , New Relic , Sentry et Logentries , au lieu de déployer et de maintenir notre propre pile StatsD ou ELK.

Nous avons externalisé l'hébergement et l'infrastructure pour la livraison de nos images à imgix , une entreprise leader dans le domaine de l'utilisation d'images dynamiques. S'ils ajoutent de nouvelles fonctionnalités, notre équipe apporte une modification à l'URL - et nos utilisateurs ont également accès à cette fonctionnalité.

Nous enregistrons toutes les actions de nos utilisateurs dans le service Stream , en utilisant leur expérience dans la création et l'optimisation de bandes personnelles hautement chargées. Stream simplifie le traitement de milliards d'actions pour nous et fournit une API simple pour entrer et sortir, qui fonctionne avec une productivité telle que notre équipe mettrait des mois, voire des années à créer par elle-même.

Nous ne formons pas nous-mêmes les algorithmes de reconnaissance d'images, mais utilisons plutôt TinEye pour les recherches d'images inversées et Google Vision pour la reconnaissance et la classification d'images.

Nous enregistrons tous les événements comportementaux dans Vero , une plate-forme pour travailler avec les notifications et les listes de diffusion, ce qui nous permet de transférer le travail avec eux entre les mains de nos collègues qui ne sont pas des développeurs. Ils peuvent eux-mêmes créer des lettres avec un haut niveau de personnalisation, basées sur l'utilisation complexe des données disponibles sur le comportement des utilisateurs.

---

Dans le même temps, nous nous concentrons sur les parties d'Unsplash qui peuvent apporter une amélioration à notre compétence de base.

Au cours de la dernière année, nous avons divisé notre application Ruby on Rails unique en Rails API, l'application Web Node.js + React et créé une application de données distincte qui collecte et traite toutes nos mesures internes et de produit.

Cela a permis à notre équipe de créer des fonctionnalités qui semblaient presque impossibles sur notre ancienne pile composée uniquement de Rails. Ayant partagé les problèmes et les technologies de nos applications, notre équipe a également eu l'opportunité d'utiliser les meilleurs outils dans chacun des domaines:

• À l'avant, nous utilisons React et Webpack avec un petit serveur Express pour prendre en charge le rendu du serveur et les demandes d'API proxy. Nous n'avons intentionnellement pas lié les outils de notre équipe frontend au backend avec des hacks temporaires comme react -rails ou webpacker . La communauté JavaScript, sans aucun doute, publie les meilleurs outils pour travailler avec le frontend, donc travailler directement avec JavaScript permet à notre équipe de fournir rapidement des fonctionnalités de haute qualité aux utilisateurs.
  
• Au backend, notre équipe continue d'utiliser le meilleur framework pour développer des applications web simples: Rails. L'écosystème Ruby on Rails fournit les meilleurs outils pour les fonctionnalités du côté backend, et puisque ce cadre est largement utilisé, tout problème avec celui-ci a déjà été trouvé par quelqu'un, documenté, et avec un haut degré de probabilité, il existe déjà une solution.
  
• Côté données, notre équipe utilise un petit serveur Express pour collecter et organiser le traitement des données. Le traitement lui-même a lieu dans Snowplow, qui s'exécute dans le cluster AWS, où il existe des images prêtes à l'emploi pour simplifier la configuration et le déploiement. Cela permet à notre seul ingénieur des données, Tim, de passer la majeure partie de son temps à transférer des données vers Snowplow et à en obtenir les résultats d'une manière qui facilite la compréhension et l'obtention d'informations par les autres membres de l'équipe.
  

Nous sommes activement engagés dans la rédaction de tests , la mesure des performances à l'aide d'outils tels que Scientist et Datadog, la mise en place de changements sous forme d'expériences et l' automatisation du travail avec notre infrastructure autant que possible.

Nous développons une nouvelle API interne basée sur GraphQL pour accélérer les itérations d'expériences, de nouvelles fonctionnalités et de produits qui ne dépendent pas les uns des autres, car nous avons réalisé que notre API basée sur REST tombe en panne sans un haut niveau de coordination entre les données, la conception, les équipes front-end et back-end - mieux nous allons passer ce temps sur les fonctionnalités, pas sur les modifications JSON.

Bien qu'il soit intéressant de travailler sur ces changements, nous ne les apportons pas parce que nous voulons étancher les démangeaisons de notre programmeur, mais parce qu'il résout nos vrais problèmes qui nous empêchent de fournir rapidement des fonctionnalités et de développer.

Je pense que la plupart des gens qui ont lu jusqu'ici ont une des trois conclusions en tête:

1. Unsplash est très simple, vous pouvez donc utiliser cette approche. Ce que je fais est beaucoup plus compliqué, nous sommes donc obligés de faire les choses différemment.
   
2. Je suis développeur. Cela semble très ennuyeux - je veux créer un nouveau système de reconnaissance d'image à haute charge!
   
3. Cool! Je m'en fiche, donnez-moi juste de belles photos gratuites que je peux utiliser.
   

Les gens avec la conclusion numéro 1, vous avez raison: il y a des entreprises qui font des choses beaucoup plus complexes que nous. Mais il n'y en a pas beaucoup. Nous créons tous les mêmes systèmes, mais en nous concentrant sur quelques autres choses, et c'est la raison pour laquelle les solutions utilisées peuvent être résumées sous forme de cadres et réutilisées dans différents projets (par conséquent, la plupart des messages sur l'embauche sont si similaires les uns aux autres).

Les gens avec la conclusion numéro 2, cela dépend de ce que vous trouvez intéressant. Si vous voulez repousser les limites de la technologie, alors allez travailler pour une entreprise dont la mission est de le faire. Il n'y en a pas beaucoup, mais la plupart des autres entreprises ne le font tout simplement pas.

Aux personnes ayant la conclusion numéro 3, je dirai: "Oui, c'est vrai!" En fin de compte, c'est pour cela que nous faisons tout cela.

Badoo est proche des principes dont l'auteur parle. La principale différence est que notre projet est beaucoup plus vaste et que l'utilisation de services externes pour nous est souvent très coûteuse. De plus, beaucoup de nos solutions sont très simples et nous essayons d'approcher soigneusement leurs changements en comparant le coût de l'introduction et de l'exploitation d'une nouvelle technologie avec les avantages que nous en retirerons. Certaines de nos solutions sont assez démodées, car elles ont été créées il y a un certain temps, mais la transition vers de nouvelles similaires juste pour la mode ne paiera pas les ressources dépensées. Dans le même temps, nous sommes prêts à introduire de nouvelles technologies, si nous comprenons qu'elles peuvent apporter de réels avantages (par exemple, PHP 7 , Go , Cassandra , Tarantool , Exasol ).