Quand on parle de Legends of Code, on pense avant tout aux équipes d’étudiants qui s’affrontent par IA interposée, développée en Java, C++ ou C#. Aujourd’hui, nous vous dévoilons les coulisses de ce concours de programmation, à travers l’architecture technique mise en oeuvre sur Amazon Web Services pour répondre à la problématique de performance engendrée par plusieurs dizaines d’IA s’affrontant plusieurs fois par heure.

Legends of Code se déroule sur toute une journée, et chaque heure un round d’affrontement des IA est organisé : l’IA d’un binôme joue contre chacune des autres IA, sur chaque carte disponible. A l’issue de cet affrontement, un classement est établi, et à la fin de la journée, la moyenne des rounds donne le classement final.

Le challenge technique

La plateforme du LoC s’articule autour de plusieurs processus permettant une intégration continue. Au début de la journée, chaque équipe dispose d’un repository git de code contenant une IA basique. Cette IA joue de manière « random », son intérêt est de donner un exemple de code et pouvoir rapidement se former sur l’API. A chaque fois que l’équipe push un commit dans ce repository, un job Jenkins va récupérer ce code, builder cette IA (en Java, C++ ou C#), versionner ce build et enfin le déployer dans un repository local à Jenkins.

Un second jobs Jenkins, customisé, va leur permettre de choisir une des précédentes IA buildées, pour pouvoir la déployer sur l’environnement de production. Toutes les heures, le game-controller liste les IAs disponibles, et les fait toutes jouer sur chacune des cartes (maps). Le résultat de ce round est ensuite transmis en JSON à un site web (écrit en play2) que les étudiants peuvent consulter.

Lors de la précédente édition du LOC, nous nous sommes heurtés à une problématique de performance due au nombre de parties à jouer à chaque round. En effet, afin d’évaluer l’efficacité des IAs des étudiants, le principe est de les faire jouer sur des cartes favorisant certaines stratégies d’attaque ou de défense. La meilleure IA étant bien évidemment celle capable de gagner sur chacune des cartes.

Ainsi, avec de nombreuses IAs à faire jouer (dû au nombre élevé de participants), et de nombreuses cartes pour les évaluer, nous avions trop de parties à jouer par heure. Nous avions donc été contraints de limiter le nombre de cartes pour tenir les délais, un round devant durer moins de 10 minutes.

En effet, notre infrastructure se composait de seulement 2 VMs sur lesquelles tournaient:

• Gitblit (repository Git)
• Jenkins (Continuous integration)
• Nexus (repository Maven)
• Gamestat-web (site web de résultats),
• Une game-room de développement (pour que les étudiants puissent tester leurs IAs avant de les livrer)
• Une game-room de production (pour jouer les rounds)

Il va sans dire que ces VMs avaient une consommation CPU proche de 100% durant toute la journée.

C’est pourquoi il nous fallait trouver un moyen d’utiliser plus de machines, pour plus de puissance de calcul, et de simplifier le déploiement et la maintenance de ces machines.

L’utilisation du cloud Amazon

Nous avons utilisé le cloud Amazon Web Services en séparant les process sur différentes machines :

• VPN
• DNS
• Gitblit et Jenkins sur une même instance
• 7 instances c3.xlarge pour les game-room de prod
• 1 instance c3.xlarge pour la game-room de dév
• 1 instance avec Docker installé et démarrant les instances :
  • Nexus
  • Sonarqube (pour évaluer la qualité du code des étudiants)
  • Gamestat-web
  • Game-controller

Nous avons aussi modifié le game-controller afin qu’il fasse du load-balancing et répartisse les parties à jouer sur les 7 game-room de production. Ce mécanisme de distribution de la charge nous a permis de diminuer le temps d’exécution des rounds à moins de 10 minutes.

Les bénéfices d’une architecture basée sur le cloud AWS

Nous avons constaté une amélioration sans précédent des temps d’exécutions : 8 minutes d’exécution pour chaque round, avec 10 étudiants supplémentaires, et 3 fois plus de cartes par rapport à la précédente édition. De plus, l’administration de la plateforme et des machines a été facilitée par l’ergonomie de la console Amazon EC2. Durant la phase de développement de projet, cela a représenté un gain de temps non négligeable. Enfin, tous les développements ont été faits et testés sur la plateforme de production en mode DevOps, nous assurant ainsi que le jour J, tout se passerait comme prévu durant les tests.

Les perspectives d’évolution de l’architecture

L’évolution de l’architecture du LOC, et son amélioration, sont encore en cours de discussion. Cependant nous étudions les possibilités suivantes :

• Utiliser Amazon S3 pour stocker nos maps et les builds d’IA des étudiants
• S’intéresser à CodeDeploy, CodePipeline et CodeCommit (nouveautés d’AWS, tout juste annoncées) nous permettant peut-être de remplacer Gitblit et Jenkins.