Architecture d'un service : composants, dépendances et flux

L'architecture d'un service est la description de tout ce dont il a besoin pour fonctionner : ses composants (application, base de données, serveurs, réseau), les autres services dont il dépend (annuaire, DNS, messagerie, sauvegarde) et les flux réseau qui les relient. La dessiner avant de déployer, c'est savoir ce qu'il faut installer, ce qu'il faut ouvrir sur le pare-feu, ce qu'il faut tester et ce qui peut tomber en panne. Ce chapitre décompose un service, recense ses dépendances, écrit sa matrice des flux et calcule la disponibilité d'une chaîne de composants.

Les composants d'un service

Un service vu par l'utilisateur, c'est une adresse dans un navigateur ou une icône sur un poste. Derrière, on retrouve presque toujours les mêmes familles de composants, quel que soit le service. Les lister une par une est la meilleure façon de ne rien oublier.

Trois vues d'une même architecture

Selon la personne à qui tu parles, tu ne dessines pas la même chose. On distingue trois vues, de la plus proche du métier à la plus technique :

Dans un portfolio, une vue technique lisible est souvent la plus utile ; pour une application, ajoute la vue applicative, qui montre comment les briques logicielles se parlent. Voici la vue technique de Prêt'Matos, où l'on voit aussi les briques applicatives dans la machine virtuelle.

Les dépendances et le mode dégradé

Une dépendance est un autre service ou composant sans lequel le tien ne fonctionne pas, ou fonctionne moins bien. Pour chacune, pose trois questions : qu'est-ce qui se passe si elle tombe ? Le service peut-il continuer en mode dégradé, c'est-à-dire en rendant l'essentiel avec des fonctions en moins ? Qui faut-il prévenir ?

Ce tableau prépare trois choses : les tests d'intégration (on vérifie chaque liaison, chapitre 4), la supervision (on surveille chaque dépendance forte, chapitre 7) et la documentation du support (le niveau 1 sait quoi répondre quand un utilisateur ne reçoit plus ses rappels).

La matrice des flux

La matrice des flux liste toutes les communications réseau dont le service a besoin : qui ouvre la connexion (la source), vers qui (la destination), avec quel protocole et quel port, et pourquoi. C'est le document que l'administrateur du pare-feu attend pour écrire ses règles, et celui que tu relis quand un flux est bloqué.

Quatre règles pour une matrice juste :

1. La source est celle qui ouvre la connexion. Zabbix interroge l'agent (F7) : la source est srv-journaux. Le pare-feu à états laisse passer les réponses sans règle de retour (pare-feu à états).
2. Un flux par besoin, avec sa raison. Une ligne « srv-pretmatos vers tout, tous ports » n'est pas une matrice, c'est un aveu d'ignorance.
3. Rien vers la base de données depuis l'extérieur de la VM. Le conteneur MySQL n'est joignable que par l'API, sur un réseau Docker interne : aucun flux 3306 dans la matrice.
4. Le chemin compte. Un flux à l'intérieur d'un même VLAN (F5) ne passe pas par pfSense : il ne se filtre qu'avec le pare-feu de la machine. Un flux entre deux VLAN se règle sur l'interface d'entrée de la source (de la matrice des flux aux règles).

Les ports qui reviennent le plus souvent dans les services du BTS :

Les points uniques de défaillance

Un point unique de défaillance (single point of failure, SPOF) est un composant dont la panne arrête tout le service, parce que rien ne le remplace. Dans l'architecture de Prêt'Matos, il y en a plusieurs : l'hôte Proxmox (s'il n'est pas en cluster), la VM srv-pretmatos, le conteneur MySQL, le pare-feu. L'annuaire, lui, n'en est pas un : deux contrôleurs de domaine se remplacent.

Supprimer tous les SPOF coûte cher : un deuxième serveur, une base répliquée, un pare-feu de secours. Pour un service interne utilisé aux heures de bureau, on accepte souvent un SPOF à condition de savoir le réparer vite : une sauvegarde testée, une procédure de restauration écrite, un délai annoncé. C'est ce que dit la fiche service : 4 h ouvrées pour restaurer. Le cours Haute disponibilité montre comment supprimer un SPOF quand le besoin le justifie.

La disponibilité d'une chaîne de composants

La disponibilité est la part du temps où le service fonctionne : 99 % sur un mois de 30 jours, c'est 7 h 12 min d'arrêt au plus. Quand un service a besoin de plusieurs composants à la fois (montés en série), sa disponibilité est le produit des leurs. Quand deux composants se remplacent (montés en parallèle), l'ensemble n'est indisponible que si les deux le sont en même temps.

En série    : A = A1 × A2 × … × An
En parallèle : A = 1 − (1 − A1) × (1 − A2)

Pour Prêt'Matos, en prenant pour chaque composant une disponibilité estimée (constatée sur l'année passée pour l'existant) :

A = 0,999 × 0,998 × 0,995 × 0,9999
  ≈ 0,99192, soit environ 99,19 %

Le service est moins disponible que son composant le plus faible (99,5 %) : chaque maillon retire un peu. Sur 30 jours (720 heures), cela laisse environ 5 h 49 min d'arrêt. Avec un seul contrôleur de domaine à 99 %, on tomberait à 98,21 % : environ 12 h 53 min d'arrêt par mois. Le second contrôleur fait gagner plus que n'importe quel réglage de l'application. Les calculs détaillés et les pièges (plage de service, maintenances prévues) sont dans le cours Supervision.

Documenter l'architecture

Le dossier d'architecture technique (DAT) rassemble tout ce chapitre en un document que l'équipe d'exploitation garde à jour. Pour un service de PME, quelques pages suffisent :

La date de fin de maintenance de chaque composant compte autant que sa version : Node.js 24 est maintenu jusqu'à fin avril 2028, MySQL 8.4 est une version à support long. Un composant hors maintenance ne reçoit plus de correctifs de sécurité. Le cours Documentation technique apprend à rédiger ce type de dossier.

Exercices