Appodeal est une entreprise de ~ 100 personnes qui travaillent à Moscou, San Francisco, Barnaul, Lutsk, Kirov, Barcelone et depuis juin 2018, également à Minsk.
Nous monétisons les applications mobiles en diffusant des annonces auprès des utilisateurs. Nous avons commencé par la médiation publicitaire, mais la pile technologique ne cesse de croître, de sorte que d'autres produits de l'industrie publicitaire ont également été ajoutés à la médiation.
Pour ceux qui ne connaissent pas Ad Tech, c'est le domaine de travail des entreprises technologiques qui travaillent dans le domaine de la publicité. Lorsque vous dites à quelqu'un que vous travaillez dans le domaine de la publicité mobile, les gens réagissent souvent avec scepticisme - apparemment, la publicité ennuyeuse "Azino Three Axes" vient à l'esprit. En fait, ce n'est que la pointe de l'iceberg, et toute cette publicité «sauvage» n'a rien à voir avec le vrai secteur de la publicité.
Et le segment mobile dans lequel nous sommes engagés dépasse depuis longtemps le segment de la publicité sur le Web:
Pourquoi intégrer des publicités dans des applications?
Bien sûr, beaucoup de ressources sont consacrées à la création d'applications - et les créateurs / propriétaires veulent que le temps et les efforts consacrés soient payants. Les propriétaires d'applications mobiles qui publient leur application sur l'App Store / Google Play sont appelés éditeurs ou éditeurs. Les éditeurs appliquent différents modèles de monétisation, des achats intégrés à la monétisation publicitaire. Mais de toutes ces méthodes, seule cette dernière permet à l'utilisateur de ne pas payer pour l'utilisation de l'application - et cela donne la plus grande couverture d'audience.
Oui, s'il y a trop de publicité, cela ennuiera tout le monde et nuira à la rétention des utilisateurs. De quoi, bien sûr, personne n'a besoin. Par conséquent, ils essaient toujours d'intégrer judicieusement la publicité afin de gagner le maximum d'argent sur leur application et en même temps de ne pas toucher un centime aux utilisateurs.
Comment ça marche?
Dès que l'éditeur décide de monétiser par la publicité, il s'adresse à l'entreprise qui peut lui faciliter la tâche. Comment cela se produit-il avec Appodeal? Après inscription sur le site, nous intégrons son application à notre service. Cela se fait via le SDK client, qui connecte l'application à la partie serveur et communique avec la partie serveur via l'API.
Si vous minimisez les détails, l'objectif de l'interaction est réduit à deux étapes:
a. Déterminez quelle annonce afficher en ce moment;
b. Envoyez des informations sur la publicité qui a été diffusée ou non, et affichez-la dans les statistiques.
Actuellement, Appodeal dessert plusieurs milliers d'applications actives qui fournissent environ 400 à 450 millions d'impressions publicitaires par jour, reçues en réponse à environ 1 milliard de demandes aux réseaux publicitaires (qui sont les fournisseurs de publicité). Pour que cela fonctionne, nos serveurs traitent environ 125 mille demandes par seconde, soit environ 10,8 milliards de requêtes par jour.
Sur quoi tout cela s'appuie-t-il?
Nous utilisons diverses technologies pour fournir rapidité, fiabilité et en même temps flexibilité de développement et de support. En ce moment, nous écrivons du code dans les langues suivantes:
- / Ruby / Ruby on Rails + React.JS (front-end) /: Il y a toujours une grande partie de l'API et la totalité du Web Part que les utilisateurs et nos employés voient
- / GoLang /: Traitement de grandes quantités de données statistiques et pas seulement
- / Scala /: Demandes de traitement en temps réel pour travailler avec des échanges de trafic en utilisant le protocole RTB (en savoir plus à ce sujet à la fin de l'article)
- / Elixir / Phoenix /: Plutôt, la partie expérimentale. Création de micro-services pour gérer certaines statistiques et API.
Pourquoi est-ce à l'origine Ruby et Ruby on Rails?
Appodeal est en concurrence sur son segment avec de très gros acteurs, il faut donc s'adapter rapidement aux évolutions du marché. Cela ressemble souvent à un changement dans les roues d'une voiture à une vitesse de 100 km / h. Ruby on Rails nous a permis de résister à la course et de prendre suffisamment pied sur le marché pour être un leader dans son segment. Les principaux avantages de Rails à notre avis:
- Un grand nombre de développeurs qualifiés
- Grande communauté. Un grand nombre de solutions et bibliothèques prêtes à l'emploi
- La vitesse d'introduction de nouvelles fonctionnalités et de modification / suppression des anciennes
Des inconvénients évidents:
- La performance globale est médiocre. Cela affecte également le manque de JIT (pour le moment), le manque de capacité à paralléliser le code (si vous ne tenez pas compte de JRuby). Dans une certaine mesure, cela reste supportable car le goulot d'étranglement est généralement la base de données et le cache. Ce que nous voyons dans l'image de NewRelic:
- Les monolithes ferroviaires ne sont pas très bien coupés sur les microservices - ils sont affectés par un haut degré de connectivité entre la logique métier et la logique d'accès aux données (ActiveRecord).
Comment sont stockées les données?
Nous avons beaucoup de données. Très. Nous parlons de milliards / dizaines / centaines de milliards d'enregistrements. Étant donné que les données sont complètement différentes, nous les stockons de différentes manières. Il ne devrait jamais être limité en architecture à une seule solution, qui est censée être universelle. La pratique montre que, premièrement, dans Highload, il n'y a pratiquement pas de solutions universelles. L'universalité signifie des indicateurs moyens (ou nettement inférieurs à la moyenne) pour l'accès / la vitesse de lecture / la taille du stockage de données en tant que frais pour cette polyvalence même. Deuxièmement, vous devez toujours essayer quelque chose de nouveau, expérimenter et rechercher des solutions non triviales aux tâches. Total:
- / PostgreSQL /: Nous aimons Postgre. Nous la considérons comme la meilleure solution de stockage OLTP pour le moment. Des données sur les utilisateurs, les applications, les campagnes publicitaires, etc. y sont stockées. Nous utilisons la réplication de réplique primaire. Nous faisons des sauvegardes uniquement pendant les vacances de Noël, car c'est pour les mauviettes (une blague).
- / VerticaDB /: Base de données orientée colonne. Nous utilisons pour stocker des milliards d'enregistrements statistiques. En bref, Vertika a été considérée pendant un certain temps comme la meilleure solution OLAP pour stocker des analyses. Le principal inconvénient est le prix énorme (individuel) de la licence.
- / ClickHouse /: Également une base de données orientée colonnes. Passez-y progressivement avec VerticaDB. Nous considérons la meilleure solution OLAP pour le moment. Ne vaut pas un centime. Cela fonctionne très rapidement et de manière fiable. Le principal inconvénient est que les données ne peuvent pas être supprimées et mises à jour (nous en parlerons dans un article séparé, si quelqu'un est intéressé).
Rien! Comment est-il impossible de supprimer et de modifier des données?!
- / Aerospike /: Le stockage de valeur-clé NoSQL le plus rapide à notre avis. Il y a un certain nombre d'inconvénients, mais en général, nous sommes satisfaits. Il existe même un tableau de comparaison pour Aerospike sur leur site de performances avec d'autres solutions: [Quand utiliser la base de données Aerospike NoSQL par rapport à Redis] (https://www.aerospike.com/when-to-use-aerospike-vs-redis/)
- / Redis /: À propos de "Radis", je pense que cela n'a aucun sens de le dire séparément. Paradoxalement, son principal avantage est la facilité d'utilisation et le filetage unique, ce qui évite les conditions de concurrence, par exemple, lorsque vous travaillez avec des compteurs courants.
- / Druid /: Nous utilisons pour les grands ensembles de données en collaboration avec les échanges RTB. En fait, pour la plupart, il joue sur le même terrain avec ClickHouse, mais historiquement, nous n'avons pas encore été en mesure de basculer vers un seul instrument.
Un tel ensemble peut sembler surchargé, mais tout d'abord, Appodeal est un grand conglomérat de plusieurs équipes de développement et plusieurs projets au sein d'une seule. Et deuxièmement, ce sont les dures réalités de la technologie publicitaire - nous ne sommes pas les seuls à utiliser une pile à plusieurs étages au sein d'une entreprise.
Comment suivez-vous cela?
Les flux de données étant volumineux, ils doivent être mis en file d'attente pour les traiter. Comme file d'attente, nous utilisons Kafka. Il s'agit d'une excellente solution fiable écrite en Scala qui ne nous a jamais encore fait défaut.
La seule exigence pour l'utilisateur dans ce cas est qu'il ait le temps de ratisser la file d'attente sans cesse croissante plus rapidement qu'elle ne se développe. Une règle simple et évidente. Par conséquent, à ces fins, nous utilisons principalement GoLang. Cependant, cela n'annule pas le fait que la RAM sur ce serveur doit être abondante.
Pour surveiller toute cette économie, vous devez surveiller et déléguer littéralement tout de suite. Pour cela, nous utilisons:
- / NewRelic /: Une solution éprouvée qui s'intègre parfaitement aux services Ruby on Rails et GoLang. Le seul inconvénient de NewRelic est son prix. Par conséquent, NewRelic n'est pas partout avec nous. Pour la plupart, nous essayons de le remplacer par nos propres métriques collectées à la main - nous les mettons dans Grafana.
- / Statsd + Grafana /: Une bonne chose pour collecter vos métriques. Avec le seul inconvénient que vous devez tout configurer vous-même et «répéter» la fonctionnalité NewRelic hors de la boîte.
- / ElasticSearch + Fluentd + Kibana /: Dans les journaux, nous mettons tout en ligne. Des requêtes PostgreSQL lentes à certains messages système Rails. En fait, une solution comme Kibana basée sur ElasticSearch vous permet de collecter facilement tous les journaux en un seul endroit, puis de rechercher les messages nécessaires dessus.
- / Airbrake /: Obligatoire dans ce processus est la collecte des erreurs avec le message stacktrace'ami. Nous déplaçons actuellement avec Airbrake vers l'une des solutions gratuites. Pour une raison, encore une fois, les prix.
Vous devez comprendre que la surveillance correctement construite est vos yeux et vos oreilles. Aveuglément impossible de travailler. Vous devez voir ce qui se passe sur vos serveurs à un moment donné, de sorte que la stabilité et la fiabilité de votre produit dépendront en grande partie de la compétence avec laquelle vous construirez un système de collecte et d'affichage des métriques.
Soit dit en passant, en parlant de fiabilité, nous contenons plusieurs serveurs de transfert pour le pré-déploiement et la vérification des versions, que nous maintenons stables sous charge, dupliquant une partie du trafic réel là-bas. Chaque semaine, nous synchronisons les bases de données entre la production et la mise en scène. Cela nous donne une sorte de «miroir» qui nous permet de tester les choses qui ne peuvent pas être vérifiées localement, ainsi que d'identifier les problèmes au niveau des tests de charge.
Est-ce vraiment si compliqué?
Il en est ainsi. Comme Elon Musk l'a écrit dans son livre: "Les meilleurs esprits de ma génération sont occupés à amener les gens à cliquer sur les publicités", m'a dit Jeff Hammerbacher, un ancien ingénieur de Facebook. "Horreur ..." Une courte liste de ce que fait Appodeal:
- Nous sommes intégrés à deux douzaines de réseaux et agences publicitaires. En mode automatique, nous enregistrons des applications dans ces réseaux, ainsi que nous configurons divers paramètres pour que ces réseaux fonctionnent à des performances maximales. Tous les réseaux n'ont pas d'API correspondantes, quelque part vous devez le faire avec des robots.
- Chaque réseau paie aux utilisateurs des revenus pour les impressions, qui doivent être reçues, ventilées par divers paramètres et traitées. Cela se fait sans arrêt. Quelque part, encore une fois, par des robots.
- Afin de fournir à l'utilisateur un revenu maximal, nous «faisons» concurrencer les grilles, en construisant la soi-disant «cascade» à partir des offres publicitaires. La cascade est construite sur la base de divers indicateurs, par exemple l'eCPM (prix moyen pour 1000 impressions), que nous prédisons de différentes manières. Plus l'offre publicitaire dans la cascade est élevée, plus nous en prédisons le prix. Cette cascade est offerte sur l'appareil aussi souvent que nécessaire. Comme vous l'avez peut-être deviné, une publicité sur laquelle personne ne clique et qui ne fera qu'ennuyer tout le monde n'intéresse personne. L'exception n'est que ce qu'on appelle. Bannières publicitaires «de marque» de Coca-Cola, Pepsi et d'autres géants d'entreprise qui ont l'habitude de parler d'eux-mêmes toujours et partout.
- Une partie de cette interaction repose sur le protocole dit RTB (Real-Time Bidding):
Dans ce cas, les soi-disant enchérisseurs sont échangés entre eux en ligne lors d'une vente aux enchères pour le droit de diffuser leurs annonces sur l'appareil sélectionné. Un point très intéressant qui mérite un article séparé. De nombreux échanges, tels que Google AdExchange, définissent un cadre serré pour le temps de réponse du serveur (par exemple, 50 ms), ce qui pose un problème de performances de pointe. En cas de désobéissance - une amende de milliers de dollars. C'est exactement ce que fait le noyau écrit en Scala avec Druid.
Chaque chasseur veut savoir où se trouve le faisan, et nos clients (comme nous) veulent savoir à qui l'annonce a été montrée, quand et pourquoi. Par conséquent, nous devons mettre en file d'attente (Kafka) tout le tas de données que nous avons, traiter progressivement et ajouter à la base de données OLAP (ClickHouse). Beaucoup de gens pensent que PostgreSQL ne fera pas face à cette tâche pas pire que toutes les solutions «hipster», mais ce n'est pas le cas. PostgreSQL est bon, mais la solution classique pour construire des index pour la vitesse d'accès aux données cesse de fonctionner lorsque le nombre de champs pour le filtrage et le tri dépasse 10, et que la quantité de données stockées approche le milliard d'enregistrements. Vous n'avez tout simplement pas assez de mémoire pour stocker tous ces index ou vous aurez des problèmes pour mettre à jour ces index. Dans tous les cas, vous ne pourrez pas obtenir les mêmes performances que les solutions orientées colonnes pour les requêtes analytiques.
Conclusion
Dans cet article, j'ai essayé de décrire au moins brièvement ce que nous faisons, comment nous stockons et traitons les données. Dites-nous dans les commentaires la pile que vous utilisez, posez des questions et demandez de nouveaux articles - nous serons heureux de partager notre expérience.