Comparatif des solutions techniques pour la fédération

Après réflexion au sein de l’équipe IGN/Panoramax, nous partageons celles-ci pour les compléter, les commenter collaborativement.


Deux systèmes sont pour l’instant envisagés pour gérer la mise en commun du catalogue des instances Panoramax / GeoVisio :

  • Méta-catalogue : un serveur recense et agrège les catalogues de toutes les instances publiques
  • Fédération décentralisée : chaque instance a connaissance de tout ou partie des séquences publiquement disponibles

Chacune des solutions a ses avantages et inconvénients, qui sont présentés ici. Ce document considère que les données partagées sont uniquement les métadonnées des photos et pas les fichiers images en eux-mêmes. Ceci constitue une première étape dans la communication entre instances.

Méta-catalogue

Principe de fonctionnement

Le méta-catalogue repose sur un serveur tiers, indépendant des instances GeoVisio actuellement existantes, qui vient interroger régulièrement ces instances afin de connaître le contenu publié. Le méta-catalogue propose alors l’ensemble de sa base d’images sous la forme d’une API STAC, au format identique à celui des instances GeoVisio. Le méta-catalogue ne stocke pas les photos, juste les métadonnées de celles-ci.

Avantages

  • Solution rapide à implémenter techniquement. En synthèse, une base de données PostgreSQL alimentée par des scripts de moissonnage des différentes instances GeoVisio publiques et le code pour fournir l’API de recherche.
  • Bonne capacité à passer à l’échelle. Les métadonnées représentant un volume faible d’information, la multiplication des instances et des photos hébergées n’entraîne pas des contraintes excessives de stockage sur une seule machine.
  • Des réponses rapides aux requêtes. Tout le catalogue étant stocké en local, la réponse aux requêtes clientes sont instantanées.
  • Une solution légère pour les mainteneurs d’instances. Aucun coût supplémentaire, la seule nécessité étant de permettre la consultation publique du catalogue et de se faire connaître du meta-catalogue.

Inconvénients

  • Une résilience limitée face aux pannes. Un serveur unique créé un noeud central dans l’éco-système Panoramax. En cas d’indisponibilité du service, on revient au fonctionnement actuel, à savoir interroger les instances une à une. Le code étant libre, tout un chacun peut redéployer le service, mais avec une rupture de service potentiellement importante. Il est toutefois possible d’ajouter de la redondance (serveur mirroir du meta-catalogue, cluster).
  • La nécessité pour une instance de se faire connaitre. Chaque administrateur d’une instance GeoVisio publique devra faire savoir au gestionnaire du méta-catalogue qu’il veut être intégré à la liste des instances publiques. Un mécanisme intégré à Geovisio pourrait faciliter une auto-inscription sur le méta-catalogue lors du déploiement initial.
  • Un nouveau service à exploiter. Cette approche rajoute un nouveau service à développer, maintenir et héberger.

Fédération décentralisée

La fédération décentralisée s’appuie sur les instances GeoVisio existantes, sans nécessité de serveur tiers. Ces instances communiqueraient régulièrement entres elles pour se partager la disponibilité de nouvelles séquences et images. Chaque instance dispose d’une vue sur les métadonnées des photos disponibles au sein de la fédération. Elle intègre dans ses réponses STAC ses propres photos et celles d’autres instances de la fédération.

Principe de fonctionnement

Avantages

  • Une meilleure résilience face aux pannes. Si un serveur est momentanément indisponible, les utilisateurs peuvent interroger n’importe quelle autre instance GeoVisio pour accéder au catalogue de la fédération. Attention, comme seules les métadonnées sont partagées, cela n’empêchera pas de perdre l’accès aux photos stockées sur les instances hors-service (tout comme avec le meta-catalogue).

Inconvénients

  • Un mix entre son propre catalogue et celui de la fédération. Il est plus compliqué pour un utilisateur tiers de comprendre d’où proviennent les métadonnées d’une photo en particulier, vu qu’elles seront mélangées dans les réponses de l’instance.
  • Une vue différente sur les photos disponibles selon l’instance. Même si chaque instance peut avoir une vue complète du catalogue de la fédération, il est possible que certains serveurs ignorent l’arrivée de nouvelles instances, ou bloquent l’affichage des photos de certaines instances. Un utilisateur aura donc un aperçu potentiellement partiel du catalogue de la fédération selon l’instance à laquelle il s’adresse.
  • Des coûts supplémentaires pour chaque instance. Les synchronisations entre chaque instance étant fréquentes, chaque serveur hébergeant une instance GeoVisio aura des échanges réseaux plus fréquents, ainsi qu’un besoin en stockage supplémentaire. Cela impactera surtout les petites instances ayant peu de ressources, qui pourraient alors se désolidariser de la fédération pour limiter les coûts.
  • Un trafic de synchronisation globalement exponentiel pour la mise à jour des catalogues :
    • N instances génereront N * (N-1) flux de synchronisation… pour 10 cela fait 90 pour 100 cela fera… 9900 alors qu’un meta-catalogue ne fera que N synchro en tout.
    • chaque instance devra faire N-1 synchro ce qui sera une charge grandissante et non maîtrisée pour chacune d’elle
  • Des contraintes supplémentaires sur la mise à jour. En cas d’évolution non-rétrocompatible des protocoles de communication entre instances, la disponibilité du catalogue de la fédération dépendra de la rapidité de chaque instance à se mettre à jour.
  • La nécessité pour une instance de se faire connaitre de toutes les autres. Problème identique au meta-catalogue mais démultiplié par le nombre d’instances.
1 Like

Bonjour,

A la lecture de ce compte-rendu, j’ai le sentiment que le choix est quasi déjà fait.
Il y a plus d’inconvénients listés pour la fédération que pour le meta-catalogue, pour moins d’avantages.

De plus, les inconvénients du meta-catalogue ont déjà des pistes de solutions (auto-inscription, cluster…), alors que les inconvénients de la fédération paraissent difficile à adresser (ressources pour synchro exponentielles, rapidité de mise à jour des instances en cas de non-rétrocompatibilité…).

Comment sont traités les inconvénients listés pour le fédéré sur d’autres projets qui fonctionnent ainsi ? Je pense à Peertube, Mastodon par exemple.

Même si le document produit paraît biaisé, on est vraiment parti sans à priori sur les deux solutions. C’est en commençant à creuser que se sont révélés un certain nombre de soucis pour l’aspect fédéré.

Sur la gestion des problèmes soulevés par la fédération entre instances, quelques pistes de réponses de comment c’est géré par ailleurs :

  • Mix entre son catalogue et celui des autres instances : sur Mastodon, on a la notion de Fil local et Fil global. Sur Peertube, tout est mélangé dans les résultats, mais une mention fait apparaître l’utilisateur + l’instance d’où vient une vidéo. En sachant qu’une instance peut n’afficher que son propre catalogue.
  • Vue différente du catalogue selon les instances : ça a toujours été un problème sur Mastodon, soit on part sur une instance “majeure” (avec les problèmes de charge que ça entraîne pour elle), soit on est sur une plus petite instance mais où l’on risque de rater du contenu car pas listé par cette instance. C’est un écho qu’on a moins souvent sur Peertube, probablement car l’usage final est plus client/serveur (je regarde une vidéo) que pair à pair (je veux discuter avec n’importe qui dans le monde). Ça n’empêche pas Peertube d’avoir un méta-catalogue.
  • Coûts en plus pour chaque instance : le principal coût supplémentaire semble venir du stockage. Certains hébergeurs Mastodon gèrent ça en limitant la capacité de fédération (federation capacity). Ou en ayant des instances hors fédération.
  • Contraintes de mise à jour : visiblement le protocole ActivityPub est assez stable (dernière version 2018), tant que les services se tiennent à la norme, pas de soucis. Ça veut aussi dire que tout ce qui s’éloigne de la norme est sujet à support aléatoire : Mastodon a une limite de nombre de caractères autorisée qui lui est spécifique, et qui a changé avec les versions. Rien n’empêche un autre client ActivityPub compatible d’envoyer des messages plus longs.
  • Nécessité d’une instance de se faire connaître : pour Peertube ça a l’air manuel ? Et pour Mastodon, c’est lié aux comptes qu’un utilisateur suit.
1 Like

Je confirme… pas d’apriori lors de la réflexion, mais oui une solution s’est montrée plus adaptée.

On peut aussi voir les choses autrement:

  • le meta-catalogue est un moteur de recherche global

C’est d’ailleurs la solution adoptée par peertube avec Sepia: https://search.joinpeertube.org/

Une instance peertube, n’a connaissance que des vidéo publiées sur les instances auxquelles elle est abonnée, pas l’ensemble des instances.

Pour mastodon, il n’y a pas encore d’équivalent, sauf pour les comptes utilisateurs.

Cette approche “moteur de recherche” du meta-catalogue correspond au fonctionnement des moteurs de recherche globaux par opposition aux moteurs de recherches locaux à chaque serveur web (quand il a une fonction recherche).

On retrouve ça dans le monde géo avec le GéoCatalogue ou data.gouv.fr qui moissonne les portails opendata.

Merci Christian pour cette synthèse très claire des deux solutions. A la lecture de celle ci, la solution N°1 présente des inconvénients qui semblent techniquement surmontables à moyen/long terme. A voir où héberger ce nouveau service :slight_smile:

Voici une petite capture d’un test en cours de fédération à l’aide d’un proxy se basant uniquement sur STAC :

+

=

Ce ne sera sûrement pas le moyen qui sera utilisé pour créer un méta-catalogue car les temps de réponses sont dépendants de ceux de l’ensemble des instances agrégées !