Bonnes pratiques pour les charges de travail multimédias

Cette page décrit les bonnes pratiques à suivre lorsque vous utilisez Cloud Storage pour des charges de travail multimédias. Ces charges de travail incluent souvent divers Google Cloud produits tels que Media CDN, l'API Live Stream, l'API Transcoder et l'API Video Stitcher.

Présentation

Google Cloud propose des solutions pour optimiser les types de charges de travail multimédias suivants :

  • Production multimédia : inclut des charges de travail telles que la post-production de films, y compris le montage vidéo, qui nécessitent beaucoup de calcul et utilisent souvent des GPU pour le calcul hautes performances. Souvent, les données multimédias résidant dans Cloud Storage sont traitées par des applications exécutées dans Compute Engine ou Google Kubernetes Engine, et le résultat de ce processus est réécrit dans Cloud Storage. Ces charges de travail nécessitent une mise à l'échelle du débit de lecture et d'écriture agrégé de Cloud Storage vers un cluster de calcul avec un temps d'inactivité du GPU plus faible. Elles nécessitent également de faibles latences de lecture et d'écriture, car cela est essentiel pour réduire la latence de queue.
  • Gestion des éléments multimédias : inclut l'organisation de vos éléments multimédias pour un stockage, une récupération et une utilisation efficaces.
  • Diffusion et distribution de contenu : inclut la diffusion de contenus multimédias aux utilisateurs, y compris les services de vidéo à la demande (VOD) et de streaming en direct. Lors de la VOD, lorsque les utilisateurs demandent du contenu qui n'est pas mis en cache sur le réseau de diffusion de contenu (CDN), le contenu est récupéré à partir des buckets Cloud Storage. Pour les requêtes de streaming en direct, le contenu est écrit dans le bucket Storage et lu simultanément à partir du CDN.

Bonnes pratiques pour les charges de travail multimédias

Pour connaître les bonnes pratiques qui s'appliquent aux charges de travail multimédias, consultez les sections suivantes.

Transfert de données

Utilisez le service de transfert de stockage pour importer plus de 1 Tio de fichiers multimédias bruts à partir d'une source sur site, telle qu'une caméra vidéo ou un espace de stockage sur site, vers Cloud Storage. Le service de transfert de stockage permet de déplacer des données de manière transparente entre les systèmes de stockage d'objets et de fichiers. Pour les transferts plus petits, choisissez le service permettant de transférer des données vers et depuis Cloud Storage ou entre des systèmes de fichiers en fonction de votre scénario de transfert.

Emplacement du bucket

Pour les charges de travail qui nécessitent des ressources de calcul, telles que la production multimédia, vous devez créer des buckets dans la même région ou dans les mêmes zones birégionales que les ressources de calcul. Cette méthode permet d'optimiser les performances en réduisant les latences de lecture et d' écriture pour vos charges de travail de traitement, les coûts et la bande passante. Pour obtenir des conseils supplémentaires sur le choix de l'emplacement du bucket, consultez Éléments à prendre en compte pour l'emplacement du bucket.

Classe de stockage

Selon le type de charge de travail multimédia, la classe de stockage que vous devez sélectionner diffère. Les types de classes de stockage recommandés pour différentes charges de travail multimédias sont les suivants :

  • Pour la gestion des éléments multimédias, tels que les vidéos d'archive, la classe de stockage par défaut d'un bucket doit être stockage Archive. Vous pouvez spécifier une autre classe de stockage pour les objets qui ont des besoins différents en termes de disponibilité ou d'accès.
  • Pour les charges de travail de production multimédia et de diffusion de contenu, étant donné que les données sont lues fréquemment à partir d'un bucket Cloud Storage, vous devez les stocker dans le stockage standard.

Pour obtenir des conseils supplémentaires sur le choix de la classe de stockage pour votre bucket, consultez Classe de stockage.

Gestion du cycle de vie des données

Pour gérer vos éléments multimédias, vous devez gérer le cycle de vie des objets de vos buckets en définissant une configuration de cycle de vie. Grâce à la fonctionnalité de gestion du cycle de vie des objets, vous pouvez gérer le cycle de vie des données, y compris définir une valeur TTL (Time To Live) pour les objets, conserver les versions obsolètes des objets et rétrograder les classes de stockage des objets pour vous aider à gérer les coûts.

Lorsque les modèles d'accès aux données sont prévisibles, vous pouvez définir la configuration du cycle de vie d'un bucket. Pour les modèles d'accès inconnus ou imprévisibles à vos données, vous pouvez définir la fonctionnalité Autoclass pour votre bucket. Avec Autoclass, Cloud Storage déplace automatiquement les données qui ne sont pas consultées fréquemment vers des classes de stockage plus froides.

Bonnes pratiques pour les charges de travail de diffusion et de distribution de contenu

Pour les charges de travail de VOD et de streaming en direct, l'objectif est d'éviter toute erreur de lecture, tout délai de démarrage de la lecture ou toute mise en mémoire tampon lors de la lecture d'une vidéo sur le lecteur vidéo des utilisateurs finaux. Ces charges de travail nécessitent également une mise à l'échelle des lectures pour tenir compte d'un grand nombre de spectateurs simultanés. Dans tous les cas, les lectures du trafic client doivent passer par un CDN.

Pour connaître les bonnes pratiques qui s'appliquent aux charges de travail de diffusion et de distribution de contenu, consultez les sections suivantes.

Utiliser efficacement le CDN

L'utilisation d'un réseau de diffusion de contenu (CDN) devant le bucket Cloud Storage améliore l'expérience de l'utilisateur final, car le CDN met en cache le contenu en réduisant la latence et en augmentant l'efficacité de la bande passante. Un CDN vous permet de réduire le coût total de possession en diminuant les coûts de bande passante, en optimisant l'utilisation des ressources et en améliorant les performances. L'utilisation de Media CDN permet de réduire le coût total de possession pour la diffusion de contenu aux utilisateurs finaux, car le coût de remplissage du cache pour Media CDN est nul. Vous pouvez utiliser Media CDN comme source d'autres CDN tiers. Avec d'autres CDN, vous bénéficiez toujours d'une certaine réduction du coût total de possession lorsque vous diffusez du contenu à partir de ce cache Media CDN au lieu de l'origine.

Si vous utilisez un CDN tiers, CDN Interconnect permet à certains fournisseurs d'établir des liaisons d'appairage direct avec le réseau périphérique de Google dans différents emplacements. Le trafic réseau sortant de Google Cloud qui transite par l'une de ces liaisons bénéficie de la connectivité directe aux fournisseurs CDN agréés et est facturé automatiquement à un tarif réduit. Pour obtenir la liste des fournisseurs approuvés, consultez Fournisseurs de services approuvés par Google.

La liste suivante présente les options à configurer lors de la configuration d'un CDN :

Sélectionner l'emplacement du bouclier d'origine

L'emplacement du bouclier d'origine est un cache entre le CDN et Cloud Storage. Si votre CDN vous permet de sélectionner l'emplacement du bouclier d'origine, suivez les consignes du CDN pour savoir s'il est recommandé de choisir le bouclier d'origine plus près de la région de votre bucket Cloud Storage ou de l'emplacement de concentration du trafic de vos utilisateurs finaux. Un bouclier d'origine est une mesure de protection qui protège votre serveur d'origine contre la surcharge. Les CDN avec bouclier d'origine contribuent à augmenter le déchargement de l'origine en ajoutant un cache supplémentaire entre l'origine et le CDN. Par exemple, Media CDN offre une infrastructure périphérique élevée à plusieurs niveaux conçue pour minimiser activement le remplissage de cache dans la mesure du possible.

Activer la réduction des requêtes

Assurez-vous que la réduction des requêtes est activée pour votre CDN. La réduction de plusieurs requêtes en une seule réduit le coût de l'opération de classe B de Cloud Storage. Les CDN disposent de caches distribués déployés dans le monde entier, mais offrent un moyen de réduire plusieurs requêtes d'utilisateur final en une seule requête à l'origine. Par exemple, Media CDN réduit activement plusieurs requêtes de remplissage de cache pilotées par l'utilisateur pour la même clé de cache en une seule requête d'origine par nœud périphérique, ce qui réduit le nombre de requêtes adressées aux buckets.

Configurer le comportement des nouvelles tentatives sur le CDN

Assurez-vous de configurer les nouvelles tentatives pour tout problème de serveur avec le code de réponse HTTP 5xx (502, 503, 504) sur votre CDN. Les CDN acceptent les nouvelles tentatives pour les requêtes d'origine, ce qui permet de relancer les requêtes d'origine infructueuses. La plupart des CDN vous permettent de spécifier le nombre de nouvelles tentatives pour l'origine actuelle. Pour en savoir plus sur les nouvelles tentatives pour les requêtes d'origine dans Media CDN, consultez Nouvelles tentatives pour les requêtes d'origine.

Options de localisation pour la distribution de contenu

Pour les charges de travail qui lisent des données à partir de Cloud Storage qui ne sont pas mises en cache sur le CDN, telles que la diffusion et la distribution de contenu de type VOD, tenez compte des facteurs suivants lorsque vous sélectionnez un emplacement pour votre bucket :

  • Pour optimiser les coûts, les buckets créés dans une seule région ont le coût de stockage le plus bas.
  • Pour optimiser la disponibilité, tenez compte des éléments suivants :
    • Pour la plupart des charges de travail multimédias, il est recommandé d'utiliser des buckets birégionaux, car ils répliquent vos objets dans deux régions pour une meilleure disponibilité.
    • Pour les cas d'utilisation qui nécessitent la diffusion de contenu et l'analyse avec géo-redondance, utilisez des buckets dans plusieurs régions pour une disponibilité maximale.
  • Pour optimiser la latence et réduire les coûts réseau, tenez compte des éléments suivants :
    • Pour la VOD, choisissez les régions les plus proches de l'endroit où se trouve la plupart de vos utilisateurs finaux ou la région où la concentration de trafic est la plus élevée.
    • Lors du streaming en direct, les buckets reçoivent des requêtes d'écriture de transcodeurs et des requêtes de lecture d'un CDN qui met en cache et distribue le contenu aux utilisateurs finaux. Pour améliorer les performances de streaming, choisissez des buckets régionaux qui sont colocalisés avec les ressources de calcul utilisées pour le transcodage.

Optimiser la longueur des segments vidéo pour les diffusions en direct

Pour les diffusions en direct, la taille de segment minimale recommandée est de deux secondes, car les segments vidéo courts sont plus sensibles aux latences d'écriture de longue traîne. Les latences d'écriture de longue traîne font référence aux opérations d'écriture lentes ou retardées pour le contenu auquel on accède rarement ou qui a un faible volume de requêtes.

La distance physique entre l'emplacement du bucket et l'emplacement de lecture des utilisateurs finaux affecte le temps de transmission. Si vos utilisateurs finaux sont éloignés de l'emplacement du bucket, nous vous recommandons d'avoir une taille de segment vidéo plus longue.

Pour offrir aux spectateurs la meilleure expérience possible, il est recommandé d' utiliser la stratégie de nouvelles tentatives et la couverture des requêtes pour les écritures sur les transcodeurs afin d'atténuer les latences de longue traîne de plus de deux secondes pour les écritures dans Cloud Storage et d'expérimenter des temps de mise en mémoire tampon plus longs d'environ dix secondes.

Augmenter progressivement le RPS

Les buckets Cloud Storage ont une capacité d'E/S initiale de 1 000 écritures d'objets par seconde et de 5 000 lectures d'objets par seconde. Pour les charges de travail de streaming en direct, la consigne est de mettre à l'échelle vos requêtes progressivement en commençant par 1 000 écritures par seconde et 5 000 lectures par seconde, et en doublant progressivement le taux de demandes toutes les 20 minutes. Cette méthode permet à Cloud Storage de redistribuer la charge sur plusieurs serveurs et d'améliorer la disponibilité et la latence de votre bucket en réduisant les risques de problèmes de lecture.

Pour un événement de streaming en direct avec RPS plus élevé, vous devez implémenter la mise à l'échelle sur votre bucket en le préchauffant ou en activant l'espace de noms hiérarchique sur votre bucket. Avant d'implémenter la mise à l'échelle sur votre bucket, vous devez effectuer les tâches suivantes :

Estimer le RPS à l'origine

Supposons que pour un streaming en direct avec un million de spectateurs, le CDN recevra un million de RPS. En supposant que votre CDN ait un taux de succès de cache (hit) de 99,0%, le trafic résultant vers Cloud Storage sera de 1%. Le nombre de requêtes par seconde sera de 1% du nombre total de spectateurs (un million), soit 10 000 RPS. Cette valeur est supérieure à la capacité d'E/S initiale.

Surveiller le RPS et résoudre les erreurs de mise à l'échelle

Vous devez surveiller le RPS et résoudre les erreurs de mise à l'échelle. Pour en savoir plus, consultez Présentation de la surveillance dans Cloud Storage . Pour surveiller les requêtes de lecture et d'écriture, observez respectivement les graphiques Nombre total de requêtes de lecture/liste/obtention et Nombre total de requêtes d'écriture dans la Google Cloud console. Si vous mettez à l'échelle le RPS sur les buckets plus rapidement que les consignes de montée en puissance spécifiées dans la section précédente, vous risquez de rencontrer l'erreur 429 Too many requests (429 : trop de requêtes). Découvrez comment résoudre l' erreur 429 Too many requests.

Les sections suivantes décrivent comment mettre à l'échelle votre bucket pour RPS plus élevé une fois que vous avez estimé le RPS à l'origine.

Implémenter la mise à l'échelle du nombre de requêtes par seconde sur votre bucket en le préchauffant

Vous pouvez accélérer le processus de mise à l'échelle avant un événement de streaming en direct en préchauffant votre bucket. Avant l'événement de streaming en direct, générez du trafic synthétique vers votre bucket qui correspond au nombre maximal de requêtes par seconde attendu que le serveur d'origine du CDN recevra pour l'événement, plus une mémoire tampon supplémentaire de 50% en tenant compte du taux de réussite du cache attendu de votre CDN. Par exemple, si vous avez estimé que le RPS à votre origine est de 10 000, votre trafic simulé doit cibler 15 000 requêtes par seconde pour préparer votre origine à l'événement.

Pour ce trafic simulé, vous pouvez utiliser les fichiers de flux en direct de l'événement précédent, tels que les segments et le fichier manifeste, ou les fichiers de test. Assurez-vous d'avoir des fichiers distincts tout au long du processus de préchauffage.

Lorsque vous générez ce trafic simulé, suivez une approche de mise à l'échelle progressive, en commençant par 5 000 requêtes par seconde et en augmentant progressivement jusqu'à atteindre votre objectif. Allouez suffisamment de temps avant votre événement pour atteindre la charge estimée. Par exemple, atteindre 15 000 requêtes par seconde, en doublant la charge toutes les 20 minutes à partir d'un nombre initial de 5 000 requêtes par seconde, prendra environ 30 minutes.

Le serveur d'origine maintient la capacité jusqu'à ce que le trafic soit cohérent. La capacité du serveur d'origine diminue progressivement jusqu'à son niveau de référence sur 24 heures. Si votre serveur d'origine connaît des intervalles de plusieurs heures entre les événements de streaming en direct, nous vous recommandons de simuler le trafic avant chaque événement.

Utiliser des buckets avec l'espace de noms hiérarchique activé pour RPS initial élevé

Les buckets Cloud Storage avec l'espace de noms hiérarchique activé offrent jusqu'à huit fois le RPS initial par rapport aux buckets sans espace de noms hiérarchique. Le RPS initial plus élevé facilite l'adaptation des charges de travail utilisant beaucoup de données et améliore le débit. Pour en savoir plus sur les limites des buckets avec l'espace de noms hiérarchique activé, consultez Limites.

Éviter les noms séquentiels pour les segments vidéo afin de mettre à l'échelle le RPS

Avec la mise à l'échelle du nombre de requêtes par seconde, les requêtes sont redistribuées sur plusieurs serveurs. Toutefois, vous pouvez rencontrer des goulots d'étranglement des performances lorsque tous les objets utilisent un préfixe non aléatoire ou séquentiel. L'utilisation de noms complètement aléatoires plutôt que de noms séquentiels offre la meilleure répartition de la charge. Toutefois, si vous souhaitez utiliser des numéros séquentiels ou des horodatages dans vos noms d'objet, intégrez une dimension aléatoire en ajoutant une valeur de hachage avant le numéro de séquence ou l'horodatage. Par exemple, si le nom d'objet d'origine que vous souhaitez utiliser est my-bucket/2016-05-10-12-00-00/file1, vous pouvez calculer le hachage MD5 du nom d'objet d'origine et ajouter les six premiers caractères du hachage en tant que préfixe de ce nom. Le nouvel objet devient my-bucket/2fa764-2016-05-10-12-00-00/file1. Pour plus d'informations, consultez Utiliser une convention de dénomination qui répartit la charge uniformément entre les plages de clés. Si vous ne pouvez pas éviter l'attribution de noms séquentiels aux segments vidéo, utilisez des buckets avec l'espace de noms hiérarchique activé pour obtenir RPS plus élevé.

Utiliser différents buckets pour chaque streaming en direct

Pour les diffusions en direct simultanées, l'utilisation de différents buckets pour chaque diffusion en direct vous aidera à mettre à l'échelle efficacement la charge de lecture et d'écriture sans atteindre les limites d'E/S du bucket. L'utilisation de différents buckets pour chaque diffusion en direct réduit les latences aberrantes importantes dues aux délais de mise à l'échelle.

Étape suivante