Bonnes pratiques pour les charges de travail multimédias

Cette page décrit les bonnes pratiques à suivre lorsque vous utilisez Cloud Storage pour les charges de travail multimédias. Ces charges de travail incluent souvent divers produits Google Cloud 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 les charges de travail telles que la post-production de films, y compris le montage vidéo, qui nécessitent beaucoup de calculs et utilisent souvent des GPU pour le calcul haute performance. Souvent, les données liées aux contenus 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 de faire évoluer le débit de lecture et d'écriture agrégé de Cloud Storage vers un cluster de calcul avec un temps d'inactivité des 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 contenus : 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 vidéo à la demande, 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 à partir du CDN simultanément.

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 stockage sur site, vers Cloud Storage. Le service de transfert de stockage permet de déplacer facilement des données entre des 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 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, les coûts et la bande passante. Pour obtenir plus de conseils sur le choix de l'emplacement du bucket, consultez Considérations relatives à l'emplacement du bucket.

Classe de stockage

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

  • Pour gérer les composants multimédias, tels que les vidéos d'archives, la classe de stockage par défaut d'un bucket doit être "Stockage Archive". Vous pouvez spécifier une classe de stockage différente 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, les données étant lues fréquemment à partir d'un bucket Cloud Storage, vous devez les stocker dans un espace de stockage Standard.

Pour obtenir plus de conseils 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 composants multimédias, vous devez gérer le cycle de vie des objets de vos buckets en définissant une configuration du 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 en définissant une valeur TTL (Time to Live) pour les objets, en conservant les versions obsolètes des objets et en rétrogradant 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. Si vous ne connaissez pas ou ne pouvez pas prévoir les modèles d'accès à 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 VOD et de diffusion en direct, l'objectif est d'éviter toute erreur de lecture, tout retard 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, le trafic client doit 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 utilisateur, 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 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 TCO 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é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 de configuration d'un CDN :

Sélectionnez 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 empêche la surcharge de votre serveur d'origine. 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 fournit une infrastructure périphérique à plusieurs niveaux conçue pour minimiser activement le remplissage de cache dans la mesure du possible.

Activer la réduction de requêtes

Assurez-vous que le regroupement des requêtes est activé pour votre CDN. En regroupant plusieurs requêtes en une seule, vous réduisez 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'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 envoyées aux buckets.

Configurer le comportement des nouvelles tentatives sur le CDN

Assurez-vous de configurer la nouvelle tentative 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 qui ont échoué. La plupart des CDN vous permettent de spécifier le nombre de tentatives pour l'origine actuelle. Pour savoir comment relancer 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 Cloud Storage non mises en cache sur le CDN, comme la diffusion de contenu 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 nécessitant 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 points suivants :
    • Pour la VOD, choisissez les régions les plus proches de la majorité de vos utilisateurs finaux ou la région où le trafic est le plus concentré.
    • Lors d'une diffusion en direct, les buckets reçoivent des requêtes d'écriture des 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 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 la plus faible recommandée est de deux secondes, car les segments vidéo courts sont plus sensibles aux latences d'écriture de longue durée. La latence d'écriture de longue traîne fait 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 celui de la lecture par les utilisateurs finaux affecte le temps de transmission. Si vos utilisateurs finaux sont loin de l'emplacement du bucket, nous vous recommandons d'utiliser une taille de segment vidéo plus longue.

Pour offrir la meilleure expérience possible aux spectateurs, nous vous recommandons d'utiliser la stratégie de réessai 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 sur Cloud Storage, et d'expérimenter des temps de mise en mémoire tampon plus longs d'environ dix secondes.

Augmenter progressivement les 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, la consigne est de faire évoluer vos requêtes progressivement en commençant par 1 000 écritures par seconde et 5 000 lectures par seconde, puis en doublant progressivement le taux de requêtes toutes les 20 minutes. Cette méthode permet à Cloud Storage de répartir 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 en direct avec un RPS plus élevé, vous devez implémenter la mise à l'échelle 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 vos RPS vers l'origine

Supposons qu'une diffusion en direct compte un million de spectateurs. Le CDN recevra alors un million de RPS. En supposant que votre CDN ait un taux de succès de cache (hit) de 99 %, le trafic résultant vers Cloud Storage sera de 1 %. Les RPS correspondront à 1 % du nombre total de spectateurs (un million), soit 10 000 RPS. Cette valeur est supérieure à la capacité d'E/S initiale.

Surveiller les RPS et résoudre les problèmes de scaling

Vous devez surveiller les RPS et résoudre les éventuelles 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, examinez respectivement les graphiques Nombre total de requêtes de lecture/liste/obtention et Nombre total de requêtes d'écriture dans la consoleGoogle Cloud . Si vous augmentez le RPS sur les buckets plus rapidement que les consignes d'augmentation spécifiées dans la section précédente, vous risquez de rencontrer l'erreur 429 Too many requests. Découvrez comment résoudre l'erreur 429 : Too Many Requests.

Les sections suivantes expliquent comment mettre à l'échelle votre bucket pour obtenir RPS plus élevé après avoir estimé le RPS à l'origine.

Implémenter la mise à l'échelle des RPS sur votre bucket en le préchauffant

Vous pouvez accélérer le processus de scaling avant un événement de streaming en direct en préchauffant votre bucket. Avant l'événement de diffusion en direct, générez du trafic synthétique vers votre bucket qui correspond au RPS maximal attendu que le serveur d'origine du CDN recevra pour l'événement, plus une marge supplémentaire de 50 % en tenant compte du taux de réussite du cache attendu de votre CDN. Par exemple, si vous avez estimé les RPS de 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 les fichiers de test. Assurez-vous d'avoir des fichiers distincts tout au long du processus d'échauffement.

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 objectif. 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 stable. La capacité du serveur d'origine diminue progressivement jusqu'à son niveau de référence sur 24 heures. Si votre serveur d'origine présente des écarts 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é offrent un RPS initial jusqu'à huit fois supérieur à celui des buckets sans espace de noms hiérarchique. Le RPS initial plus élevé facilite l'adaptation des charges de travail intensives en 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 la section Limites.

Éviter les noms séquentiels pour les segments vidéo afin de faire évoluer les RPS

Avec la mise à l'échelle du RPS, 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. Employez plutôt des noms aléatoires que des noms séquentiels, qui optimiseront la répartition de la charge. Toutefois, si vous souhaitez utiliser des numéros séquentiels ou des codes temporels 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 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 de ce nom. Le nouvel objet devient my-bucket/2fa764-2016-05-10-12-00-00/file1.. Pour en savoir plus, 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 de nommer les segments vidéo de manière séquentielle, 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 différents buckets pour chaque diffusion vous aidera à mettre à l'échelle efficacement la charge de lecture et d'écriture sans atteindre les limites d'E/S pour le 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.

Étapes suivantes