Práticas recomendadas para cargas de trabalho de mídia

Esta página descreve as práticas recomendadas ao usar o Cloud Storage para cargas de trabalho de mídia. Essas cargas de trabalho geralmente incluem vários produtos do Google Cloud , como Media CDN, API Live Stream, API Transcoder e API Video Stitcher.

Visão geral

OGoogle Cloud oferece soluções para otimizar os seguintes tipos de cargas de trabalho de mídia:

  • Produção de mídia: inclui cargas de trabalho como pós-produção de filmes, incluindo edição de vídeo, que são pesadas para computação e geralmente usam GPUs para computação de alta performance. Muitas vezes, os dados relacionados a mídia armazenados no Cloud Storage são processados por aplicativos executados no Compute Engine ou no Google Kubernetes Engine, e a saída desse processo é gravada de volta no Cloud Storage. Essas cargas de trabalho exigem o escalonamento da taxa de transferência agregada de leitura e gravação do Cloud Storage para um cluster de computação com um tempo ocioso de GPU menor. Além disso, eles exigem latências de leitura e gravação baixas, o que é crucial para reduzir a latência de cauda.
  • Gerenciamento de recursos de mídia: inclui a organização dos recursos de mídia para armazenamento, recuperação e uso eficientes.
  • Veiculação e distribuição de conteúdo: inclui streaming de mídia para usuários, incluindo serviços de vídeo on demand (VoD) e transmissão ao vivo. Durante o VoD, quando os usuários solicitam conteúdo que não está em cache na rede de distribuição de conteúdo (CDN), ele é buscado nos buckets do Cloud Storage. Para solicitações de transmissão ao vivo, o conteúdo é gravado no bucket do Storage e lido da CDN simultaneamente.

Práticas recomendadas para cargas de trabalho de mídia

Para conferir as práticas recomendadas que se aplicam a cargas de trabalho de mídia, consulte as seções a seguir.

Transferência de dados

Use o Serviço de transferência do Cloud Storage para fazer upload de mais de 1 TiB de arquivos de mídia brutos de uma origem local, como uma câmera de vídeo ou um armazenamento local, para o Cloud Storage. O Serviço de transferência do Cloud Storage permite a movimentação de dados entre sistemas de armazenamento de objetos e arquivos. Para transferências menores, escolha o serviço para transferir dados para e do Cloud Storage ou entre sistemas de arquivos com base no seu cenário de transferência.

Local do bucket

Para cargas de trabalho que exigem recursos de computação, como produção de mídia, crie buckets na mesma região ou em regiões duplas dos recursos de computação. Esse método ajuda a otimizar o desempenho, reduzindo as latências de leitura e gravação das cargas de trabalho de processamento, o custo e a largura de banda. Para mais orientações sobre como escolher o local do bucket, consulte Considerações sobre o local do bucket.

Classe de armazenamento

Dependendo do tipo de carga de trabalho de mídia, a classe de armazenamento que você deve selecionar varia. Os tipos de classe de armazenamento recomendados para diferentes cargas de trabalho de mídia são os seguintes:

  • Para gerenciar recursos de mídia, como vídeos de arquivo, a classe de armazenamento padrão de um bucket precisa ser Archive Storage. É possível especificar uma classe de armazenamento diferente para objetos com necessidades de disponibilidade ou acesso diferentes.
  • Para cargas de trabalho de produção de mídia e veiculação de conteúdo, como os dados são lidos com frequência de um bucket do Cloud Storage, armazene os dados no armazenamento padrão.

Para mais orientações sobre como escolher a classe de armazenamento do seu bucket, consulte Classe de armazenamento.

Gerenciamento do ciclo de vida dos dados

Para gerenciar seus recursos de mídia, defina uma configuração de ciclo de vida para gerenciar o ciclo de vida de objetos dos seus buckets. Com o recurso Gerenciamento do ciclo de vida de objetos, é possível gerenciar o ciclo de vida dos dados, incluindo a definição de um time to live (TTL) para objetos, a retenção de versões não atuais de objetos e o downgrade de classes de armazenamento de objetos para ajudar a gerenciar custos.

Quando os padrões de acesso a dados são previsíveis, é possível definir a configuração do ciclo de vida de um bucket. Para padrões de acesso desconhecidos ou imprevisíveis aos seus dados, é possível definir o recurso de classe automática para seu bucket. Com o Autoclass, o Cloud Storage move automaticamente os dados que não são acessados com frequência para classes de armazenamento de acesso raro.

Práticas recomendadas para cargas de trabalho de exibição e distribuição de conteúdo

Para cargas de trabalho de VoD e transmissão ao vivo, o objetivo é evitar erros de reprodução, atrasos no início da reprodução ou armazenamento em buffer ao assistir um vídeo no player dos usuários finais. Essas cargas de trabalho também exigem o escalonamento de leituras para considerar um grande número de espectadores simultâneos. Em todos os casos, o tráfego de clientes deve passar por uma CDN.

Para conferir as práticas recomendadas que se aplicam a cargas de trabalho de disponibilização e distribuição de conteúdo, consulte as seções a seguir.

Use a CDN de forma eficaz

Usar uma rede de fornecimento de conteúdo (CDN) na frente do bucket do Cloud Storage melhora a experiência do usuário final, já que a CDN armazena conteúdo em cache, reduzindo a latência e aumentando a eficiência da largura de banda. Com uma CDN, é possível reduzir o custo total de propriedade (TCO) ao diminuir os custos de largura de banda, otimizar o uso de recursos e melhorar o desempenho. O uso da Media CDN ajuda a reduzir o TCO para veicular o conteúdo aos usuários finais, já que o custo de preenchimento de cache da Media CDN é zero. Você pode usar o Media CDN como origem de outras CDNs de terceiros. Com outras CDNs, você ainda tem alguma redução no TCO ao veicular conteúdo do cache da Media CDN em vez da origem.

Se você estiver usando uma CDN de terceiros, a Interconexão de CDN permite que provedores selecionados estabeleçam links de peering direto com a rede de borda do Google em vários locais. O tráfego de rede que sai do Google Cloud por um desses links se beneficia da conectividade direta com provedores de CDN compatíveis e é cobrado automaticamente com preços reduzidos. Para uma lista de provedores aprovados, consulte Provedores de serviços aprovados pelo Google.

Confira abaixo as opções de configuração de uma CDN:

Selecionar o local da proteção de origem

O local de proteção de origem é um cache entre a CDN e o Cloud Storage. Se a CDN permitir que você selecione o local do escudo de origem, siga as diretrizes da CDN sobre se é recomendável escolher o escudo de origem para ficar mais perto da região do bucket do Cloud Storage ou do local de concentração do tráfego do usuário final. Um escudo de origem é uma medida de proteção que evita a sobrecarga do servidor de origem. As CDNs com blindagem de origem ajudam a aumentar o descarregamento de origem adicionando um cache extra entre a origem e a CDN. Por exemplo, a Media CDN oferece uma infraestrutura de borda em camadas projetada para minimizar ativamente o preenchimento de cache sempre que possível.

Ativar o agrupamento de solicitações

Verifique se o recolhimento de solicitações está ativado para sua CDN. Ao recolher várias solicitações em uma única, o custo da operação da classe B do Cloud Storage é reduzido. As CDNs têm caches distribuídos implantados em todo o mundo, mas oferecem uma maneira de agrupar várias solicitações do usuário final em uma única solicitação de origem. Por exemplo, a Media CDN recolhe ativamente várias solicitações de preenchimento de cache orientadas pelo usuário para a mesma chave de cache em uma única solicitação de origem por nó de borda, reduzindo o número de solicitações feitas aos buckets.

Configurar o comportamento de repetição na CDN

Configure a repetição para problemas do servidor com o código de resposta HTTP 5xx (502, 503, 504) na CDN. As CDNs oferecem suporte a novas tentativas de origem, permitindo a repetição de solicitações sem êxito à origem. A maioria das CDNs permite especificar o número de novas tentativas para a origem atual. Para informações sobre como repetir solicitações de origem na Media CDN, consulte Repetir solicitações de origem.

Opções de local para distribuição de conteúdo

Para cargas de trabalho que leem dados do Cloud Storage não armazenados em cache na CDN, como serviço de conteúdo e distribuição de conteúdo VoD, considere os seguintes fatores ao selecionar um local para seu bucket:

  • Para otimizar o custo, os buckets criados em uma única região têm o custo de armazenamento mais baixo.
  • Para otimizar a disponibilidade, considere o seguinte:
    • Para a maioria das cargas de trabalho de mídia, é recomendável usar buckets birregionais, porque eles replicam seus objetos em duas regiões para melhorar a disponibilidade.
    • Para casos de uso que exigem veiculação de conteúdo e análise com georredundância, use buckets em multirregiões para ter a maior disponibilidade.
  • Para otimizar a latência e reduzir os custos de rede, considere o seguinte:
    • Para VoD, escolha as regiões mais próximas de onde a maioria dos usuários finais está ou a região com maior concentração de tráfego.
    • Durante a transmissão ao vivo, os buckets recebem solicitações de gravação de transcodificadores e solicitações de leitura de uma CDN que armazena em cache e distribui o conteúdo para usuários finais. Para melhorar o desempenho do streaming, escolha buckets regionais que estejam colocalizados com os recursos de computação usados para transcodificação.

Otimizar a duração do segmento de vídeo para transmissões ao vivo

Para transmissões ao vivo, o menor tamanho de segmento recomendado é de dois segundos porque segmentos de vídeo curtos são mais sensíveis a latências de gravação de cauda longa. As latências de gravação de cauda longa se referem às operações de gravação lentas ou atrasadas para conteúdo que é acessado com pouca frequência ou tem um baixo volume de solicitações.

A distância física entre o local do bucket e o local de reprodução dos usuários finais afeta o tempo de transmissão. Se os usuários finais estiverem longe do local do bucket, recomendamos um tamanho maior de segmento de vídeo.

Para oferecer a melhor experiência aos espectadores, recomendamos usar a estratégia de nova tentativa e a proteção de solicitação para gravações nos transcodificadores. Isso ajuda a reduzir as latências de cauda longa de mais de dois segundos para gravações no Cloud Storage e a testar tempos de buffer mais longos, de aproximadamente dez segundos.

Aumentar gradualmente o QPS

Os buckets do Cloud Storage têm uma capacidade inicial de E/S de 1.000 gravações de objetos por segundo e 5.000 leituras de objetos por segundo. Para cargas de trabalho de transmissão ao vivo, a diretriz é escalonar as solicitações gradualmente, começando com 1.000 gravações por segundo e 5.000 leituras por segundo, e dobrando incrementalmente a taxa de solicitação a cada 20 minutos. Esse método permite que o Cloud Storage redistribua a carga entre vários servidores e melhora a disponibilidade e a latência do bucket, reduzindo as chances de problemas de reprodução.

Para um evento de transmissão ao vivo com QPS mais alto, implemente o escalonamento no bucket pré-aquecendo o bucket ou ativando o namespace hierárquico. Antes de implementar o escalonamento no seu bucket, faça o seguinte:

Estimar seu QPS para a origem

Suponha que, para uma transmissão ao vivo com um milhão de espectadores, a CDN receba um milhão de QPS. Supondo que sua CDN tenha uma taxa de ocorrência em cache de 99%, o tráfego resultante para o Cloud Storage será de 1%. A QPS será 1% do total de espectadores (um milhão), o que equivale a 10.000 QPS. Esse valor é maior do que a capacidade inicial de E/S.

Monitore o QPS e resolva problemas de escalonamento

Monitore as QPS e resolva os erros de escalonamento. Para mais informações, consulte Visão geral do monitoramento no Cloud Storage . Para monitorar as solicitações de leitura e gravação, observe os gráficos Contagem total de solicitações de leitura/listagem/recebimento e Contagem total de solicitações de gravação, respectivamente, no console doGoogle Cloud . Se você dimensionar o QPS nos intervalos mais rápido do que as diretrizes de aumento especificadas mencionadas na seção anterior, poderá encontrar o erro 429 Too many requests. Saiba como resolver o erro 429: Há muitas solicitações.

As seções a seguir descrevem como escalonar seu bucket para QPS mais altos depois de estimar o QPS para a origem.

Implementar o escalonamento de QPS no bucket fazendo o pré-aquecimento dele

Para acelerar o processo de escalonamento antes de um evento de transmissão ao vivo, faça o pré-aquecimento do bucket. Antes do evento de transmissão ao vivo, gere tráfego sintético para seu bucket que corresponda ao QPS máximo esperado que o servidor de origem da CDN vai receber para o evento, além de um buffer adicional de 50%, considerando a taxa de acerto de cache esperada da CDN. Por exemplo, se você estimou o QPS para sua origem em 10.000, o tráfego simulado deve segmentar 15.000 solicitações por segundo para preparar a origem para o evento.

Para esse tráfego simulado, use os arquivos de feed ao vivo do evento anterior, como segmentos e manifesto, ou arquivos de teste. Verifique se você tem arquivos distintos durante todo o processo de aquecimento.

Ao gerar esse tráfego simulado, siga uma abordagem de escalonamento gradual, começando com 5.000 solicitações por segundo e aumentando progressivamente até atingir sua meta. Reserve tempo suficiente antes do evento para atingir a carga estimada. Por exemplo, atingir 15.000 solicitações por segundo, dobrando a carga a cada 20 minutos de um valor inicial de 5.000 solicitações por segundo, leva aproximadamente 30 minutos.

O servidor de origem mantém a capacidade até que o tráfego seja consistente. A capacidade do servidor de origem diminui gradualmente até o nível de referência em 24 horas. Se o servidor de origem tiver intervalos de várias horas entre os eventos da transmissão ao vivo, recomendamos que você simule o tráfego antes de cada evento.

Usar buckets com namespace hierárquico ativado para QPS inicial alto

Os buckets do Cloud Storage com o namespace hierárquico ativado oferecem até oito vezes o QPS inicial em comparação com os buckets sem HNS. Quanto maior o QPS inicial, mais fácil é fazer o escalonamento com uso intensivo de dados cargas de trabalho com uma capacidade de processamento aprimorada. Para informações sobre limitações em buckets com namespace hierárquico ativado, consulte Limitações.

Evite nomes sequenciais para segmentos de vídeo para escalonar o QPS

Com o escalonamento de QPS, as solicitações são redistribuídas entre vários servidores. No entanto, você pode encontrar gargalos de desempenho quando todos os objetos usam um prefixo não aleatório ou sequencial. O uso de nomes completamente aleatórios em vez de sequenciais proporciona a melhor distribuição da carga. No entanto, se você quiser usar números ou carimbos de data/hora sequenciais como parte dos nomes dos objetos, torne-os aleatórios adicionando um valor de hash antes do número ou carimbo de data/hora sequencial. Por exemplo, se o nome original do objeto que você quer usar for my-bucket/2016-05-10-12-00-00/file1, calcule o hash MD5 do nome original e adicione os primeiros seis caracteres do hash como prefixo. O novo objeto se torna my-bucket/2fa764-2016-05-10-12-00-00/file1. Para mais informações, consulte Usar uma convenção de nomenclatura que distribua a carga uniformemente pelos intervalos de chaves. Se não for possível evitar a nomenclatura sequencial para segmentos de vídeo, use buckets com namespace hierárquico ativado para ter um QPS mais alto.

Use buckets diferentes para cada transmissão ao vivo

Para transmissões ao vivo simultâneas, usar buckets diferentes para cada uma ajuda a escalonar a carga de leitura e gravação de maneira eficaz sem atingir os limites de E/S do bucket. Usar intervalos diferentes para cada transmissão ao vivo diminui as latências discrepantes grandes devido a atrasos de escalonamento.

A seguir