Simple Message Queue (SMQ, anciennement MNS) prend en charge la migration depuis AWS Simple Queue Service (SQS) et AWS Simple Notification Service (SNS). Comparez les fonctionnalités, les limites et les SDK des deux services, puis suivez un processus en quatre étapes avec lecture et écriture doubles pour migrer vos charges de travail.
Contexte
SMQ, Amazon SQS et Amazon SNS partagent des capacités de messagerie similaires :
SMQ propose à la fois le modèle de messagerie basé sur les files d'attente et le modèle basé sur les topics.
Amazon SQS fournit le modèle de messagerie basé sur les files d'attente.
Amazon SNS offre le modèle de messagerie basé sur les topics.
Étant donné que ces services se chevauchent fonctionnellement, la migration d'Amazon SQS ou d'Amazon SNS vers SMQ est simple.
Prérequis
Avant de commencer, procédez comme suit :
Un compte Alibaba Cloud avec SMQ activé. Activer SMQ et autoriser les utilisateurs RAM à accéder à SMQ.
Un inventaire de vos files d'attente Amazon SQS et de vos topics Amazon SNS, incluant les configurations telles que les périodes de rétention, les délais de visibilité, les paramètres de délai, les abonnements et les politiques de nouvelle tentative.
Les identifiants d'accès pour vos environnements AWS et Alibaba Cloud.
Une compréhension claire de vos producteurs et consommateurs de messages afin de planifier le basculement avec lecture et écriture doubles.
Correspondance des concepts
Le tableau suivant établit la correspondance entre les concepts clés d'Amazon SQS/Amazon SNS et de SMQ. Notez les différences de comportement indiquées dans la troisième colonne.
| Concept AWS | Équivalent SMQ | Différences de comportement |
|---|---|---|
| File d'attente standard SQS | File d'attente SMQ (modèle de messagerie basé sur les files d'attente) | Les deux services prennent en charge les états de message Actif, Inactif, Supprimé et Expiré. Le délai de visibilité par défaut de SMQ est de 30 secondes ; Amazon SQS n'en possède pas. |
| File d'attente FIFO SQS | File d'attente FIFO SMQ (mise en séquence) | Pris en charge par les deux services. |
| File d'attente de lettres mortes SQS | File d'attente de lettres mortes SMQ | Pris en charge par les deux services. |
| Topic SNS | Topic SMQ (modèle de messagerie basé sur les topics) | Les noms de topics SMQ ne sont pas sensibles à la casse (1 à 120 caractères). Les noms de topics Amazon SNS sont sensibles à la casse (3 à 64 caractères). |
| Topic FIFO SNS | Topic FIFO SMQ (mise en séquence) | Pris en charge par les deux services. |
| Abonnement SNS (politique de filtre JSON) | Abonnement SMQ (filtrage basé sur les tags) | Le filtrage des données diffère : SMQ utilise un filtrage basé sur les tags, tandis qu'Amazon SNS repose sur des politiques JSON. Convertissez votre logique de filtre lors de la migration. |
| Points de terminaison d'abonnement SNS (File d'attente, HTTP, SMS, E-mail, Push mobile, Lambda) | Points de terminaison d'abonnement SMQ (File d'attente, HTTP, Message texte, E-mail, Push mobile, Function Compute) | Amazon SNS s'intègre à AWS Lambda ; SMQ s'intègre à Function Compute. |
| File d'attente de lettres mortes SNS | File d'attente de lettres mortes SMQ (modèle de topic) | Pris en charge par les deux services. |
Comparaison des fonctionnalités
Les tableaux suivants comparent les fonctionnalités de SMQ, Amazon SQS et Amazon SNS selon le modèle de messagerie.
Modèle de messagerie basé sur les files d'attente
| Fonctionnalité | SMQ | Amazon SQS |
|---|---|---|
| Cycle de vie des messages | Pris en charge (états : Actif, Inactif, Supprimé, Expiré) | Pris en charge (états : Actif, Inactif, Supprimé, Expiré) |
| Période de rétention personnalisée pour les messages | Pris en charge | Pris en charge |
| Délai de message (période planifiée) | Pris en charge | Pris en charge |
| Période de délai de visibilité | Pris en charge | Pris en charge |
| Longueur maximale du message | Pris en charge | Pris en charge |
| File d'attente de lettres mortes | Pris en charge | Pris en charge |
| File d'attente FIFO (mise en séquence) | Pris en charge | Pris en charge |
Modèle de messagerie basé sur les topics
| Fonctionnalité | SMQ | Amazon SNS |
|---|---|---|
| Filtrage des données | Filtrage des données par tag | Filtrage des données par politique JSON |
| Abonnement à une file d'attente | Pris en charge | Pris en charge |
| Abonnement HTTP | Pris en charge | Pris en charge |
| Abonnement par message texte | Pris en charge | Pris en charge |
| Abonnement par e-mail | Pris en charge | Pris en charge |
| Push mobile | Pris en charge | Pris en charge |
| Function Compute | Pris en charge | Pris en charge |
| File d'attente de lettres mortes | Pris en charge | Pris en charge |
| Topic FIFO (mise en séquence) | Pris en charge | Pris en charge |
Comparaison des limites
Certaines différences de limites peuvent influencer votre plan de migration. Les tableaux ci-dessous comparent les limites de SMQ, Amazon SQS et Amazon SNS selon le modèle de messagerie.
Limites du modèle de messagerie basé sur les files d'attente
| Limite | SMQ | Amazon SQS |
|---|---|---|
| Nom de la file d'attente | Sensible à la casse, 1 à 120 caractères. | Sensible à la casse, 1 à 80 caractères. |
| Période de rétention des messages | 7 jours | 14 jours |
| Intervalle d'interrogation longue (long polling) | Valeurs valides : 0 à 30. Valeur par défaut : 15. Unité : secondes. | Valeurs valides : 0 à 20. Unité : secondes. |
| Charge utile maximale du message | 64 Ko. Pour augmenter cette limite, soumettez un ticket. | 256 Ko |
| Période de délai de visibilité | Valeurs valides : 1 à 43200. Valeur par défaut : 30. Unité : secondes. | Valeurs valides : 1 à 43200. Unité : secondes. Aucune valeur par défaut n'est définie. |
| ID de file d'attente | Les noms de files d'attente sont uniques par région. Les ID de message sont globalement uniques. Les handles de réception sont des chaînes personnalisées. | Les noms de files d'attente sont uniques par région. Les ID de message sont globalement uniques. Les handles de réception sont des chaînes personnalisées. |
| Délai de message | DelaySeconds : 0-604800 secondes. | DelaySeconds : 0-604800 secondes. |
| Nombre maximal de messages accumulés | Aucune limite | Aucune limite |
| Nombre maximal de requêtes par seconde (QPS) | Aucune limite par file d'attente. Le QPS total (file d'attente + topic) est plafonné à 20 000 par compte et par région. Politique de limitation. | Aucune limite |
Limites du modèle de messagerie basé sur les topics
| Limite | SMQ | Amazon SNS |
|---|---|---|
| Nom du topic | Insensible à la casse, 1 à 120 caractères. | Sensible à la casse, 3 à 64 caractères. |
| Longueur maximale du message | 64 Ko | 256 Ko |
| Politique de nouvelle tentative | Backoff : 3 nouvelles tentatives à des intervalles de 10 à 20 secondes. Décroissance exponentielle : 176 nouvelles tentatives par jour. | Backoff : 3 nouvelles tentatives à des intervalles de 20 secondes. Décroissance exponentielle : nombre de nouvelles tentatives configurable. |
| Nombre maximal d'abonnements à un seul topic | 100. Pour augmenter cette limite, soumettez un ticket. | 12500000 |
| QPS maximal | Aucune limite par topic. Le QPS total (file d'attente + topic) est plafonné à 20 000 par compte et par région. Politique de limitation. | 300 QPS par topic ou 10 Mo/s. Le comptage commence lorsque le topic reçoit sa première requête. |
Différences de limites clés et solutions de contournement
Portez une attention particulière aux différences de limites suivantes :
Charge utile maximale du message (64 Ko contre 256 Ko) : SMQ est limité par défaut à 64 Ko, contre 256 Ko pour Amazon SQS et Amazon SNS. Pour demander une limite plus élevée, soumettez un ticket. Vous pouvez également stocker les corps de message volumineux dans OSS et transmettre la référence de l'objet dans le message. Transmettre des messages surdimensionnés.
Nombre maximal d'abonnements par topic (100 contre 12 500 000) : SMQ autorise par défaut 100 abonnements par topic, contre 12 500 000 pour Amazon SNS. Pour augmenter cette limite, soumettez un ticket.
Période de rétention des messages (7 jours contre 14 jours) : SMQ conserve les messages jusqu'à 7 jours, contre 14 jours pour Amazon SQS. Assurez-vous que vos consommateurs traitent les messages dans ce délai de 7 jours.
Filtrage des données : SMQ utilise un filtrage basé sur les tags pour les abonnements aux topics, tandis qu'Amazon SNS repose sur des politiques JSON. Repensez votre logique de filtre lors de la migration.
Comparaison des SDK
Le tableau suivant compare les SDK disponibles.
| SDK | Alibaba Cloud SMQ | Amazon SQS | Amazon SNS |
|---|---|---|---|
| Opérations API | Référence API | Référence API | Référence API |
| SDK HTTP | SDK pour Java, SDK pour Python, SDK pour C#, SDK pour PHP, SDK pour C++, SDK pour Go et SDK pour JMS | SDK pour Java, SDK pour JavaScript, SDK pour PHP, SDK pour Python, SDK pour Ruby et SDK pour .NET | SDK pour Java, SDK pour JavaScript, SDK pour PHP, SDK pour Python, SDK pour Ruby et SDK pour .NET |
Processus de migration
Synchronisez les métadonnées des files d'attente, des topics et des abonnements entre AWS et SMQ, puis utilisez des politiques de lecture et d'écriture doubles pour migrer les données.
La migration se déroule en quatre étapes, chacune ayant un objectif, des actions requises et des critères de sortie.
Étape 1 : État de référence et préparation des ressources
Objectif : Préparer les ressources SMQ équivalentes.
Actions :
Inventoriez toutes les files d'attente Amazon SQS et tous les topics Amazon SNS. Enregistrez leurs configurations : périodes de rétention, délais de visibilité, paramètres de délai et abonnements.
Créez les files d'attente et les topics correspondants dans SMQ avec des configurations équivalentes. Tenez compte des différences de limites : taille de la charge utile du message, limites d'abonnement et périodes de rétention.
Synchronisez les métadonnées d'abonnement. Convertissez les politiques de filtre JSON d'Amazon SNS en filtres basés sur les tags SMQ le cas échéant.
Configurez la surveillance pour AWS et SMQ afin de comparer le flux de messages pendant la migration.
Critères de sortie : Les files d'attente et les topics SMQ sont créés et configurés. La surveillance est en place pour les deux environnements.
Étape 2 : Activer la double lecture sur les consommateurs
Objectif : Activer la double lecture afin que les consommateurs traitent les messages des deux services.
Actions :
Mettez à jour les applications consommatrices pour qu'elles lisent à la fois les files d'attente Amazon SQS et SMQ (double lecture), en vous assurant qu'elles gèrent les messages SMQ avant le basculement des producteurs.
Validez que les messages SMQ sont consommés correctement. Vérifiez la compatibilité du format des messages, le comportement d'accusé de réception et la gestion des erreurs.
Surveillez le décalage des consommateurs (consumer lag) et les taux d'erreur des deux côtés pour confirmer que la consommation SMQ est stable.
Critères de sortie : Les consommateurs traitent avec succès les messages provenant de SMQ sans erreur pendant une période prolongée.
Étape 3 : Basculer les producteurs vers SMQ
Objectif : Basculer les producteurs vers l'écriture dans SMQ tout en maintenant la double lecture côté consommateur.
Actions :
Mettez à jour les applications productrices pour publier des messages dans SMQ au lieu d'Amazon SQS, ou en plus de celui-ci.
Si vous exécutez une écriture double, surveillez les deux flux de messages pour confirmer que les messages arrivent correctement dans SMQ.
Une fois les producteurs entièrement basculés vers SMQ, vous pouvez arrêter l'écriture double. Les consommateurs doivent continuer la double lecture pour vider les messages restants d'Amazon SQS.
Critères de sortie : Tous les producteurs publient avec succès dans SMQ. La livraison des messages est confirmée via la surveillance.
Étape 4 : Mettre hors service les ressources AWS
Objectif : Mettre hors service les ressources Amazon SQS/Amazon SNS.
Actions :
Attendez que tous les messages restants dans les files d'attente Amazon SQS soient vidés. Surveillez la profondeur de la file d'attente jusqu'à ce qu'elle atteigne zéro.
Supprimez la logique de double lecture des applications consommatrices afin qu'elles ne lisent que depuis SMQ.
Mettez hors service les files d'attente Amazon SQS et les topics Amazon SNS dans AWS.
Mettez à jour votre documentation et vos procédures opérationnelles pour refléter la nouvelle architecture basée sur SMQ.
Critères de sortie : Toutes les ressources Amazon SQS/Amazon SNS sont mises hors service. Tous les producteurs et consommateurs fonctionnent exclusivement via SMQ.
Tests et validation
Effectuez ces tests avant et pendant la migration :
Tests fonctionnels : Envoyez des messages de test via SMQ. Vérifiez que les consommateurs les reçoivent correctement et que les attributs de message, les délais et les délais de visibilité fonctionnent comme prévu.
Validation du filtrage : Vérifiez que les filtres basés sur les tags de SMQ produisent les mêmes résultats que vos filtres de politique JSON Amazon SNS.
Tests de performance : Comparez le débit et la latence des messages entre votre configuration AWS et SMQ. La limite QPS de SMQ est de 20 000 par compte et par région. Politique de limitation.
Tests de la file d'attente de lettres mortes : Envoyez des messages mal formés ou non traitables pour vérifier que les files d'attente de lettres mortes SMQ les capturent correctement.
Tests du comportement de nouvelle tentative : Vérifiez que la politique de nouvelle tentative (backoff et décroissance exponentielle) répond à vos besoins. Notez les différences d'intervalles et de nombres de nouvelles tentatives entre SMQ et Amazon SNS.
Surveillance et alertes : Confirmez que vos outils de surveillance capturent les métriques SMQ (nombre de messages, décalage des consommateurs, taux d'erreur) et que les alertes se déclenchent comme prévu.
Préparation au retour arrière : Maintenez les ressources Amazon SQS/Amazon SNS actives pendant les étapes 2 et 3. Si des problèmes surviennent avec SMQ, revenez à Amazon SQS pour les producteurs et au mode de double lecture pour les consommateurs jusqu'à résolution.