Dépasser le battage médiatique de Pokemon Go : minimiser l'impact sur l'infrastructure

Sauf si vous avez vécu dans une grotte, déconnecté du monde extérieur depuis le début de l'été, vous devriez avoir entendu parler de la sortie du jeu en réalité augmentée Pokemon Go par Niantic Labs. Continent après continent, pays après pays, le jeu continue d'attirer de plus en plus de public et de joueurs. De nos jours, cela signifie également que de plus en plus d'applications autour du jeu sont créées et c'est ici que commence cette histoire.

L'émergence des applications Pokemon Go

Les 6 jours suivant la sortie initiale de PokemonGo, certains joueurs/développeurs du monde entier ont pris le temps d'analyser le jeu afin de comprendre comment l'application mobile communique avec les serveurs de Niantic Labs. Ils ont finalement publié un premier client API tiers en Python . Après quelques jours supplémentaires, des clients dans n'importe quel langage de programmation étaient disponibles, ce qui a entraîné la création d'un très grand nombre d'applications par la communauté. Les principaux problèmes que les gens essaient de résoudre sont : « Quels sont les pokémons autour de moi ? » et « Où sont les pokémons rares que je traque depuis des jours ? »

Le 16 juillet (2 jours après la sortie de la bibliothèque python), le projet PokemonGo-Map a démarré, pour proposer une application python simple pour visualiser les pokémons autour d'un emplacement spécifique donné comme configuration. Le serveur se fait passer pour un utilisateur spécifique à un emplacement spécifique, se déplaçant et découvrant des pokémons, les affichant sur une carte GoogleMap.

L'application a été plusieurs semaines sur la page tendance de Github, propulsant sa popularité vers le monde hype du jeu Pokemon Go. Beaucoup de gens ont été disposés :

1. À utiliser l'application

2. À déployer l'application

3. À contribuer à l'application

À partir de ce moment, nous avons supposé que Scalingo pourrait aider à résoudre le problème numéro 2.

Déploiement en un clic

En décembre de l'année dernière, nous avons lancé notre fonctionnalité de déploiement en 1 clic. Cela vous permet de mettre un bouton sur vos pages web ou sur la page de votre projet Github pour permettre aux gens de déployer un projet open-source en un seul clic.

Nous avons soumis une demande de tirage au projet de carte qui a été acceptée. À partir de ce moment, les personnes se rendant sur la page du projet ont pu déployer l'application en moins de deux minutes sur la plateforme.

SQLite - Houston, il pourrait y avoir un problème

Près de 1 000 instances de l'application ont été déployées en quelques semaines. Nous savions à l'avance que toutes ces personnes allaient le faire, car c'est gratuit, profitant de notre essai gratuit, et en retour, elles découvriraient les avantages d'une plateforme comme Scalingo.

Après les premières dizaines de déploiements, l'équipe technique a été alarmée : l'utilisation du disque a augmenté anormalement, après une courte analyse, les applications PokemonGo-Map utilisaient en moyenne 10MBps de bande passante disque. Faisons un calcul simple : 1000 * 10 = 10GBps, même réparti sur plusieurs serveurs, c'est un problème.

Pourquoi l'application utilise-t-elle autant d'IO ? Une réponse : SQLite.

D'habitude, nous décourageons l'utilisation de SQLite non pas à cause de l'utilisation du disque mais parce qu'elle ne correspond pas au modèle PaaS. SQLite écrit ses données dans un seul fichier, généralement suffixé '.db' aux côtés d'une application. Dans le modèle PaaS, le disque autour de votre application est temporaire et toute opération de déploiement ou de redémarrage entraînerait une perte de données car le fichier '.db' disparaîtrait.

Étant donné que les données recueillies à partir de l'API Niantic sont uniquement temporaires, représentant les états des pokémons à un moment donné, il n'était pas un problème d'utiliser SQLite, même si redémarré ou redéployé, les données seraient récupérées à nouveau.

Voici un exemple de l'un de nos outils de surveillance du serveur, devinez quand était le pic d'IO ?

Résoudre le problème d'IO

À partir de ce moment, nous avions deux solutions :

1. Arrêter la fonction de déploiement en un clic pour cette application

2. Trouver un moyen de gérer une telle charge IO

Arrêter les déploiements serait radical mais nous étions sous les projecteurs, il n'était pas intéressant d'un point de vue commercial d'arrêter cela maintenant, cette solution ne devrait être notre dernier recours.

Notre équipe technique a jeté un œil au projet pour voir comment il fonctionne, pour analyser s'il y avait quelque chose à faire pour réduire l'utilisation du disque. Cependant, il n'est pas dans notre politique de modifier le code source de ce qui est déployé sur la plateforme, nous devrions accepter quoi que ce soit et la plateforme devrait s'adapter aux besoins de l'application.

L'un de nous a fait l'hypothèse suivante : « et si la base de données SQLite était en mémoire au lieu d'être sur le disque ? ». C'est une idée qui valait la peine d'y réfléchir. Les données de la base de données SQLite n'étaient jamais vraiment grandes (environ 10 Mo), les placer en RAM augmenterait raisonnablement la consommation de mémoire de l'application et ferait tomber l'IO à... 0.

D'un certain point de vue, c'est un hack sale, d'un autre côté, c'est une solution élégante à un problème très précis. Quelques heures plus tard, nous déployions dans notre cluster de production un crochet détectant si l'application est un PokemonGo-Map, et si c'est le cas, créant dynamiquement un répertoire TMPFS où la base de données SQLite est créée par l'application.

« TMPFS est un système de fichiers temporaire qui réside en mémoire et/ou dans vos partitions d'échange, en fonction de combien vous le remplissez. Monter des répertoires en tant que TMPFS peut être un moyen efficace d'accélérer l'accès à leurs fichiers ou d'assurer que leur contenu est automatiquement effacé au redémarrage. » - Archlinux Wiki

Conclusion

Après avoir redémarré toutes les applications concernées, l'utilisation du disque est tombée à nouveau à la normale et nous avons pu gérer de plus en plus de déploiements sans craindre de diminuer les performances des applications de production de nos clients.

Ce n'est pas dans nos habitudes de développer des choses personnalisées pour des applications spécifiques, mais il est parfois nécessaire de maintenir notre infrastructure stable et son coût normal (pour que notre modèle commercial fonctionne réellement).

Cet article illustre un aspect de l'effervescence de Pokemon Go, d'autres projets liés au jeu sont également hébergés sur la plateforme, avec leur ensemble de problèmes, mais c'est une autre histoire.