TL; DR : Outfit7 est, à la base, une entreprise axée sur les données. La collecte et l'analyse des mesures de performance de nos jeux présentent de nombreux défis intéressants. Dans cet article, j'explorerai nos décisions de conception d'infrastructure et ce que nous avons appris en cours de route.

Bonjour, je m'appelle Tilen Kavčič. Je suis l'un des membres principaux du backend chez Outfit7, spécialisé dans l'infrastructure cloud et la R&D. La mission de notre équipe est de créer des solutions performantes et évolutives qui soutiennent la croissance de notre entreprise. Je suis en partie ingénieur logiciel, en partie ingénieur de données, avec un intérêt pour DevOps. La meilleure partie de mon travail consiste à avoir la chance de créer des solutions qui simplifient le développement de nouveaux logiciels. Ma mission actuelle est de moderniser notre pile de données, en apportant les meilleures pratiques d'ingénierie logicielle à nos équipes de données.

Arrière plan

Chez Outfit7, nous pensons que tous nos jeux doivent avoir l'air, jouer et se sentir bien. Avec 430 millions d'utilisateurs actifs par mois, il peut être difficile d'avoir une image claire des performances de nos jeux et de notre entreprise. Les données que nous recueillons nous aident à comprendre nos performances sur le marché en évolution rapide des jeux mobiles. Obtenir une rétroaction rapide est la clé. Pour cette raison, nous avons besoin d'une infrastructure évolutive et fiable, et qui, idéalement, ne nuit pas trop au portefeuille de l'entreprise. Au cours de la dernière décennie, nous avons continuellement amélioré notre infrastructure pour accueillir notre base d'utilisateurs croissante. Aujourd'hui, nous traitons un demi-million d'insertions de lignes par seconde. Laissez-moi vous montrer comment. Bienvenue dans l'infrastructure Billion Events.

Infrastructure

Commençons par un aperçu de notre infrastructure. Nous recevons des données de diverses sources de données, telles que des données d'utilisation de jeux, des services tiers, etc., que nous enregistrons dans un stockage persistant. Ici, nous nous concentrerons uniquement sur les données envoyées par nos jeux, car c'est ce qui constitue la colonne vertébrale de nos analyses. Des points de terminaison de collecte de données au stockage persistant, tout est hébergé sur Google Cloud Platform. Commençons par la première couche, aux points de terminaison de notre API :

1. Points de terminaison API
   Nous exécutons nos points de terminaison de collecte de données sur différents services gérés (App Engine, Cloud Run et Kubernetes Engine). Notre point de terminaison principal, où nous collectons les données d'utilisation, s'exécute sur Kubernetes Engine. Nous avons choisi Kubernetes car il offre un bon équilibre entre performances et coûts. Parce que nous avons une base d'acteurs mondiaux, nous gérons trois clusters, chacun dans des régions différentes (États-Unis, UE et Asie). Notre cluster principal réside aux États-Unis, où nous obtenons le plus de trafic, tandis que le cluster Asie sert de point de terminaison pour nos utilisateurs en Chine. Nous avons également mis en place un cluster en Europe qui est notre point de terminaison de secours en cas de défaillance des points de terminaison dans les clusters américains et asiatiques. Toutes les données sont validées et transmises à notre couche de livraison de données.
2. Livraison des données
   Cette deuxième couche est un middleware entre nos points de terminaison API et les charges de travail de traitement des données. Il fournit une livraison asynchrone des messages avec l'avantage de protéger nos données jusqu'à ce qu'elles soient écrites dans un stockage persistant. Nous utilisons Pub/Sub (similaire à Apache Kafka) qui fournit un service de livraison de messages simple, fiable et évolutif.
3. Traitement des données
   Dans cette couche, nous effectuons une légère transformation des données (dégroupage des données client) et une diffusion en continu des données dans un stockage persistant. Notre cadre principal pour ce faire est Apache Beam qui s'exécute sur une infrastructure cloud gérée appelée Dataflow. Il s'agit d'un moyen éprouvé de créer des pipelines ETL, car il fournit un moyen fiable d'insérer des données dans un stockage persistant.
4. Stockage des données
   Après tout cela, les données sont finalement écrites dans BigQuery. Il s'agit de notre principal entrepôt de données, qui alimente l'ensemble de notre charge de travail d'analyse. C'est rapide, fiable et exactement ce dont nous avons besoin pour stocker et analyser nos données.

Ce que nous avons appris

Environnement de développement

Ces environnements sont importants car ils créent un espace sûr où les ingénieurs peuvent créer et tester de nouvelles fonctionnalités. Sans eux, vous êtes toujours à un pas de casser l'environnement de production. Notre équipe prend ces environnements au sérieux. Au tout début, nous séparons les services de production et de développement en utilisant des autorisations d'accès et des fichiers de configuration. L'utilisation de l'infrastructure en tant que code (nous utilisons Terraform) accélère la création d'environnements de développement et de production. Si vous souhaitez créer un meilleur environnement de développement, nous vous recommandons de consulter l'application The Twelve-Factor [1].

Essais

La partie la plus importante de tout service est probablement les tests. Les tests unitaires et d'intégration fournissent un bon aperçu si vos services fonctionnent comme prévu. Et pour les services de base qui ont un impact direct sur l'entreprise, les tests sont indispensables. Nous avons eu beaucoup de succès en détectant les bogues dans notre code avant de publier notre code en production. La note clé ici est que les tests doivent être significatifs et doivent tester les fonctionnalités de base de notre service. Pour tirer parti de cela, nous utilisons CI / CD pour automatiser les phases de publication et de test, ce qui réduit considérablement le travail manuel.

Métrique

Bien que les tests couvrent principalement notre logique métier principale pendant le développement, nous devons toujours surveiller le comportement et la santé de nos services pendant et après le déploiement. Pour ce faire, nous créons des métriques qui nous donnent un aperçu en temps réel de la performance de notre service. En plus de cela, nous élaborons des politiques d'alerte qui nous informent lorsque quelque chose ne va pas. Nous avons également une fonctionnalité d'abandon automatique dans notre pipeline CI/CD si les métriques sont supérieures à un certain seuil. Mais créer des métriques utiles peut être délicat. Vous pouvez soit sur-surveiller et surcharger vos personnes d'astreinte avec des alertes, soit sous-surveiller et ignorer les problèmes qui nuisent aux performances de l'entreprise. Je recommande de lire le livre SRE de Google, qui vous aidera à trouver le juste milieu [2].

Simplicité

L'ajout de nouvelles fonctionnalités est inévitable, même lorsque l'infrastructure centrale est intacte. Nous devons garder à l'esprit que prendre des décisions qui nécessitent des systèmes complexes nuira à votre équipe à long terme. Lors de la conception de vos systèmes, vous devez équilibrer la complexité et les coûts. Les solutions cloud gérées telles que Pub/Sub sont généralement le meilleur moyen de réduire la complexité, mais elles peuvent être plus coûteuses. Notre équipe utilise des solutions cloud gérées car elles réduisent la charge globale des ingénieurs. Nous simplifions également notre processus de publication. Nous avons une règle, si vous la poussez vers main, elle sera testée et publiée. Plus de scripts et de documents sur la façon de publier un nouveau code.

[1] : https://12factor.net/

[2] : https://sre.google/workbook/monitoring/

Conclusion

Dans cet article, nous avons examiné notre infrastructure de données de base, qui est responsable de la réception et de la sauvegarde des données analytiques de nos jeux. En raison de la grande quantité de données que nous recevons, nous devions créer une conception d'infrastructure fiable qui évoluerait avec notre croissance. Le choix de la bonne technologie n'est qu'une partie de la création d'un tel système. Tout système de base doit être conçu dans un souci de simplicité avec des environnements de tests, de métriques, de journalisation et de développement qui offrent aux développeurs un filet de sécurité. Nous avons traversé de nombreuses itérations de notre système au cours des deux dernières années, apprenant à chaque fois quelque chose de nouveau.