Gerenciamento das atualizações de serviços

As atualizações de serviços do MemoryDB são liberadas regularmente. Se tiver um ou mais clusters qualificados para essas atualizações de serviços, você receberá notificações por e-mail, SNS, Personal Health Dashboard (PHD), e Amazon CloudWatch Events quando as atualizações forem lançadas. As atualizações também são exibidas na página Atualizações de serviços no console do Atualizações de serviços. Usando este painel, é possível visualizar todas as atualizações de serviço e os status em relação à sua frota do MemoryDB.

Você controla quando aplicar uma atualização antes do início da atualização automática. Recomendamos veementemente que você aplique qualquer atualização do tipo security-update para garantir que o seu MemoryDB esteja sempre atualizado com os patches de segurança atuais.

As seguintes seções analisam essas opções em detalhes.

Visão geral da manutenção gerenciada e das atualizações de serviço do Amazon MemoryDB

Atualizamos frequentemente nossa frota do MemoryDB, com patches e upgrades aplicados a instâncias de forma contínua. Fazemos isso de duas formas:

Essas atualizações de serviço e manutenções são necessárias para aplicar upgrades que fortalecem a segurança, a confiabilidade e o desempenho operacional.

A manutenção gerenciada contínua acontece de tempos em tempos e diretamente nas janelas de manutenção, sem exigir nenhuma ação de sua parte. É importante observar que as janelas de manutenção são obrigatórias para todos os clientes e não há opção de não aderir a esse serviço. É altamente recomendável evitar atividades críticas ou importantes durante essas janelas de manutenção estabelecidas. Além disso, esteja ciente de que atualizações críticas não podem ser ignoradas para garantir a segurança e o desempenho ideal do sistema.

As atualizações de serviço oferecem flexibilidade para que você as aplique por conta própria. Elas têm um horário programado e podem ser movidas para a janela de manutenção para serem aplicadas por nós após o vencimento da data prevista.

Você pode gerenciar as atualizações aplicando-as o mais rápido possível ou substituindo os nós, já que as atualizações são aplicadas automaticamente durante a substituição. Não haverá atividade de atualização durante as janelas de manutenção futuras se as atualizações já tiverem sido aplicadas a todos os nós anteriores.

Atualizações de serviço

Atualizações de serviço no MemoryDB permite aplicar determinadas atualizações de serviço a seu critério. Essas atualizações podem ser dos seguintes tipos: patches de segurança ou pequenas atualizações de software. Essas atualizações ajudam a fortalecer a segurança, a confiabilidade e o desempenho operacional dos seus clusters.

O valor dessas atualizações de serviço é que é possível controlar quando aplicar a atualização (por exemplo, você pode adiar a aplicação de atualizações de serviço quando há um evento comercial importante que exija disponibilidade 24 horas por dia, 7 dias por semana dos clusters do MemoryDB).

Se tiver um ou mais clusters qualificados para essas atualizações de serviço, você receberá notificações por e-mail, pelo Amazon SNS, pelo AWS Health Dashboard e por eventos do Amazon CloudWatch Events quando as atualizações forem lançadas. As atualizações também são exibidas na página Atualizações de serviços no console do Atualizações de serviços. Usando este painel, é possível visualizar todas as atualizações de serviço e os status em relação à sua frota do MemoryDB.

Você controla quando aplicar uma atualização antes do início da atualização automática. Recomendamos veementemente que você aplique qualquer atualização do tipo security-update para garantir que o seu MemoryDB esteja sempre atualizado com os patches de segurança atuais.

O cluster pode fazer parte de diferentes atualizações de serviço. A maioria das atualizações não exige que você as aplique separadamente. A aplicação de uma atualização ao cluster marcará as outras atualizações como concluídas, sempre que aplicável. Talvez seja necessário aplicar várias atualizações ao mesmo cluster separadamente caso o status não mude para “concluído” automaticamente.

Impacto e tempo de inatividade das atualizações de serviço

Quando você ou o Amazon MemoryDB aplicam uma atualização de serviço a um ou mais clusters do MemoryDB, ela é aplicada a no máximo um nó por vez em cada fragmento até que todos os clusters selecionados sejam atualizados. Os nós que estão sendo atualizados apresentarão um tempo de inatividade de alguns segundos, enquanto o restante do cluster continuará fornecendo tráfego.

Como a substituição de um nó afeta a aplicação? – Para nós do MemoryDB, o processo de substituição foi projetado para garantir durabilidade e disponibilidade. Para clusters de nó único do MemoryDB, este cria dinamicamente uma réplica, restaura os dados de nossos componentes de durabilidade e, depois, faz failover para ela. Para grupos de replicação que consistem em vários nós, o MemoryDB substitui as réplicas existentes e sincroniza os dados de nossos componentes de durabilidade com as novas réplicas. O MemoryDB só é Multi-AZ quando há mais de um nó, portanto, nesse cenário, a substituição do primário aciona um failover em uma réplica de leitura. As substituições planejadas de nós são concluídas enquanto o cluster continua atendendo às solicitações de escrita recebidas. Se houver apenas um nó, o MemoryDB substituirá o primário e, depois, sincronizará os dados de nossos componentes de durabilidade. O nó primário não fica disponível durante esse período, levando a uma interrupção mais longa da gravação.

Quais práticas recomendadas devo seguir para uma experiência de substituição tranquila e para minimizar a perda de dados? – No MemoryDB, os dados são altamente duráveis e a perda de dados não é esperada, mesmo em implementações de um único nó. No entanto, é recomendável implementar estratégias Multi-AZ e de backup para minimizar as chances de perda no caso improvável de falha. Para uma experiência de substituição tranquila, tentamos substituir apenas nós suficientes do mesmo cluster por vez para manter o cluster estável. É possível provisionar réplicas primárias e de leitura em diferentes zonas de disponibilidade ativando a Multi-AZ. Nesse caso, quando um nó é substituído, o perfil principal fará failover para uma réplica no fragmento. Esse fragmento agora atenderá ao tráfego e os dados serão restaurados a partir de seus componentes de durabilidade. Se a configuração incluir somente uma réplica primária e uma única por fragmento, recomendamos adicionar outras réplicas antes da aplicação de patches. Isso evitará a redução da disponibilidade durante o processo de aplicação de patches. Recomendamos programar a substituição durante um período com baixo tráfego de gravação de entrada.

Quais práticas recomendadas de configuração do cliente devo seguir para minimizar a interrupção da aplicação durante a manutenção? – No MemoryDB, a configuração do modo de cluster está sempre ativada, o que fornece a melhor disponibilidade durante operações gerenciadas ou não gerenciadas. Os endpoints individuais dos nós de réplica podem ser usados para todas as operações de leitura. No MemoryDB, o failover automático está sempre ativado no cluster, o que significa que o nó primário pode mudar. Portanto, a aplicação deve confirmar o perfil do nó e atualizar todos os endpoints de leitura para garantir que você não esteja causando uma carga excessiva no primário. Da mesma forma, evite sobrecarregar as réplicas com solicitações de leitura durante as janelas de manutenção. Uma forma de fazer isso é garantir que você tenha pelo menos duas réplicas de leitura para evitar qualquer interrupção de leitura durante a manutenção.

É importante testar as aplicações de clientes para confirmar se eles estão em conformidade com o protocolo Redis/Valkey Cluster e se as solicitações podem ser redirecionadas entre os nós adequadamente. É aconselhável implementar estratégias de recuo e repetição para evitar sobrecarregar os nós do MemoryDB durante as atividades de manutenção e substituição.

Reagendamento: você pode adiar a atualização do serviço alterando a janela de manutenção. A atualização programada só será aplicada ao cluster se a data programada corresponder à janela de manutenção do cluster. Depois que você alterar a janela de manutenção e a data programada tiver passado, a atualização do serviço será reprogramada para a janela recém-especificada nas semanas seguintes. Você receberá uma nova notificação uma semana antes da nova data.

A segurança na AWS é uma responsabilidade compartilhada. É altamente recomendável aplicar a atualização o quanto antes.

Optar por não receber atualizações de serviço: você pode optar por não receber uma atualização de serviço verificando o valor do atributo “Data de início da atualização automática”. Se o valor do atributo “Data de início da atualização automática” de uma atualização de serviço for definido, o MemoryDB agendará a atualização do serviço para todos os clusters restantes para a próxima janela de manutenção, e não será possível optar por não atualizar. Ainda assim, se você aplicar a atualização de serviço aos clusters restantes antes da janela de manutenção, o MemoryDB não reaplicará a atualização do serviço durante a janela de manutenção. Para obter mais informações, consulte Como aplicar as atualizações de serviço.

Por que as atualizações de serviço não podem ser aplicadas diretamente pelo MemoryDB durante as janelas de manutenção? – Observe que o objetivo das atualizações de serviço é oferecer flexibilidade sobre quando aplicá-las. Os clusters que não participam dos programas de conformidade compatíveis com o MemoryDB podem optar por não aplicar essas atualizações ou por aplicá-las com uma frequência reduzida ao longo do ano. No entanto, é recomendável aplicar as atualizações para manter a conformidade com os regulamentos. Isso vale somente quando o atributo “Data de início da atualização automática” de uma atualização de serviço não está atribuído. Para obter mais informações, consulte Validação de conformidade para MemoryDB.

Como as atualizações aplicadas na janela de manutenção são diferentes das atualizações de serviço? – As atualizações aplicadas por meio da manutenção gerenciada contínua são programadas diretamente em suas janelas de manutenção, sem a necessidade de nenhuma ação de sua parte. As atualizações de serviço são programadas e permitem que você controle quando deseja aplicá-las pela “Data de início da atualização automática”. Se ainda não forem aplicadas até essa data, o MemoryDB pode agendá-las na sua janela de manutenção.

Atualizações da manutenção gerenciada contínua

Essas atualizações são obrigatórias e são aplicadas diretamente nas janelas de manutenção sem a necessidade de nenhuma ação de sua parte. Essas atualizações são distintas das oferecidas pelas atualizações de serviço.

Tempo de inatividade e impacto da manutenção contínua

Quanto tempo demora a substituição de um nó? – A substituição normalmente é concluída em 30 minutos. A substituição pode levar mais tempo em determinadas configurações de instância e padrões de tráfego.

Como a substituição de um nó afeta a aplicação? – As atualizações contínuas de manutenção gerenciada são aplicadas da mesma forma que as “atualizações de serviço”, por meio da substituição de nós. Consulte mais detalhes na seção acima Tempo de inatividade e impacto das atualizações de serviço.

Como gerenciar as substituições de nós por conta própria? – Você tem a opção de gerenciar essas substituições a qualquer momento antes da janela agendada para a substituição do nó. Se optar por gerenciar a substituição por conta própria, você poderá realizar várias ações, dependendo do seu caso de uso.

Como posso saber mais sobre as próximas substituições programadas? – Você deve receber uma notificação de integridade no AWS Health Dashboard. Além disso, você pode encontrar o status de diferentes atualizações de serviços com a API DescribeServiceUpdates. Observe que nos esforçamos para notificar proativamente os clientes sobre substituições previsíveis. No entanto, em casos excepcionais, como falhas imprevisíveis, pode haver substituições sem aviso prévio.

Posso alterar a manutenção programada em um horário mais adequado? – Sim, você pode adiar a manutenção programada para um horário mais adequado alterando a janela de manutenção.

Por que estão sendo feitas essas substituições de nós? – Essas substituições são necessárias para aplicar as atualizações obrigatórias de software ao host subjacente. As atualizações ajudam a fortalecer nossa segurança, confiabilidade e desempenho operacional.

Essas substituições afetam meus nós em várias zonas de disponibilidade e clusters de diferentes regiões ao mesmo tempo? – As substituições podem ser executadas em várias zonas de disponibilidade ou regiões em paralelo, dependendo da janela de manutenção dos clusters.