Deolan : Migration vers une architecture Cloud native

Deolan est une startup française créée en 2007 dans le secteur de l’aérien. Parmi ses principales activités, on note une plate-forme de communication des flux d’informations entre les différents acteurs que sont par exemple les tours opérateurs et les compagnies aériennes. L’équipe qui forme cette entreprise possède une très bonne vision produit ainsi qu’une maîtrise des technologies et méthodologies pour y parvenir. Elle pratique l’agilité pour la gestion du backlog et met en oeuvre une architecture applicative efficace.

La position centrale de leur plate-forme s’illustre bien à travers une des fonctionnalités courantes de leurs services. Par exemple, ils sont en charge de communiquer la liste des passagers d’un tour opérateur à la porte d’embarquement de l’aéroport. Autant dire que les opérations ne peuvent pas supporter d’indisponibilités ni de failles. La transmission des flux est quant à elle réalisée sur des serveurs FTP ou par emails. Les clients n’ayant pas forcément le souhait d’investir dans l’intégration d’une API Deolan.

Activité imprévisible et roadmap ambitieuse

Le coeur de leur activité étant directement lié à la fréquentation des passagers sur les avions de ligne, la charge sur la plate-forme suit naturellement cette fluctuation. Par exemple, lors de la période estivale, il n’est pas rare de subir une augmentation de la charge due à un triplement du nombre de passagers, puis quelques semaines plus tard, retrouver une diminution là aussi importante. Nous noterons que ces éléments sont soit de nature prévisible tels que les périodes estivales ou non prévisibles (telluriques, climatiques, sécuritaires … ). En résumé, une problématique complexe qui ne permet pas de réaliser un “capacity planning” fiable et réaliste. L’infrastructure actuelle historique souffre de cette incapacité à absorber sereinement ces pics malgré un socle applicatif stable.

Le graphique ci-dessus représente bien cette fluctuation de la volumétrie des données de passagers gérés par la plate-forme Deolan. On constate aisément des variations lors des périodes estivales ainsi qu’une augmentation générale.

Dernier point, les solutions SaaS aujourd’hui proposées par Deolan s’adressent principalement à des grands comptes. Une des stratégies porte sur un marché plus vaste mais nettement plus morcelé, celui des TPE et PME. Dans ce cas de figure, un fournisseur Cloud apportera toute la flexibilité nécessaire en cas de succès ou d’échec de la stratégie. Cela permet de limiter la perte en cas d’échec ou de l’accélérer en cas de réussite, ce qui n’est pas réalisable chez un hébergeur traditionnel.

Solution

Une solution dont ils ont commencé à dessiner les contours afin de résoudre ces problèmes est de prendre les services d’un fournisseur Cloud, en l’occurrence Amazon Web Services. Initialement, vu comme un fournisseur capable d’héberger une base de données ou des serveurs applicatifs isolés, l’équipe souhaite accélérer la transformation de leurs applications afin qu’elles deviennent Cloud natives (terme décrivant une application qui exploite tous les bénéfices d’une plate-forme Cloud telle que la scalabilité).

Dans un premier temps, cette migration se focalise sur deux composants essentiels pour la réception des informations à savoir le FTP et le serveur de mails. Cette tâche est actuellement accomplie par des instances ProFTPd et Postfix. En plus d’être chronophage, ces serveurs sont surchargés lors des pics d’activités. Accroître la taille de l’infrastructure n’est plus une solution viable à cause des coûts que cela représente (coût du hardware et aussi coût humain).

Après plusieurs itérations d’ateliers et de réflexions sur la mise en place d’une alternative Cloud, l’infrastructure suivante est née :

[

Nous ne représentons ici qu’une vision conceptuelle d’une partie de la plate-forme. Elle nous permettra d’illustrer les choix d’architectures que nous avons pris de concert :

1. Route53 est utilisé pour “load balancer” les instances supportant le serveur FTP. Le dispatch s’effectue en fonction du “health check“.
2. La gestion des emails se fera grâce au service Amazon SES. Service d’envoi et de réception de mails. Parmi les grands atouts de cette solution, on notera le taux de déliverabilité excellent puisqu’il est identique à celui de la partie e-commerce d’Amazon. Et bien évidemment la dimension sécurité, financière et managée de la solution.
3. Les serveurs FTP sont installés sur des instances Micro à travers une “launch-configuration” dans un groupe d’auto scaling. Ils possèdent chacun une base de données qui est un répliqua en lecture de la base de données maître se trouvant dans le datacenter Deolan. Cette base contient les informations de connexion des utilisateurs. Il n’ a pas été décidé de prendre une base RDS vu la petite volumétrie que cela représente. Ces serveurs utilisent S3 comme solution de stockage grâce à un point de montage réalisé avec s3fs-fuse.
4. La connexion entre le data center Deolan et AWS s’effectue à travers un VPN.
5. Toutes les informations provenant du FTP et des emails sont stockées dans un stockage S3 et cryptées. Les avantages de cette solution sont nombreux, on notera en plus des légendaires taux de disponibilité et de durabilité la très bonne intégration de SES vers S3 (S3Action). Ainsi, tous les emails reçus sont automatiquement copiés dans le bucket adéquat.
6. Tous les évènements d’objets créés dans S3 génèrent un message dans une queue AmazonSQS. Ainsi, tous les fichiers et emails reçus seront traités par les consommateurs de cette queue.
7. Des instances réparties suivant différentes zones de disponibilité dans un groupe d’auto scaling consomment la queue. Il est ainsi possible d’augmenter ou de diminuer le nombre de consommateurs pour dépiler plus ou moins rapidement le traitement des informations entrantes.

Dernier point concernant la mise en place de cette nouvelle infrastructure : la stratégie adoptée pour mettre en oeuvre cette migration a été de posséder les deux environnements : legacy et AWS simultanément et de dispatcher le trafic en fonction du domaine attaqué. Cette stratégie apporte plusieurs bénéfices :

1. Pas de migration “big bang” et le lot de stress qui l’accompagne.
2. Qualifier la pertinence de l’infrastructure sur des environnements de tests.
3. Effectuer de l’AB Testing en ne migrant que certains clients dans un premier temps.

Pour ce dernier point, nous ne sélectionnerons que les clients qui auront moins de contraintes stratégiques et avec lesquels nous aurons pu récupérer une validation de cette technique.

“Guidelines”

Des critères ont permis de guidés et de bornés certaines de nos réflexions. Nous ne les citerons pas tous dans cette article ou en tout cas, pas de manière exhaustive :

1. La réversibilité : effectuer en permanence cette gymnastique de l’esprit qui consiste à déterminer la quantité de travail à réaliser pour porter cette architecture chez un autre fournisseur Cloud ou On-premise. Bonus : vous vous apercevrez que cet exercice vous oriente souvent vers une architecture où les composants sont correctement découplés.
2. La sécurité : vous portez votre plate-forme sur le Cloud alors vous devez être vigilant sur les questions de sécurité. La bonne isolation des environnements et aussi la bonne exploitation des fonctionnalités offerte : politique de compartiment, ACL, Server Side Encryption …
3. La scalabilité : nous utiliserons bien les mécanismes de scaling automatique offerts par notre fournisseur. Chez AWS, cela passera par la création de “launch configuration” pour déclencher le provisionning de nouvelles instances dans un “scaling group” en fonction du “healt-check” retourné à route 53.
4. Le coût : malgré le côté élastique de l’infrastructure, on pourra effectuer quelques simulations notamment pour valider que certains choix d’architecture sont judicieux.  Il n’est pas nécessaire de chercher à tout prix une simulation parfaite puisque si votre infrastructure est bien dessinée, le coût qu’elle représente sera parfaitement adapté à la charge, bref prévisible.

L’expérience Deolan est très intéressante puisqu’elle montre qu’il est possible d’avoir une approche itérative quant la migration de son architecture applicative vers une plateforme Cloud. Né initialement d’une envie d’amélioration de leurs services, l’architecture cible permet d’absorber sereinement un marché plus important sans cette Épée de Damoclès qu’est une infrastructure traditionnelle. Elle offre aussi un niveau de fiabilité accrue qui à travers une fréquence des incidents plus rare offre un niveau de confiance ainsi plus élevé. Ce dernier point étant un facteur clé pour projeter le futur de la plateforme ainsi que le business sus-jacent.