Resumo

  • Os incidentes do Cloud Storage em 8 e 9 de outubro somaram 18 horas e 11 minutos em us-central1 e us-central1-b; os sintomas divulgados se concentraram nas gravações.
  • O Google atribuiu o primeiro episódio a uma otimização que ignorou a capacidade no roteamento e a recorrência a uma reversão incompleta; o relatório não cita clientes nem quantifica perdas.

Quando há uma interrupção de armazenamento em nuvem, a discussão costuma começar pelo lugar onde ficam as cópias. O relatório do Google aponta outra pergunta: por qual caminho passa uma solicitação de gravação antes de se tornar um objeto armazenado? Em 8 de outubro, clientes do Cloud Storage que usavam us-central1 enfrentaram maior latência e mais erros de gravação por 12 horas e 30 minutos. O problema retornou no dia seguinte na zona us-central1-b e durou 5 horas e 41 minutos. O total informado pelo Google é de 18 horas e 11 minutos, mas foram dois episódios separados por uma recuperação, não uma interrupção contínua de 18 horas.

Os sintomas públicos são específicos. Segundo o Google, os clientes viram principalmente respostas HTTP 503 UNAVAILABLE em operações WriteObject e tempos limite no cliente; as gravações concluídas também tiveram latência muito maior. O relatório final afirma que outras regiões do Cloud Storage e outros serviços do Google Cloud não foram afetados por esse evento específico. Uma seção preliminar mencionava impacto pequeno em leituras, mas o resumo final não quantifica esse efeito. O registro sustenta, portanto, um problema delimitado no caminho de gravação de uma região e, durante a recorrência, de uma zona.

Não prova que todos os clientes da região foram afetados, que todas as gravações falharam ou que objetos armazenados foram perdidos.

O Google situa o primeiro gatilho em uma atualização de configuração de classificação do tráfego, concebida para lidar com restrições locais de capacidade. A otimização contornou a lógica habitual de roteamento sensível à capacidade. Uma fração pequena dos nós de armazenamento, com pouca capacidade de atendimento, recebeu então uma parcela desproporcional do tráfego de escrita. Os recursos desses nós se esgotaram; os serviços de ingestão de objetos começaram a expirar; e as solicitações encaminhadas a eles ficaram lentas ou não foram concluídas.

Um problema separado no banco de dados também provocou erros de processamento de metadados durante parte do primeiro intervalo. A cadeia é composta: uma decisão de distribuição alterou o caminho dos pedidos, concentrou trabalho e coincidiu com uma falha secundária de metadados.

A recorrência no dia seguinte é o ponto mais relevante para a operação. O Google a atribui a uma reversão incompleta de um recurso de planejamento de uploads, que rompeu o balanceamento de carga e sobrecarregou nós menores. A primeira mitigação não havia restaurado totalmente o estado de segurança anterior. Isso não prova que toda reversão seja pouco confiável nem que tenha ocorrido uma falha regional mais ampla. Mostra, porém, que encerrar um incidente e restaurar a configuração são decisões diferentes: o serviço pode parecer recuperado enquanto uma alteração residual mantém aberto o mesmo caminho de falha.

A descrição da recuperação também revela uma limitação prática. O Google tentou primeiro acrescentar capacidade de emergência, mas afirma que limites regionais de capacidade impediram essa alternativa. Os engenheiros drenaram tráfego dos nós mais sobrecarregados, desativaram ou reverteram a otimização, desfizeram uma atualização distinta do banco de dados e redirecionaram as solicitações. Depois que o tráfego e a utilização se estabilizaram, os nós drenados voltaram ao serviço.

Capacidade extra nem sempre é uma saída de emergência; roteamento, isolamento de tráfego e precisão da reversão podem ser os controles disponíveis quando a região não pode simplesmente crescer sob demanda.

A arquitetura publicada do Cloud Storage ajuda a enquadrar o evento sem extrapolar. O Google diz que buckets regionais armazenam dados de forma redundante em pelo menos duas zonas da região escolhida. Buckets de duas regiões e multirregionais replicam entre regiões de modo assíncrono depois que a gravação inicial é armazenada em uma região e duas zonas. Para essas localizações mais amplas, o Google descreve atendimento automático por outra região durante uma falha regional, mas ressalta que a replicação é assíncrona. A documentação de consistência diz que um objeto fica imediatamente disponível para leitura após uma gravação bem-sucedida.

Nada disso informa quais localizações de bucket os clientes afetados usavam.

Essa fronteira não pode ser apagada. O relatório não diz que a replicação multirregional falhou, que houve perda de dados ou que cópias geográficas ficaram indisponíveis. O que descreve é um gargalo no caminho que aceita novas gravações. A redundância geográfica pode reduzir a exposição a uma falha ligada a um lugar, mas a arquitetura também precisa lidar com controles de software e capacidade compartilhados pelo serviço de escrita. Resiliência de armazenamento não é uma propriedade única: durabilidade das cópias, ingestão, processamento de metadados, leitura e recuperação da aplicação têm dependências distintas.

As medidas preventivas anunciadas pelo Google acompanham essa cadeia. A empresa diz que validará mudanças de balanceamento em regiões menores antes de implantá-las em regiões grandes e muito utilizadas; que fará os limites de capacidade prevalecerem para impedir que a lógica de tráfego contorne as salvaguardas de reserva; e que melhorará a movimentação interna de dados em células de armazenamento altamente utilizadas. São ações futuras descritas pelo Google, não controles cuja conclusão tenha sido verificada de modo independente.

O registro público não informa resultados de testes, volume de solicitações atingidas, clientes, distribuição de localizações de buckets ou perdas medidas. A conclusão possível é mais restrita: uma otimização de roteamento e uma reversão incompleta atravessaram duas vezes a proteção local de capacidade; a aplicabilidade da redundância geográfica continua sendo outra pergunta.

Fontes: relatório final do Google, disponibilidade e durabilidade do Cloud Storage, localizações dos buckets, consistência, estratégia de novas tentativas.