Architecture AWS EKS (Services et Infrastructure)

Ce document fournit un aperçu complet de l'architecture AWS pour l'infrastructure des services EKB. L'architecture suit les modèles cloud-natifs avec les services gérés d'AWS, l'orchestration Kubernetes et la mise à l'échelle automatique.

Aperçu de l'architecture AWS

L'architecture suit les modèles cloud-natifs avec les services gérés d'AWS, l'orchestration Kubernetes et la mise à l'échelle automatique.

Diagramme d'architecture

flowchart TD
    INTERNET[\"🌐 INTERNET\"]
 
    DNS[\"Fournisseur DNS\\n(Route 53 / Cloudflare / etc.)\\n──────────────────────────────\\n• app.your-domain — Web Frontend\\n• api.your-domain — FastAPI Backend\\n• automations.your-domain — Automator\\n• supabase.your-domain — Supabase Kong\\n• signoz.your-domain — SigNoz\"]
 
    ALB[\"APPLICATION LOAD BALANCER\\n──────────────────────────────\\n• Terminaison SSL via ACM\\n• Redirection HTTP → HTTPS\\n• Vérifications de santé et groupes cibles\\n• Routage par nom d'hôte/chemin\"]
 
    subgraph VPC[\"VPC\"]
        subgraph PUB[\"Sous-réseaux publics (3 AZs)\"]
            NAT[\"Passerelle NAT × 3\"]
        end
        subgraph PRIV[\"Sous-réseaux privés (3 AZs)\"]
            NODES[\"Nœuds de travail EKS\"]
        end
    end
 
    subgraph EKS[\"CLUSTER EKS\"]
        KARPENTER[\"KARPENTER — Approvisionnement dynamique des nœuds\\n──────────────────────────────\\n• Priorisation des instances Spot et consolidation\\n• Gestion des interruptions via SQS\\n• Classes de nœuds : général, calcul intensif, base de données\"]
        KEDA[\"KEDA — Mise à l'échelle automatique des pods basée sur les événements\\n──────────────────────────────\\n• Mise à l'échelle du seuil CPU / Mémoire\\n• Stabilisation rapide de la réduction d'échelle\"]
        PODS[\"PODS D'APPLICATION\\n──────────────────────────────\\n• Web Frontend (port 3000)\\n• FastAPI Backend (port 8001)\\n• Travailleurs Celery\\n• Automator (port 80)\\n• Services Supabase (Kong, Auth, Storage…)\\n• PostgreSQL Automator (port 5432)\"]
        SIGNOZ[\"OBSERVABILITÉ — SigNoz (optionnel)\\n──────────────────────────────\\n• Traçage distribué, métriques, journaux\\n• Agent k8s-infra pour les métriques du cluster\"]
    end
 
    subgraph DATA[\"COUCHE DE DONNÉES\"]
        REDIS[\"ELASTICACHE\\n(Redis)\\n──────────\\n• Chiffrement\\n• Multi-AZ\\n• Port 6379\"]
        MQ[\"AMAZON MQ\\n(RabbitMQ)\\n──────────\\n• File d'attente asynchrone\\n• AMQP/SSL\\n• Port 5671\"]
        SUPABASE[\"SUPABASE\\n(DB / Auth)\\n──────────\\nOption A : Cloud\\nOption B : Auto-hébergée\\nvia CNPG HA sur EKS\"]
    end
 
    INTERNET --> DNS
    DNS --> ALB
    ALB --> VPC
    PUB --> PRIV
    PRIV --> EKS
    EKS --> DATA

Information

Supabase auto-hébergée utilise un cluster PostgreSQL HA géré par CloudNativePG (ha-supabase-db) avec regroupement PgBouncer, MinIO pour le stockage d'objets et la pile d'application Supabase complète déployée via helm-deployment/supabase-kubernetes-ha. Supabase Cloud est l'alternative si l'auto-hébergement n'est pas requis.

Composants clés

1. Couche réseau

Fournisseur DNS

Objectif : Résolution des noms de domaine ; fonctionne avec n'importe quel fournisseur (Route 53, Cloudflare, etc.)
Domaines (utilisez votre propre domaine, par ex. example.com) :
- app.example.com — Web Frontend
- api.example.com — FastAPI Backend
- automations.example.com — Service Automator
- supabase.example.com — Supabase Kong (auto-hébergée uniquement)
- signoz.example.com — Observabilité SigNoz (optionnel)
Validation SSL : Enregistrements CNAME requis pour la validation DNS d'ACM

Application Load Balancer (ALB)

Objectif : Terminaison SSL, équilibrage de charge et routage basé sur le nom d'hôte
Fonctionnalités :
- Terminaison SSL/TLS avec les certificats ACM (caractère générique ou par service)
- Redirection HTTP → HTTPS
- Vérifications de santé pour tous les groupes cibles
Géré par : Contrôleur AWS Load Balancer (graphique Helm dans helm-deployment/infrastructure)

VPC

CIDR : Spécifique à l'environnement (par ex. 10.x.0.0/16)
Zones de disponibilité : 3 AZs dans la région choisie
Sous-réseaux : 3 publics (Passerelles NAT) + 3 privés (nœuds EKS)
Sortant : Passerelle NAT par AZ pour la sortie des nœuds

2. Couche de calcul

Cluster EKS

Version : Kubernetes 1.33
Groupe de nœuds système : Groupe de nœuds géré exécutant le contrôleur Karpenter (pas sur les nœuds gérés par Karpenter, selon les bonnes pratiques d'AWS)
Modules complémentaires : Pilote CSI EBS, Contrôleur AWS Load Balancer, CoreDNS, kube-proxy

Karpenter — Approvisionnement dynamique des nœuds

Objectif : Approvisionnement des nœuds juste à temps et optimisation des coûts
Classes de nœuds :
- Usage général : Instances Spot pour la plupart des charges de travail
- Calcul intensif : Instances haute-CPU pour les tâches liées au CPU
- Mémoire intensive : Instances optimisées pour la mémoire pour les grands ensembles de données
- Base de données : Instances à la demande pour les charges de travail avec état/base de données
- GPU : Instances GPU pour les charges de travail IA/ML (optionnel)
Fonctionnalités : Priorisation des Spot, consolidation automatique, gestion des interruptions basée sur SQS

KEDA — Mise à l'échelle automatique des pods basée sur les événements Kubernetes

Objectif : Mise à l'échelle horizontale des pods basée sur les métriques de ressources
Cibles :

Service	Répliques	Seuil CPU	Seuil mémoire
Web Frontend	2–8	60%	80%
FastAPI Backend	2–10	70%	80%
Travailleurs Celery	2–8	70%	80%
Automator	2–8	70%	80%

Réduction d'échelle : Fenêtre de stabilisation de 30 s pour une réponse rapide

3. Services d'application

Web Frontend

Port : 3000
Répliques : 2–8 (gérées par KEDA)
Objectif : Application React servant l'interface utilisateur

FastAPI Backend

Port : 8001
Répliques : 2–10 (gérées par KEDA)
Objectif : Serveur API REST gérant la logique métier et l'accès aux données

Travailleurs Celery

Répliques : 2–8 (gérées par KEDA)
Objectif : Traitement des tâches en arrière-plan (mis en file d'attente via RabbitMQ)

Service Automator

Port : 80
Répliques : 2–8 (gérées par KEDA)
Objectif : Automation des flux de travail et orchestration

Supabase Kong

Port : 8000 (service de cluster interne)
Objectif : Passerelle API pour tous les services Supabase
Routage : Le trafic externe atteint Kong via l'entrée ALB définie dans odin-services/main-ingress.yaml

SigNoz (optionnel)

Espace de noms : monitoring
Composants : Plateforme SigNoz + agent DaemonSet k8s-infra
Objectif : Traçage distribué, agrégation des métriques, gestion des journaux
Activé par : ENABLE_SIGNOZ=true

4. Couche de données

ElastiCache Redis

Objectif : Cache, stockage de session et courtier/backend de résultats Celery
Configuration :
- Type de nœud : configurable (par ex. cache.t3.micro)
- Port : 6379
- Chiffrement au repos et en transit
- Multi-AZ pour la haute disponibilité
Activé par : ENABLE_AWS_SERVICES=true

Amazon MQ (RabbitMQ)

Objectif : File d'attente de messages pour le traitement asynchrone des tâches
Configuration :
- Moteur : RabbitMQ
- Ports : 5671 (AMQP/SSL), 15671 (Gestion/SSL)
- Mode de déploiement : instance unique ou active/veille
Activé par : ENABLE_AWS_SERVICES=true

Supabase — Option A : Cloud (géré)

Objectif : PostgreSQL géré externe, Auth, Storage et Realtime
Connexion : URL du projet Supabase et clé du rôle de service configurées dans values/odin-services.yaml

Supabase — Option B : Auto-hébergée sur EKS

Objectif : Pile Supabase complète s'exécutant à l'intérieur du cluster
Composants :
- Opérateur CloudNativePG (cnpg-system) — gère le cycle de vie du cluster Postgres
- Base de données Supabase HA (ha-supabase-db) — Ressource Cluster CloudNativePG avec regroupement PgBouncer
- Application Supabase (namespace supabase) — Kong, Auth, Storage (MinIO), Meta, Rest, Realtime, Studio
Ordre de déploiement : CloudNativePG → Base de données Supabase HA → Application Supabase
Activé par : ENABLE_CNPG=true, ENABLE_HA_SUPABASE_DB=true, ENABLE_SUPABASE=true

PostgreSQL Automator

Objectif : Base de données PostgreSQL locale pour le service Automator
Port : 5432
Stockage : Volume persistant EBS
Affinité des nœuds : Nœuds dédiés à la base de données

5. Sécurité et IAM

Rôles IAM

Rôle	Objectif
Rôle de cluster EKS	Permissions API au niveau du cluster
Rôle de groupe de nœuds	Permissions des nœuds EC2 (ECR, SSM, réseau)
Rôle du contrôleur Karpenter	Approvisionnement EC2, file d'attente d'interruption SQS
Rôle du contrôleur AWS Load Balancer	Gestion d'ELBv2 et EC2
Rôle du pilote CSI EBS	Gestion du cycle de vie des volumes EBS

Les noms de rôles suivent le modèle <env-name>-<component> et sont créés par le module EKS Terraform.

Groupes de sécurité

ALB : Auto-créé par le contrôleur AWS Load Balancer (entrée 80/443)
Cluster EKS : Communication nœud-à-nœud et pod
Redis : Port 6379 uniquement depuis le CIDR VPC
RabbitMQ : Ports 5671, 15671 uniquement depuis le CIDR VPC

SSL/TLS

Terminaison : Niveau ALB (les pods voient HTTP en clair en interne)
Certificats : Certificats ACM — soit par service, soit un caractère générique unique
Validation : Validation DNS CNAME via votre fournisseur DNS
Protocole minimum : TLS 1.2

6. Infrastructure en tant que code

Modules Terraform

modules/eks: Cluster EKS, VPC, groupes de nœuds, Karpenter, IAM, versions Helm
État : Bucket S3 avec versioning, table de verrouillage DynamoDB

Terragrunt

Isolation de l'environnement : Un répertoire par environnement sous terragrunt/environments/
Modèle : env-template-folder — copier et remplir les espaces réservés pour créer un nouvel environnement
Configuration DRY : root.hcl partagée avec les remplacements par environnement
Indicateurs d'activation/désactivation : Services basculés via variables d'environnement (ENABLE_*)

Graphiques Helm

Graphique	Espace de noms	Description
`infrastructure`	`infrastructure`	Contrôleur ALB
`odin-services`	`default`	Web, API, Travailleurs, Automator, Entrée
`aws-ebs-csi-driver`	`kube-system`	Approvisionnement des volumes EBS
`keda`	`keda`	Mise à l'échelle automatique des pods
`cloudnative-pg`	`cnpg-system`	Opérateur PostgreSQL
`ha-supabase-db`	`ha-supabase-db`	Cluster Postgres HA + PgBouncer
`supabase-kubernetes-ha`	`supabase`	Pile Supabase complète
`signoz`	`monitoring`	Plateforme d'observabilité
`k8s-infra`	`monitoring`	Agent des métriques du cluster

Flux de données

1. Flux de demande utilisateur

Utilisateur → DNS → ALB (terminaison SSL) → Pod EKS (Web Frontend)
                                          → Pod EKS (FastAPI Backend)
                                          → Pod EKS (Supabase Kong)

L'utilisateur accède à app.example.com
DNS se résout vers l'ALB
ALB termine SSL et route par nom d'hôte vers le groupe cible correct
Web Frontend sert l'application React et effectue des appels API vers api.example.com
FastAPI Backend traite les demandes et lit/écrit dans les services de données

2. Flux de demande API

Client → ALB → FastAPI Backend → Redis (cache) / RabbitMQ (file d'attente) / Supabase (BD)

Le client appelle api.example.com
ALB route vers le pod FastAPI
Le backend vérifie le cache Redis ; en cas d'absence, interroge la base de données Supabase
Les tâches asynchrones sont mises en file d'attente dans RabbitMQ et traitées par les travailleurs Celery

3. Flux de traitement en arrière-plan

FastAPI → RabbitMQ → Celery Worker → Base de données Supabase

FastAPI met une tâche en file d'attente dans RabbitMQ
Celery Worker retire de la file d'attente et traite la tâche
Les résultats sont réécrits dans la base de données Supabase

4. Flux de travail Automator

Automator → PostgreSQL (local) → Redis → APIs externes

Automator reçoit une demande de flux de travail
L'état du flux de travail est persistant dans l'instance PostgreSQL locale
Redis cache les résultats intermédiaires
Les API externes sont appelées dans le cadre de l'automation

5. Flux de mise à l'échelle

Métriques → KEDA → Mise à l'échelle des pods → Karpenter → Approvisionnement des nœuds

KEDA évalue les métriques CPU/Mémoire par rapport aux seuils configurés
Les pods sont mis à l'échelle horizontalement dans la plage de répliques configurée
Si la capacité du cluster est insuffisante, Karpenter provisionne de nouveaux nœuds EC2 (préférant les Spot)
Lorsque la charge diminue, KEDA réduit l'échelle des pods ; Karpenter consolide et termine les nœuds inactifs

6. Flux de sécurité

Internet → ALB (TLS 1.2+, ACM) → Groupes de sécurité → Pods → Rôles IRSA IAM → APIs AWS

Tout le trafic externe termine TLS à l'ALB
Les groupes de sécurité appliquent l'accès réseau à privilège minimal
Les pods communiquent avec les services AWS via IRSA (Rôles IAM pour les comptes de service)

Résumé de la haute disponibilité

Fonctionnalité	Implémentation
Déploiement multi-AZ	3 AZs pour les nœuds EKS, Redis, sous-réseaux
Équilibrage de charge	ALB avec plusieurs groupes cibles
Redondance des pods	Minimum 2 répliques par service
HA de la base de données	Cluster CloudNativePG avec PgBouncer (auto-hébergée) ou Supabase Cloud
Redondance du cache	ElastiCache Multi-AZ
Mise à l'échelle automatique des nœuds	Karpenter avec mélange Spot + À la demande
Mise à l'échelle automatique des pods	KEDA basée sur CPU/Mémoire
Observabilité	SigNoz (optionnel)
Gestion de l'état	S3 avec versioning + verrouillage DynamoDB

Optimisation des coûts

Instances Spot : Karpenter priorise les Spot pour toutes les charges de travail non-base de données
Consolidation des nœuds : Karpenter récupère automatiquement les nœuds sous-utilisés
Dimensionnement correct des pods : KEDA réduit l'échelle des pods pendant les périodes calmes
À la demande uniquement si nécessaire : La classe de nœud de base de données utilise À la demande pour la stabilité

Maintenance et opérations

Processus de déploiement

cd terragrunt/environments/<your-env-name>
# Définir les variables d'environnement ENABLE_* et domaine/certificat requises
terragrunt apply
# Mises à jour roulantes : réappliquer après la mise à jour des balises d'image ou des fichiers de valeurs

Voir Guide de déploiement Terragrunt pour la séquence de déploiement complète.

Stratégie de sauvegarde

Snapshots EBS : Snapshots automatisés pour les volumes persistants (Base de données Automator, Supabase MinIO)
CloudNativePG : Archivage WAL continu + sauvegardes de base programmées (si configuré)
Supabase Cloud : Sauvegardes quotidiennes gérées (option cloud)
État IaC : Bucket S3 versionné

Récupération d'urgence

Multi-AZ : Tous les services avec état s'étendent sur plusieurs zones de disponibilité
CloudNativePG HA : Basculement automatique entre les répliques principales et Postgres
Supabase Cloud : Redondance interrégionale (option cloud)
État Terraform : Le versioning S3 permet de revenir à tout état précédent

Aperçu de l'architecture AWS

Diagramme d'architecture​

Composants clés​

1. Couche réseau​

Fournisseur DNS​

Application Load Balancer (ALB)​

VPC​

2. Couche de calcul​

Cluster EKS​

Karpenter — Approvisionnement dynamique des nœuds​

KEDA — Mise à l'échelle automatique des pods basée sur les événements Kubernetes​

3. Services d'application​

Web Frontend​

FastAPI Backend​

Travailleurs Celery​

Service Automator​

Supabase Kong​

SigNoz (optionnel)​

4. Couche de données​

ElastiCache Redis​

Amazon MQ (RabbitMQ)​

Supabase — Option A : Cloud (géré)​

Supabase — Option B : Auto-hébergée sur EKS​

PostgreSQL Automator​

5. Sécurité et IAM​

Rôles IAM​

Groupes de sécurité​

SSL/TLS​

6. Infrastructure en tant que code​

Modules Terraform​

Terragrunt​

Graphiques Helm​

Flux de données​

1. Flux de demande utilisateur​

2. Flux de demande API​

3. Flux de traitement en arrière-plan​

4. Flux de travail Automator​

5. Flux de mise à l'échelle​

6. Flux de sécurité​

Résumé de la haute disponibilité​

Optimisation des coûts​

Maintenance et opérations​

Processus de déploiement​

Stratégie de sauvegarde​

Récupération d'urgence​

Ressources supplémentaires​