Práticas recomendadas para cargas de trabalho de multimédia

Esta página descreve as práticas recomendadas quando usa o Cloud Storage para cargas de trabalho de multimédia. Estas cargas de trabalho incluem frequentemente vários Google Cloud produtos, como o Media CDN, a API Live Stream, a API Transcoder e a API Video Stitcher.

Vista geral

Google Cloud oferece soluções para otimizar os seguintes tipos de cargas de trabalho de multimédia:

  • Produção de multimédia: inclui cargas de trabalho como a pós-produção de filmes, incluindo a edição de vídeo, que exigem muito processamento e usam frequentemente GPUs para computação de alto desempenho. Muitas vezes, os dados relacionados com multimédia residentes no Cloud Storage são processados por aplicações em execução no Compute Engine ou no Google Kubernetes Engine, e o resultado deste processo é novamente escrito no Cloud Storage. Estas cargas de trabalho requerem o dimensionamento do débito de leitura e escrita agregado do Cloud Storage para um cluster de computação com um tempo de inatividade da GPU inferior. Também requerem latências de leitura e escrita baixas, uma vez que são cruciais para reduzir a latência final.
  • Gestão de recursos multimédia: inclui a organização dos seus recursos multimédia para um armazenamento, uma obtenção e uma utilização eficientes.
  • Publicação e distribuição de conteúdo: inclui streaming de multimédia para utilizadores, incluindo serviços de vídeo a pedido (VoD) e streaming em direto. Durante o VoD, quando os utilizadores pedem conteúdo que não está em cache na rede de fornecimento de conteúdo (RFC), o conteúdo é obtido dos contentores do Cloud Storage. Para pedidos de streaming em direto, o conteúdo é escrito no contentor de armazenamento e lido na RFC em simultâneo.

Práticas recomendadas para cargas de trabalho de multimédia

Para ver as práticas recomendadas que se aplicam às cargas de trabalho de multimédia, consulte as secções seguintes.

Transferência de dados

Use o Serviço de transferência de armazenamento para carregar mais de 1 TiB de ficheiros multimédia não processados de uma origem no local, como uma câmara de vídeo ou um armazenamento no local para o Cloud Storage. O Serviço de transferência de armazenamento permite a movimentação de dados perfeita entre sistemas de armazenamento de objetos e ficheiros. Para transferências mais pequenas, escolha o serviço para transferir dados para e do Cloud Storage ou entre sistemas de ficheiros com base no seu cenário de transferência.

Localização do contentor

Para cargas de trabalho que requerem recursos de computação, como produção de multimédia, deve criar contentores nas mesmas regiões ou regiões duplas que os recursos de computação. Este método ajuda a otimizar o desempenho reduzindo as latências de leitura e gravação para as suas cargas de trabalho de processamento, o custo e a largura de banda. Para mais orientações sobre como escolher a localização do contentor, consulte as Considerações sobre a localização do contentor.

Classe de armazenamento

A classe de armazenamento que deve selecionar varia consoante o tipo de carga de trabalho de multimédia. Os tipos de classes de armazenamento recomendados para diferentes cargas de trabalho de multimédia são os seguintes:

  • Para gerir recursos multimédia, como vídeos de arquivo, a classe de armazenamento predefinida de um contentor deve ser o armazenamento de arquivo. Pode especificar uma classe de armazenamento diferente para objetos com diferentes necessidades de disponibilidade ou acesso.
  • Para fluxos de trabalho de produção de multimédia e publicação de conteúdo, uma vez que os dados são lidos com frequência a partir de um contentor do Cloud Storage, deve armazená-los no armazenamento padrão.

Para obter mais orientações sobre a escolha da classe de armazenamento para o seu contentor, consulte o artigo Classe de armazenamento.

Gestão do ciclo de vida dos dados

Para gerir os seus recursos multimédia, deve gerir o ciclo de vida dos objetos dos seus contentores definindo uma configuração do ciclo de vida. Com a funcionalidade de gestão do ciclo de vida de objetos, pode gerir o ciclo de vida dos dados, incluindo a definição de um tempo de vida (TTL) para objetos, a retenção de versões não atuais de objetos e a diminuição das classes de armazenamento de objetos para ajudar a gerir os custos.

Quando os padrões de acesso aos dados são previsíveis, pode definir a configuração do ciclo de vida de um contentor. Para padrões de acesso desconhecidos ou imprevisíveis aos seus dados, pode definir a funcionalidade Autoclass para o seu contentor. Com a classe automática, o Cloud Storage move automaticamente os dados que não são acedidos com frequência para classes de armazenamento mais frias.

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

Para cargas de trabalho de VoD e streaming em direto, o objetivo é evitar erros de reprodução, atrasos no início da reprodução ou buffering durante a reprodução de um vídeo no leitor de vídeo dos utilizadores finais. Estas cargas de trabalho também requerem o dimensionamento das leituras para ter em conta um grande número de visitantes em simultâneo. Em todos os casos, as leituras de tráfego de clientes devem passar por uma RFC.

Para ver as práticas recomendadas que se aplicam às cargas de trabalho de distribuição e publicação de conteúdo, consulte as secções seguintes.

Use a RFC de forma eficaz

A utilização de uma rede de fornecimento de conteúdo (RFC) antes do contentor do Cloud Storage melhora a experiência do utilizador final, uma vez que a RFC coloca conteúdo em cache, reduzindo a latência e aumentando a eficiência da largura de banda. Uma RFC permite-lhe reduzir o custo total de propriedade (TCO) através da redução dos custos de largura de banda, da otimização da utilização de recursos e da melhoria do desempenho. A utilização da RFC de multimédia ajuda a reduzir o TCO para publicar o conteúdo para os utilizadores finais, uma vez que o custo de preenchimento da cache da RFC de multimédia é zero. Pode usar a RFC de conteúdo multimédia como origem de outras RFCs de terceiros. Com outras RFCs, continua a ter alguma redução do CCT quando publica conteúdo a partir desta cache da RFC de multimédia em vez da origem.

Se estiver a usar uma RFC de terceiros, a interligação de RFCs permite que os fornecedores selecionados estabeleçam associações diretas com a rede de limite da Google em várias localizações. O tráfego de saída da sua rede que sai de Google Cloud através de um destes links beneficia da conetividade direta com fornecedores de CDN suportados e é faturado automaticamente com preços reduzidos. Para ver uma lista de fornecedores aprovados, consulte o artigo Fornecedores de serviços aprovados pela Google.

A lista seguinte indica as opções de configuração quando configura uma RFC:

Selecione a localização do escudo de origem

A localização do escudo de origem é uma cache entre a RFC e o Cloud Storage. Se a sua RFC lhe permitir selecionar a localização do escudo de origem, siga as diretrizes da RFC sobre se é recomendável escolher o escudo de origem para estar mais próximo da região do seu contentor do Cloud Storage ou da localização de concentração do tráfego de utilizadores finais. Um escudo de origem é uma medida de proteção que protege o seu servidor de origem contra sobrecarga. As RFCs com proteção de origem ajudam a aumentar a transferência da origem adicionando uma cache adicional entre a origem e a RFC. Por exemplo, a RFC de multimédia oferece uma infraestrutura de limite hierarquizada que foi concebida para minimizar ativamente o preenchimento da cache sempre que possível.

Ative a união de pedidos

Certifique-se de que a redução de pedidos está ativada para a sua RFC. A redução de vários pedidos num único pedido reduz o custo de operação de classe B do Cloud Storage. As RFCs têm caches distribuídas implementadas em todo o mundo, mas oferecem uma forma de reduzir vários pedidos de utilizadores finais a um único pedido de origem. Por exemplo, a RFC de multimédia reduz ativamente vários pedidos de preenchimento da cache iniciados pelo utilizador para a mesma chave de cache num único pedido de origem por nó de limite, reduzindo assim o número de pedidos feitos aos contentores.

Configure o comportamento de repetição na RFC

Certifique-se de que configura a repetição para quaisquer problemas do servidor com o código de resposta HTTP 5xx: 502, 503 e 504 na RFC. As RFCs suportam novas tentativas de origem, o que permite repetir pedidos sem êxito à origem. A maioria das RFCs permite especificar o número de novas tentativas para a origem atual. Para informações sobre como repetir pedidos de origem na RFC de conteúdo multimédia, consulte o artigo Repetir pedidos de origem.

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

Para cargas de trabalho que leiam dados do Cloud Storage que não estejam em cache na RFC, como a publicação de conteúdo e a distribuição de conteúdo do tipo VoD, considere os seguintes fatores ao selecionar uma localização para o seu contentor:

  • Para otimizar em função do custo, os contentores criados numa única região têm o custo de armazenamento mais baixo.
  • Para otimizar em função da disponibilidade, considere o seguinte:
    • Para a maioria das cargas de trabalho de multimédia, é recomendado usar contentores de duas regiões porque replicam os seus objetos em duas regiões para uma melhor disponibilidade.
    • Para exemplos de utilização que requerem publicação de conteúdo e estatísticas com georredundância, use contentores em várias regiões para ter a disponibilidade mais elevada.
  • Para otimizar a latência e reduzir os custos de rede, considere o seguinte:
    • Para VoD, escolha regiões mais próximas da localização da maioria dos seus utilizadores finais ou a região com a maior concentração de tráfego.
    • Durante a stream em direto, os contentores recebem pedidos de escrita de transcodificadores e pedidos de leitura de uma RFC que armazena em cache e distribui o conteúdo aos utilizadores finais. Para um desempenho de streaming melhorado, escolha contentores regionais que estejam localizados juntamente com os recursos de computação usados para a transcodificação.

Otimize a duração dos segmentos de vídeo para streams em direto

Para streams em direto, o tamanho mínimo recomendado do segmento é de dois segundos, uma vez que os segmentos de vídeo curtos são mais sensíveis às latências de escrita de cauda longa. As latências de escrita de cauda longa referem-se às operações de escrita lentas ou atrasadas para conteúdo que é acedido com pouca frequência ou tem um baixo volume de pedidos.

A distância física entre a localização do contentor e a localização de reprodução dos utilizadores finais afeta o tempo de transmissão. Se os seus utilizadores finais estiverem longe da localização do contentor, recomendamos que tenha um tamanho de segmento de vídeo mais longo.

Para oferecer aos visitantes a melhor experiência, recomendamos que use a estratégia de repetição e a cobertura de risco de pedidos para gravações nos transcodificadores, de modo a mitigar as 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 o valor de CPS

Os contentores do Cloud Storage têm uma capacidade de IO inicial de 1000 gravações de objetos por segundo e 5000 leituras de objetos por segundo. Para cargas de trabalho de streams em direto, a diretriz é dimensionar os pedidos gradualmente, começando com 1000 escritas por segundo e 5000 leituras por segundo, e duplicando incrementalmente a taxa de pedidos a cada 20 minutos. Este método permite que o Cloud Storage redistribua a carga por vários servidores e melhora a disponibilidade e a latência do seu contentor, reduzindo as probabilidades de problemas de reprodução.

Para um evento de stream em direto com um QPS mais elevado, deve implementar o dimensionamento no seu contentor pré-aquecendo o contentor ou ativando o espaço de nomes hierárquico no contentor. Antes de implementar o ajuste de escala no seu contentor, deve realizar as seguintes tarefas:

Estime o QPS para a origem

Suponhamos que, para uma stream em direto com um milhão de visitantes, a RFC recebe um milhão de QPS. Partindo do princípio de que a sua RFC tem uma taxa de acertos da cache de 99,0%, o tráfego resultante para o Cloud Storage será de 1%. O QPS será 1% do total de visitantes (um milhão), o que equivale a 10 000 QPS. Este valor é superior à capacidade de IO inicial.

Monitorize as QPS e resolva problemas de dimensionamento

Deve monitorizar o QPS e resolver problemas de erros de escalabilidade. Para mais informações, consulte o artigo Vista geral da monitorização no Cloud Storage . Para monitorizar os pedidos de leitura e escrita, observe o gráfico Total de pedidos de leitura/listagem/obtenção e o gráfico Total de pedidos de escrita, respetivamente, na Google Cloud consola. Se dimensionar o CPS em intervalos mais rapidamente do que as diretrizes de aumento gradual especificadas mencionadas na secção anterior, pode encontrar o erro 429 Demasiados pedidos. Saiba como resolver o erro 429 Demasiados pedidos.

As secções seguintes descrevem como dimensionar o seu limite de pedidos para um QPS mais elevado depois de ter estimado o QPS para a origem.

Implemente o dimensionamento de CPS no seu contentor pré-aquecendo-o

Pode acelerar o processo de escalabilidade antes de um evento de streaming em direto preparando o seu contentor. Antes do evento de streaming em direto, gere tráfego sintético para o seu contentor que corresponda ao máximo de QPS esperado que o servidor de origem da RFC vai receber para o evento, mais uma margem adicional de 50% que tenha em conta a taxa de acertos na cache esperada da sua RFC. Por exemplo, se estimou que o QPS para a sua origem é de 10 000, o tráfego simulado deve segmentar 15 000 pedidos por segundo para preparar a sua origem para o evento.

Para este tráfego simulado, pode usar os ficheiros de feeds em direto do evento anterior, como segmentos e manifesto, ou ficheiros de teste. Certifique-se de que tem ficheiros distintos durante todo o processo de aquecimento.

Ao gerar este tráfego simulado, siga uma abordagem de escalabilidade gradual, começando com 5000 pedidos por segundo e aumentando progressivamente até atingir o seu objetivo. Atribua tempo suficiente antes do evento para alcançar o carregamento estimado. Por exemplo, atingir 15 000 pedidos por segundo, duplicando a carga a cada 20 minutos a partir de 5000 pedidos por segundo iniciais, demora aproximadamente 30 minutos.

O servidor de origem mantém a capacidade até o tráfego ser consistente. A capacidade do servidor de origem diminui gradualmente até ao nível de base ao longo de 24 horas. Se o seu servidor de origem tiver lacunas de várias horas entre os eventos de stream em direto, recomendamos que simule o tráfego antes de cada evento.

Use contentores com espaço de nomes hierárquico ativado para um valor de CPS inicial elevado

Os contentores do Cloud Storage com o espaço de nomes hierárquico ativado oferecem até oito vezes o QPS inicial em comparação com os contentores sem HNS. O QPS inicial mais elevado facilita o dimensionamento de cargas de trabalho com grande volume de dados e oferece um débito melhorado. Para obter informações sobre as limitações em contentores com o espaço de nomes hierárquico ativado, consulte Limitações.

Evite nomes sequenciais para segmentos de vídeo para dimensionar QPS

Com o dimensionamento de QPS, os pedidos são redistribuídos por vários servidores. No entanto, pode encontrar gargalos de desempenho quando todos os objetos usam um prefixo não aleatório ou sequencial. A utilização de nomes completamente aleatórios em vez de nomes sequenciais oferece-lhe a melhor distribuição de carga. No entanto, se quiser usar números sequenciais ou datas/horas como parte dos nomes dos objetos, introduza aleatoriedade nos nomes dos objetos adicionando um valor hash antes do número sequencial ou da data/hora. Por exemplo, se o nome do objeto original que quer usar for my-bucket/2016-05-10-12-00-00/file1, pode calcular o hash MD5 do nome do objeto original e adicionar os primeiros seis carateres do hash como um prefixo ao nome do objeto. O novo objeto torna-se my-bucket/2fa764-2016-05-10-12-00-00/file1. Para mais informações, consulte Use uma convenção de nomenclatura que distribua a carga uniformemente pelos intervalos de chaves. Se não conseguir evitar a nomenclatura sequencial para segmentos de vídeo, use contentores com o espaço de nomes hierárquico ativado para obter um QPS mais elevado.

Use diferentes contentores para cada transmissão em direto

Para streams em direto simultâneas, a utilização de diferentes contentores para cada stream em direto ajuda a dimensionar a carga de leitura e escrita de forma eficaz sem atingir os limites de E/S para o contentor. A utilização de diferentes intervalos para cada stream em direto diminui as latências atípicas grandes devido a atrasos no dimensionamento.

O que se segue?