Rubriques SNS et architecture de diffusion multiple

Amazon Simple Notification Service (SNS) est un service de messagerie publication/abonnement entièrement géré. Les éditeurs envoient des messages à une rubrique SNS, puis SNS les distribue immédiatement à tous les abonnés. Contrairement à SQS (fondé sur l'extraction), SNS est fondé sur la transmission : il distribue les messages aux abonnés dès leur publication. SNS est donc idéal pour diffuser simultanément des événements à plusieurs systèmes en aval.

Comme SQS, SNS propose deux types de rubriques : les rubriques Standard offrent un ordre des messages garanti au mieux, une livraison au moins une fois et un débit quasiment illimité ; elles peuvent distribuer des messages à SQS, Lambda, des points de terminaison HTTP, des e-mails, des SMS et des appareils mobiles. Les rubriques FIFO garantissent un ordre strict et une livraison exactement une fois, uniquement vers des abonnés SQS FIFO. Elles prennent en charge jusqu'à 3 000 messages par seconde avec le traitement par lots et sont utilisées lorsque l'ordre des événements doit être conservé entre plusieurs abonnés.

SNS prend en charge plusieurs types d'abonnés fondés sur des protocoles :

• SQS : mise en file d'attente durable (la plus courante pour le traitement asynchrone)
• Lambda : invocation directe (synchrone du point de vue de SNS)
• HTTP/HTTPS : distribution par webhook vers des points de terminaison externes
• E-mail / E-mail-JSON : notification destinée aux utilisateurs
• SMS : distribution de messages texte
• Notifications push mobiles : FCM, APNs via des applications de plateforme
• Firehose : flux vers S3 ou Redshift via Kinesis Data Firehose

La diffusion en étoile est le modèle central de SNS : vous publiez un message dans une rubrique et SNS le distribue simultanément à tous les abonnés. Par exemple, un nouvel événement de commande est diffusé vers une file SQS pour la préparation en entrepôt, une autre file SQS pour la mise à jour des stocks, une fonction Lambda pour la détection des fraudes et un abonnement par e-mail pour l'équipe des opérations. Chaque abonné traite l'événement indépendamment, sans couplage entre eux. Cette approche est bien plus évolutive qu'un consommateur unique qui achemine les messages vers plusieurs systèmes.

Le modèle recommandé combine SNS et SQS : vous publiez dans SNS, qui diffuse les messages vers plusieurs files SQS. Cela fournit :

• Durabilité : si un consommateur est indisponible, les messages restent en file dans SQS
• Mise à l'échelle indépendante : chaque consommateur traite les messages à son propre rythme
• Découplage : les nouveaux consommateurs s'abonnent simplement à SNS sans modification de l'éditeur
• Résilience aux nouvelles tentatives : SQS fournit un délai d'invisibilité et une DLQ

Les abonnés Lambda directs ne disposent pas de la mise en mémoire tampon fournie par SQS, ce qui fait de SNS→SQS→Lambda le modèle à trois niveaux le plus résilient.

Lorsque SNS ne parvient pas à distribuer un message à un abonné (le point de terminaison HTTP renvoie une erreur 5xx, Lambda lève une exception ou SQS est indisponible), il effectue de nouvelles tentatives selon une stratégie de temporisation exponentielle. Les stratégies varient selon le protocole : les points de terminaison HTTP bénéficient de 4 nouvelles tentatives immédiates au maximum, puis d'une temporisation exponentielle sur 23 jours ; pour Lambda et SQS, les nouvelles tentatives sont gérées par leurs propres mécanismes. Configurez une DLQ de rubrique SNS pour recueillir les messages ayant épuisé toutes leurs tentatives de distribution et vous assurer qu'aucun événement n'est perdu silencieusement.

Publiez dans SNS à l'aide de AWS SDK ou de CLI. Chaque message peut inclure un objet (pour les e-mails), un corps de message (jusqu'à 256 KB) et des attributs de message pour le routage. Pour différents types d'abonnés (SQS, e-mail ou appareil mobile), vous pouvez utiliser une structure de message afin d'envoyer un contenu différent à chaque protocole : un JSON contenant des clés propres à chaque protocole vous permet d'adapter la charge utile à chaque type d'abonné.

Les politiques de filtrage des abonnements permettent à chaque abonné de ne recevoir que les messages qui le concernent, en fonction des attributs de message. Sans filtrage, tous les abonnés reçoivent tous les messages publiés. Avec une politique de filtrage, un abonné indique les valeurs d'attribut qui l'intéressent. Par exemple, une file de commandes « PREMIUM » s'abonne avec le filtre {"orderType": ["PREMIUM"]} ; une file « STANDARD » filtre avec ["STANDARD"]. Chaque abonné traite uniquement le sous-ensemble qui le concerne, ce qui réduit le traitement inutile.

SNS prend en charge les notifications push mobiles directes vers les appareils iOS (APNs) et Android (FCM/GCM). Vous enregistrez les jetons des appareils en tant qu'ARN de points de terminaison de plateforme, puis vous publiez directement vers un point de terminaison ou vers une rubrique comportant des abonnés d'applications de plateforme. Pour les notifications directes vers des appareils à grande échelle (des millions d'appareils), combinez SNS avec la diffusion en étoile SQS : SNS achemine l'événement de notification vers SQS, puis un service worker gère la résolution groupée des jetons et la distribution à grande échelle.

Protégez les messages SNS avec le chiffrement côté serveur à l'aide de AWS KMS. Cela chiffre les messages au repos dans l'infrastructure SNS. Le contrôle d'accès utilise à la fois des politiques fondées sur les ressources (qui peut publier dans la rubrique ou s'y abonner) et des politiques IAM. Pour autoriser un compartiment S3 à publier des notifications dans une rubrique SNS, accordez sns:Publish au principal de service S3 dans la politique fondée sur les ressources de la rubrique. Limitez toujours la publication aux sources autorisées afin d'empêcher l'injection d'événements non autorisés.

SNS et SQS sont complémentaires, et non concurrents. SNS (transmission) sert à diffuser immédiatement des messages à plusieurs consommateurs : utilisez-le lorsque plusieurs systèmes doivent réagir à un événement. SQS (extraction) sert au traitement fiable et durable par un seul consommateur, avec nouvelles tentatives et DLQ : utilisez-le lorsqu'un consommateur doit traiter chaque message exactement une fois, à son propre rythme. Le modèle de diffusion en étoile SNS→SQS vous offre les deux : la distribution par diffusion de SNS et le traitement durable avec nouvelles tentatives de SQS. Cette combinaison apparaît fréquemment dans les scénarios d'examen SAA-C03.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les rubriques SNS fournissent une diffusion publication/abonnement fondée sur la transmission vers des abonnés tels que SQS, Lambda, HTTP, SMS et e-mail, simultanément ; que l'architecture de diffusion en étoile utilise une rubrique SNS alimentant plusieurs files SQS afin d'obtenir un traitement d'événements durable, indépendant et évolutif pour plusieurs consommateurs ; et que les politiques de filtrage des abonnements réduisent le traitement inutile en acheminant uniquement les événements pertinents vers chaque abonné selon les attributs de message. Nous allons maintenant étudier en détail le filtrage des messages SQS et l'intégration SNS + SQS.