Le développeur qui conçoit une application dans le cloud public n'a que l'embarras du choix en matière de stockage. SQL, NoSQL, bases de données graphiques, bases de données orientées documents et jusqu'aux systèmes de fichiers à l'ancienne... Choisir le bon stockage est généralement une décision simple à prendre, car les bases de données et systèmes de fichiers les plus utilisés ne sont qu'à un clic dans la console.

La façon dont on aborde généralement le stockage est dictée par le monde on-premise dans lequel il fallait prendre en compte l'architecture sous-jacente et les serveurs utilisés pour les applications. Dans ce contexte, les coûts des licences poussaient bien souvent à utiliser le stockage SQL existant, en recourant à la même database pour tout conserver, depuis les données sur les produits jusqu'aux images, en passant par les vidéos.

Le cloud a boosté l’utilisation des blobs

Mais avec l'avènement du cloud public et de services tels qu'en apporte Microsoft avec Azure, par exemple, le stockage agrégé n'est plus nécessaire. Au lieu d'un espace de stockage unique et d'un seul système de fichiers pour l'ensemble du code, il est désormais possible d'utiliser des data stores optimisés spécifiques qui traitent un type de contenu et qui le font bien. Une partie de cette transition est passée par les stores NoSQL, avec des recherches clés-valeurs rapides et sans recours à des structures relationnelles complexes. Avec les services cloud, les questions de coûts conditionnent les choix technologiques tant pour les utilisateurs que pour les fournisseurs, et les structures monolithiques que l'on avait jusque-là ont été décomposées pour être livrées sous la forme de services individuels.

Il y a quelques années, lorsqu'on voulait créer un site de partage de photos, par exemple, on pouvait le faire en recourant à un système de fichiers distribué à grande échelle, en enregistrant les photos des utilisateurs dans un espace de stockage hiérarchisé combinant des disques durs et des systèmes à bande offrant un accès rapide. Ce modèle ne fonctionnerait plus maintenant. L'ampleur des systèmes actuels submergerait rapidement la structure des fichiers. Aujourd'hui, en divisant le stockage en modules remplissant chacun une tâche spécifique, on peut construire des systèmes qui peuvent rapidement passer à l'échelle parce qu'ils sont agnostiques par rapport au matériel sous-jacent. C'est là où le stockage objet ou stockage blob (Binary Large OBject) entre en jeu. Se présentant au départ comme une technique pour stocker des contenus binaires dans des bases de données relationnelles, le stockage blob standalone était intégré à la version originale d'Azure Data Services de Microsoft. Destiné à prendre en charge les toutes premières applications natives du cloud, le support blob d'Azure a été conçu pour héberger le contenu des applications mobiles et desktop. Cette version initiale s'est considérablement développée, ajoutant la prise en charge du stockage hiérarchisé et des différents types de blobs.

Un modèle de stockage hiérarchisé

Une grande partie de ce que font les développeurs avec le stockage se concentre sur les données binaires non structurées. Le stockage blob d'Azure permet de le gérer sans passer par un système de fichiers. C'est une façon simple et rapide de travailler avec les données binaires des applications, et en prime, il est également intégré aux outils analytiques d'Azure Data Lake, ce qui permet d'analyser ce que les utilisateurs ou les terminaux stockent et la façon dont le stockage est utilisé. Comme tous les services Azure, le stockage objet doit faire partie d'un groupe de ressources et être associé à un compte pour la facturation. Une fois son compte créé à partir du portail Azure ou de l'interface de ligne de commande Azure, on peut commencer à provisionner le stockage. Le cloud public de Microsoft utilise un modèle hiérarchisé pour gérer les blobs. Il faut en premier lieu disposer d'un conteneur pour les héberger. Là encore, il faut utiliser soit Azure Portal, soit l'interface en ligne de commande pour créer ce conteneur, en suivant les règles de nommage standard d'Azure. Les comptes de stockage peuvent héberger plusieurs conteneurs. On peut donc créer des conteneurs séparés pour des types de contenu distincts ou pour gérer les contenus d'utilisateurs spécifiques. Il n'y a pas de limite au nombre de conteneurs que vous pouvez avoir dans un compte, ni sur le nombre de blobs pouvant être stockés dans un conteneur.

Dès que le premier conteneur est mis en place, il est prêt à recevoir les données. On peut charger un blob à travers le portail, puis le voir et le télécharger en utilisant les mêmes outils. Trois types de blobs sont supportés : bloc, ajout et page. La plupart des applications utilisent plutôt des blobs de type bloc, qui gèrent le texte et d'autres données binaires. Les blobs ajout (append) sont une forme spécialisée de blobs blocs qui peut être étendue en écrivant plus de données dans un blob. Les objets blob de pages sont des fichiers massifs à accès aléatoire, qui peuvent monter jusqu'à 8 To. C'est ce qu'Azure utilise pour héberger ses propres fichiers VHD pour les serveurs virtuels. C'est l'option idéale pour construire ses propres systèmes de fichiers cloud (et même les utiliser comme stockage adressable par ses applications sur site).

Plusieurs outils pour importer des blobs

Stocker des données en mode objet peut s'avérer complexe si elles ne sont pas générées par des applications. Bien qu'il existe sur Azure Portal des outils pour charger du contenu blob dans le cloud, charger les fichiers un à un est, au mieux, fastidieux. Il existe d'autres moyens, notamment l'outil AzCopy (en ligne de commande) pour Linux et Windows. Ce dernier peut copier des données dans les blobs à partir de serveurs sur site, à travers des conteneurs blob dans un compte de stockage Azure, et même entre différents comptes de stockage. Si l'on utilise Linux comme plate-forme de développement, un outil comme Blobfuse permet de monter le stockage blob Azure comme un système de fichiers distant, ce qui permet de copier les données à travers un VPN. En cas de quantités importantes de données à charger, la bande passante du réseau peut constituer un facteur limitant. Au lieu d'utiliser un VPN, on peut utiliser le service Data Box d'Azure pour copier les données sur un ensemble de disques gérés. Une fois renvoyés à Microsoft, les contenus de la Data Box sont chargés dans le stockage sous forme de blobs, prêts à l'emploi. De manière similaire, le service Azure Import/Export utilise vos propres disques durs pour le transfert de données.

Microsoft propose de nombreux outils de développement utilisant Azure Blob Storage. Il existe des SDK pour les langages et frameworks les plus courants, avec des API REST pour l'accès général. On commence par s'authentifier. Une fois connecté sur Azure, on peut soit créer un nouveau conteneur, soit ajouter du contenu blob à un conteneur existant. Les API des SDK sont conçues pour être utilisées de manière asynchrone afin de gérer les latences depuis les terminaux mobiles. Il y a des limites sur les SDK. Par exemple, on ne peut récupérer que jusqu'à 5000 ID de blob à la fois. Au-dessus, il faudra donc recourir à un code de pagination pour gérer la récupération de toutes les données. Les administrateurs souhaitant monitorer l'utilisation du stockage pourront s'appuyer sur l'application Azure Storage Explorer (l'Explorateur de stockage). Celle-ci est disponible pour Windows, MacOS et Linux. Elle permettra de voir les données qui ont été chargées et de comprendre rapidement comment les comptes Azure Storage sont utilisés.

Redondance sur plusieurs régions Azure

Les applications plus complexes utilisant ce type de stockage peuvent tirer profit des fonctionnalités d'Azure telles que la redondance et la hiérarchisation. Il est possible de répartir le stockage de façon redondante sur plusieurs régions Azure, avec une grande cohérence. Il y a un coût de réplication supplémentaire qui doit être pris en compte, mais il est de l'ordre de quelques centimes par gigaoctet. L'offre de stockage hiérarchisé permet de choisir entre différentes vitesses d'accès et coûts de stockage, les options allant du stockage blob premium à haut débit jusqu'à l'archivage.

Construire ses applications avec un stockage hiérarchisé peut réduire leur coût. Un exemple : un service photo peut utiliser un stockage à accès rapide pour les vignettes d'images récentes, tandis que les vignettes plus anciennes seront conservées sur un type de stockage froid. Les images haute résolution peuvent être stockées sur un système d'archivage qui permettra de les récupérer uniquement sur demande spécifique. Lorsqu'un utilisateur fait défiler ses images, le code peut effectuer une pré-lecture des vignettes pour éviter les problèmes de latence, avec des processus en arrière-plan pour faire passer les vignettes plus anciennes d'un niveau de stockage à un autre.