internship-novaquark/report/R_technique.md

Aspects scientifiques et techniques

Analyse des plates-forme d'informatique dans les nuages

Objectifs

Les serveurs du jeu seront regroupés au sein d'une structure permettant facilement d'adapter leur nombre en fonction du besoin (fortement en corrélation avec le nombre de joueurs inscrits et connectés).

Depuis quelques années, un grand nombre de plate-forme se développent, fournissant un service clef en main ; mais des solutions libres sont également disponibles lorsque l'on désire s'occuper du service manuellement.

Ici, l'objectif était de trouver les avantages et les inconvénients de chaque fournisseur et de contre balancer cette analyse par rapport aux solutions à mettre en place soi-même.

Alternatives possibles

Développer une solution de mise à l'échelle automatique, parfaitement adapté à nos besoins n'était pas envisageable : cela aurait réclamé une équipe dédiée au développement de cette solution alternative. Comme ce n'est pas le cœur de métier du studio, cette solution a d'emblée été écartée.

Cadre imposé

Propositions retenues

Les fournisseurs de service d'hébergement dans les nuages retenus sont :

• Amazon Web Services Elastic Cloud 2 ;
• Digital Ocean ;
• Gandi ;
• Google Compute Engine ;
• Ikoula ;
• Linode ;
• Lunacloud ;
• Numergy ;
• Rackspace ;
• Windows Azure.

Les solutions libres retenues sont :

• Ecalyptus ;
• Libvirt.

Résultats obtenus

%FIXME

Analyse des outils de déploiement automatique

Objectifs

Les outils de déploiement automatique vont éviter toutes les problématiques de configuration des différents serveurs que peuvent être le manque d'harmonisation, les difficultés de réalisation des mises à jour, les besoins de tests de l'environnement avant la mise en production, le redéploiement rapide d'une version stable ou précédente.

Il est nécessaire de configurer de nombreuses machines dans différents cadres :

• ajout d'un nouveau serveur au sein du cluster (fournir le contexte) ;
• configuration d'une machine virtuelle à destination des développeurs ;
• configuration des serveurs annexes (sites web, bases de données, monitoring, ...).

Alternatives possibles

Dans de nombreux environnements chaque machine est configurée à la main par un administrateur système, a chaque étape, une erreur humaine peut venir interférer dans la procédure de mise à jour.

Cette solution est évidemment à écarter si l'on veut garder le contrôle de son système d'information et pouvoir faire face à tout type de problème.

Cadre imposé

Propositions retenues

Les outils de déploiment automatique retenus sont :

• Ansible ;
• Capistrano ;
• CFEngine ;
• Chef ;
• Fabric ;
• Puppet.

Résultats obtenus

%FIXME

Analyse des solutions de virtualisation

Objectifs

La virtualisation peut nous être utile à plusieurs niveaux :

• la mise en place d'un environnement de tests de plusieurs machines ;
• l'utilisation d'un environnement standardisé pour les développeurs ;
• le déploiement d'environnements standardisés et minimalistes.

Si dans une contexte de production les serveurs sont utilisés à une valeur proche de leur puissance maximale, pour un environnement de test, il est tout à fait envisageable de regrouper les différentes machines nécessaire au sein de plusieurs machines virtuelles d'une même machine physique, dédiée aux tests.

Pour les développeurs, l'installation de l'environnement de développement n'est pas toujours facile (surtout s'ils doivent alterner entre deux systèmes d'exploitation différent) et requiert une certaine standardisation (version précises de certaine bibliothèques, paquet particulier). La virtualisation permet de leur fournir un environnement clef en main qu'ils n'ont pas à maintenir.

Sont apparues ces dernières années des technologies prônant le déploiement en production de machines virtuelles ou conteneur. Cela permet d'avoir une série de machine hôte dédiée au déploiement et des machines virtuelles minimalistes et standardisées (pas d'écoute SSH par exemple).

Propositions retenues

Sous GNU/Linux, les solutions retenues sont :

• Docker ;
• Libvirt ;
• Linux Kernel-based Virtual Machine (KVM) ;
• Linux Containers (LXC) ;
• Oracle VirtualBox.

Sur Windows, seul Oracle VirtualBox répondait aux contraintes, en particulier car le logiciel Boot2Docker s'intègre uniquement à cette solution.

Résultats obtenus

Globalement, les technologies de virtualisation de type hyperviseur n'ont plus guère d'avantages face aux conteneurs : ils permettent de garantir un niveau de sécurité et d'isolation quasi-identique, sans avoir la lourdeur de gestion d'autant de noyau que l'on veut lancer de machines.

Docker et LXC ont donc été retenus. La première version stable de Docker est sortie pendant mon stage, ce qui a été déterminant pour le choix de cette solution. LXC reste dans la course pour tout ce qui nécessite une configuration avancée que ne permettrait pas de faire Docker.

Conception d'un programme de relevé de métriques système

Objectifs

Afin de pouvoir déterminer le moment optimal pour démarrer un nouveau serveur, il faut relever un certain nombre de métrique et déterminer dans une première phase l'indicateur le plus adapté.

Cadre imposé

Avant mon arrivée dans l'entreprise, mon maître de stage a fait le choix de la base de données InfluxDB pour le stockage des métriques (aussi bien système que business).

Propositions retenues

La base de données retenue est toute récente ; c'est pourquoi il n'existait encore aucun programme pour faire simplement un relevé de métriques système (consommation CPU, mémoire vive disponible, bande passante, ...). Il a donc été choisi de le développer.

Le langage retenu fut le Go : le langage compilant les binaires statiquement, il n'y aurait donc rien de plus à installer sur les machines sur lesquels nous devrons faire les relevés.

Résultats obtenus

Le projet a été terminé et mis en ligne publiquement sur GitHub sous licence CC0.

Mise en place d'un processus de livraison du serveur à destination des développeurs du client

Objectifs

Notre jeu se basant sur un serveur, chaque personne utilisant le client (développeur ou graphiste) a donc besoin de se connecter à un serveur « stable » afin de pouvoir visualiser l'impact de ses modifications dans l'environnement de jeu.

Chaque développeur, pour ses tests peut avoir besoin d'une version particulière du serveur : une version avancée pour les développeurs travaillant sur l'intégration réseau, une version stable pour les graphistes, ... Et chacun peut avoir besoin de faire des tests dans un environnement particulier.

Ainsi, chacun devrait avoir accès à un serveur de jeu dédié et à un serveur de jeu global (lorsqu'il est question de faire des tests à plusieurs).

Cadre imposé

Le temps passé au développement est primordial comparé au temps passé à tenter de configurer l'environnement à partir de la documentation. Une solution clef en main où le moins de connaissances préalables sont nécessaire est un plus.

Propositions retenues

Pour la mise en place de ce processus, il a été retenu la mise à disposition :

• de machines virtuelles pré-configurées : l'équipe serveur met à disposition du reste de l'équipe des fichiers .ova : un disque virtuel au format VMDK associé à une configuration de machine virtuelle au format OVF ;
• de conteneurs associés à des scripts d'automatisation ;
• d'un conteneur sur une machine dédiée : l'équipe serveur s'occupe de mettre en place les conteneurs en fonction des besoins de chacun, sans avoir à gérer les problèmes lié à la configuration personnelle des machines de chacun.

Difficultés

Chacune des solutions listée ci-dessus a été testée. La première solution a souffert d'un manque de consultation des besoins des développeurs : travailler dans une machine virtuelle en ligne de commande n'est en général pas à la portée des développeurs plus habitués à Visual Studio.

%FIXME parler de l'interface console

Dans un soucis d'harmonisation des technologies, Docker a été retenu dans un second temps pour répondre également aux problématiques de déploiement futurs.

Après une semaine de test sur les machines des développeurs, de nombreux problèmes m'ont été remontés. Ces problèmes étant liés d'une part à la difficulté de configuration automatique des machines sous Windows et d'autre part à la complexité grandissante des scripts automatisant pourtant seulement le téléchargement et l'exécution d'un conteneur dans un environnement connu, il a été décidé que ces machines virtuelles ne seraient plus distribuées aux développeurs : ils disposeront d'un accès sur une machine virtuelle maintenue par l'équipe en charge de l'administration système.

Résultats obtenus

Compte tenu de la diversité des systèmes employés et de la non-maîtrise de ceux-ci par les développeurs (filtrage de ports par un anti-virus nouvellement installé, version différentes de Windows, ...), la solution utilisant des conteneurs contrôlés par l'équipe serveur sur une machine dédiée a été retenue.

Conception de l'architecture de test de monté en charge

Objectifs

Une fois les premières versions du serveur livrées, nous nous sommes rapidement intéressé à ses capacités : en particulier le nombre maximum de joueurs pouvant être accueillit.

Propositions retenues

En tant que start-up, nous avons eu un certain nombre de crédit sur Amazon Web Service afin de tester et démarrer notre activité sur leur plate-forme.

Nous avons donc utilisé un certain nombre de nos crédits afin de lancer 20 machines virtuelles exécutant chacune plusieurs clients.

Résultats obtenus

Dans un premier temps, la monté en charge montrait que le serveur ne permettait pas de dépasser 250 joueurs. Au delà, l'analyse qui s'en est suivie a montré que le scheduler de la bibliothèque d'acteurs que nous utilisions ne faisais pas correctement son travail : il en résultait une surcharge des canaux de diffusion, entraînant le plantage du serveur.

Ce problème a été corrigé dans la version suivante de la bibliothèque d'acteurs. La nouvelle monté en charge a permis d'atteindre cette fois plus de 700 joueurs simultanément, à ce moment, c'était bien le CPU qui était limitant et il n'en résultat pas de plantage du serveur.

Conception de l'architecture des serveurs

Objectifs

Alternatives possibles

Cadre imposé

Propositions retenues

Difficultés

Résultats obtenus

Intégration de métriques dans le serveur

Objectifs

Les métriques relevées précédemment concernait le système : consommation CPU, utilisation de la mémoire et de la bande passante, ... Pour des besoins statistiques (et à terme business), il est nécessaire d'intégrer au serveur l'envoi de métrique telles que le nombre de joueurs inscrits, connectés, ...

Difficultés

Le serveur étant écrit en C++, il est nécessaire d'utiliser une bibliothèque C ou C++ pour s'interfacer avec la base de données. Malheureusement, comme elle est récente, cette bibliothèque n'avait pas encore été développée.

J'ai donc pris le soin de la développer puis de la proposer aux développeurs de la base de données qui l'ont intégré, La bibliothèque est désormais disponible sur GitHub : https://github.com/influxdb/influxdb-c

Résultats obtenus

Le travail d'intégration de métriques a d'abord conduit à la réalisation