Architecture de LionsBase¶
Vue d’ensemble¶
LionsBase est une application hébergée composée de trois composants principaux :
Un serveur web : ce composant reçoit les requêtes HTTP des clients (typiquement un navigateur web). Certaines requêtes sont traitées directement par le serveur web, typiquement les requêtes vers du contenu statique comme les images. Les requêtes vers les pages web sont transmises au serveur applicatif pour un traitement supplémentaire. LionsBase utilise Nginx comme serveur web,
Un serveur applicatif : ce composant est responsable de la gestion de la logique métier. Il prépare dynamiquement les pages web qui seront mises à disposition du client final par le serveur web. PHP-FPM est notre serveur applicatif de choix.
Un serveur de base de données : les données permanentes, comme les enregistrements de membres, sont stockées dans une base de données. LionsBase utilise MySQL comme base de données.
Les composants sont indépendants et peuvent être hébergés sur des serveurs différents.
Architecture¶
LionsBase is deployed on dedicated virtual machines for each Multiple District (or country) so that there is a clear separation of data. Virtual machines are currently based on VMware vSphere for convenience and security but basically requires a LAMP or LEMP stack.
At the moment, LionsBase is physically hosted in a secure datacenter, in Switzerland.
If the multiple district is large enough and thus the load is becoming too high for a single server to handle it, or to serve as a fail-over solution, LionsBase may be installed on multiple servers.
Figure 1 : Vue d’ensemble technique de l’architecture¶
Comme décrit sur la figure Figure 1, l’architecture peut facilement faire face à un nombre de clubs croissant en augmentant d’abord la capacité et la puissance des composants puis en les dupliquant :
- Augmentation de capacité (alias évolutivité verticale)
Comme l’infrastructure est virtualisée, dès que la charge ou le nombre de clubs augmente, la capacité des serveurs (c-à-d. les machines virtuelles) sera augmentée en conséquence (en ajoutant plus d’espace disque, de CPU ou de RAM).
- Augmentation de ressources (alias évolutivité horizontale)
Mise à part l’augmentation de capacité, de nouveaux serveurs peuvent être déployés et complètement configurés en l’espace de quelques minutes. Les requêtes pour les clubs sont ensuite redirigées vers le serveur de nom en utilisant les DNS. Nous comptons pour cela sur un service DNS anycast globalement distribué.
Scaling the web and application layer is not difficult. However, scaling the database is more challenging. Currently, our architecture supports one hot replica of the master server and several read replicas. Scaling further is just a matter of deploying a second similar setup. That is, our architecture will easily follow the growth of our customers.
Sécurité¶
Notre infrastructure suit les meilleures pratiques en terme de sécurité. En effet, chaque serveur est tenu à jour, totalement patché et sécurisé (contrôle d’accès, pare-feu, etc.). Pour accroître encore plus le niveau de sécurité, un reverse proxy analyse chaque requête à destination de notre infrastructure :
Un pare-feu web applicatif (WAF) surveille les requêtes au niveau applicatif et empêche différentes attaques comme les injections SQL, le XSS, les robots, les aspirateurs de contenu, les DDoS, etc.
Le proxy place les ressources statiques (images, fichiers CSS, JS, etc.) dans un cache globalement distribué (c.-à-d. un CDN) afin d’améliorer les performances des sites.
Le proxy se charge aussi de la gestion SSL.
Le reverse proxy est pris en charge par un fournisseur tiers (principalement pour protéger notre infrastructure des DDoS).
Serveurs de noms (DNS)¶
Comme LionsBase est une application hébergée, elle a besoin de contrôler les paramètres DNS de votre domaine, ceci afin de garantir la sécurité (SSL, WAF, anti-DDoS, etc.) et d’offrir une bonne expérience à vos utilisateurs. À cette fin, vous n’avez qu’à changer les serveurs DNS utilisés par votre domaine auprès de la société gérant votre nom de domaine.
Surveillance¶
Chaque serveur est vérifié toutes les 5 minutes et des alertes sont envoyées en cas de problème.
Échange d’information¶
La figure Figure 2 montre le processus général lorsqu’un membre accepte de partager ses informations (veuillez lire la section Échange d’information dans l’application mobile pour plus de détails).
Figure 2 : Vue d’ensemble de l’échange d’information¶
What is really important to understand is that the LionsBase data associated to a given multiple district is completely separate from another multiple district. In short, each multiple district runs its own dedicated LionsBase database, code (application) and naturally assets (documents, images and photos, …).
When members choose to share their information, a flag in the source database indicates that, together with the list of fields that may be shared. A daily task exports the corresponding data as a flat file and puts it in an « import » directory of the other multiple district sandboxes where another task will then iterate over the available external sources of data and import them into a separate space of its LionsBase database.
Note
Members who change their mind and do not share their profile anymore will get their data getting wiped out of the other multiple districts after the next daily import of data.