Comment leboncoin a migré 12 millions d’emails quotidiens vers AWS en préservant la réputation de ses adresses IP

Chaque jour, leboncoin.fr envoie 12 millions d’emails transactionnels à ses utilisateurs. Ces messages incluent les notifications de cycle de vie d’annonces, les alertes de recherches sauvegardées et les copies de messagerie interne. En 2024, un incident silencieux a fait perdre près de 15 millions d’emails en quelques semaines. La continuité de service était compromise et la confiance des utilisateurs menacée.

Dans cet article, nous expliquons comment l’équipe Infrastructure Self-Service de leboncoin a migré cette plateforme critique depuis son datacenter vers Amazon EC2. La migration a préservé la réputation IP construite sur plusieurs années grâce à AWS BYOIP. L’équipe a reconstruit l’observabilité autour d’Amazon MSK et d’Amazon OpenSearch Service. Cette approche a réduit le temps de détection des incidents de plusieurs semaines à quelques minutes et éliminé les pertes d’emails.

Le déclencheur : l’incident silencieux de 2024

Le lift-and-shift de 2020 a basculé 99 % de l’infrastructure de leboncoin sur AWS. Quelques workloads sont restés dans le datacenter, dont 20 serveurs Postfix gérés en Puppet. La maintenance s’était dégradée au fil des années. L’observabilité était minimale.

En 2024, près de la moitié des serveurs sont tombés en panne. L’incident est resté invisible pendant plusieurs semaines. Le bilan a atteint environ 15 millions d’emails perdus. Un sujet de second plan est devenu une priorité absolue.

Le choix de la stack

L’équipe Infrastructure Self-Service de leboncoin a évalué plusieurs MTA avec son partenaire deliverability Postmastery. Les solutions évaluées incluaient PowerMTA, KumoMTA, Halon et Green Arrow. PowerMTA a été retenu pour ses performances et son concept de `Virtual MTAs`. Les Virtual MTAs permettent d’attacher plusieurs IPs publiques à un même serveur. Le mécanisme de backoff automatique gère les rate-limits fournisseur. L’API facilite l’intégration.

L’équipe a abandonné Puppet pour le provisioning. La nouvelle plateforme est décrite intégralement en Terraform et Ansible. Le déploiement s’effectue sur Amazon EC2.

Le défi central : préserver la réputation IP

En email transactionnel, la délivrabilité repose sur la réputation des IPs émettrices. Les plages d’IPs publiques des fournisseurs cloud apparaissent fréquemment dans les listes de blocage des fournisseurs de boîtes mail. leboncoin disposait dans son datacenter d’un CIDR `/23` de 512 IPs publiques. Cette réputation s’était construite sur plusieurs années.

AWS BYOIP a fourni la solution. L’équipe a découpé le `/23` en deux `/24`. Le premier est resté annoncé depuis le datacenter pour assurer la continuité. Le second a été transféré vers AWS. Le processus a nécessité la création d’une ROA dans le RIPE et le provisioning du CIDR via la CLI AWS. L’advertising a démarré depuis AWS et l’annonce côté datacenter s’est arrêtée. Ces IPs sont devenues disponibles comme AWS Elastic IP Addresses. L’équipe les a attachées aux instances Amazon EC2 du pool PowerMTA.

Un warm-up en trois vagues

Le warm-up reste obligatoire dès qu’une IP a été ré-affectée ou inactive trop longtemps. La migration s’est déroulée en trois vagues.

La première vague a utilisé 5 adresses IP déjà chaudes. La montée en charge s’est effectuée en 4 jours. La deuxième vague a mobilisé 5 adresses IP dormantes depuis un mois. La montée en charge complète a pris 1 mois. La troisième vague a déployé 11 adresses IP neuves sans aucune réputation initiale. La montée en charge s’est achevée en 1 mois, contre 4 mois lors de la première campagne menée en datacenter.

Le couple Virtual MTAs PowerMTA et pondération HAProxy a permis de répartir le trafic au pourcent près sur chaque IP. Microsoft et Yahoo ont commencé à throttler certaines IPs. Le backoff automatique de PowerMTA a basculé le trafic vers les IPs saines. Ce mécanisme a évité la mise en blacklist.

L’architecture cible sur AWS

L’architecture finale s’articule autour de deux comptes AWS dédiés. Dans le compte Producers, les microservices émetteurs envoient leurs flux SMTP vers un Network Load Balancer. Ces microservices incluent les notifications de cycle de vie d’annonces, les alertes de recherches sauvegardées, les serveurs de messagerie interne et les autres producteurs transactionnels. Le compte Messaging héberge le Network Load Balancer.

Le Network Load Balancer répartit le trafic sur trois instances Amazon EC2 PowerMTA. Ces instances sont déployées dans trois zones de disponibilité. Chaque instance porte 7 Virtual MTAs. Au total, 21 adresses IP publiques issues du transfert BYOIP sortent vers les fournisseurs de boîtes mail. Ces fournisseurs incluent Gmail, Microsoft, Orange, Yahoo et d’autres FAI.

Une observabilité repensée sur AWS

L’observabilité constitue l’autre apport majeur de cette migration. Les logs PowerMTA incluent le destinataire, les en-têtes SMTP, les codes retour et les messages d’erreur des fournisseurs. L’équipe streame ces logs vers Amazon MSK. Des pipelines Vector traitent les données. Amazon OpenSearch Service indexe les logs pour exploration dans Kibana. Un en-tête personnalisé permet de remonter de l’email final jusqu’au microservice émetteur.

Datadog complète le dispositif côté métriques d’infrastructure. La console Postmastery apporte les indicateurs de réputation. Ces indicateurs incluent le Sender Score, Google Postmaster et le throttling par fournisseur. L’ensemble alimente un alerting Slack temps réel. Les alertes couvrent les anomalies de queues, les pics de bounces et les dégradations de réputation.

Le bonus inattendu : Smart Capping

Quelques mois après la mise en production, une annonce leboncoin est devenue virale. SFR a interprété le pic de notifications associé comme du mail-bombing. L’opérateur a immédiatement rate-limité l’ensemble des IPs. Tous les destinataires SFR ont été impactés, bien au-delà de l’annonce concernée.

L’enseignement est clair. L’infrastructure ne doit pas porter la logique métier. Les équipes produit doivent définir par workflow et par utilisateur ce qui constitue un volume légitime. L’équipe technique a répondu par une segmentation du trafic en pools de Virtual MTAs dédiés par type d’email. Un incident sur un workflow promotionnel ne peut plus affecter un email de reset de mot de passe.

Les résultats en chiffres

La migration complète s’est effectuée en 8 mois. Aucune perte d’emails n’a été constatée depuis la mise en production. Le coût d’infrastructure s’élève à environ 1 800 dollars par an avec la stack PowerMTA sur Amazon EC2. Le temps de détection des incidents est passé de plusieurs semaines à quelques minutes.

L’équipe a réactivé les feedback loops Microsoft et Yahoo. La plateforme catégorise automatiquement les bounces. Les dashboards affichent les métriques par domaine et par fournisseur.

Conclusion

leboncoin a migré une plateforme d’envoi d’emails transactionnels critique depuis un datacenter on-premise vers AWS. AWS BYOIP a préservé une réputation IP construite sur plusieurs années. Le projet a finalisé la sortie du datacenter historique. L’équipe a rebâti une stack d’observabilité moderne sur AWS. Cette architecture instaure une frontière saine entre l’infrastructure et le produit.

Vous pouvez transférer vos propres plages IP vers AWS pour préserver votre réputation métier. Amazon MSK et Amazon OpenSearch Service offrent une observabilité complète sur vos flux critiques. Cette approche réduit drastiquement le temps de détection et de résolution des incidents.

Pour aller plus loin

• Consultez la documentation Bring Your Own IP Addresses (BYOIP) dans Amazon EC2 pour transférer vos plages IP.
• Découvrez Amazon Managed Streaming for Apache Kafka pour gérer vos flux de données en temps réel.
• Explorez Amazon OpenSearch Service pour indexer et analyser vos logs.
• Apprenez à utiliser AWS Elastic IP Addresses pour attacher des IPs publiques à vos instances

Auteurs