Expert en architecture des SI · Bloc 5

GeoTrack

Migration d'une plateforme de géolocalisation de flotte vers une architecture cloud haute disponibilité.

Quentin Kaczmareck

C5.1.1 → C5.4.1

Déroulé

Quatre temps

PARTIE 1

Comprendre

L'existant, les contraintes, le besoin.

C5.1.1 · C5.1.2 · C5.1.3

PARTIE 2

Concevoir

L'architecture cible et ses frontières.

C5.2.1 · C5.2.2

PARTIE 3

Construire

La migration et son automatisation.

C5.3.1 · C5.3.2

PARTIE 4

Prouver

La démonstration et les mesures.

C5.2.3 · C5.3.3 · C5.4.1

Chaque planche porte en haut à droite la compétence qu'elle documente. Une démonstration live intervient en partie 4.

2

Contexte

Pourquoi ce projet a démarré

DÉCLENCHEUR

Un partenariat commercial

Un accord avec un équipementier ouvre la voie à une multiplication des installations de balises.

QUESTION 1

L'infrastructure tiendra-t-elle ?

Capacité de traitement et résilience à une montée de charge que personne n'a mesurée.

QUESTION 2

À quel coût ?

Les nouvelles conditions de licence de l'hyperviseur font grimper la facture, sur une capacité déjà surdimensionnée.

QUESTION 3

La sécurité actuelle est-elle suffisante ?

Aucun contrôle automatisé sur la chaîne de livraison, et un cloisonnement à établir avant d'ouvrir la plateforme à plus de clients.

12 400

véhicules aujourd'hui

50 000

objectif à 24 mois

×4

de charge à absorber

3

1

Partie 1

Comprendre

L'existant, les contraintes, le besoin.

C5.1.1 · C5.1.2 · C5.1.3

4

C5.1.1 · Cartographie

C5.1.1

Le SI existant

Hyperviseur mutualisé · hébergeur français

12 400 véhicules · ~410 msg/s

API monolithique

VM applicative

Cache dernière position

VM Redis

File de messages RabbitMQ

VM courtier · découple l'API du traitement

PostgreSQL — primaire

VM base de données

PostgreSQL — replica

VM base de données

Lien 100 Mb/s
≈ 45 Go / h

réplication hors site

Site local · France

NAS de sauvegarde

hors hyperviseur, hors site

Seule copie qui survivrait à la perte de l'hôte. 1 To à restaurer par le lien.

5

C5.1.1 · Analyse

C5.1.1

Quatre constats, un atout

REDONDANCE

Le replica ne franchit pas l'hôte

Primaire et replica dans le même hyperviseur.

SAUVEGARDE

En place, jamais testée

Aucune restauration n'a été jouée. Le délai réel reste inconnu.

DÉBIT

22 heures pour 1 To

La base pèse 1 To et le lien à 100 Mb/s plafonne à 45 Go par heure.

COÛT

Aucune baisse la nuit

La capacité est réservée en continu. La facture suit le pic.

ATOUT

Tout tourne en VM

Le socle reste portable : un lift & shift vers une autre plateforme est possible sans réécrire les applications.

6

C5.1.2 · Orientations stratégiques

C5.1.2

Ce que le commanditaire attend

ENJEU COMMERCIAL

Tenir le partenariat

L'infrastructure ne doit pas devenir le facteur limitant de la croissance annoncée.

ENJEU ÉCONOMIQUE

Sortir du coût fixe

La facture suit aujourd'hui le pic, 24 h sur 24. Elle doit suivre l'usage réel.

ENJEU DE CONFIANCE

Rester maître de la donnée

Des positions de conducteurs, hébergées en France, sur des briques dont on peut sortir.

ENJEU D'ÉQUIPE

Faire converger applications et plateforme

Travailler avec les équipes de développement pour que les applications exploitent les possibilités de la plateforme — élasticité, redémarrage sans état, observabilité — et que la plateforme serve leurs contraintes.

Trois contraintes en découlent : réglementaire, stratégique, environnementale.

7

C5.1.2 · Contraintes

C5.1.2

Trois cadres non négociables

RÉGLEMENTAIRE

RGPD

Une position horodatée reconstitue les déplacements d'un conducteur.

Hébergement en France · rétention bornée · isolation en base

STRATÉGIQUE

Réversibilité

Pas de dépendance forte à un fournisseur, licences comprises.

Briques portables · managé si neutre

ENVIRONNEMENTAL

Sobriété

La capacité doit suivre l'usage.

Processeurs ARM · compression ~90 %

8

C5.1.3 · Cahier des charges

C5.1.3

Vingt-deux exigences, quatre familles

Chacune s'écrit en trois colonnes — référence, énoncé, critère mesurable — pour qu'un tiers puisse la vérifier sans nous. Six sont citées ici, une développée sur la planche suivante.

Réf Exigence Cible
ET-1Débit d'ingestion soutenu≥ 1 670 msg/s
ET-4Redondance3 zones, perte d'une zone sans coupure
ES-1HébergementFrance, sans sortie de l'UE
ES-3Isolation entre clientsgarantie en base
ET-6Reproductibilitérecréable depuis le code
EX-5Élasticité du coûtla facture suit l'usage

EF

Exigence fonctionnelle — ce que le système fait

ET

Exigence technique — comment il le fait

ES

Exigence de sécurité et de conformité

EX

Exigence d'exploitation — vie courante

9

C5.1.3 · Structure

C5.1.3

Ce que contient une exigence

DE L'ÉNONCÉ À LA PREUVE

Une exigence sans critère mesurable n'est pas une exigence, c'est un souhait. Chacune porte le cas qui la vérifie.

ET-1 · Débit d'ingestion soutenu

FAMILLETechnique — comment le système le fait ÉNONCÉL'ingestion tient la charge cible sans perte de message. CRITÈRE≥ 1 670 msg/s soutenus, zéro rejet ORIGINE DU CHIFFRE50 000 véhicules × 1 point / 30 s — pas un ordre de grandeur, une division VÉRIFIÉE PARR1.3 — injection à 1 670 msg/s pendant 10 minutes RÉSULTAT3 010 msg/s persistés en régime permanent · conforme
10

C5.1.3 · Dimensionnement

C5.1.3

La charge cible

50 000

véhicules · 1 point / 30 s

1 670

messages par seconde

144 M

points par jour · 3 à 5 Ko

11

2

Partie 2

Concevoir

L'architecture cible et ses frontières.

C5.2.1 · C5.2.2

12

C5.2.1 · Architecture

C5.2.1

L'architecture cible, par environnement

Nuage AWS · région eu-west-3 (Paris)

Réseau privé — applicatif et observabilité

Sous-réseaux publics — 3 zones

Répartiteur de chargeentrée publique HTTPS
Passerelle de sortieune par réseau · endpoints S3 et SQS hors NAT
Passerelle Internetune seule porte d'entrée

Sous-réseaux privés — plan de contrôle non exposé

Amazon EKSorchestrateur de conteneurs
API Ingestion · API LectureWorkers · Console web
PostgreSQL 18 · CloudNativePG1 primaire + 2 réplicas, 3 zones · WAL sur volume séparé
Machines ARM (Graviton) · capacité ajustée automatiquement sur la profondeur de la file
Relais d'administrationsans adresse publique
Agents d'observabilitéémettent vers la gestion

Réseau privé — gestion

Amazon EKScluster de gestion
Coffre de secrets · Déploiement continuobservabilité centralisée
Intégration continue isoléeexécuteurs jetables, sortie filtrée
Relais d'administrationseul point d'accès humain
Frontière structurelleCe réseau porte les clés, le déploiement et l'intégration continue. Sa compromission vaudrait celle de tout le reste.

Services gérés

Amazon SQSfile d'attente
ElastiCache Valkeycache · dernière position
Amazon S3archives et état
Amazon ECRregistre d'images
AWS KMSchiffrement

Le trafic public entre par le répartiteur de charge. Le plan de contrôle n'est pas exposé : l'administration passe par un relais géré, sans adresse publique ni port entrant. Les deux réseaux communiquent par une liaison privée explicite, limitée aux flux déclarés. Ce couple applicatif / gestion est répliqué par périmètre : un management pour le hors-production, un autre pour la production — jamais de management global.

13

C5.2.1 · Clusters

C5.2.1

Les deux clusters et leurs services

Cluster applicatif geotrack-dev-workload

Groupe « general » — t4g.medium, 2 à 10 nœuds

API Ingestionreçoit et publie
API Lecturerestitue
Workersconsomment la file
Console webcarte de flotte
Workers 1 → 20 sur la profondeur de file, cible 400 messages par worker · API Lecture 2 → 10 sur la charge processeur

Groupe « data » — t4g.large épinglé, placement contraint

PostgreSQL — primaireécritures
Réplique 1lectures
Réplique 2lectures
Une réplique par zone de disponibilité · budget d'interruption garanti

Services transverses du cluster

Opérateur PostgreSQL
Mise à l'échelle sur la file
Distribution des secrets
Contrôle à l'admission
Équilibrage et gestion DNS
Agents d'observabilité

Cluster de gestion geotrack-mgmt-nonprod

Groupe « management » — t4g.large, 3 nœuds obligatoires

Coffre de secrets3 répliques, quorum, descellement automatique
Déploiement continupilote les deux clusters
Supervision — métriques, journaux, traces, alertes
Contrôle à l'admission · secrets · équilibrage · certificats

Groupe « ci » — Spot, quatre types diversifiés, placement contraint

Exécuteurs d'intégrationun conteneur jetable par tâche
Construction d'imagespartagée entre les chaînes
Aucun accès aux clusters applicatifs

Pourquoi ce cluster est séparé

Il porte le coffre de secrets, le pilote de déploiement et l'intégration continue. Celle-ci exécute du code non vérifié avec des droits élevés : c'est le voisin le plus risqué, donc il vit hors du réseau applicatif.

14

C5.2.1 · Flux

C5.2.1

Le chemin d'un point

Ingestion découplée par file d'attente : la réponse à la balise ne dépend pas de la base.

Balise véhicule1 point / 30 s
①
Répartiteur de chargeentrée HTTPS
②
API Ingestionvalide et publie
③
Amazon SQSfile d'attente
④
Workersécriture groupée · 1 → 20 selon la file
⑤
PostgreSQLhypertable · index unique (véhicule, temps)
⑥
API Lecturerestitution
échec ×5
⑦
File de rebutisolée, rejouable
ElastiCache Valkeydernière position en cache
Amazon S3archives WAL
⑧ lecture temps réel servie par le cache, sans requête en base

① réception ② répartition ③ validation puis publication, réponse immédiate ④ mise en file ⑤ consommation ⑥ écriture — l'index unique garantit l'idempotence ⑦ mise en cache de la dernière position ⑧ lecture temps réel

15

C5.2.1 · C5.3.2 · Sécurité

C5.2.1 · C5.3.2

Quatre couches, aucune dans le code applicatif

RÉSEAU

Quatre frontières

Réseaux privés séparés entre les deux clusters — la seule frontière structurelle.

Groupes de sécurité entre machines, politiques réseau entre conteneurs, périmètres de déploiement entre dépôts et clusters.

La frontière dure est posée là où l’erreur coûte le plus cher : ≈ 586 $ / mois, assumés

DONNÉES

Isolation portée par la base

Une vue à barrière de sécurité filtre par client. Le rôle de lecture n’a aucun droit sur la table.

Une erreur dans l’API ne fait pas sortir la donnée.

La garantie ne dépend pas du code applicatif

IDENTITÉS

Aucun identifiant statique

Coffre en quorum, secrets à durée de vie courte. Un rôle sans clé par service, un jeton signé et révocable par balise.

TLS sur tous les flux, disques, sauvegardes et files chiffrés.

Un secret qui expire en quelques heures ne se vole pas utilement

LIVRAISON

Cinq contrôles bloquants

Analyse de l’infrastructure, analyse des images, signature, contrôle à l’admission, filtrage réseau.

Cinq portes, et aucune n’avertit : chacune refuse

Quatre vulnérabilités réelles arrêtées avant publication

Une dépendance introduite indirectement · une image de base en fin de support · un correctif publié, absent de l’image

Zéro ligne en lecture croisée

Le test qui compte pour le RGPD, rejoué à chaque campagne de recette

16

C5.2.1 · Souveraineté

C5.2.1

Trois éditeurs ont refermé leur licence

Terraform

OpenTofu

Reprise sans modification du code existant.

Vault

OpenBao

Coffre de secrets et autorité de certification.

Redis

Valkey

Environ 20 % moins cher chez le fournisseur.

17

C5.2.2 · Cahier de recettes

C5.2.2

Vingt-deux cas, six familles

R1

Ingestion et découplage

4

R2

Traitement et persistance

4

R3

Isolation entre clients

3

R4

Résilience

4

R5

Chaîne de livraison

4

R6

Exploitation

3

18

C5.2.2 · Structure

C5.2.2

Ce que contient un cas de recette

CINQ RUBRIQUES

Chaque cas est rejouable par un tiers, sans connaissance du projet, et se conclut par un verdict.

R1.3 · Ingestion soutenue à la charge cible

OBJECTIFVérifier ET-1 : le débit d'ingestion tient la charge cible sans perte. PRÉCONDITIONSEnvironnement de démonstration déployé, file vide, observabilité active. ÉTAPESInjecter un trafic de balises simulées à 1 670 msg/s pendant 10 minutes, puis relever la profondeur de file et le nombre de messages persistés. RÉSULTAT ATTENDUAucun message perdu, profondeur de file stable, capacité de traitement ajustée automatiquement. VERDICTConforme · Conforme sous réserve · Non conforme
19

3

Partie 3

Construire

La migration et son automatisation.

C5.3.1 · C5.3.2

20

C5.3.1 · Protocole d'intégration

C5.3.1

Construire à côté, basculer à la fin

L'ancienne plateforme reste en service pendant les onze mois. La cible se construit en parallèle, sans jamais toucher à la production en service.

CONSTRUCTION

Onze couches, une par une

Chaque couche est construite, prouvée, puis détruite et reconstruite depuis le code. Un défaut se découvre sur une couche isolée, et la reproductibilité est vérifiée en continu.

VALIDATION

Recette avant tout client

Vingt-deux cas rejoués sur la plateforme complète, dont la lecture croisée entre clients. Aucun client n'est déplacé avant que la campagne soit passée.

BASCULE

Une seule fenêtre, à la fin

Les clients basculent en une fois, au mois onze. L'ancienne plateforme reste debout : le retour arrière consiste à ne pas basculer.

Ce qui avance par couches, c'est la construction — pas les clients.

21

C5.3.1 · Calendrier

C5.3.1

Onze mois, onze artefacts

Chaque mois se termine sur un artefact livré. Trois jalons conditionnent la suite.

M1

Cadrage

cahier des charges

M2

Socle

onze couches de code

M3

Réseau

deux réseaux privés

M4

Clusters

deux clusters

M5

Coffre, GitOps

coffre et pilote

M6

Données

base répliquée

M7

Observabilité

métriques, journaux, traces

M8

Applicatif

quatre services

M9

Livraison

chaîne et contrôles

M10

Recette

22 cas joués

M11

Bascule

compte-rendu de bascule

JALON M5 · COFFRE ET GITOPS

Prouve qu'aucun secret ne vit dans un dépôt et que le cluster se pilote depuis le code.

JALON M10 · RECETTE

Prouve les vingt-deux cas sur l’environnement déployé, relevés et captures à l’appui.

JALON M11 · BASCULE

Prouve la reprise du service sans coupure pour les clients de l’ancienne plateforme.

22

C5.3.1 · Méthode d'intégration

C5.3.1

Tout en code, rien à la main

Chaque élément de l'infrastructure est décrit dans un dépôt et appliqué par une chaîne. Rien n'est créé depuis une console.

État vérifiable

L'écart entre le code et le réel est détecté à chaque exécution. Une ressource créée à la main est signalée, puis effacée.

Revue avant application

Le plan d'application est lu et approuvé sur la demande de fusion. Aucune modification n'atteint un cluster sans relecture.

Décisions tracées

Quarante-trois décisions d'architecture enregistrées avec leurs alternatives écartées, dont onze révisent une décision antérieure. Chacune est rattachée à un chemin de code.

La méthode traditionnelle a été écartée : chaque installation manuelle produit un état unique que personne ne sait reproduire.

23

C5.3.2 · Automatisation

C5.3.2

Du commit au conteneur en service

Aucun dépôt de code ne détient d'accès aux clusters, et aucune commande n'est exécutée sur le cluster. L'analyse précède la publication, et le contrôle à l'admission refuse ce qui n'est pas signé.

Développeurdépôt de code
①
Chaîne d'intégrationqualité, analyse de l'infrastructure, construction
②
Analyse de vulnérabilitésbloque avant publication
③
Amazon ECRimage signée à la publication
④
Dépôt de manifestessource de vérité
⑤
Déploiement continuapplique sur les clusters
Contrôle à l'admissionrefuse une image non signée ou dont l'empreinte n'est pas figée

① validation du code ② construction d'une archive, sans publication ③ analyse : quatre vulnérabilités réelles arrêtées ici ④ signature puis publication au registre ⑤ mise à jour de la version déclarée, reprise automatique

24

C5.3.2 · Moyens d'automatisation

C5.3.2

Trois moyens, aucun geste manuel

DESCRIPTION

OpenTofu

L'infrastructure décrite en code : onze couches, un état par couche, recréables dans l'ordre.

Réseau, clusters, base, coffre

RÉCONCILIATION

Argo CD

Le pilote GitOps lit le dépôt de manifestes et rapproche en continu l'état réel de l'état déclaré.

Le dépôt décide, pas l'opérateur

CHAÎNE

Pipelines

Ils construisent, analysent, signent, publient l'image et mettent à jour la version déclarée.

Exécuteurs jetables, sortie filtrée

Aucun de ces trois moyens n'exige d'accès humain à un cluster.

25

C5.3.2 · Mise en production

C5.3.2

Comment une nouvelle version arrive

RETENU

Déploiement canary

Une fraction du trafic part vers la nouvelle version. Les indicateurs sont comparés à ceux de la version en place, puis la part augmente — ou revient à zéro.

Progression du trafic

5 %→25 %→50 %→100 %

Sous le canary, les conteneurs sont remplacés un par un : un budget d'interruption garantit qu'un nombre minimal reste en service.

Retour arrière par annulation d'un commit, sans intervention sur le cluster.

ÉCARTÉ

Bleu / vert

Doubler la flotte le temps du basculement double la facture, sans bénéfice ici : l'ingestion est sans état et la base est partagée.

Recréation avec coupure

Arrêter puis redéployer coupe l'ingestion : les balises n'ont pas de tampon suffisant pour absorber la fenêtre.

Livraison directe à 100 % du trafic

Le premier défaut touche tous les clients en même temps ; le retour arrière intervient après l’incident, pas avant.

AVANT LA PRODUCTION

Toute version traverse d'abord la préproduction — même code, même chaîne, même canary, à échelle réduite. Elle n'atteint la production qu'une fois ce passage tenu.

26

C5.3.2 · Résultat

C5.3.2

Ce que l'automatisation a changé

Opération Avant Après
Mise en production4 h, de nuit< 15 min
Retour arrièrerestauration manuelleannulation d'un commit
Recréer un environnementhors de portée≈ 2 h, depuis le code
Perte d'un nœuddiagnostic et remise en service à la mainnœud recréé automatiquement
Adapter la capacitéimpossibleautomatique
Contrôles de sécuritéaucun5 bloquants
27

4

Partie 4

Prouver

La démonstration et les mesures.

C5.2.3 · C5.3.3 · C5.4.1

28

C5.2.3 · Démonstration

C5.2.3

Une démonstration : la plateforme sous charge

Sur l'environnement déployé. Une montée de charge, et ce que le cluster en fait.

1 · ÉTAT INITIAL

Le parc au repos

Deux clusters en service, la file vide, le nombre de traitements au plancher.

2 · INJECTION

La charge monte

Un générateur pousse un trafic de balises simulées au-delà de la charge cible de 1 670 messages par seconde.

3 · RÉACTION

Le cluster suit

La profondeur de file monte. Le nombre de services de traitement augmente d'abord ; de nouveaux hôtes ne rejoignent le groupe que lorsque les machines en place sont saturées.

4 · RETOUR

La capacité redescend

L'injection s'arrête. Les ressources sont rendues d'elles-mêmes, sans intervention.

Observé en direct : le débit d'ingestion (ET-1) et l'élasticité (EX-5). Les autres exigences sont couvertes par la campagne de recette.

29

C5.2.3 · PoC

Démonstration

Montée de charge sur la plateforme, et effets sur le cluster : le scaling automatique des ressources.

C5.2.3 · Ce que le PoC valide

C5.2.3

Ce que la démo montre, ce que la recette prouve

ET-1 · EX-5

Débit et élasticité

La capacité suit la profondeur de file, puis redescend : la facture suit l'usage.

observé en démo

ET-4

Redondance

Base répliquée sur trois zones, plan de contrôle non exposé.

campagne de recette

ES-3

Isolation entre clients

La lecture croisée ne retourne aucune ligne : la garantie est portée par la base, pas par l'API.

campagne de recette

ET-6

Reproductibilité

La version en service vient d’un commit, sans commande manuelle sur le cluster.

campagne de recette

31

C5.3.3 · Compte-rendu de test

C5.3.3

Extrait du compte-rendu

Cas Résultat attendu Résultat obtenu Verdict
R1.3≥ 1 670 msg/s sans perte3 010 msg/s persistés en régime permanent, file à zéroConforme
R3.1Lecture croisée : aucune ligne retournée0 ligne, la vue filtre avant le code applicatifConforme
R5.3Image non signée refuséeRefusée à l'admission : « no signatures found ». Empreinte figée sur les pods conformesConforme
R4.1Perte d'une instance sans coupureReprise Spot en conditions réelles : service continu, nœud remplacéConforme

Chaque ligne renvoie au cas correspondant du cahier de recettes, avec ses relevés et ses captures.

32

C5.3.3 · Campagne

C5.3.3

Résultats de la campagne de recette

22

cas joués sur 22 — dont 19 pleinement conformes

0

cas non conforme

3

conformes sous réserve, réserves nommées : file de rebut, restauration à un instant T, repli sans cache

Les familles ingestion, isolation, livraison et exploitation passent intégralement.

33

C5.3.3 · Charge

C5.3.3

Le test de charge

3 010

messages/seconde soutenus · cible 1 670

0

échec et 0 doublon sur ~2,9 M de messages

42 %

de charge machine au plus fort

34

C5.4.1 · Exploitation

C5.4.1

Surveiller depuis l'extérieur

Métriques

Profondeur de file, retard de réplication, latence des interfaces.

Journaux

Centralisés depuis les deux clusters, avec service et environnement.

Traces

Une requête suivie de l'entrée jusqu'à la base, à travers la file.

35

C5.4.1 · Documentation

C5.4.1

Le guide d'utilisation

Trois lectures pour un même document : l'administrateur de la plateforme, l'exploitant qui la surveille, le gestionnaire de flottes qui administre clients et balises.

CHAPITRES 1-2

Prendre la main, déployer de zéro

CHAPITRE 3

Livrer une version, revenir en arrière

CHAPITRES 4-5

Surveiller, sauvegarder, restaurer

CHAPITRE 6

Gérer et faire tourner les secrets

CHAPITRES 7-8

Administrer clients et balises

CHAPITRES 9-10

Arrêter la plateforme, annexes

36

C5.4.1 · Structure

C5.4.1

Ce que contient une procédure

TROIS RUBRIQUES

Une procédure qui ne décrit pas le succès n'est pas une procédure : c'est un aide-mémoire.

Les chapitres qu'on ouvre sous pression commencent par la commande, pas par l'explication.

3.4 · Revenir en arrière

COMMANDEgit revert <sha> && git push RÉSULTAT ATTENDULe pilote détecte l'écart en moins de 3 minutes et redéploie la version précédente, par canari. Aucune action sur le cluster. SI ÇA DIFFÈRETrop lent ? rollouts abort renvoie le trafic vers la version stable immédiatement, sans attendre les paliers.

Pourquoi un revert et non un reset : le retour arrière doit laisser une trace. Un historique réécrit rend l'incident inanalysable — et c'est précisément le moment où on aura besoin de le relire.

37

Coût

Ce que coûte chaque périmètre

PérimètreCompositionPar moisNature
Pack GP-1-NSX — plateforme actuelle2 hôtes · 128 Go RAM par hôte · 16c/32t à 2,8 GHz · 2 × 3 To de datastores3 380 € HTfacturé aujourd’hui
Démonstration2 plans de contrôle · 11 machines≈ 732 €mesuré
Production + développement4 plans · ~21 machines≈ 2 119 €estimé

Le pack héberge UN environnement. Les 2 119 € en couvrent CINQ, plus le coffre, le déploiement continu, l'intégration continue, l'observabilité, et une préproduction qui réplique la production. À montant comparable, on passe d'un environnement à cinq — et la facture suit l'usage au lieu de suivre le pic réservé 24 h sur 24. Montants cloud convertis au taux de 1 $ = 0,92 €.

38

Retour d'expérience

Trois difficultés, un point commun

ADMISSION

Politique de sécurité

Un mode dégradé qui ne dégrade pas ce qu'on croit.

INTER-CLUSTERS

Authentification

Un mécanisme valable dans un cluster, inopérant depuis l'autre.

RÉSEAU

Filtrage entre conteneurs

Un flux non déclaré, supprimé sans trace.

Aucune des trois ne produit de message d'erreur. Elles produisent du silence.

39

Perspectives

Ce qui suit

PRODUIT

Stockage froid des positions

Déplacer les positions anciennes vers un stockage moins coûteux, et proposer des forfaits clients selon la profondeur d'historique.

RÉSILIENCE

Éprouver le multi-région

L'architecture le permet. Reste à le déployer et à mesurer le basculement réel.

EXPLOITATION

Filtrer les journaux à l'usage

Ne conserver que ce qui sert réellement au diagnostic, pour la pertinence et pour le coût.

40

Fin de présentation

Merci

Avez-vous des questions ?

Quentin Kaczmareck · Bloc 5 · Concevoir et mettre en œuvre l'architecture d'un SI41