Conception d'une plateforme de recherche multi-tenant sur AWS

Transformer une application AWS Amplify unique en une plateforme cloud capable de provisionner et d'exploiter de multiples applications de recherche par l'automatisation.

Senior Backend & Cloud Engineer·Institut d'Études Avancées de Paris
RôleSenior Backend & Cloud Engineer
Responsabilités
Architecture backendInfrastructure cloudPlatform engineeringCI/CDInfrastructure as CodeObservabilité

Le défi

Quand j'ai rejoint le projet, la plateforme consistait en une seule application AWS Amplify pour l'Institut d'Études Avancées de Paris.

Cela fonctionnait bien pour un site unique, mais l'organisation était en pleine expansion.

De nouvelles initiatives de recherche nécessitaient des sites web indépendants, avec leur propre image de marque, équipes éditoriales et cycles de déploiement, tout en partageant la même logique métier et la même plateforme de données. L'architecture existante ne pouvait pas soutenir cette vision.

Chaque nouveau site nécessitait le provisionnement manuel de ressources AWS, la configuration d'infrastructure, le déploiement d'applications frontend et la mise à jour des services backend. L'équipe d'ingénierie était devenue le goulot d'étranglement.

Mon objectif n'était pas simplement de migrer des technologies. C'était de construire une plateforme où créer une nouvelle application devenait un changement de configuration plutôt qu'un projet d'infrastructure.

Défi 1 — Reconstruction de la plateforme backend

La première étape a été de sortir d'AWS Amplify. Amplify avait accéléré la première version du projet mais devenait de plus en plus contraignant à mesure que la plateforme grandissait. La logique GraphQL personnalisée, les exigences multi-tenant et le contrôle de l'infrastructure nécessitaient tous une architecture de plus bas niveau.

J'ai reconçu le backend autour d'AWS AppSync et de fonctions Lambda déployables indépendamment. Au lieu d'un seul gros backend, la plateforme est devenue une collection de services autonomes.

APIs Publiques
│
↓
AWS AppSync
│
↓
40+ Fonctions Lambda
│
↓
MongoDB Atlas

Couche d'exécution Lambda partagée

Chaque Lambda partageait la même couche d'exécution fournissant :

  • Authentification JWT
  • RBAC
  • Intégration Sentry
  • Gestion du warm-up
  • Gestion centralisée des erreurs

Cela a supprimé le code dupliqué tout en gardant chaque capacité métier déployable indépendamment.

Défi 2 — Concevoir une plateforme cloud plutôt qu'une application web

La plateforme hébergeait finalement de multiples initiatives de recherche. Bien que chaque site ait l'air différent, ils partageaient tous le même backend.

Au lieu de cloner des projets, j'ai conçu Netboard. Netboard a transformé la création d'application en un workflow de provisioning.

Administrateur
│
↓
Configuration tenant
│
↓
GitHub Actions
│
↓
Terraform
│
↓
Infrastructure AWS
│
↓
Application en ligne

Provisionné automatiquement par tenant :

  • CloudFront
  • S3
  • Route53
  • Certificats ACM
  • Configuration Lambda
  • Secrets Parameter Store
  • Déploiement frontend

Chaque tenant conservait sa propre image de marque, ses traductions, son contenu et ses assets tout en partageant l'intégralité de la plateforme applicative. Créer un nouveau site ne nécessitait plus de travail manuel sur AWS.

Défi 3 — Construire une infrastructure cloud reproductible

À mesure que le nombre d'environnements et de tenants augmentait, l'infrastructure manuelle devenait impossible à maintenir.

J'ai reconstruit l'intégralité de la plateforme AWS avec Terraform et Terragrunt. La plateforme opérait sur quatre comptes AWS :

Des modules Terraform réutilisables géraient chaque composant :

  • Lambda
  • AppSync
  • CloudFront
  • S3
  • Route53
  • SES
  • SQS
  • Monitoring
  • MongoDB Atlas
  • Infrastructure CI

Les mêmes définitions d'infrastructure étaient utilisées partout, garantissant des déploiements reproductibles et réduisant la dérive de configuration.

Défi 4 — Automatiser la livraison logicielle

Déployer des dizaines de fonctions Lambda sur plusieurs tenants est rapidement devenu un autre goulot d'étranglement.

J'ai conçu une plateforme de déploiement basée sur GitHub Actions. Au lieu de serveurs de build persistants, les jobs CI utilisaient des runners auto-hébergés éphémères déployés dynamiquement sur AWS ECS avec Spot Instances.

GitHub Actions
│
↓
Runner ECS éphémère
│
↓
Terraform
│
↓
Déploiement Lambda
│
↓
Déploiement Nuxt
│
↓
Invalidation CloudFront

Le pipeline ne reconstruisait que les composants affectés par un changement. Les déploiements d'infrastructure, backend et frontend s'exécutaient indépendamment quand c'était possible. Cela a considérablement réduit les temps de déploiement tout en minimisant les risques en production.

Évolution de la plateforme de données

La plateforme originale stockait les données dans DynamoDB et utilisait Cognito pour l'authentification. À mesure que le projet évoluait, les deux sont devenus limitants.

J'ai mené la migration vers MongoDB Atlas, l'authentification JWT personnalisée, des relations de données plus riches, la recherche full-text et les pipelines d'agrégation.

J'ai également développé des outils de migration pour importer les données de production existantes depuis DynamoDB et les systèmes SQL legacy vers la nouvelle plateforme.

Génération de modèles de données partagés

À mesure que la plateforme grandissait, maintenir séparément les formulaires frontend, les schémas GraphQL et les modèles backend devenait source d'erreurs.

J'ai introduit une couche de modèles TypeScript partagée agissant comme source de vérité unique. À partir d'une seule définition de modèle, la plateforme générait automatiquement les schémas GraphQL, les opérations client, les formulaires dynamiques et les configurations de listes.

Cela a éliminé les problèmes de synchronisation entre le frontend et le backend tout en réduisant les coûts de maintenance.

Observabilité de production

Opérer une plateforme serverless nécessite de l'observabilité plutôt que de l'administration de serveurs.

J'ai construit la stack de monitoring complète autour de Sentry auto-hébergé, Grafana, CloudWatch et Ackee.

Le monitoring couvrait : les performances Lambda, les métriques CloudFront, les erreurs applicatives, la santé de l'infrastructure et le statut des déploiements.

Architecture

          Applications Nuxt
                 │
         CloudFront + S3
                 │
            AWS AppSync
                 │
         40+ Fonctions Lambda
                 │
            MongoDB Atlas

Infrastructure : Terraform / Terragrunt
CI/CD          : GitHub Actions · Runners ECS éphémères · Spot Instances
Observabilité  : Grafana · Sentry · CloudWatch

Réalisations clés

  • Conception et développement de l'architecture backend
  • Construction d'une plateforme de provisioning multi-tenant sur AWS
  • Conception de l'Infrastructure as Code pour quatre comptes AWS
  • Développement de 40+ services backend serverless
  • Implémentation de pipelines CI/CD entièrement automatisés
  • Construction de runners GitHub Actions auto-hébergés éphémères sur ECS
  • Migration des données de production depuis DynamoDB et systèmes SQL legacy
  • Conception de génération de code partagé pour les modèles backend et frontend
  • Construction d'une stack d'observabilité de production complète

Technologies

AWSLambdaAppSyncTerraformTerragruntGitHub ActionsECSSpot InstancesMongoDB AtlasNode.jsGraphQLNuxt.jsVue.jsSentryGrafana