Réplication des documents

Comme dit précédemment, la réplication et la synchronisation des données en pair à pair est un vaste sujet qui a fait l‘objet d‘importants travaux depuis de nombreuses années. Le

68 https://github.com/cozy/cozy-doctypes 69 https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html 70 https://cozy.github.io/cozy-stack/permissions.html

138 challenge ici n‘est pas académique, mais bien industriel ; la plupart des protocoles de synchronisation actuels étant centralisés et fermés.

Le protocole de réplication CouchDB [CouchDB Replication Protocol 2017] possède les avantages d‘être libre, décentralisé, documenté et robuste. De plus, son intégration native dans Cozy le pose comme un candidat particulièrement crédible pour la réplication des données entre serveurs Cozy. De fait, la première implémentation du partage en Node.js l‘utilise. Cela garantit des performances et une fiabilité générale grâce à la reprise sur panne de la synchronisation, de la gestion de l‘historique des versions, etc.

Cependant, la dernière version de Cozy faite en Go n‘utilise pas cette réplication dans sa première implémentation. En effet, suite à des tests de montée en charge, il est apparu que la consommation mémoire de CouchDB augmentait considérablement en fonction du nombre de partages et de documents, comme montré en Figure 23. Ce comportement n‘est néanmoins pas totalement déterministe et difficile à appréhender sans rentrer dans les

détails d‘implémentation de CouchDB, codé en Erlang71. Conjugué au fait que

l‘implémentation du protocole de réplication n‘est pas une tâche triviale, cela rendait la livraison du partage incertaine au vu des délais et contraintes de Cozy Cloud.

Figure 23. Consommation de RAM en fonction du nombre de partages et documents

Le choix a donc été fait de se passer de la réplication CouchDB dans un premier temps, sans que cela ne soit définitif. Il est notamment envisagé d‘utiliser la réplication CouchDB pour les utilisateurs auto-hébergés, c'est-à-dire qui ont installé Cozy sur leurs propres 71 https://www.erlang.org/ 0 50 100 150 200 250 300 350 0 20 40 60 80 100 RAM (Mo) Nombre de partages

10 docs par partage

0 100 200 300 400 500 600 700 800 900 0 200 400 600 800 1000 RAM (Mo)

Nombre de documents par partage

139 machines. Dans ce cas de figure, les contraintes d‘utilisation mémoire sont généralement moins fortes que dans une architecture mutualisée, tandis que le besoin de résilience l‘est d‘autant plus, la stabilité du réseau étant moins garantie que sur des infrastructures spécialisées. De plus, les dernières versions de CouchDB laissent entrevoir un impact mémoire moindre grâce à une mutualisation des processus de réplication.

A la place, nous avons implémenté un système de réplication et de synchronisation qui combine des appels HTTP et un système de triggers, dont la documentation est accessible en ligne⁷², pour répliquer les documents et maintenir le partage à jour dans les partages

master-*. Chaque document créé, mis à jour ou supprimé est évalué afin de déterminer s‘il rentre dans un partage, suivant le principe de l‘évaluation des Filters de SWYSWYK. S‘il est correctement évalué, un processus appelé worker est déclenché par le trigger, qui propage la modification chez les pairs. Afin de s‘assurer que seules les nouvelles modifications sont propagées, un système de gestion de versions simple a été implémenté : avant chaque propagation, le worker compare les hash des documents pour s‘assurer qu‘il y a bien des différences. Outre le fait que cela évite des communications réseaux inutiles, cette vérification évite de se retrouver dans un phénomène de boucle infinie pour un partage

master-master : si le document partagé D1 est modifié chez Alice, il rentre dans un trigger, et est propagé chez Bob. Or, cela serait considéré chez lui comme une nouvelle mise à jour, et un worker chercherait de nouveau à le propager chez Alice qui irait le re-propager, etc.

Enfin, dans le cas où Alice et Bob feraient chacun des mises à jours simultanées sur le même document chacun de leur côté, cela crée un conflit : il est impossible de savoir quelle version est la plus récente et une fusion automatique n‘est pas toujours possible. Dans ce cas, une nouvelle version du document est créée, avec le tag conflict dans son nom ainsi que la date et l‘heure de la mise à jour qui a provoqué le conflit. A charge d‘Alice et Bob de fusionner manuellement les documents en conflits.

Ce système est une part importante de l‘implémentation du partage dans Cozy, dont le code est accessible en ligne⁷³, mais de nombreux points restent perfectibles. Par exemple, les

72

https://cozy.github.io/cozy-stack/jobs.html

73

140 mises à jour devant être propagées pourraient être regroupées dans une mémoire tampon si elles sont très fréquentes, pour optimiser les coûts réseaux. Ces écritures pourraient aussi être persistées dans un document de la base de données, afin de pouvoir assurer une reprise sur panne en cas de défaillance. De plus, le processus de synchronisation est asynchrone et pourrait être exécuté en isolation du reste de la stack, comme c‘est déjà le cas pour certaines tâches. Par exemple les connecteurs, en charge de se connecter à des sites externes pour importer les données de l‘utilisateur (factures, historique bancaire, données IoT, etc) sont isolés via nsjail⁷⁴. Cela peut être vu comme une implémentation logicielle de l‘environnement isolé de SWYSWYK. Enfin, comme dit précédemment, tous les échanges se font via des requêtes HTTP protégées par TLS. Cela ne protège cependant pas les métadonnées du partage (on sait qu‘Alice communique avec Bob et à quelle fréquence, mais sans connaître le contenu). Ce problème pourrait être évité en explorant des solutions utilisant TOR⁷⁵ où les destinataires et émetteurs des requêtes sont anonymisés, au risque d‘une dégradation des performances.

Ainsi, à l‘heure où ces lignes sont écrites, des efforts d‘implémentations et des tests sont toujours en cours pour garantir la fiabilité et la robustesse du protocole.