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 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 a pós-produção de filmes, incluindo a edição de vídeo, que exigem muita computação e geralmente usam GPUs para computação de alto desempenho. Muitas vezes, os dados relacionados à 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 a redução da taxa de leitura e gravação agregada do Cloud Storage para um cluster de computação com um tempo de inatividade da GPU menor. Eles também exigem latências de leitura e gravação baixas, já que isso é crucial para reduzir a latência de cauda.
  • Gerenciamento de recursos de mídia: inclui a organização de 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á armazenado em cache na rede de entrega de conteúdo (CDN), o conteúdo é buscado dos buckets do Cloud Storage. Para solicitações de transmissão ao vivo, o conteúdo é gravado no bucket do Storage e lido do 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 de dados do Cloud Storage para fazer upload de mais de 1 TiB de arquivos de mídia bruta de uma origem local, como câmera de vídeo ou armazenamento local, para o Cloud Storage. O Serviço de transferência do Cloud Storage permite o movimento 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 que os recursos de computação. Esse método ajuda a otimizar o desempenho reduzindo a latência de leitura e gravação das 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 arquivados, a classe de armazenamento padrão de um bucket precisa ser "Archive Storage". É possível especificar uma classe de armazenamento diferente para objetos com disponibilidade ou necessidades de 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 no armazenamento padrão.

Para mais orientações sobre como escolher a classe de armazenamento para 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 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 e o downgrade de classes de armazenamento 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 seus dados, é possível definir o recurso de classe automática para seu bucket. Com a classe automática, 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 distribuição e exibiçã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 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 considerar 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 distribuição e veiculação de conteúdo, consulte as seções a seguir.

Usar o 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 o CDN armazena o conteúdo em cache, reduzindo a latência e aumentando a eficiência da largura de banda. Com uma CDN, você pode reduzir o custo total de propriedade (TCO, na sigla em inglês) 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 a veiculação do conteúdo aos usuários finais, já que o custo de preenchimento de cache para a Media CDN é zero. É possível usar o Media CDN como a origem de outras CDNs de terceiros. Com outras CDNs, você ainda tem uma redução no TCO ao veicular conteúdo do cache do Media CDN em vez da origem.

Se você estiver usando um CDN de terceiros, o CDN Interconnect 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 meio de um desses links se beneficia da conectividade direta com provedores de CDN com suporte e é cobrado automaticamente com preços reduzidos. Para uma lista de provedores aprovados, consulte Provedores de serviços aprovados pelo Google.

Confira a seguir as opções a serem configuradas ao configurar uma CDN:

Selecione o local do escudo de origem

O local do escudo de origem é um cache entre a CDN e o Cloud Storage. Se o CDN permitir que você selecione o local do escudo de origem, siga as diretrizes do CDN para saber se é recomendável escolher o escudo de origem mais próximo da região do seu bucket do Cloud Storage ou do local de concentração de tráfego do usuário final. O escudo de origem é uma medida de proteção contra sobrecarga do servidor de origem. As CDNs com blindagem de origem ajudam a aumentar o offload da 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 o CDN. O agrupamento de várias solicitações em uma única solicitação reduz o custo da operação da classe B do Cloud Storage. Os CDNs distribuem caches implantados em todo o mundo, mas oferecem uma maneira de reunir várias solicitações do usuário final em uma única solicitação para a origem. Por exemplo, o Media CDN agrupa 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 sua CDN. As CDNs oferecem suporte a novas tentativas de origem, permitindo a repetição de solicitações não concluídas para a origem. A maioria das CDNs permite especificar o número de tentativas 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 no CDN, como a veiculação e distribuição de conteúdo do tipo 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 maior disponibilidade.
    • Para casos de uso que exigem veiculação de conteúdo e análise com redundância geográfica, 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 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 um CDN que armazena em cache e distribui o conteúdo para os usuários finais. Para melhorar a performance do streaming, escolha buckets regionais que estejam colocalizados com os recursos de computação usados para a transcodificação.

Otimizar a duração 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 os trechos 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 a melhor experiência aos espectadores, recomendamos usar a estratégia de nova tentativa e solicitar proteção para gravações nos transcodificadores, a fim de reduzir latências de cauda longa de mais de dois segundos para gravações no Cloud Storage e experimentar tempos de buffer mais longos de aproximadamente dez segundos.

Aumente gradualmente a QPS

Os buckets do Cloud Storage têm uma capacidade inicial de E/S de 1.000 gravações de objeto por segundo e 5.000 leituras de objeto por segundo. Para cargas de trabalho de transmissão ao vivo, a orientação é escalonar as solicitações gradualmente, começando com 1.000 gravações por segundo e 5.000 leituras por segundo e duplicando 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 melhore 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 aquecendo-o ou ativando o namespace hierárquico. Antes de implementar a escala 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 sua CDN tenha uma taxa de acerto de cache de 99,0%, o tráfego resultante para o Cloud Storage será de 1%. O QPS será de 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 problemas de escalonamento

Monitore o 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 o gráfico Total de solicitações de leitura/listagem/recebimento e o gráfico Total de solicitações de gravação, respectivamente, no console do Google Cloud. Se você aumentar o QPS nos buckets mais rápido do que as diretrizes de aceleração 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 dimensionar seu bucket para QPS mais alto depois de estimar o QPS para a origem.

Implementar a escalabilidade de QPS no seu bucket pré-aquecendo-o

Para acelerar o processo de escalonamento antes de um evento de transmissão ao vivo, pré-aqueça seu 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 no evento, mais um buffer adicional de 50% na taxa de acerto de cache esperada da sua CDN. Por exemplo, se você estimou que a QPS para sua origem é de 10.000, o tráfego simulado deve ter como alvo 15.000 solicitações por segundo para preparar a origem para o evento.

Para esse tráfego simulado, você pode usar os arquivos de feed ao vivo do evento anterior, como segmentos e manifesto, ou arquivos de teste. Verifique se você tem arquivos diferentes durante 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 o objetivo. Aloque tempo suficiente antes do evento para alcançar a carga estimada. Por exemplo, alcançar 15.000 solicitações por segundo, dobrando a carga a cada 20 minutos 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 para o nível de referência em 24 horas. Se o servidor de origem tiver intervalos de várias horas entre os eventos de transmissão ao vivo, recomendamos simular 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 o namespace hierárquico. 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 dimensionar o QPS

Com o escalonamento de QPS, as solicitações são redistribuídas entre vários servidores. No entanto, é possível 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 proporciona a melhor distribuição de carga. No entanto, se você quiser usar números sequenciais ou carimbos de data/hora como parte dos nomes dos objetos, torne-os aleatórios adicionando um valor de hash antes do número de sequência ou do carimbo de data/hora. Por exemplo, se o nome do objeto original que você quer usar for my-bucket/2016-05-10-12-00-00/file1, você poderá calcular o hash MD5 do nome do objeto original e adicionar os primeiros seis caracteres do hash como um 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 uma delas ajuda a escalonar o carregamento de leitura e gravação de forma eficaz sem atingir os limites de E/S do bucket. O uso de intervalos diferentes para cada transmissão ao vivo diminui as latências de valores fora da curva devido a atrasos de escalonamento.

A seguir