Comment créer une application de messagerie instantanée sur Azure ?

L’apparition de nouveaux moyens de communications a bouleversé les interactions humaines. En évolution permanente depuis la fin du XXème siècle, la messagerie instantanée permet aux utilisateurs de communiquer en temps réel par internet, et ce dans le monde entier. Aujourd’hui, elles sont utilisées par des milliards d’utilisateurs actifs à travers le monde, et plusieurs dizaines de milliards de messages sont envoyés chaque jour.

Vous-êtes-vous déjà demandé comment concevoir l’architecture d’une application de messagerie instantanée sur Azure ?

Retour vers le futur

La messagerie instantanée n’est pas aussi récente que l’on pourrait le croire. En effet, sous UNIX, elle existe depuis longtemps sous forme de texte grâce à la commande « talk » ; puis il y a eu l’équivalent sous Microsoft Windows avec WinPopUP. Ces deux systèmes étaient alors basés sur une paire utilisateur/machine. Le protocole standard Internet Relay Chat (ICR), fournit lui aussi depuis 1988 des fonctionnalités simples de discussions multicanales. Ces manières d’échanger sur internet ne sont toutefois plus considérées comme étant de la messagerie instantanée. Cela est dû au fait qu’il n’y a pas ou peu d’authentification ni de gestion de présence, éléments essentiels des messageries instantanées actuelles

Qu’est-ce qu’une messagerie instantanée ? 

Définissons tout d’abord les éléments structurant une plateforme de messagerie instantanée telle que nous le considérons aujourd’hui :

• Transmission des messages : tous les messages doivent être délivrés par l’intermédiaire d’internet
• Variété des messages : les messages pouvant être délivrés peuvent aussi bien contenir du texte que des médias (photos et/ou vidéos)
• Montée en charge et résilience : tous les messages doivent être délivrés sans doublons, sans perte, quel que soit le nombre d’utilisateurs
• Distribution Globale : tous les messages doivent être délivrés en instantané, peu importe où se situe l’émetteur et le receveur du message
• Sécurité : tous les canaux sont isolés, un message destiné à une personne spécifique ne doit pas être lu par une autre personne

La sécurité est l’élément essentiel de la plateforme. Cette dernière doit avoir la capacité de protéger les utilisateurs et leurs messages en appliquant un niveau de chiffrement adéquat.

Comment concevoir une telle plateforme dans Azure ?

Un des aspects fondamentaux de la messagerie instantanée est de pouvoir assurer la compartimentation et le bon chiffrement des messages. En effet, il essentiel que les messages envoyés soient toujours délivrés au bon destinataire. Pour ce faire, il est donc recommandé d’appliquer un chiffrement dit de bout en bout : seules les personnes communiquant ensemble ont accès aux messages.

Techniquement, comment cela fonctionne ? La solution de chiffrement repose sur le principe dit de cryptographie asymétrique :

1. Initialisation de la conversation : Paul souhaite envoyer un message à Julie. Il récupère, au niveau du répertoire de la plateforme, la clef publique de Julie.
2. Chiffrement du message: Paul chiffre son message à l’aide de sa clef privé et de la clef publique de Julie.
3. Envoie du message : Paul envoie son message chiffré à Julie.
4. Déchiffrement: Julie utilise ses clefs (sa clef privée et la clef publique de Paul) afin de déchiffrer le message.

Grâce à ce principe, seule Julie est capable de déchiffrer le message que Paul lui a envoyé. Pour les conversations de groupe, c’est la même solution : l’utilisateur enverra un message unique dans son interface, cependant un message sera envoyé à chaque participant en appliquant le même principe de chiffrement.

Maintenant que les messages sont chiffrés et lisibles uniquement des utilisateurs voulus, intéressons-nous au backend de l’application et plus précisément à la base de données utilisée.

La base de données contient :

• Les clefs publiques des utilisateurs: ces dernières sont récupérées lors de l’initialisation d’une conversation par l’application mobile de l’envoyeur afin de chiffrer les messages.
• Les profils des utilisateurs: ces derniers sont composés des informations personnelles des utilisateurs (nom, numéro de phone, id d’application …)
• Les messages chiffrés des utilisateurs.

Il est à noter que les clefs privées des utilisateurs ne sont pas stockées dans le cloud. Ces dernières seront stockées et gérées au sein même de l’application mobile afin de limiter la surface d’attaque.

Rappelons-nous qu’une messagerie instantanée moderne doit être performante et résiliente, il faut nous donc une base de données répondant à ce besoin : Azure Cosmos DB.

Azure Cosmos DB

Afin d’obtenir la latence la plus faible possible, il est essentiel que la donnée soit au plus près de l’utilisateur. Azure Cosmos DB est une base de données globalement distribuée permettant de répliquer en toute transparence les données partout dans le monde. Ainsi, l’application peut fonctionner sur une copie des données, au plus proche des utilisateurs.

L’avantage de Azure Cosmos DB est qu’il est possible d’ajouter ou de supprimer une nouvelle région à tout moment, en un clic, et sans interruption de service. La réplication multi-maître permet également d’écrire partout à travers le monde, garantissant le traitement des lectures et écritures en moins de 10 millisecondes (au 99ème centile).

Azure Cosmos DB apporte également une scalabilité horizontale illimitée en répartissant les données et le débit sur un grand nombre de partitions logiques, reliées à des partitions physiques. Ces partitions physiques sont gérées par Azure Cosmos DB ; les partitions logiques, elles, sont définies par la clef de partition. Il est essentiel de choisir une bonne clef de partition afin de bien distribuer les données, la charge, et le débit, et ainsi éviter de créer des partitions chaudes.

Pour cette application de messagerie instantanée, la clef de partition composite “Conversation ID + Time“ est un bon choix. En effet, rajouter la dimension de temps (yyyy/mm/dd/hh) permet d’augmenter la granularité de la clef et diminue le risque d’atteinte des limitations de stockage par partition. Cela permet également d’envisager une séparation entre les données récentes (fortement requêtées) et plus anciennes (moins requêtées) avec une architecture lambda ; et donc une rationalisation des coûts.

Maintenant que les messages sont correctement chiffrés et stockés, que les utilisateurs sont inscrits et protégés, il reste à définir la gestion des événements, des notifications et l’envoie de médias.

Les interactions utilisateurs 

Pour cela nous allons définir une API App qui aura le rôle de gérer les différentes interactions utilisateurs :

• Renseignement de profil
• Envoie des messages
• Envoie des médias
• Lecture des messages
• Lecture des médias

Il faut alors les combiner à des fonctions, qui elles, auront pour but de réaliser les actions associées.

Deux étapes sont nécessaires à la création d’une discussion :

1. Envoie du message
2. Récupération et lecture du message

Comment envoyer les messages ?

Tout d’abord intéressons-nous à l’architecture d’envoi de messages :

1. Le message, chiffré à l’aide de sa clef privé et de la clef publique du destinataire, est envoyé par l’utilisateur. Deux possibilités :

2. Le message est un message texte: l’API App envoie le message dans un Azure Service Bus, ce qui aura comme conséquence de déclencher une Azure Functions.

3. La fonction aura pour but de venir récupérer le message et le déposer dans la base de données.

2′. Le message est un contenu média l’API App aura alors deux actions concomitantes : d’une part elle stockera le « payload » de l’action dans le Service Bus, et d’autre part le média dans un Blob.

3′. Au bout d’un certain temps le média sera stocké par une autre fonction dans un blob de type archive. Cela permet de faire des économies sur le coût de stockage des médias.

La question des discussions de groupes se posent alors. Nous avons pris la décision, pour des raisons de simplicités de gestion du chiffrement, d’envoyer autant de messages que de personnes dans la conversation.

Par exemple, si nous prenons une conversation à 3 utilisateurs, Paul Julie et Karim : Paul envoie un message au groupe. Ce message sera chiffré et envoyé à Julie et Karim en utilisant les clefs publiques de ces derniers. Cela permet alors de s’assurer que chaque message pourra être déchiffré seulement par le destinataire. De plus, il n’y a pas besoin d’avoir à gérer une autre clef de chiffrement partagée par les membres de ladite discussion. Cependant, il faudra gérer ce mécanisme au niveau applicatif afin d’éviter que le message apparaisse plusieurs fois.

Maintenant que nous avons vu comment envoyer des messages, il faut que le destinataire soit notifié et qu’il puisse accéder à ce message.

Comment recevoir les messages ?

Les messages chiffrés sont stockés dans la base de données. Il faut alors notifier l’utilisateur qu’un message non lu est disponible et lui mettre à disposition.

Intéressons-nous à l’architecture cible :

Le message chiffré (texte ou média) est envoyé par l’utilisateur à l’aide de sa clef privée et de la clef publique du destinataire. Deux possibilités alors :

1. Le message est un message texte; l’API App envoie ce dernier dans un Service Bus où une fonction sera déclenchée.
2. La fonction va venir prendre le message et le stocker dans la base Cosmos DB.
3. Le destinataire du message est notifié à l’aide de Notification Hub.
4. Le destinataire du message va ouvrir le message pour le lire. Cela s’illustre par une demande de lecture de message d’ID « n°i » à l’API App.
5. L’API App poste dans un Event Hub l’événement « utilisateur x demande de lire le message d’ID n°i » ce qui va déclencher une fonction
6. Le rôle de cette fonction va être de récupérer le bon message en base pour le poster dans un cache. Pour une discussion de groupe notamment, cela permet de limiter les accès à la base de données et donc d’améliorer l’expérience utilisateur et de réduire le coût de la solution.
7. L’utilisateur peut alors lire le message.
8. Le message est un média; l’API App aura alors deux actions concomitantes : d’une part elle stockera le « payload » de l’action dans le Service Bus, et d’autre part, le média dans un Blob.
9. Une fonction sera alors déclenchée afin d’indexer le média.
10. Le destinataire du message est notifié à l’aide de Notification Hub.
11. Azure Media Services récupère le fichier média afin de l’encoder correctement et de le délivrer à l’utilisateur au travers d’un Content Delivery Network (CDN).
12. L’utilisateur accède au CDN afin de lire son contenu média.
13. Au bout d’un certain temps le média sera stocké par une autre fonction dans un blob de type archive. Cela permet de faire des économies sur le coût de stockage des médias.

Une partie importante de la solution réside au sein même de l’application mobile. Cela nécessite du développement afin de réaliser l’interface utilisateur, gérer le chiffrement/déchiffrement des messages, la vérification du destinataire (Est-ce qu’il existe ? Est-ce que je possède sa clef publique ? Etc.) …

En résumé…

Il y a deux principaux points d’attentions pour ce type d’application : le bon chiffrement des messages et la bonne compartimentation des conversations.

Vous avez désormais les bases pour concevoir une architecture de messagerie instantanée scalable et hautement disponible, chiffrée de bout en bout. Azure vous offre la capacité d’utiliser une solution de cryptage et de sécurité capable d’assumer de fortes montées en charge tout en s’assurant de la performance et de la bonne expérience utilisateur.

Découvrez Azure et ses possibilités afin d’innover et de disrupter votre marché !

Et vous, have you ever wondered…?

• Episode 1 de la saga « Have You Wondered » : Comment concevoir une plateforme VOD sur Azure ?

Liste des produits utilisés :

• Blob Storage : Sert à stocker de grandes quantités de données non structurées (ex. données textuelles ou binaires), qui sont accessibles depuis n’importe où dans le monde via HTTP ou HTTPS. Vous pouvez utiliser les BLOB pour exposer des données publiquement ou de façon privée pour une application.
• Content Delivery Network : Fournit une livraison de contenu sécurisée et fiable avec une portée mondiale et un ensemble riche de fonctionnalités.
• Azure Event Hub : Azure Event Hub est un bus d’événement pouvant processer des millions d’événements par seconde.
• Azure Functions : Azure Functions est une solution serverless pour faire tourner de petite partie de code, ou fonctions, dans le cloud.
• Azure Redis Cache : Azure Redis Cache est utilisé comme cache pour améliorer les performances et l’évolutivité des systèmes qui dépendent fortement des backend.
• Azure Cosmos DB: Azure Cosmos DB est le service de base de données multimodale ayant une distribution mondiale.
• Azure Service bus: Azure service bus est un service manager de gestion de message.
• Azure Mobile App: Azure Mobile App est un service manager offrant aux développeurs et aux intégrateurs systèmes une plateforme de développement d’application mobile.
• Azure Media Service: c’est un gestionnaire de contenu multimédia manager offrant différents services.
• Azure API App : permet de gérer (get/post) des API dans le cloud dans différents langages
• Azure Notification Hub: est un moteur de notification push manager prenant en charge tous les types d’OS.
• Azure Key Vault: HSM manager dans le cloud.
• Azure Active Directory: annuaire d’identité permettant de gérer les identités et les accès utilisateurs.