Le stockage d’objets est une façon commode et abordable de stocker et de consulter des données en nuage grâce à une interface de protocole d’application (API). Les services de stockage d’objets sont conçus pour faciliter la gestion des données de toute sorte d’une manière programmable.
Qu’il s’agisse de photos ou de documents, de segments de code ou de résultats de recherche, le stockage d’objets traite toutes les données de la même façon, avec pour conséquences ce qui suit :
- rationalisation des opérations, puisque les applications interagissent toutes avec les données au moyen d’une seule API;
- économie de coûts grâce à une réduction de l’infrastructure requise pour gérer le stockage;
- hausse du rendement par la diminution du nombre de demandes présentées au serveur principal.
Pouvoir stocker les données sans avoir à les structurer – comme on devrait le faire avec une base de données ou un système de fichiers organisé en hiérarchie — gagne en popularité. Le stockage d’objets transforme les données téléversées en objets dont on emplit un « contenant ». Songez à un répertoire, composé d’objets plutôt que de fichiers. Le contenant s’accompagne de privilèges d’accès par défaut, de métadonnées robustes et d’identifiants uniques, le tout donnant accès à un jeu de données précis. Les objets sont conservés dans une infrastructure aisément accessible (capable de détecter les échecs et de rétablir les redondances), ce qui en accroît la disponibilité et la fiabilité. La plupart du temps, les services de stockage d’objets sont conçus pour garantir une « cohérence éventuelle ». En d’autres termes, bien que le service réponde sur-le-champ quand on crée, modifie ou supprime un objet, l’action en tant que telle peut survenir ultérieurement. Cet asynchronisme permet aux applications d’interagir plus rapidement avec les services de stockage, car elles n’ont pas besoin d’attendre d’avis leur signalant la synchronisation d’un événement.
Le revers de la médaille est qu’on pourrait consulter des données désuètes quand un objet ou des métadonnées ont été récemment remplacés. Les fichiers fréquemment modifiés (les bases de données, par exemple) conviennent mal à ce type d’environnement. Cependant, ceux qui se rapprochent davantage de la lecture comme les fichiers Web statiques, les données scientifiques, les copies de sauvegarde et d’autres éléments tolérant la latence, s’y prêtent à merveille.
Les services d’infonuagique publics proposent des tarifs concurrentiels de transfert et de stockage. On peut aussi recourir à de nombreuses sources ouvertes et à l’auto- hébergement pour stocker un volume important de données. Les projets comme Swift d’OpenStack réutilisent efficacement du matériel ancien pour en faire une solution de stockage d’objets stable et résiliente. Le stockage d’objets par auto-hébergement pourrait vous épargner de l’argent, surtout si vous avez du vieil équipement que l’on peut adapter; toutefois, vous devrez gérer le matériel et les logiciels, ce qui alourdira votre tâche.
Stockage de blocs et stockage d’objets
La principale différence entre le stockage d’objets et le stockage classique concerne la façon dont on accède aux données. Dans le premier cas, on fait abstraction de la couche sous-jacente du système d’exploitation (OS) et des services en autorisant l’utilisateur— ou le service — à accéder à certains éléments par l’intermédiaire d’une API de transfert d’état représentationnel (REST). Le stockage usuel, en blocs, fait appel à un système de fichiers pour autoriser la consultation et la manipulation de blocs de données. Le fait qu’on interagit directement avec le système de fichiers réduit la latence lors de la connexion, ce qui accélère la lecture et l’écriture. Cependant, le stockage de blocs n’offre pas la même accessibilité, capacité d’évolution et redondance que le stockage d’objets.
Le stockage de blocs est aussi très sensible à la latence. Beaucoup de services d’infonuagique proposent le stockage de blocs sur leur réseau (EBS – Elastic Block Store – d’Amazon, par exemple), mais il n’y a pas réplication automatique des blocs dans tous les centres de données du nuage, comme ce serait le cas avec le stockage d’objets. En effet, le stockage de blocs perd notablement en performance dès qu’on tente d’accéder aux données hors du centre où elles sont conservées dans le nuage. On doit cette détérioration à la forte cohérence qu’exige le stockage de blocs (au lieu d’une cohérence éventuelle), ce qui signifie que les modifications ne sont reconnues que lorsque tous les sites de stockage ont effectivement enregistré les données.
Pour soutenir les applications plus anciennes, le système de fichiers sera doté d’une passerelle qui donnera accès à un service de stockage d’objets. Cette passerelle fait en sorte que l’application n’a pas besoin d’une API REST pour stocker les objets, mais pareille solution suppose souvent une perte au niveau de la performance.
Le stockage d’objets convient le mieux dans certaines situations et pour remédier à des problèmes particuliers comme nous l’illustrons avec les exemples que voici.
Utilisations
Archivage et sauvegarde des données
Les petites comme les grandes entreprises recourent au stockage d’objets pour économiser les coûts associés à la sauvegarde et à l’archivage externes des données.
Avec sa redondance intégrée, le stockage d’objets atténue les risques de perte de données à la suite d’une défaillance du matériel ou d’une panne quelconque.
Pouvoir télécharger des objets grâce à un hyperlien accélère et facilite aussi la récupération des données. Enfin, les API permettent d’automatiser aisément le téléversement et la gestion des données.
Récupérer les données enregistrées sur une bande magnétique ou dans un système de stockage à long terme comme Glacier d’Amazon ou Azure Archive s’avère parfois aussi difficile qu’onéreux. À moins d’être sûr que les données peuvent rester archivées des mois ou des années, le stockage d’objets constitue un objectif valable. Certains services d’infonuagique publics proposent l’archivage automatique des objets inactifs ou plus anciens. Ainsi, on pourrait établir que les objets qui n’ont pas été consultés depuis au moins trois mois soient archivés dans un service de stockage moins coûteux. Une telle séparation automatique du stockage pourrait devenir une manière efficace de gérer intelligemment les données que l’on consulte plus ou moins fréquemment.
Contenu Web
Le stockage d’objets est excellent pour soulager le serveur principal des éléments Web les plus volumineux ou les plus incongrus. Chaque objet se voit attribuer un URL unique conduisant directement à lui. Quand on affecte les bonnes autorisations d’accès à l’objet, n’importe qui pourra le consulter sur Internet, comme s’il figurait toujours sur le serveur.
Les éléments gardés dans le stockage d’objets n’alourdiront pas le site et se chargeront parallèlement au reste du contenu, ce qui abrègera souvent le temps de chargement et réduira le coût de la largeur de bande.
Certains éléments conviennent mieux que d’autres au stockage d’objets. Les vidéos, les PDF de grande taille ou plus populaires et les applications téléchargeables en sont des exemples. L’entreprise qui propose un service de stockage d’objets pourrait offrir la géo-redondance, sorte de réseau de diffusion de contenu (CDN) rudimentaire qui rapproche les fichiers du public visé. À partir des métadonnées de l’objet, il est également possible de créer un URL auquel n’auront accès que les utilisateurs autorisés, ou qui ne sera accessible que pendant un certain temps. Ceux qui fournissent des services de stockage d’objets n’optimisent cependant pas tous la mise en antémémoire et il arrive qu’ils ne proposent pas toutes les fonctionnalités d’un vrai CDN. L’utilité d’un tel service dépendra des capacités de votre plateforme.
Le stockage d’objets se prête idéalement aux éléments Web qui consomment trop de largeur de bande, occupent trop d’espace disque ou poussent la connexion à ses limites, en raison de la configuration existante du site.
Utilisation des métadonnées
Un autre avantage du stockage d’objets a trait aux métadonnées. Les systèmes de fichiers classiques et le stockage d’objets ne fournissent pas d’informations sur le fichier proprement dit, hormis son nom et celui du dossier qui le contient. Le nom du fichier (qui n’est pas forcément unique) se situe dans une arborescence de dossiers et peut être descriptif ou pas. Pareille organisation est loin d’être idéale, surtout quand les fichiers sont nombreux et ne sont pas structurés. Des dossiers organisés selon la date, le titre des projets ou des appellations subjectives engendreront vite une hiérarchie trop compliquée. De plus, le nombre maximal de caractères qu’autorise le système de fichiers entrave largement l’usage de données contextuelles, si bien qu’on pourrait avoir besoin d’une base de données distincte ou d’une solution pour les métadonnées.
Chaque objet reçoit un identifiant universel unique (UUID). D’autres services recourent alors aux métadonnées pour traiter, manipuler et exploiter autrement ces objets.
Plus les métadonnées sont riches, plus elles faciliteront l’automatisation et conféreront de la clarté à l’objet sur lequel on travaille. Ensuite, la lecture d’un script de travail permettra certaines manipulations à partir des métadonnées associées à l’objet.
Voici comment on pourrait se servir des métadonnées. Imaginez un outil qui extrait les images de Twitter en vue de les classer. L’outil découvre une illustration, la téléverse dans le stockage d’objets puis l’étiquette avec des métadonnées et marque l’image pour signaler qu’elle n’a pas encore été classée. Un second processus prend la relève en cherchant les objets « non classés » pour les traiter. On pourrait y arriver avec des applications comme TensorFlow ou d’autres processus d’analyse. Après inspection, le script retranche l’étiquette « non classé » dans les métadonnées de l’objet et la remplace par les résultats de la recherche. L’application principale pourra alors explorer l’objet traité et chercher les métadonnées pertinentes, selon la tâche à accomplir.
Lac de données
Par « lac de données » en entend un référentiel dans lequel les organisations et, parfois, de simples utilisateurs versent les données brutes de diverses sources. Son principal avantage est que les fichiers sont tous regroupés et peuvent être reliés entre eux. Les données structurées (celles exportées des rangées ou des colonnes d’une base de données, par exemple), semi-structurées (valeurs CSV, journaux, XML, JSON, YML, etc.) et non structurées/binaires (documents, courriels, images, fichiers audio/vidéo, applications) peuvent ensuite être organisées à partir des métadonnées. Idéalement, des processus automatisés vérifieront les données et prendront diverses mesures.
L’analyse et d’autres opérations maintiendront les données organisées et en garantiront la pertinence.
L’expression « lac de données » fait pendant au concept du « magasin de données », qui désigne un dépôt plus modeste d’informations organisées, issues des données brutes. On n’y retrouve pas de données brutes, mais des résultats structurés ou épurés en fonction des opérations. Le hic, avec cette approche, est qu’elle a tendance à cloisonner l’information en amas. Une telle séparation peut rendre l’évaluation croisée avec d’autres jeux de données, cloisonnés eux aussi, plus difficile. Un autre inconvénient du magasin de données, comparativement au lac de données, est qu’il ne conserve pas toujours les données brutes. Une fois traitées, celles-ci sont supprimées, ce qui ne laisse que l’interprétation des données originales. Il serait donc difficile, voire impossible de remonter jusqu’aux données brutes si une erreur survenait ou si on ajoutait de nouveaux filtres. Les données corrompues pourraient engendrer des lacunes qu’on aurait pu éviter si les données brutes avaient été préservées.
En conservant les données d’origine et en en permettant une meilleure analyse croisée, le lac de données élimine les problèmes inhérents du magasin de données. Toutefois, bien qu’intéressant, le lac de données soulève certains risques. En effet, sans une gestion et les métadonnées appropriées, notre lac pourrait se transformer en « marécage ». C’est que les lacs de données incitent les organisations à tout stocker pour l’éternité dans l’éventualité où la moindre information s’avérera utile à un moment quelconque. Or, si ces données ne sont pas gérées, il sera peut-être impossible de les retrouver quand on en aura besoin. On met souvent en place un lac de données sans le planifier, en présumant qu’il s’agit d’un moyen magique pour analyser l’information. À l’instar de n’importe quel autre outil, le lac de données est formidable quand on s’en sert correctement. Sinon, il devient une perte de temps et d’argent, détruit des actifs et, de manière générale, sème désordre et chaos.
Sécurité du stockage d’objets et de blocs
Selon l’usage auquel il est destiné, le stockage de blocs et d’objets peut s’accompagner d’une approche différente en matière de sécurité. De manière générale, la protection des données se divise comme suit : comment sécuriser le stockage et comment sécuriser l’accès aux données. L’encryptage et les listes de contrôle d’accès (ACL) protègent à la fois les objets et les blocs stockés, mais leur mise en œuvre diverge.
Dans le nuage, on peut considérer le stockage de blocs comme une unité de disque physique annexée à l’instance. On protège le disque entier en autorisant la connexion ou pas. Il peut aussi y avoir encryptage, qu’il soit automatique, quand il est appliqué par le service d’infonuagique, ou que l’utilisateur en gère directement l’application. Le système de fichiers applique les restrictions supplémentaires du système d’exploitation local aux fichiers et aux dossiers. Des services systémiques comme Apache ou Samba gèrent l’accès aux sites Web et aux autres systèmes que le système de fichiers.
La sécurisation du stockage d’objets est tout autre. Les contenants et les objets qu’ils renferment peuvent être publics ou privés. Publics, n’importe qui y accédera grâce à l’hyperlien; privés, l’accès aux données nécessitera d’abord l’authentification de l’utilisateur et une autorisation. D’autre part, sur certaines plateformes de stockage, la permission applicable à l’objet l’emporte sur celle applicable au contenant grâce à une ACL, aux politiques particulières aux contenants ou les deux. Impossible de téléverser quelque chose dans un contenant sans que demande d’une API authentifiée. Beaucoup de fournisseurs vous permettront d’autoriser l’accès à divers comptes sur la même plateforme. Chaque objet peut être chiffré avant téléversement, mais beaucoup de services d’infonuagique proposent l’encryptage automatique des objets et des contenants au niveau du serveur.
Assorti d’un modèle de sécurité simple mais adaptable, le stockage d’objets est un choix intéressant pour maintes applications. Par défaut, vous serez le seul à pouvoir accéder à vos objets (après avoir présenté vos justificatifs d’identité). L’addition d’une ACL vous permettra de gérer les activités de lecture et d’écriture des autres utilisateurs au niveau du contenant.
Conclusion
Les particuliers comme les organisations cherchent comment réduire leurs frais, rationaliser leurs opérations et élargir l’exploitation de leurs données. Dans certains cas, le stockage d’objets offre des avantages appréciables qu’on ne retrouve pas dans le stockage de blocs. Une API de première catégorie, adaptée à l’infonuagique, fera du transfert des données dans le nuage un processus uniforme, prêt à être automatisé. Les métadonnées et un identifiant unique enrichiront le contexte de ces données, qu’on pourra récupérer grâce à l’URL d’un site Web qui y autorisera un accès rapide et configurable.
La diffusion publique d’objets pourrait aussi alléger la charge que supporte l’infrastructure existante. Enfin, le stockage d’objets accroît la souplesse sur le plan de la sécurité en associant aux contenants une autorisation globale qui peut être surmontée par une permission accordée à chaque objet.
Outre les économies directes que cela suppose, traiter les fichiers comme des objets est une façon générale, donc indépendante du type de nuage, d’uniformiser le stockage des données entre les nombreux services d’infonuagique et de faciliter l’accès à l’information. Le stockage d’objets ouvre de nouvelle voies pour la collecte, la gestion et l’analyse des données.