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

Com o Cloud Storage, é possível armazenar e disponibilizar recursos de áudio e vídeo, além de otimizar o desempenho do streaming, minimizar a latência de reprodução e gerenciar custos. Para dar suporte a fluxos de trabalho de mídia, é possível integrar o Cloud Storage a Google Cloud produtos como Media CDN, API Live Stream, API Transcoder e API Video Stitcher. Neste documento, descrevemos as práticas recomendadas ao usar o Cloud Storage para cargas de trabalho de mídia.

Visão geral das cargas de trabalho de mídia

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 exigem muita 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 leitura e gravação agregada do Cloud Storage para um cluster de computação com um tempo de inatividade de 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 dos recursos de mídia para armazenamento, recuperação e uso eficientes.
  • Disponibilizaçã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 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 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 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 birregiões que os recursos de computação. Esse método ajuda a otimizar o desempenho, reduzindo as latências de leitura e gravação para as 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

A classe de armazenamento que você deve selecionar varia de acordo com o tipo de carga de trabalho de mídia. 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 em um bucket do Cloud Storage, é preciso armazenar os dados no Standard Storage.

Para mais orientações sobre como escolher a classe de armazenamento do 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 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 para seus dados, é possível definir o recurso de classe automática para o 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 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 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 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 diminuir os custos de largura de banda, otimizar a utilização de recursos e melhorar o desempenho. O uso do Media CDN ajuda a reduzir o TCO para disponibilizar 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 origem de outras CDNs de terceiros. Com outras CDNs, você ainda tem alguma redução de TCO ao exibir conteúdo desse cache do Media CDN em vez da origem.

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

Confira as opções para configurar uma CDN:

Selecione o local do Origin Shield

O local do Origin Shield é um cache entre a CDN e o Cloud Storage. Se a CDN permitir que você selecione o local do Origin Shield, siga as diretrizes da CDN para saber se é recomendável escolher o Origin Shield para ficar mais próximo 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 blindagem 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 sua CDN. O recolhimento de várias solicitações em uma única solicitação reduz o custo operacional da classe B do Cloud Storage. As CDNs têm caches distribuídos implantados em todo o mundo, mas oferecem uma maneira de reunir várias solicitações de usuários finais em uma única solicitação para a origem. Por exemplo, o Media CDN recolhe ativamente várias solicitações de preenchimento de cache orientadas pelo usuário para a mesma chave 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 nova tentativa na CDN

Configure a nova tentativa para qualquer problema de servidor com o código de resposta HTTP 5xx (502, 503, 504) na CDN. As CDNs são compatíveis com novas tentativas de origem, permitindo novas tentativas de solicitações malsucedidas para a 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 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 de conteúdo e distribuição de um conteúdo do tipo 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 melhorar a disponibilidade.
    • Para casos de uso que exigem veiculação de conteúdo e análise com redundância geográfica, use buckets em multirregiõ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 em cache e distribui o conteúdo para os usuários finais. Para melhorar o desempenho do streaming, escolha buckets regionais que estejam no mesmo local que 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 ter um tamanho de segmento de vídeo maior.

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

Aumentar as QPS gradualmente

Os buckets do Cloud Storage têm uma capacidade de E/S inicial 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 dobrar 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 bucket pré-aquecendo o bucket ou ativando o namespace hierárquico nele. Antes de implementar o escalonamento no bucket, execute as seguintes tarefas:

Estimar as 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,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 de IO inicial.

Monitorar as QPS e resolver 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/lista/coleta e Contagem total de solicitações de gravação, respectivamente, no console doGoogle Cloud . Se você escalonar as QPS em buckets mais rápido do que as diretrizes de aumento especificadas mencionadas na seção anterior, poderá encontrar o erro 429 Muitas solicitações. 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

É 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% que considere a taxa de ocorrência em cache esperada da CDN. Por exemplo, se você estimou que as QPS para sua origem seriam de 10.000, seu tráfego simulado precisa ter como meta 15.000 solicitações por segundo para preparar sua origem para o evento.

Para esse tráfego simulado, use os arquivos de feed ao vivo do evento anterior, como segmentos e manifestos, 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, para 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, serão necessários 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 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 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 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 nomes sequenciais oferece 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, introduza aleatoriedade nos nomes dos objetos 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, calcule o hash MD5 do nome do objeto original e adicione os seis primeiros 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, confira 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 receber QPS mais altas.

Usar buckets diferentes para cada transmissão ao vivo

Para transmissões ao vivo simultâneas, usar buckets diferentes para cada transmissão ajuda 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 as latências de outliers grandes devido a atrasos de escalonamento.

A seguir