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 Google Cloud produtos, como o Media CDN, a API Live Stream, a API Transcoder e a API Video Stitcher.

Visão geral

Google Cloud O 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 a pós-produção de filmes, incluindo edição de vídeo, que são pesadas em computação e geralmente usam GPUs para computação de alto desempenho. Muitas vezes, os dados relacionados à mídia que residem no Cloud Storage são processados por aplicativos em execução 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 capacidade de processamento agregada de leitura e gravação do Cloud Storage para um cluster de recursos computacionais com um tempo de inatividade menor da GPU. Elas também exigem latências de leitura e gravação baixas, o que é fundamental 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 mídia de streaming 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á armazenado em cache na rede de fornecimento de conteúdo (CDN), o conteúdo é buscado nos buckets do Cloud Storage. Para solicitações de transmissão ao vivo, o conteúdo é gravado no bucket do Storage e lido na 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 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 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 de e para o Cloud Storage ou entre sistemas de arquivos com base no 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 que os recursos de computação. Esse método ajuda a otimizar o desempenho, reduzindo as latências de leitura e gravação para cargas de trabalho de processamento, custo e 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ê precisa selecionar é diferente. 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 o Archive Storage. É possível especificar uma classe de armazenamento diferente para objetos que têm 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 para o bucket, consulte Classe de armazenamento.

Gerenciamento do ciclo de vida dos dados

Para gerenciar seus recursos de mídia, gerencie o ciclo de vida de objetos dos seus buckets definindo uma configuração de ciclo de vida. 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 aos 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 dados, é possível definir o recurso Autoclass para o bucket. Com o Autoclass, o Cloud Storage move automaticamente os dados que não são acessados com frequência para classes de armazenamento mais frias.

Práticas recomendadas para cargas de trabalho de veiculaçã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 buffering ao reproduzir um vídeo no player de vídeo dos usuários finais. Essas cargas de trabalho também exigem o escalonamento de leituras para contabilizar um grande número de espectadores simultâneos. Em todos os casos, as leituras de tráfego do cliente precisam passar por uma CDN.

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

Usar a CDN de maneira eficaz

O uso de 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. Uma CDN permite reduzir o custo total de propriedade (TCO) ao reduzir os custos de largura de banda, otimizar o uso de recursos e melhorar o desempenho. O uso do Media CDN ajuda a reduzir o TCO para veicular o conteúdo aos usuários finais, já que o custo de preenchimento de cache do Media CDN é zero. É possível usar o Media CDN como a origem de outras CDNs de terceiros. Com outras CDNs, você ainda tem alguma redução de TCO ao veicular conteúdo desse cache do Media CDN em vez da origem.

Se você estiver usando uma CDN de terceiros, o CDN Interconnect permitirá que os 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 conferir uma lista de provedores aprovados, consulte Provedores de serviços aprovados pelo Google.

A seguir, listamos as opções de configuração ao configurar uma CDN:

Selecionar o local do escudo de origem

O local do escudo 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 de tráfego do usuário final. Um escudo de origem é uma medida de proteção que protege o servidor de origem contra sobrecarga. As CDNs com proteção de origem ajudam a aumentar o descarregamento de origem adicionando um cache extra entre a origem e a CDN. Por exemplo, o 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 a CDN. O recolhimento de várias solicitações em uma única reduz o custo da operação da classe de armazenamento B do Cloud Storage. As CDNs têm caches distribuídos implantados em todo o mundo, mas oferecem uma maneira de recolher várias solicitações de usuários finais em uma única solicitação de origem. Por exemplo, o 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

Verifique se você configurou a repetição para problemas de servidor com o código de resposta HTTP 5xx (502, 503, 504) na CDN. As CDNs oferecem suporte a repetições de origem, permitindo a repetição de solicitações sem êxito para a origem. A maioria das CDNs permite especificar o número de repetições para a origem atual. Para informações sobre como repetir solicitações de origem no 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 que não estão armazenados em cache na CDN, como veiculação e distribuição de conteúdo de um tipo de VoD, considere os seguintes fatores ao selecionar um local para o bucket:

  • Para otimizar o custo, os buckets criados em uma única região têm o menor custo de armazenamento.
  • 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 melhor disponibilidade.
    • Para casos de uso que exigem veiculação de conteúdo e análise com georredundância, use buckets em várias regiões para 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 a 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 e distribui o conteúdo aos usuários finais. Para um desempenho de streaming aprimorado, escolha buckets regionais que estejam localizados com os recursos de computação usados para transcodificação.

Otimizar o comprimento do segmento de vídeo para transmissões ao vivo

Para transmissões ao vivo, o tamanho mínimo recomendado do segmento é de dois segundos, porque segmentos de vídeo curtos são mais sensíveis a latências de gravação de cauda longa. Latências de gravação de cauda longa se referem a operações de gravação lentas ou atrasadas para conteúdo que é acessado com pouca frequência ou tem um volume baixo 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 de segmento de vídeo maior.

Para oferecer aos espectadores a melhor experiência, é recomendável usar a estratégia de repetição e a proteção de solicitação para gravações nos transcodificadores para atenuar latências de cauda longa de mais de dois segundos para gravações no Cloud Storage e testar tempos de buffer mais longos de aproximadamente dez segundos.

Aumentar o QPS gradualmente

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 em 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 seu bucket pré-aquecendo o bucket ou ativando o namespace hierárquico no bucket. Antes de implementar o escalonamento no bucket, realize as seguintes tarefas:

Estimar o 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 a CDN tenha uma taxa de ocorrência em cache de 99,0%, o tráfego resultante para o Cloud Storage será de 1%. O QPS será 1% do total de espectadores (um milhão), o que equivale a 10.000 QPS. Esse valor é maior que a capacidade inicial de E/S.

Monitorar o QPS e resolver erros de escalonamento

Monitore o QPS e resolva 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 o gráfico Contagem total de solicitações de leitura/listagem/recebimento e o gráfico Contagem total de solicitações de gravação no Google Cloud console. Se você escalonar o QPS em buckets 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 Too many requests.

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

Implementar o escalonamento de QPS no bucket pré-aquecendo o bucket

É possível acelerar o processo de escalonamento antes de um evento de transmissão ao vivo pré-aquecendo o bucket. Antes do evento de transmissão ao vivo, gere tráfego sintético para o bucket que corresponda ao QPS máximo esperado que o servidor de origem da CDN receberá para o evento, além de um buffer adicional de 50%, considerando a taxa de ocorrência de cache esperada da CDN. Por exemplo, se você estimou que o QPS para sua origem seja de 10.000, o tráfego simulado precisará segmentar 15.000 solicitações por segundo para preparar a origem para o evento.

Para esse tráfego simulado, é possível usar os arquivos de feed publicado 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 a meta. Alocar 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 QPS inicial de 5.000 solicitações por segundo, levará 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 para o nível de referência em 24 horas. Se o servidor de origem tiver lacunas de várias horas entre os eventos de 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 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.

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

Com o escalonamento de QPS, as solicitações são redistribuídas em 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 nomes sequenciais oferece a melhor distribuição de 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, você poderá calcular o hash MD5 do nome original do objeto e adicionar os seis primeiros caracteres do hash como prefixo ao nome do objeto. 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.

Usar buckets diferentes para cada transmissão ao vivo

Para transmissões ao vivo simultâneas, o uso de buckets diferentes para cada transmissão ao vivo ajudará a escalonar a carga de leitura e gravação de maneira eficaz sem atingir os limites de E/S do bucket. O uso de buckets diferentes para cada transmissão ao vivo diminui latências de outliers grandes devido a atrasos de escalonamento.

A seguir