Google Cloud offre de nombreuses options pour stocker des données. Cet article en explore une : le stockage objet Google Cloud Storage (GCS).

**Mission**
Google Cloud Storage a pour vocation de conserver et de récupérer des données binaires sous forme d'entités complètes. Sur votre ordinateur, une telle entité s'appelle un fichier ; stockée dans GCS, on parle d'objet. Contrairement aux fichiers de votre ordinateur, les objets GCS sont immuables : ils ne peuvent jamais être modifiés.
Les objets GCS peuvent être supprimés ou remplacés, mais pas modifiés. Cette caractéristique peut être exploitée dans de nombreuses architectures à l'échelle du cloud.
Les objets GCS sont également opaques. GCS ne connaît pas la structure interne des objets, car il s'agit simplement de séquences de données binaires. Le service s'appuie sur des métadonnées associées pour suivre certains aspects de l'objet, comme la date et l'heure de création, le type MIME et la taille.
Les objets GCS sont durables. Google les stocke à l'aide de différentes techniques pour garantir au moins onze " 9 ", soit 99,999999999 % de durabilité annuelle dans une région donnée. (Pour se prémunir contre les pertes liées à des sinistres locaux, naturels ou d'origine humaine, l'utilisateur peut choisir de stocker ses données dans plusieurs régions, voire dans plusieurs clouds.) Onze 9, cela signifie qu'un milliard d'objets stockés pendant 100 ans n'entraîneraient au plus qu'une seule perte.
Les objets GCS sont disponibles. Cela signifie que GCS est en mesure de fournir un objet à la demande. Le service propose plusieurs options de SLA pour la disponibilité mensuelle : 99,95 %, 99,9 % ou 99,0 %. Concrètement, cela représente 22 minutes, 44 minutes ou 7 heures et 18 minutes d'indisponibilité par mois.
Les objets GCS sont stockés dans des buckets au sein d'un projet GCP. Les buckets fournissent un contexte de stockage aux objets : identité, projet hôte — auquel sont associés la sécurité et un compte de facturation —, emplacement géographique, politiques diverses, etc.
Un bucket GCS possède un identifiant unique au niveau mondial exprimé sous forme d'URI . Google utilise le schéma d'URI gs: pour les buckets et les objets GCS.
La syntaxe de l'URI est la suivante : gs://
Par exemple, gs://doit-intl-storage/logo.png est une URI unique au niveau mondial.
Rôle architectural
GCS occupe une place importante dans la conception de nombreux systèmes cloud. De manière générale, c'est l'option de stockage la moins coûteuse. En revanche, vous devrez surveiller la latence, la bande passante et les contraintes architecturales habituelles pour préserver l'efficacité économique.
N'oubliez pas que GCS est un service. On y accède via une API REST, elle-même encapsulée par des bibliothèques clientes disponibles dans de nombreux langages de programmation, une CLI et de nombreux outils tiers. GCS n'est pas un système de stockage par blocs : il ne peut pas être utilisé directement comme système de fichiers pour une machine virtuelle ou des conteneurs.
Coûts
Plusieurs facteurs pèsent sur le coût d'utilisation de Google Cloud Storage. Voici les principaux à garder à l'œil :
- La taille de l'objet
- La durée de stockage
- Les caractéristiques du bucket : emplacement, redondance et classe de stockage
- L'activité, comme l'écriture et la lecture d'un objet et de ses métadonnées
- Les octets transmis sur un ou plusieurs réseaux lors du transfert de l'objet
Les coûts s'envisagent de deux façons. D'abord, le coût de stockage d'un objet auquel on ne touche plus une fois écrit (ni lecture ni suppression) : c'est le coût de stockage pur. Ensuite, les coûts liés à l'activité : lecture, transfert, suppression, interrogation, etc.
Passons aux chiffres pour mieux cerner la situation. Pour le stockage pur, prenons l'exemple d'un objet unique de 1 Gio stocké pendant un an. (Pour mémoire, 1 Gio = 1073741824 octets (= 10243 o = 230 o).)
Le stockage standard le plus onéreux est celui du Brésil, à 0,42 $, alors qu'il peut descendre à 0,24 $ dans de nombreux autres endroits. Le stockage standard est idéal pour les objets fréquemment sollicités. Pour les objets inactifs, les coûts de la classe archive sont bien plus bas : 0,036 $ au Brésil, 0,0144 $ ailleurs.
Les coûts liés à l'activité peuvent surprendre les nouveaux utilisateurs. Des frais s'appliquent à l'écriture, à la lecture, au listage des objets et à leur suppression prématurée (lorsqu'un objet est conservé dans une classe de stockage à long terme). Ces frais peuvent peser sur l'ingénierie, voire sur l'architecture, d'un système à l'échelle du cloud.
Pour illustrer, j'ai accompagné une entreprise qui gère des images satellites. Son système on-premise stockait de nombreuses petites tuiles d'image. Une fois la migration vers GCS effectuée, l'équipe a constaté que sa conception — lire de petites tuiles pour reconstituer une grande image — entraînait des coûts extrêmement élevés à cause de l'activité de lecture.
Le système a été repensé pour stocker des images moins nombreuses mais plus volumineuses, puis les découper en mémoire après lecture. C'est très contre-intuitif, mais c'est la réalité de GCS.
Sécurité
J'aborderai le thème plus large de la sécurité dans le cloud dans un article distinct. La sécurité de GCS est gérée par IAM. Par le passé, de sérieuses fuites de données se sont produites, car il était trop facile de configurer par inadvertance un accès public à un bucket de stockage. Google a corrigé ce point et de nombreux avertissements sont désormais en place.
Pour rester en contact, suivez-nous sur le DoiT Engineering Blog , le canal LinkedIn de DoiT et le canal Twitter de DoiT . Pour découvrir nos opportunités de carrière, rendez-vous sur https://careers.doit-intl.com .