Bonnes pratiques relatives à Cloud Storage

Cette page contient un index des bonnes pratiques relatives à Cloud Storage. Les informations collectées ici vous offrent un aperçu rapide des éléments à prendre en compte lors de la création d'une application utilisant Cloud Storage.

Si vous débutez avec Cloud Storage, cette page ne constitue peut-être pas le meilleur point de départ, car elle ne vous apprend pas les bases de l'utilisation de Cloud Storage. Pour vous familiariser avec Cloud Storage, nous vous suggérons de commencer par les pages Découvrir le stockage d'objets avec la console Google Cloud ou Découvrir le stockage d'objets avec l'outil gcloud.

Dénomination

Consultez les pages Dénomination des buckets et Dénomination des objets pour en savoir plus sur les exigences et les considérations à prendre en compte pour les noms.

Trafic

Effectuez une estimation approximative de la quantité de trafic qui sera envoyé à Cloud Storage. Plus précisément, prenez en compte les éléments suivants :
- Les opérations par seconde. Combien d'opérations par seconde prévoyez-vous, à la fois pour les buckets et pour les objets, ainsi que pour les opérations de création, de mise à jour et de suppression ?
- La bande passante. Quel volume de données sera envoyé, et sur quelle période ? Pensez à utiliser un outil tel que Wolfram Alpha pour éviter les erreurs de calcul.
- Le contrôle du cache. La spécification des métadonnées Cache-Control sur les objets accessibles au public sera bénéfique pour la latence de lecture des objets actifs ou fréquemment consultés. Pour savoir comment configurer des métadonnées d'objets comme Cache-Control, consultez la page Afficher et modifier des métadonnées.
Concevez votre application de sorte à réduire le plus possible les pics de trafic. Si des clients de votre application effectuent des mises à jour, répartissez-les tout au long de la journée.
Lorsque vous concevez des applications pour des taux de requêtes élevés, tenez compte des limites de débit pour certaines opérations. Vous devez connaître les limites de bande passante pour certains types de sortie, et suivre les consignes concernant les taux de requêtes et la distribution des accès. Tenez particulièrement compte de l'autoscaling et de la nécessité d'augmenter progressivement les taux de requêtes afin d'optimiser les performances.
Lors du traitement des erreurs :
- Assurez-vous que votre application utilise une stratégie de nouvelle tentative afin d'éviter les problèmes dus à des pics importants de trafic.
- réessayez avec une nouvelle connexion, en tentant éventuellement de résoudre de nouveau le nom de domaine. Votre nouvelle tentative emprunte ainsi un chemin d'accès différent pour éviter de rencontrer le même composant défectueux que la requête initiale.
Si votre application est sensible au temps de latence, utilisez des requêtes couvertes (requêtes doublées). Les requêtes couvertes vous permettent d'effectuer de nouvelles tentatives plus rapidement et de réduire la latence de queue. Notez également qu'avec cette approche, le délai d'expiration des requêtes est préservé (sa réduction pourrait entraîner l'expiration prématurée des requêtes). Pour en savoir plus, consultez l'article The Tail at Scale (en anglais).
Déterminez le niveau de performances que vos clients attendent de votre application. Cela vous aide à choisir une option de stockage et une région lors de la création de buckets. Par exemple, envisagez de colocaliser vos ressources de calcul avec vos buckets Cloud Storage pour les applications d'analyse.

Emplacements et options de stockage de données

Pour savoir comment stocker au mieux vos données, consultez les pages Classe de stockage et Emplacement du bucket.

LCA et contrôle des accès

Les requêtes Cloud Storage désignent les buckets et les objets par leur nom. Par conséquent, même si les LCA empêchent les tiers non autorisés d'effectuer des opérations sur des buckets ou des objets, un tiers peut tenter d'envoyer des requêtes comportant des noms de buckets ou d'objets, et déterminer leur existence en observant les réponses d'erreur. Il est alors possible que des informations contenues dans des noms de buckets ou d'objets soient divulguées. Si la confidentialité de vos noms de buckets ou d'objets vous préoccupe, vous devez prendre les précautions appropriées, par exemple :
- Choisissez des noms de buckets et d'objets difficiles à deviner. Par exemple, le nom de bucket mybucket-gtbytul3 est suffisamment aléatoire pour que des tiers non autorisés ne puissent pas le deviner ni en déduire d'autres noms.
- Évitez d'indiquer des informations sensibles dans les noms de buckets ou d'objets. Par exemple, au lieu de nommer votre bucket mysecretproject-prodbucket, appelez-le somemeaninglesscodename-prod. Dans certaines applications, vous pouvez conserver des métadonnées sensibles dans des en-têtes Cloud Storage personnalisés tels que x-goog-meta, plutôt que de les encoder dans des noms d'objets.
L'utilisation de groupes est préférable à la liste explicite d'un grand nombre d'utilisateurs. Non seulement leur scaling est meilleur, mais ils constituent également un moyen très efficace pour mettre à jour le contrôle des accès pour un grand nombre d'objets simultanément. Enfin, le coût est plus avantageux, car vous n'avez pas besoin d'émettre une requête par objet pour modifier les LCA.
Passez en revue et suivez les bonnes pratiques de contrôle des accès.
Le système de contrôle des accès de Cloud Storage permet de spécifier que les objets sont lisibles publiquement. Assurez-vous que tous les objets que vous écrivez avec cette autorisation sont publics. Une fois "publiées", les données sur Internet peuvent être copiées à de nombreux endroits. Il est donc impossible de reprendre le contrôle en lecture d'un objet écrit avec cette autorisation.
Le système de contrôle des accès de Cloud Storage permet de spécifier que les buckets sont publiquement accessibles en écriture. Bien qu'il puisse être pratique de configurer un bucket de cette manière pour diverses raisons, nous vous déconseillons d'utiliser cette autorisation. Elle peut être employée de manière abusive pour diffuser des contenus illégaux, des virus et d'autres logiciels malveillants. Le propriétaire du bucket est juridiquement et financièrement responsable du contenu stocké dans son bucket.

Si vous devez mettre du contenu à la disposition d'utilisateurs de manière sécurisée, et que ceux-ci ne possèdent pas de compte utilisateur, nous vous recommandons d'utiliser des URL signées. Ces dernières vous permettent par exemple de fournir un lien vers un objet. Les clients de votre application n'ont pas besoin de s'authentifier auprès de Cloud Storage pour accéder à l'objet. Lorsque vous créez une URL signée, vous contrôlez le type d'accès (lecture, écriture, suppression) et sa durée.

Importations de données

Si vous utilisez des rappels XMLHttpRequest (XHR) pour obtenir des informations sur la progression, évitez de fermer et de rouvrir la connexion si vous détectez que la progression a cessé. Cela crée une mauvaise boucle de rétroaction positive pendant les périodes de congestion du réseau. Lorsque le réseau est encombré, les rappels XHR peuvent être mis en attente derrière l'activité d'acquittement (ACK/NACK) du flux d'importation. Le cas échéant, la fermeture et la réouverture de la connexion entraînent une utilisation plus importante de la capacité du réseau, précisément au moment où vous pouvez le moins vous le permettre.
Pour le trafic d'importation, nous vous recommandons de définir des délais avant expiration raisonnablement longs. Pour garantir une bonne expérience aux utilisateurs finaux, vous pouvez définir un minuteur côté client qui met à jour la fenêtre d'état du client avec un message (par exemple, "encombrement du réseau") lorsque votre application n'a pas reçu de rappel XHR depuis longtemps. Lorsque cela se produit, ne vous contentez pas de fermer la connexion et effectuez une nouvelle tentative.
La compression gzip est un moyen pratique et facile de réduire la bande passante requise pour chaque requête. Même si la décompression des résultats nécessite un temps CPU supplémentaire, la compression est généralement très avantageuse en termes de coûts de réseau.

Un objet importé au format gzip peut généralement être diffusé au format gzip également. Toutefois, évitez d'importer des contenus ayant à la fois content-encoding: gzip et un content-type compressé, car cela pourrait entraîner un comportement inattendu.
Nous vous recommandons d'utiliser des importations avec reprise, qui vous permettent de reprendre le transfert de données même lorsqu'un échec de communication a interrompu le flux de données. Vous pouvez également utiliser les importations en plusieurs parties de l'API XML pour importer des parties d'un fichier en parallèle, ce qui peut potentiellement réduire le temps nécessaire à l'importation globale.

Suppression de données

Consultez la page Supprimer des objets pour obtenir des instructions et des considérations sur la suppression de données. Vous pouvez également utiliser des fonctionnalités de contrôle du cycle de vie des données pour éviter que vos données ne soient supprimés par erreur par votre logiciel d'application ou des utilisateurs.