311 lines
11 KiB
Markdown
311 lines
11 KiB
Markdown
# 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
|