Surfer sur la hype Pokémon Go : minimiser l’impact sur l’infrastructure

À moins d’avoir passé l’été coupé du monde, vous avez forcément entendu parler de Pokémon Go, le jeu en réalité augmentée lancé par Niantic Labs. Continent après continent, pays après pays, le jeu a connu une adoption fulgurante. Et avec cette popularité croissante, de nombreuses applications autour du jeu ont vu le jour — c’est là que notre histoire commence.

L’émergence des applications autour de Pokémon Go

Dans les six jours qui ont suivi la sortie initiale de Pokémon Go, des joueurs et développeurs du monde entier ont commencé à analyser le fonctionnement de l’application pour comprendre comment elle communiquait avec les serveurs de Niantic. Ils ont rapidement publié un premier client API non officiel en Python.

Quelques jours plus tard, des clients étaient disponibles dans de nombreux langages, entraînant la création d’un grand nombre d’applications par la communauté. Les principales questions auxquelles ces outils tentaient de répondre étaient :

• « Quels Pokémon y a-t-il autour de moi ? »

• « Où trouver les Pokémon rares que je cherche depuis des jours ? »

Le 16 juillet (soit deux jours après la publication de la bibliothèque Python), le projet PokemonGo-Map est lancé. Il propose une application simple permettant de visualiser les Pokémon autour d’une position donnée. Le serveur simule un utilisateur se déplaçant dans une zone et affiche les Pokémon détectés sur une carte Google Maps.

Le projet a rapidement figuré parmi les tendances GitHub pendant plusieurs semaines, surfant sur la popularité du jeu. De nombreuses personnes ont alors souhaité :

• utiliser l’application

• la déployer

• y contribuer

C’est à ce moment que nous avons pensé que Scalingo pouvait aider à résoudre le second problème.

Déploiement en un clic

En décembre précédent, nous avions lancé notre fonctionnalité de déploiement en un clic. Elle permet d’ajouter un bouton sur une page web ou un dépôt GitHub afin de déployer un projet open source en un seul clic.

Nous avons proposé une pull request au projet PokemonGo-Map, qui a été acceptée. Dès lors, les visiteurs pouvaient déployer l’application sur Scalingo en moins de deux minutes.

SQLite : Houston, nous avons un problème

Près de 1 000 instances de l’application ont été déployées en quelques semaines. Nous nous y attendions : l’offre gratuite permettait aux utilisateurs de tester facilement la plateforme.

Mais après quelques dizaines de déploiements, l’équipe technique a été alertée : l’utilisation disque augmentait de façon anormale. Après analyse, chaque instance de PokemonGo-Map utilisait en moyenne 10 MB/s de bande passante disque. Un calcul rapide :

1000 × 10 MB/s = 10 GB/s

Même réparti sur plusieurs serveurs, cela posait problème.

La cause ? SQLite.

Nous déconseillons généralement SQLite, non pas pour des raisons de performance brute, mais parce qu’il ne correspond pas bien au modèle PaaS. SQLite écrit ses données dans un fichier local (.db), alors que sur une plateforme PaaS, le disque est éphémère : un redémarrage ou un déploiement entraîne la perte des données.

Dans ce cas précis, ce n’était pas bloquant : les données issues de l’API Niantic étaient temporaires et pouvaient être régénérées.

Résoudre le problème d’IO

Deux options s’offraient à nous :

• désactiver le déploiement en un clic pour cette application

• trouver une solution pour absorber cette charge disque

La première solution était radicale, mais peu souhaitable d’un point de vue produit. Nous avons donc exploré la seconde.

Après analyse du projet, une idée a émergé :

Et si la base SQLite était stockée en mémoire plutôt que sur disque ?

Les données étant relativement légères (environ 10 MB), les stocker en RAM permettait de réduire drastiquement les accès disque… jusqu’à zéro.

Quelques heures plus tard, nous déployions un mécanisme détectant les applications PokemonGo-Map et créant dynamiquement un système de fichiers TMPFS pour héberger la base SQLite.

TMPFS est un système de fichiers temporaire résidant en mémoire (et/ou swap). Il permet d’accélérer l’accès aux fichiers et garantit leur suppression automatique au redémarrage.

Conclusion

Après redémarrage des applications concernées, l’utilisation disque est revenue à la normale. Nous avons pu continuer à accueillir de nouveaux déploiements sans impacter les performances des applications en production de nos clients.

Ce n’est pas dans nos habitudes de développer des solutions spécifiques à une application, mais cela peut parfois s’avérer nécessaire pour garantir la stabilité de l’infrastructure et maîtriser les coûts.

Cet article illustre un aspect de l’effervescence autour de Pokémon Go. D’autres projets liés au jeu ont également été hébergés sur la plateforme, chacun avec ses propres défis — mais cela fera l’objet d’une autre histoire.