Edge Computing : Patterns d'Architecture et Compromis
#edge-computing#iot#cloud#architecture#cdn
L'edge computing rapproche le calcul de la source de données ou de l'utilisateur final. Ce n'est pas un remplacement du cloud mais un complément -- la bonne architecture place les charges de travail là où elles délivrent le plus de valeur selon les exigences de latence, bande passante et souveraineté des données.
Niveaux de l'edge computing
| Niveau | Localisation | Latence | Exemples |
|---|---|---|---|
| Edge device | Sur l'appareil lui-même | < 1ms | Smartphones, capteurs, gateways |
| Near edge | Réseau local / on-premises | 1-10ms | Serveurs d'usine, magasins |
| Far edge / MEC | Edge telco, PoP régional | 5-20ms | MEC 5G, nœuds edge FAI |
| Edge CDN | PoPs distribués mondialement | 10-50ms | Cloudflare, CloudFront, Fastly |
| Région cloud | Data center centralisé | 50-200ms | Régions AWS, GCP, Azure |
Patterns d'architecture
Edge Computing CDN
Exécuter du code aux points de présence CDN, au plus près des utilisateurs.
- Cas d'usage : tests A/B, personnalisation, validation de tokens, geo-routage
- Plateformes : Cloudflare Workers, Lambda@Edge, Vercel Edge Functions, Deno Deploy
- Contraintes : temps d'exécution limité, pas d'état persistant, APIs restreintes
Edge IoT
Traiter les données on-premises ou sur des gateways avant d'envoyer au cloud.
- Cas d'usage : inspection qualité en usine, maintenance prédictive, analytique vidéo
- Plateformes : AWS IoT Greengrass, Azure IoT Edge, Google Distributed Cloud Edge
- Contraintes : compute limité, connectivité non fiable, complexité de gestion de flotte
Multi-Access Edge Computing (MEC)
Compute en bordure du réseau telco, permis par la 5G.
- Cas d'usage : véhicules autonomes, AR/VR, gaming temps réel, automatisation industrielle
- Plateformes : AWS Wavelength, Google Distributed Cloud, Azure Edge Zones
- Contraintes : partenariats opérateurs requis, couverture géographique limitée
Compromis Edge vs Cloud
| Dimension | Edge | Cloud |
|---|---|---|
| Latence | Très faible | Plus élevée (aller-retour réseau) |
| Coût de bande passante | Réduit (traitement local) | Plus élevé (transfert de toutes les données) |
| Capacité de calcul | Limitée | Virtuellement illimitée |
| Fraîcheur des données | Temps réel | Quasi temps réel à batch |
| Complexité de gestion | Élevée (nœuds distribués) | Plus faible (centralisé) |
| Modèle de coût | Hardware + maintenance | Pay-per-use |
| Périmètre de sécurité | Physiquement distribué | Contrôles centralisés |
Inférence AI/ML à l'edge
Exécuter des modèles ML à l'edge permet des décisions temps réel sans aller-retour cloud :
- Optimisation de modèles -- TensorFlow Lite, ONNX Runtime, TensorRT pour les appareils contraints
- Accélération matérielle -- NVIDIA Jetson, Google Coral, Intel Neural Compute Stick
- Gestion de modèles -- versionnement, tests A/B et rollback sur des milliers d'appareils
- Apprentissage fédéré -- entraîner sur les données edge sans les envoyer au cloud
Quand inférer à l'edge
| Facteur | Inférence edge | Inférence cloud |
|---|---|---|
| Exigence de latence | < 100ms | Secondes acceptables |
| Sensibilité des données | Ne peuvent quitter les locaux | Peuvent être envoyées au cloud |
| Connectivité | Intermittente ou absente | Fiable |
| Complexité du modèle | Simple à moyen | Complexe, grands modèles |
Défis de synchronisation des données
- Résolution de conflits -- que se passe-t-il quand edge et cloud ne sont pas d'accord ? Last-write-wins, CRDTs, ou résolution manuelle
- Consistance éventuelle -- les nœuds edge peuvent être hors ligne ; concevoir pour la sync éventuelle
- Filtrage des données -- envoyer uniquement les données agrégées ou anormales au cloud
- Gestion de la bande passante -- prioriser les données critiques quand la connectivité est limitée