Bonnes pratiques pour les charges de travail multimédias

Cloud Storage vous permet de stocker et de diffuser des assets audio et vidéo tout en optimisant les performances de streaming, en minimisant la latence de lecture et en gérant les coûts. Pour prendre en charge les workflows multimédias, vous pouvez intégrer Cloud Storage à des produitsGoogle Cloud tels que Media CDN, l'API Live Stream, l'API Transcoder et l'API Video Stitcher. Ce document décrit les bonnes pratiques à suivre lorsque vous utilisez Cloud Storage pour des charges de travail multimédias.

Présentation des charges de travail multimédias

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 ressources 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 d'effectuer un scaling du débit d'agrégation en lecture et en écriture 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 crucial pour réduire la latence de queue.
  • Gestion des composants multimédias : inclut l'organisation de vos composants 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 en streaming aux utilisateurs, y compris les services de vidéo à la demande (VoD) et de streaming en direct. Pendant 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 diffusion 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 applicables 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 depuis 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 facilement des données 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 nécessitant 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 régions doubles 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, le coût et la bande passante. Pour en savoir plus sur le choix de l'emplacement du bucket, consultez Éléments à prendre en compte pour l'emplacement du bucket.

Classe de stockage

La classe de stockage à sélectionner dépend du type de charge de travail multimédia. Les types de classes de stockage recommandés pour différentes charges de travail multimédias sont les suivants :

  • Pour gérer les composants multimédias, tels que les vidéos d'archive, la classe de stockage par défaut d'un bucket doit être le stockage Archive. Vous pouvez spécifier une classe de stockage différente pour les objets ayant des besoins de disponibilité ou d'accès différents.
  • Pour les charges de travail de production multimédia et de diffusion de contenu, les données étant lues fréquemment à partir d'un bucket Cloud Storage, vous devez les stocker dans un espace de stockage Standard.

Pour en savoir plus sur le choix de la classe de stockage de votre bucket, consultez Classe de stockage.

Gestion du cycle de vie des données

Pour gérer vos composants multimédias, vous devez gérer le cycle de vie des objets de vos buckets en définissant une configuration de cycle de vie. La fonctionnalité de gestion du cycle de vie des objets vous permet de gérer le cycle de vie des données, y compris de définir une valeur TTL (Time To Live) pour les objets, de conserver les versions obsolètes des objets et de 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 de 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é de classe automatique pour votre bucket. Avec la classe automatique, Cloud Storage déplace automatiquement les données qui ne sont pas fréquemment consultées 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 diffusion en direct, l'objectif est d'éviter les erreurs de lecture, les retards de démarrage de la lecture ou la 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 un scaling 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 applicables 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 (TCO) en réduisant 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 du contenu aux utilisateurs finaux, car le coût de remplissage du cache pour Media CDN est nul. Vous pouvez utiliser Media CDN comme source pour d'autres CDN tiers. Avec d'autres CDN, vous bénéficiez toujours d'une réduction du coût total de possession lorsque vous diffusez du contenu à partir de ce cache Media CDN plutôt qu'à partir 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érentes zones. Le trafic réseau sortant de Google Cloudqui transite par l'une de ces liaisons bénéficie de la connectivité directe aux fournisseurs de 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.

Voici les options à configurer lors de la configuration d'un CDN :

Sélectionner l'emplacement de la protection 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 un bouclier d'origine plus proche 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 les surcharges. Les CDN avec bouclier d'origine permettent d'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 coalescence de requêtes

Assurez-vous que la réduction de requêtes est activée pour votre CDN. La réduction de plusieurs requêtes en une seule réduit le coût des opérations de classe B de Cloud Storage. Les CDN disposent de caches distribués déployés dans le monde entier, mais permettent de regrouper plusieurs requêtes d'utilisateurs finaux en une seule requête adressée à 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 de nouvelle tentative sur le CDN

Assurez-vous de configurer une nouvelle tentative pour tout problème de serveur avec un 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 lisant des données à partir de Cloud Storage qui ne sont pas mises en cache sur le CDN, telles que la diffusion de contenu et la distribution d'un 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 points 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 nécessitant la diffusion de contenu et l'analyse avec géoredondance, utilisez des buckets dans des zones multirégionales pour une disponibilité optimale.
  • Pour optimiser la latence et réduire les coûts réseau, tenez compte des points suivants :
    • Pour la VoD, choisissez les régions les plus proches de l'emplacement de la plupart de vos utilisateurs finaux ou la région où le trafic est le plus concentré.
    • Pendant la diffusion en direct, les buckets reçoivent des requêtes d'écriture de la part des transcodeurs et des requêtes de lecture de la part 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 colocalisés avec les ressources de calcul utilisées pour le transcodage.

Optimiser la durée 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 les contenus auxquels on accède rarement ou qui ont 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'utiliser une taille de segment vidéo plus longue.

Pour offrir une expérience optimale aux spectateurs, nous vous recommandons d'utiliser la stratégie de nouvelle tentative 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 de tester des temps de mise en mémoire tampon plus longs d'environ dix secondes.

Augmenter progressivement le nombre de 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 diffusion en direct, il est recommandé d'ajuster progressivement vos requêtes en commençant par 1 000 écritures par seconde et 5 000 lectures par seconde, puis 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 diffusion en direct avec un nombre de RPS plus élevé, vous devez mettre en œuvre le scaling sur votre bucket en préchauffant votre bucket ou en activant l'espace de noms hiérarchique sur votre bucket. Avant d'implémenter le scaling sur votre bucket, vous devez effectuer les tâches suivantes :

Estimer votre nombre de RPS vers l'origine

Supposons que pour une diffusion en direct avec un million de spectateurs, le CDN reçoive 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 RPS sera de 1% du nombre total de spectateurs (un million), ce qui équivaut à 10 000 RPS. Cette valeur est supérieure à la capacité d'E/S initiale.

Surveillez le nombre de RPS et résolvez les erreurs de scaling.

Vous devez surveiller le RPS et résoudre les erreurs de scaling. 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/get et Nombre total de requêtes d'écriture dans la consoleGoogle Cloud . Si vous augmentez le nombre de 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 expliquent comment faire évoluer votre bucket pour obtenir un nombre de RPS plus élevé après avoir estimé le nombre de RPS vers l'origine.

Implémenter le scaling des RPS sur votre bucket en le préchauffant

Vous pouvez accélérer le processus de scaling avant un événement de diffusion en direct en préchauffant votre bucket. Avant l'événement de diffusion en direct, générez un trafic synthétique vers votre bucket correspondant au nombre maximal de RPS que le serveur d'origine du CDN devrait recevoir pour l'événement, plus une marge de 50% en tenant compte du taux de succès de cache attendu de votre CDN. Par exemple, si vous avez estimé le RPS vers votre origine à 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 des fichiers de test. Assurez-vous de disposer de fichiers distincts tout au long du processus de préchauffage.

Lorsque vous générez ce trafic simulé, suivez une approche de scaling progressif, en commençant par 5 000 requêtes par seconde et en augmentant progressivement jusqu'à atteindre votre cible. Prévoyez suffisamment de temps avant votre événement pour atteindre la charge estimée. Par exemple, pour atteindre 15 000 requêtes par seconde, en doublant la charge toutes les 20 minutes à partir d'une charge initiale de 5 000 requêtes par seconde, il faudra 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 subit des interruptions de plusieurs heures entre les événements de diffusion 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 un RPS initial élevé

Les buckets Cloud Storage avec l'espace de noms hiérarchique activé fournissent jusqu'à huit fois plus de RPS initiales que les buckets sans espace de noms hiérarchique. La limite initiale de RPS plus élevée 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 d'ajuster les RPS

Avec le scaling des RPS, les requêtes sont redistribuées sur plusieurs serveurs. Cependant, 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 vous permet d'obtenir la meilleure répartition de charge. Toutefois, si vous souhaitez utiliser des numéros séquentiels ou des codes temporels dans vos noms d'objet, intégrez-y une chaîne aléatoire en ajoutant une valeur de hachage avant le numéro de séquence ou le code temporel. 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 au nom de l'objet. Le nouvel objet devient my-bucket/2fa764-2016-05-10-12-00-00/file1.. Pour en savoir plus, consultez Utiliser une convention d'attribution de nom qui répartit la charge uniformément entre les plages de clés. Si vous ne pouvez pas éviter d'utiliser des noms séquentiels pour les segments vidéo, utilisez des buckets avec l'espace de noms hiérarchique activé pour obtenir un RPS plus élevé.

Utiliser des buckets différents pour chaque diffusion en direct

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

Étapes suivantes