Esta página foi útil?
Seus comentários sobre este conteúdo são importantes. Queremos saber sua opinião.
Comentários adicionais?
1500 caracteres restantes
À prova de falhas: orientação para arquiteturas resilientes na nuvem

À prova de falhas: orientação para arquiteturas resilientes na nuvem

Atualizado: junho de 2014

Autores: Marc Mercuri, Ulrich Homann, Mark Simms, Jason Wescott e Andrew Townhill

Revisores: Michael Thomassy, Curt Peterson, Stuart Ozer, Fran Dougherty, Tim O’Brien, Hatay Tuna, Patrick Butler Monterde, Mark Kottke, Lewis Curtis, William Bellamy

Data da publicação: junho de 2014

À prova de falhas adjetivo. Algo criado para funcionar automaticamente para evitar a quebra de um mecanismo, sistema ou algo semelhante.

Indivíduos - seja no contexto de funcionários, cidadãos ou consumidores - demandam acesso instantâneo aos serviços de aplicativo, computação e dados. O número de pessoas conectadas e os dispositivos que elas usam para se conectarem a esses serviços estão crescendo cada vez mais. Em um mundo de serviços sempre ativos, os sistemas que oferecem suporte a eles devem ser criados para estarem disponíveis e serem resilientes.

Esses serviços serão implantados nos ambientes de nuvem que são preenchidos com mercadorias em configurações predefinidas. Historicamente, você pode ter comprado um hardware superior para escalar verticalmente, em ambientes de nuvem, assim, você deve escalar horizontalmente. Você mantém os custos baixos para esses ambientes de nuvem usando um hardware de mercadoria. O hardware de mercadoria falhará e a nuvem precisará de arquitetura para falha de compreensão. Historicamente, você pode ter focado em prevenir falhar e otimizar "Tempo Médio Entre Falhas". Nesse novo ambiente, o foco muda para um "Tempo Médio para Restauração com Impacto Mínimo".

É muito provável que esses serviços desenvolvidos por você sejam compostos. Eles serão compostos de uma ou mais plataformas de terceiros ou de primeiros e serviços de provedor de terceiros. Esses serviços serão construídos em infraestrutura de nuvem que falhará. A arquitetura também deve assumir que os serviços consumidos também falharão. Como na arquitetura de infraestrutura, o design de arquitetura de aplicativo deve compreender falhas.

A iniciativa à prova de falhas dentro da Microsoft é destinada a fornecer diretrizes gerais para criar arquiteturas de nuvem resilientes, diretrizes para implementar essas arquiteturas em tecnologias da Microsoft e receitas para implementar essas arquiteturas para cenários específicos. Os autores deste documento são membros da divisão Empresa + Nuvem da Microsoft, Computação Confiável e Serviços de Consultoria da Microsoft.

Este documento destaca as considerações de arquitetura para criar sistemas escalonáveis e resilientes.

Este documento está organizado nas seguintes seções:

  • Decompor o aplicativo por carga de trabalho: definir como uma abordagem voltada para cargas de trabalho fornece um melhor controle sobre custos, maior flexibilidade na escolha das tecnologias mais adequadas para a carga de trabalho e permite uma abordagem mais ajustada à disponibilidade e à resiliência.

  • Estabeleça um modelo do ciclo de vida: estabelecer um modelo de ciclo de vida de aplicativo ajuda a definir o comportamento esperado de um aplicativo em produção e fornecerá requisitos e ideias para a arquitetura geral.

  • Estabelecer um modelo de disponibilidade e um plano: o modelo de disponibilidade identifica o nível de disponibilidade que é esperado para sua carga de trabalho. Isso é importante porque informará muitas das decisões que você tomará ao estabelecer seu serviço.

  • Identificar Pontos da Falha, Modos de Falha e Efeitos de Falha: para criar uma arquitetura resiliente, é importante entender e identificar pontos e modos de falha. Especificamente, fazer uma busca pró-ativa para entender e documentar o que pode causar uma interrupção estabelecerá um esboço que pode ser usado na análise e no planejamento.

  • Padrões e considerações de resiliência: esta seção representa a maioria do documento e contém considerações importantes em serviços de computação, armazenamento e plataforma. Essas considerações têm um foco nas práticas comprovadas para entregar um aplicativo íntegro em considerações importantes em serviços de computação, armazenamento e plataforma.

  • Design para operações: em um mundo que espera que os serviços estejam "sempre ativos", é importante que eles sejam criados para operações. Esta seção aborda as práticas comprovadas para criar operações que abrangem o ciclo de vida, incluindo o estabelecimento de um modelo de integridade para implementar a telemetria para visualizar essas informações de telemetria para os públicos de operações e desenvolvedores.

Aplicativos que são geralmente compostos por várias cargas de trabalho.

As cargas de trabalho diferentes podem ter requisitos diferentes, níveis diferentes de importância para o negócio e níveis diferentes de análise financeira associados a eles, e isso ocorre com frequência. Ao decompor um aplicativo em cargas de trabalho, uma organização obtém uma flexibilidade valiosa. Uma abordagem voltada para cargas de trabalho fornece melhor controle sobre o custo, maior flexibilidade na escolha das tecnologias mais adequadas para a carga de trabalho, abordagens específicas de cargas de trabalho para obter disponibilidade e segurança, flexibilidade e agilidade para adicionar e implantar novos recursos etc.

Ao considerar a resiliência, é útil fazer isso no contexto dos cenários. A seguir são exibidos alguns exemplos de cenários típicos:

  • Serviço de Dados de Esportes

    O serviço de dados do cliente fornece informações de esportes. O serviço tem duas cargas de trabalho primárias. A primeira fornece estatísticas para o jogador e as equipes. A segunda fornece pontuações e comentários para os jogos que estão em andamento no momento.

  • Site de Comércio Eletrônico

    Uma loja online vende produtos por meio de um site em um modelo bem-estabelecido. O aplicativo tem várias cargas de trabalho, com a mais popular sendo “pesquisa e procura” e “check-out.”

  • Social

    Um site social de alto perfil permite que membros de uma comunidade se envolvam em experiências compartilhadas em fóruns, conteúdo gerado pelo usuário e eventualmente jogos. O aplicativo tem várias cargas de trabalho, incluindo registro, pesquisa e procura, interação social, jogos, email etc.

  • Web

    Uma organização deseja fornecer uma experiência para os clientes pelo seu site. O aplicativo precisa entregar experiências em navegadores com base em PC, assim como os tipos de dispositivos móveis populares (telefone, tablet). O aplicativo tem várias cargas de trabalho que incluem registro, pesquisa e procura, publicação de conteúdo, comentários sociais, moderação, jogos etc.

Vamos analisar de perto um dos cenários e decompô-lo em cargas de trabalho filhas. Um site de comércio eletrônico, pode ter várias cargas de trabalho – procura & pesquisa, checkout & gerenciamento, registro de usuário, conteúdo gerado pelo usuário (revisões e avaliações), personalização etc.

As definições de exemplo de duas das principais cargas de trabalho para o cenário seriam:

  • Procura e pesquisa permite que os clientes naveguem em um catálogo de produtos, procurem itens específicos e talvez gerenciem cestas ou listas de desejos. Essa carga de trabalho pode ter atributos como acesso de usuário anônimo, tempos de resposta inferiores a um segundo e caching. A degradação de desempenho pode ocorrer na forma de tempos de resposta maiores com carga de usuário inesperada ou interrupções tolerantes a aplicativos para atualizações do estoque de produtos. Nesses casos, o aplicativo pode escolher continuar fornecendo informações do cache.

  • Checkout e gerenciamento ajuda os clientes a fazer, acompanhar e cancelar pedidos; selecionar métodos de entrega e opções de pagamento; e gerenciar perfis. Essa carga de trabalho pode ter atributos como o acesso seguro, processamento em fila, acesso a gateways de pagamento de terceiros e conectividade para sistemas locais de back-end. Embora o aplicativo possa tolerar um maior tempo de resposta, ele não pode tolerar perda de pedidos; consequentemente, ele é criado para garantir que os pedidos do cliente sejam sempre aceitos e capturados, independentemente de o aplicativo poder ou não processar o pagamento ou providenciar a entrega.

Um modelo de ciclo de vida de aplicativo define o comportamento esperado de um aplicativo quando ele está operacional. Em fases e momentos diferentes, um aplicativo colocará demandas diferentes no sistema se estiver em um nível funcional ou de escala. Os modelos de ciclo de vida refletirão isto.

As cargas de trabalho devem ter modelos de ciclo de vida definidos para todos os cenários relevantes e aplicáveis em níveis apropriados de granularidade. Os serviços podem ter diferenças de ciclo de vida horárias, diárias, semanais ou sazonais que, quando modeladas, identificam a capacidade, a disponibilidade, o desempenho e os requisitos específicos de escalabilidade ao longo do tempo.

À prova de falhas_03

Figura 1. Exemplos de ciclo de vida em diferentes indústrias e cenários

Sempre existirão períodos de tempo que possuem seus próprios ciclos de vida, como:

  • Um especial relacionado a uma demanda de picos durante um período das férias.

  • Aumento de envios de declarações de imposto de renda antes da data de vencimento.

  • Janelas de tempo de deslocamento na manhã e à tarde.

  • O envio de avaliações de resultados de funcionário no final do ano.

Muitas organizações conhecem esses tipos de cenários e os ciclos de vida específicos de cenário relacionados.

A decomposição permite que você tenha diferentes Contratos de Nível de Serviço (SLAs) internos no nível de carga de trabalho. Um exemplo disso é o exemplo de API de Dados de Esportes que possuía um SLA meta de 99,99%. Entretanto, você pode dividir essa API em duas cargas de trabalho: “Live Scores + Commentary” e “Team, Player e League Statistics”

Para carga de trabalho “Live Scores + Commentary”, o ciclo de vida tem um padrão "ativo e inativo". Entretanto, a disponibilidade de "Team, Player e League Statistics” será constante. A decomposição por carga de trabalho permite a você ter SLAs personalizados para as necessidades de disponibilidade da carga de trabalho agregada do serviço composto.

À prova de falhas_12

Figura 2

Assim que o modelo do ciclo de vida é identificado, a próxima etapa é estabelecer um modelo de disponibilidade e um plano. Um modelo de disponibilidade para o seu aplicativo identifica o nível de disponibilidade que é esperado para sua carga de trabalho. Isso é importante porque informará muitas das decisões que você tomará ao estabelecer seu serviço.

Há vários pontos a considerar e várias ações possíveis que podem ser executadas.

Ao desenvolver a disponibilidade do plano, é importante entender qual é a disponibilidade desejada para o seu aplicativo, as cargas de trabalho no aplicativo e os serviços que são utilizados na entrega dessas cargas de trabalho.

Entender o ciclo de vida da carga de trabalho ajudará você a escolher o SLA que deseja fornecer. Um SLA pode não ser fornecido publicamente para seu serviço. No entanto, sua arquitetura deve destinar uma linha de base disponível que você aspirará atender.

Dependendo do tipo de solução que estiver construindo, existirá um número de considerações e opções para fornecer alta disponibilidade. Os provedores de serviço comercial não oferecem SLAs de 100%, pois a complexidade e o custo para fornecer esse nível de SLA são impraticáveis ou não lucrativos. A decomposição de seu aplicativo para o nível de carga de trabalho permite a você tomar decisões e implantar abordagens para disponibilidade. Entregar 99,99% de tempo de ativação para o aplicativo inteiro pode ser impraticável, mas para uma carga de trabalho em um aplicativo, pode ser exequível.

Mesmo no nível de carga de trabalho, você pode não escolher implementar cada opção. O que você escolhe implementar ou não é determinado por seus requisitos. Seja quais forem as opções que você escolher, faça escolhas conscientes que informem e que considerem todas as opções.

A autonomia refere-se à independência e à diminuição de dependência entre as partes que compõem o serviço como um todo. A dependência de componentes, dados e entidades externas deve ser verificada ao criar serviços, com a preocupação de transformar funcionalidades relacionadas em unidades independentes dentro do serviço. Fazer isso fornece a agilidade para atualizar versões de unidades independentes diferentes, um controle mais preciso de escalar essas unidades independentes etc.

As arquiteturas de carga de trabalho geralmente são compostas por componentes autônomos que não dependem de intervenção manual, e não falham quando as entidades das quais dependem não estão disponíveis. Os aplicativos compostos de partes independentes são:

  • disponíveis e operacionais

  • flexíveis e facilmente recuperáveis

  • baixo risco para estados de falha não íntegros

  • fáceis de dimensionar por meio de replicação

  • menos prováveis de exigir intervenções manuais

Essas unidades independentes geralmente aproveitarão a comunicação assíncrona, o processamento de dados baseado em pull e a automação para assegurar o serviço contínuo.

A perspectiva é de que o mercado evolua até um ponto em que haverá interfaces padronizadas para determinados tipos de funcionalidade para cenários verticais e horizontais. Quando essa visão futura for realizada, um provedor de serviços poderá se envolver com provedores diferentes e implementações ligeiramente diferentes que resolvam o trabalho designado da unidade autônoma. Para serviços contínuos, isso será feito de modo autônomo e será baseado em políticas.

Da mesma forma que a autonomia é uma aspiração, a maioria dos serviços utilizará uma dependência de um serviço de terceiros, mesmo que seja apenas para hospedagem. É obrigatório entender os SLAs desses serviços dependentes e incorporá-los ao seu plano de disponibilidade.

Esta seção identifica os tipos diferentes dos SLAs que podem ser relevantes para seu serviço. Para cada um desses tipos de serviço, há considerações e abordagens importantes, assim como as perguntas que devem ser feitas.

Serviços da plataforma da nuvem pública

Os serviços fornecidos por uma plataforma comercial de computação em nuvem, como computação ou armazenamento, têm os acordos de nível de serviço criados para acomodar uma variedade de clientes em escala significativa. Dessa forma, os SLAs para esses serviços não são negociáveis. Um provedor pode fornecer níveis estratificados de serviço com diferentes SLAs, mas essas camadas serão não-negociáveis. O provedor de serviço usa níveis de serviço em camadas com SLAs diferentes para fornecer uma qualidade previsível de serviço.

Questões a serem consideradas para este tipo de serviço:

  • Este serviço permite apenas um determinado número de chamadas para a API de serviço?

  • Este serviço coloca limite na frequência de chamadas para a API de serviço?

  • O serviço limita o número de servidores que podem chamar a API de serviço?

  • Quais são as informações disponíveis publicamente sobre como o serviço entrega sua promessa de disponibilidade?

  • Como esse serviço comunica seu status de integridade?

  • Qual é o SLA (contrato de nível de serviço) indicado?

  • Quais são os serviços de plataforma equivalentes fornecidos por outros terceiros?

Serviços "gratuitos" de terceiros

Muitos terceiros fornecem serviços “gratuitos” à comunidade. Para organizações do setor privado, isso em grande parte é feito para ajudar a criar um ecossistema de aplicativos em torno do produto ou serviço principal. Para o setor público, isso é feito para fornecer dados para a sociedade e as empresas que têm claramente pago por sua coleção com o financiamento do governo por meio de impostos.

A maioria desses serviços não virá com acordos de nível de serviço; portanto, a disponibilidade não é garantida. Quando os SLAs são fornecidos, eles geralmente são voltadas para as restrições que são colocadas em aplicativos de consumo e os mecanismos que serão usados para os impor. Os exemplos de restrições podem incluir limitar ou colocar sua solução em uma lista de bloqueios se ela exceder um determinado número de chamadas de serviço, exceder um determinado número de chamadas em um determinado período (x por minuto) ou exceder o número de servidores permitidos que chamam o serviço.

Questões a serem consideradas para este tipo de serviço:

  • Este serviço permite apenas um determinado número de chamadas para a API de serviço?

  • Este serviço coloca limites na frequência de chamadas para a API de serviço?

  • O serviço limita o número de servidores que podem chamar a API de serviço?

  • Quais são as informações disponíveis publicamente sobre como o serviço entrega sua promessa de disponibilidade?

  • Como esse serviço comunica seu status de integridade?

  • Qual é o SLA (contrato de nível de serviço) indicado?

  • Este é um serviço de mercadoria em que a funcionalidade e/ou os dados necessários estão disponíveis de vários provedores de serviços?

  • Se for um serviço de mercadoria, a interface é interoperável entre outros provedores de serviços (diretamente ou por meio de uma camada de abstração disponível)?

  • Quais são os serviços de plataforma equivalentes fornecidos por outros terceiros?

Serviços comerciais de terceiros

Os serviços comerciais fornecidos por terceiros têm os acordos de nível de serviço que são criados para acomodar as necessidades de clientes pagantes. Um provedor pode fornecer níveis estratificados de SLAs com diferentes níveis de disponibilidade, mas esses SLAs serão não-negociáveis.

Questões a serem consideradas para este tipo de serviço:

  • Este serviço permite apenas um determinado número de chamadas para a API de serviço?

  • Este serviço coloca limites na frequência de chamadas para a API de serviço?

  • O serviço limita o número de servidores que podem chamar a API de serviço?

  • Quais são as informações disponíveis publicamente sobre como o serviço entrega sua promessa de disponibilidade?

  • Como esse serviço comunica seu status de integridade?

  • Qual é o SLA (contrato de nível de serviço) indicado?

  • Este é um serviço de mercadoria em que a funcionalidade e/ou os dados necessários estão disponíveis de vários provedores de serviços?

  • Se for um serviço de mercadoria, a interface é interoperável entre outros provedores de serviços (diretamente ou por meio de uma camada de abstração disponível)?

  • Quais são os serviços de plataforma equivalentes fornecidos por outros terceiros?

Serviços em nuvem da comunidade

Uma comunidade de organizações, como uma cadeia de fornecimento, pode tornar os serviços disponíveis para organizações membros.

Questões a serem consideradas para este tipo de serviço:

  • Este serviço permite apenas um determinado número de chamadas para a API de serviço?

  • Este serviço coloca limites na frequência de chamadas para a API de serviço?

  • O serviço limita o número de servidores que podem chamar a API de serviço?

  • Quais são as informações disponíveis publicamente sobre como o serviço entrega sua promessa de disponibilidade?

  • Como esse serviço comunica seu status de integridade?

  • Qual é o SLA (contrato de nível de serviço) indicado?

  • Como um membro da comunidade, há uma possibilidade de negociar um SLA diferente?

  • Este é um serviço de mercadoria em que a funcionalidade e/ou os dados necessários estão disponíveis de vários provedores de serviços?

  • Se for um serviço de mercadoria, a interface é interoperável entre outros provedores de serviços (diretamente ou por meio de uma camada de abstração disponível)?

  • Quais são os serviços de plataforma equivalentes fornecidos por outros terceiros?

Serviços em nuvem internos de uma empresa

Uma empresa pode criar serviços principais, como dados de preço de estoque ou metadados de produto, disponíveis para suas divisões e seus departamentos.

Questões a serem consideradas para este tipo de serviço:

  • Este serviço permite apenas um determinado número de chamadas para a API de serviço?

  • Este serviço coloca limites na frequência de chamadas para a API de serviço?

  • O serviço limita o número de servidores que podem chamar a API de serviço?

  • Quais são as informações disponíveis publicamente sobre como o serviço entrega sua promessa de disponibilidade?

  • Como esse serviço comunica seu status de integridade?

  • Qual é o SLA (contrato de nível de serviço) indicado?

  • Como um membro da organização, há uma possibilidade de negociar um SLA diferente?

  • Este é um serviço de mercadoria em que a funcionalidade e/ou os dados necessários estão disponíveis de vários provedores de serviços?

  • Se for um serviço de mercadoria, a interface é interoperável entre outros provedores de serviços (diretamente ou por meio de uma camada de abstração disponível)?

  • Quais são os serviços de plataforma equivalentes fornecidos por outros terceiros?

Serviços em nuvem internos de um departamento ou uma divisão

Uma divisão ou departamento corporativo podem tornar os serviços disponíveis para outros membros de sua organização imediata.

Questões a serem consideradas para este tipo de serviço:

  • Este serviço permite apenas um determinado número de chamadas para a API de serviço?

  • Este serviço coloca limites na frequência de chamadas para a API de serviço?

  • O serviço limita o número de servidores que podem chamar a API de serviço?

  • Quais são as informações disponíveis publicamente sobre como o serviço entrega sua promessa de disponibilidade?

  • Como esse serviço comunica seu status de integridade?

  • Qual é o SLA (contrato de nível de serviço) indicado?

  • Como um membro da divisão, há uma possibilidade de negociar um SLA diferente?

  • Este é um serviço de mercadoria em que a funcionalidade e/ou os dados necessários estão disponíveis de vários provedores de serviços?

  • Se for um serviço de mercadoria, a interface é interoperável entre outros provedores de serviços (diretamente ou por meio de uma camada de abstração disponível)?

  • Quais são os serviços de plataforma equivalentes fornecidos por outros terceiros?

Os 9s da disponibilidade de serviço composta

Aproveitar os serviços existentes pode fornecer uma agilidade significativa na entrega de soluções para sua organização ou para a venda comercial. Embora isso seja atraente, é importante entender o impacto real dessas dependências no SLA geral para a carga de trabalho.

A disponibilidade normalmente é expressa como uma porcentagem do tempo de atividade em um determinado ano. Essa porcentagem de disponibilidade expressa é referida pelos números “9.” Por exemplo, 99,9 representa um serviço com "três noves" e 99,999 representa um serviço com "cinco noves".

 

% de disponibilidade

Tempo de inatividade por ano

Tempo de inatividade por mês

Tempo de inatividade por semana

90% (um nove)

36,5 dias

72 horas

16,8 horas

95%

18,25 dias

36 horas

8,4 horas

97%

10,96 dias

21,6 horas

5,04 horas

98%

7,30 dias

14,4 horas

3,36 horas

99% (dois noves)

3,65 dias

7,20 horas

1,68 horas

99.5%

1,83 dias

3,60 horas

50,4 minutos

99.8%

17,52 horas

86,23 minutos

20,16 minutos

99,9% (três noves)

8,76 horas

43,2 minutos

10,1 minutos

99.95%

4,38 horas

21,56 minutos

5,04 minutos

99,99% (quatro noves)

52,56 minutos

4,32 minutos

1,01 minutos

99,999% (cinco noves)

5,26 minutos

25,9 segundos

6,05 segundos

99,9999% (seis noves)

31,5 segundos

2,59 segundos

0,605 segundos

99,99999% (sete noves)

3,15 segundos

0,259 segundos

0,0605 segundos

Um equívoco comum é relacionado ao número de 9s fornecido para um serviço composto. Especificamente, no geral, supõe-se que se um serviço fornecido for composto por 5 serviços, cada um com um tempo de atividade prometido de 99,99% em seus SLAs, o serviço composto resultante terá uma disponibilidade de 99,99%. Esse não é o caso.

À prova de falhas_13

Figura 3: O tempo de inatividade relacionado aos 9s mais comum

O SLA composto é realmente um cálculo que considera a quantidade de tempo de inatividade por ano. Um serviço com um SLA de quatro 9s (99,99%) pode ficar até 52,56 minutos offline.

Inserir 5 desses serviços com um SLA de 99,99% em uma composição apresenta um risco identificado no SLA de 262,8 minutos ou 4,38 horas. Isso reduz a disponibilidade para 99,95%, antes que uma única linha de código seja escrita!

É verdade que, geralmente, você não pode alterar a disponibilidade de um serviço de terceiro. Entretanto, ao gravar seu código, é possível aumentar a disponibilidade geral de seu aplicativo usando técnicas como as descritas neste documento.

noteObservação
Alguns serviços podem fornecer diferentes camadas de serviços para diferentes preços ou com base em parceiros de negócios.

Considere a API de Dados de Esportes referida anteriormente. Os usuários jogam em dias específicos e apenas por um número determinado de horas nesses dias. Durante esses períodos, o SLA seria de 100%. Quando não há jogos programados, essa carga de trabalho tem um SLA de 0%. A carga de trabalho "Estatísticas da Liga, do Jogador e da Equipe" tem um padrão de ciclo de vida mais consistente. Também existe um requisito para que essa carga de trabalho tenha um SLA de 99% o tempo todo.

À prova de falhas_14

Figura 4

Ao aproveitar serviços externos, a importância de entender os SLAs, individualmente e seu impacto na composição, não pode ser enfatizada suficientemente.

Para criar uma arquitetura resiliente, é importante compreendê-la. Especificamente, fazer um esforço pró-ativo para entender e documentar o que pode causar uma interrupção.

Entender os pontos da falha e os modos de falha de um aplicativo e os serviços de carga de trabalho relacionados pode permite que você tome decisões informadas e direcionadas sobre estratégias para a resiliência e a disponibilidade.

Os pontos de falha são locais em que as falhas podem resultar em uma interrupção de serviço. Um foco importante está em elementos de design que estão sujeitos a alterações externas.

Os exemplos de pontos de falha incluem;

  • Conexões de banco de dados

  • Conexões de site

  • Arquivos de configuração

  • Chaves do Registro

As categorias de pontos comuns de falha incluem;

  • ACLs

  • Acesso ao banco de dados

  • Acesso externo ao site/serviço

  • Transações

  • Configuração

  • Capacidade

  • Rede

Quando os pontos de falha definem as áreas que podem resultar em uma interrupção, os modos de falha identificam a maneira específica na qual a falha pode ocorrer.

Os exemplos de modos de falha incluem;

  • Um arquivo de configuração faltando

  • Tráfego significativo que excede a capacidade de recursos

  • Um banco de dados atingindo a capacidade máxima

Os efeitos de falha são as consequências de falha na funcionalidade. Saiba sobre os efeitos de falha e a frequência em que esses tipos de falha são mais prováveis de ocorrer. Fazendo isso, é possível priorizar quando e como você endereça os pontos de falha e os modos de falha de seu aplicativo ou serviço.

Este documento abordará considerações importantes em serviços de computação, armazenamento e plataforma. Antes de abordar estes tópicos, é importante recapitular vários tópicos que afetam a resiliência básica que são geralmente mal-interpretados e/ou não implementados.

Conforme mencionado anteriormente, uma arquitetura resiliente deve otimizar a autonomia. Um dos modos de obter autonomia está tornar a comunicação assíncrona. Uma arquitetura resiliente deve usar como padrão a interação assíncrona, com interações síncronas que acontecem somente como resultado de uma exceção.

As camadas da Web sem estado ou as camadas da Web com um cache distribuído podem fornecer isso no front-end de uma solução. As filas podem fornecer esse recurso para comunicação para a interação entre serviços de carga de trabalho ou para serviços dentro de um serviço de carga de trabalho.

O último permite que as mensagens sejam colocadas em filas e serviços secundários podem recuperá-las. Isso pode ser feito com base em lógica, tempo ou lógica que considera o volume. Além de tornar o processo assíncrono, isso também permitirá dimensionar as camadas de envio ou de recebimento de filas conforme for apropriado.

Uma área comum em que as falhas transientes ocorrerão é o local onde a arquitetura se conecta a um serviço ou recurso como, por exemplo, um banco de dados. Ao consumir esses serviços, é uma prática comum implementar a lógica que apresenta o conceito de tempo limite. Essa lógica identifica um prazo aceitável no qual uma resposta é esperada e gerará um erro identificável ao exceder esse prazo. Com base na aparência do erro de tempo limite, as etapas adequadas serão usadas com base no contexto no qual ocorreu o erro. O contexto pode incluir o número de vezes que esse erro ocorreu, o impacto potencial do recurso indisponível, as garantias de SLA para o período de tempo atual para o cliente específico etc.

Ao criar os serviços que entregarão sua carga de trabalho, você deverá aceitar e compreender que as falhas ocorrerão e deverá realizar as etapas adequadas para tratá-las.

Uma das áreas comuns para tratar é falhas transitórias. Como nenhum serviço tem o tempo de atividade de 100%, é realista esperar que você não consiga se conectar a um serviço de que uma carga de trabalho depende. A incapacidade de se conectar ou as falhas observadas de um desses serviços podem ser breves (menos de um segundo) ou permanentes (um provedor é desligado).

Degradar de forma suave

O seu serviço de carga de trabalho deve pretender tratar essas falhas transitórias de forma suave. O Netflix, por exemplo, durante uma interrupção no provedor de nuvem, utilizou uma fila de vídeo mais antiga para os clientes quando o repositório de dados primário não estava disponível. Outro exemplo seria um site de comércio eletrônico que continua a coletar pedidos se o gateway de pagamentos não está disponível. Isso fornece a capacidade de processar pedidos quando o gateway de pagamentos ficar disponível novamente ou depois de realizar failover para um gateway secundário de pagamento.

Considerações de Alto Nível para Degradação de Forma Suave

Ao pensar sobre como degradar de maneira suave, as considerações a seguir são fundamentais:

  • Componentes que não tem o contexto completo da solicitação devem simplesmente falhar e passar na mensagem de exceção. Para resolver isso, implemente um disjuntor, descrito posteriormente neste documento, para acelerar a falha quando você atingir os limites de contagem de falhas.

  • Falhas que podem ser transitórias na natureza são comuns. Lide com elas usando o padrão Tentar Novamente descrito posteriormente neste documento.

  • O chamador pode ser capaz de corrigir algumas solicitações com falha tentando novamente a solicitação usando diferentes parâmetros em um caminho diferente.

  • Se o sucesso da solicitação não é crítico para o cenário, lide com a falha usando uma omissão simples.

  • É possível lidar com falhas retornando uma mensagem de sucesso e enfileirando as solicitações com falha para serem processadas posteriormente, quando o recurso retornar para um estado normal.

  • Você pode ser capaz de retornar algo que já foi previamente corrigido, por exemplo, credenciais armazenadas em cache, dados obsoletos do cache, etc.

  • É possível lidar com algumas falhas fornecendo uma experiência que é quase correta, por exemplo, acesso temporário, valores aproximados, melhor alternativa, noscript, etc.

  • Em vez de lançar um erro, você pode fornecer algumas alternativas, por exemplo, valores aleatórios, direitos anônimos, imagens padrão, etc.

Considerações de tratamento de falhas transitórias

Há várias considerações importantes para a implementação de tratamento de falhas transitórias, conforme detalhado nas seções a seguir.

  • Lógica de repetição

    A forma mais simples de tratamento de falha transitória é repetir a operação que falhou. Se estiver usando um serviço comercial de terceiros, implementar a "lógica de repetição" geralmente resolverá esse problema.

    Observe que os designs devem normalmente limitar o número de vezes que a lógica será repetida. A lógica normalmente tentará executar as ações um determinado número de vezes, registrando um erro e/ou usando um serviço ou fluxo de trabalho secundário se a falha persistir.

  • Retirada exponencial

    Se o resultado da falha transitória for devido à limitação pelo serviço devido à carga pesada, as tentativas repetidas de chamar o serviço somente estenderão a limitação e afetarão a disponibilidade geral.

    Geralmente é desejável reduzir o volume de chamadas para o serviço para ajudar a impedir ou reduzir a limitação. Isso é feito normalmente de maneira algorítmica, por exemplo, repetir imediatamente depois da primeira falha, aguardar 1 segundo após a segunda falha, 5 segundos após a terceira falha etc. até finalmente o êxito ou atingir um limite definido para falhas pelo aplicativo.

    Essa abordagem é chamada de “retirada exponencial”.

  • Idempotência

    Um pressuposto central com serviços conectados é que eles não estarão 100% disponíveis e que o tratamento de falha transitória com lógica de repetição é uma abordagem central de implementação. Nos casos em que a lógica de repetição está implementada, há o potencial para que a mesma mensagem seja enviada mais de uma vez, para que as mensagens sejam enviadas fora de sequência etc.

    As operações devem ser criadas para serem idempotentes, garantindo que o envio da mesma mensagem várias vezes não resulte em um repositório de dados inesperado ou poluído.

    Por exemplo, inserir dados de todas as solicitações pode resultar na adição de vários registros se a operação de serviço for chamada várias vezes. Uma abordagem alternativa seria implementar o código como um 'upsert' inteligente. Um carimbo de data/hora ou um identificador global podem ser usados para identificar mensagens novas e mensagens processadas previamente, inserindo somente as mais novas no banco de dados e atualizando registros existentes se a mensagem for mais nova do que a que foi recebida no passado.

  • Comportamento de compensação

    Além da idempotência, outra área a ser considerada é o conceito de comportamento de compensação. Em um mundo de conjuntos de sistemas cada vez mais conectados e a emergência de serviços compostos, é importante entender como controlar o comportamento de compensação.

    Para muitos desenvolvedores de aplicativos de linha de negócios, os conceitos de transações não são novos, mas o quadro de referência é geralmente vinculado à funcionalidade transacional exposta por tecnologias de dados locais e por bibliotecas de código relacionadas. Ao examinar o conceito em termos de nuvem, essa mentalidade precisa fazer novas considerações relacionadas à orquestração de serviços distribuídos.

    Uma orquestração de serviço pode abranger vários sistemas distribuídos e ter execução longa e de estado. A própria orquestração raramente é síncrona, pode abranger vários sistemas e pode ir de segundos a anos com base no cenário de negócios.

    Em um cenário de cadeia de fornecimento que possa vincular 25 organizações na mesma atividade de carga de trabalho, por exemplo, pode haver um conjunto de 25 ou mais sistemas que estão interconectados em uma ou mais orquestrações de serviço.

    Se houver êxito, os 25 sistemas devem ser informados de que a atividade foi bem-sucedida. Para cada ponto de conexão na atividade, os sistemas participantes podem fornecer uma ID de correlação para as mensagens recebidas de outros sistemas. Dependendo do tipo de atividade, o recebimento dessa ID de correlação pode atender a parte da transação que está completa de forma nocional. Em outros casos, após a conclusão das interações de todas as 25 partes, e a mensagem de confirmação pode ser enviada para todas as partes (diretamente de um único serviço ou por pontos específicos da interação de orquestração para cada sistema).

    Para tratar as falhas na composição e/ou em atividades distribuídas, cada serviço deve expor uma interface de serviço e operações para receber solicitações para cancelar uma determinada transação por um identificador exclusivo. Por trás da fachada de serviço, os fluxos de trabalho devem ser utilizados para compensar o cancelamento dessa atividade. De modo ideal, eles seriam procedimentos automatizados, mas podem ser simples como o roteamento para uma pessoa na organização para reparar manualmente.

Um disjuntor é um comutador que interrompe automaticamente o fluxo de corrente elétrica se a corrente exceder um limite predefinido. Os disjuntores são usados com mais frequência como precaução de segurança onde a corrente excessiva por um circuito pode ser perigosa. Ao contrário de um fusível, um disjuntor pode ser redefinido e reusado.

O mesmo padrão é aplicável ao design de software, e particularmente aplicável para os serviços onde a disponibilidade e a resiliência são uma consideração importante.

No caso de um recurso não estar disponível, implementar um disjuntor de software pode responder com uma ação apropriada e responder adequadamente.

Um disjuntor terá três estados: Fechado, Aberto e Entreaberto.

O estado Fechado é o estado normal para o aplicativo ou serviço. Quando estiver em um estado Fechado, as solicitações serão roteadas por meio de um caminho padrão. Um contador acompanha as taxas de falha e as avalia com base em um limite. Se uma taxa de falha cruzar o limite, o disjuntor altera para um estado Aberto. Se uma chamada para um recurso de banco de dados falhar depois de 100 tentativas de conexão consecutivas, provavelmente não valerá a pena continuar a chamar o banco de dados. Um disjuntor pode ser acionado nesse limite e as ações apropriadas poderão ser executadas.

Quando em um estado Aberto, o disjuntor roteia solicitações para o(s) caminho(s) de mitigação. Isso poderia ser uma falha rápida ou outra forma de degradação gratuita. Quando alterar para o estado Aberto, o disjuntor também iniciará um temporizador. Quando o temporizador expirar, ele alterará para um estado Entreaberto.

O estado Entreaberto começará a rotear um número limitado de solicitações por meio do caminho normal. Se forem bem-sucedidas, o disjuntor muda para o estado Fechado. Se esse número limitado de solicitações falhar, o disjuntor retornará para o estado Aberto.

Quando incluir o padrão do disjuntor em sua arquitetura, considere o seguinte:

  • Um disjuntor pode invocar mitigações diferentes ou tempos diferentes quando no estado Aberto com base no tipo de exceção lançada da operação.

  • Um disjuntor deveria registrar todos os estados de transição. Isso permite que os operadores monitorem o comportamento de transição e ajustem os temporizadores para evitar estados Aberto prolongados ou oscilações frequentes entre estados Aberto e Entreaberto.

  • Em vez de usar um temporizador para transição de Aberto para Entreaberto, o disjuntor poderia testar periodicamente o caminho padrão para determinar se voltou ao normal.

  • Tenha cuidado ao usar um disjuntor quando lidar com uma operação que trata de vários fragmentos. A preocupação aqui é que a integridade possa estar no nível do fragmento e isso pode resultar em dois cenários indesejáveis:

    • Mover para um estado Aberto quando somente um fragmento falha.

    • Mover acidentalmente para um estado Fechado quando um ou mais fragmentos estão normais.

Uma implementação comum desse padrão está relacionada a acessar os bancos de dados ou os serviços de dados. Assim que falhar um tipo estabelecido e um nível de atividade, o disjuntor reagirá. Com dados, isso normalmente é causado pela incapacidade de conectar-se a um banco de dados ou um serviço de dados na frente desse banco de dados.

Se uma chamada para um recurso de banco de dados falhar depois de 100 tentativas de conexão consecutivas, provavelmente não valerá a pena continuar a chamar o banco de dados. Um disjuntor pode ser acionado nesse limite e as ações apropriadas poderão ser executadas.

Em alguns casos, especialmente ao se conectar aos serviços de dados, este pode ser o resultado da limitação baseada em um cliente que excede o número de chamadas permitidos em um período de tempo determinado. O disjuntor pode injetar atrasos entre chamadas até o momento em que as conexões forem estabelecidas com sucesso e até atenderem os níveis de tolerância.

Em outros casos, o repositório de dados pode não estar indisponível. Se uma cópia redundante de dados estiver disponível, o sistema poderá fazer failover para essa réplica. Se uma réplica verdadeira estiver indisponível ou se o serviço de banco de dados estiver inativo amplamente em todos os data centers dentro de um provedor, uma abordagem secundária poderá ser utilizada. Isso pode incluir fornecer dados de uma versão dos dados solicitados por um provedor de serviço de dados alternativo. Essa fonte alternativa pode ser de um cache, um tipo de repositório de dados persistente alternativo no provedor de nuvem atual, um provedor de nuvem separado ou em um data center local. Quando uma alternativa não estiver disponível, o serviço também poderá retornar um erro reconhecível que possa ser tratado apropriadamente pelo cliente.

Exemplo de disjuntor: Netflix

Netflix, uma empresa de streaming de mídia, é geralmente considerado um grande exemplo de arquitetura resiliente. Ao discutir o padrão de disjuntor na Netflix, essa equipe chama vários critérios que são incluídos em seu disjuntor no Blog de tecnologia da Netflix. Isso inclui:

  1. Uma solicitação para o serviço remoto expira.

  2. O pool de threads e a fila de tarefas associadas usadas para interagir com uma dependência do serviço estão a 100% de capacidade.

  3. A biblioteca de cliente usada para interagir com uma dependência do serviço gera uma exceção.

Tudo isso contribui para a taxa de erros geral. Quando essa taxa de erros exceder seus limites definidos, o disjuntor é “disparado” e o circuito para esse serviço imediatamente serve fallback mesmo sem tentar se conectar ao serviço remoto.

Nessa mesma entrada de blog, a equipe do Netflix declara que o disjuntor para cada um de seus serviços implementa um fallback usando uma das três abordagens a seguir:

  1. Fallback personalizado – uma biblioteca cliente de serviço fornece um método invocável de fallback ou dados disponíveis localmente em um servidor de API (por exemplo, um cookie ou um cache local) são usados localmente para gerar uma resposta de fallback.

  2. Falhar no modo silencioso – um método retornará um valor nulo para o cliente solicitante, o que funciona bem quando os dados que estão sendo solicitados são opcionais.

  3. Falhar no modo rápido – quando os dados forem necessários ou nenhum fallback bom estiver disponível, uma resposta 5xx é retornada para o cliente. Essa abordagem concentra-se em manter os servidores de API íntegros e capazes de realizar uma recuperação rápida quando os serviços impactados ficarem online novamente, mas faz isso às custas de afetar negativamente o UX cliente.

Para impor um SLA, uma organização deve resolver como seu serviço de dados lidará com as duas categorias de exceções: partes confiáveis e atores ruins.

Partes confiáveis e lista de permissões

As partes confiáveis são organizações com as quais a organização pode ter acordos especiais, e para quem determinadas exceções aos SLAs padrão podem ser feitas.

  • Terceiros com acordos personalizados

    Pode haver alguns usuários de um serviço que desejam negociar políticas ou condições de preços especiais. Em alguns casos, um alto volume de chamadas para o serviço de dados pode garantir um preço especial. Em outros casos, a procura um determinado serviço de dados pode exceder o volume especificado em camadas de uso padrão. Esses clientes devem ser definidos como partes confiáveis para evitarem ser inadvertidamente sinalizados como atores ruins.

  • Lista de permissões

    A abordagem típica para tratar partes confiáveis é estabelecer uma lista de permissões. Uma lista de permissões, que identifica uma lista de partes confiáveis, será usada pelo serviço quando ele determinar quais regras de negócio aplicar ao processar o uso do cliente. A lista de permissões é geralmente feita autorizando-se um intervalo de endereços IP ou uma chave de API.

    Ao estabelecer uma política do consumo, a organização deverá identificar se a lista de permissões tem suporte; como um cliente deverá se candidatar para estar na lista de permissões; como adicionar um cliente à lista de permissões; e sob quais circunstâncias um cliente será removido dela.

  • Tratando atores ruins

    Se partes confiáveis ficam em uma extremidade do espectro do cliente, o grupo na extremidade oposta será o que chamamos de “atores ruins”. Atores ruins colocam uma carga sobre o serviço, normalmente de tentativa de “excesso de consumo”. Em alguns casos, o comportamento ruim é genuinamente acidental. Em outros casos, é intencional e, em algumas situações, é mal-intencionado. Esses atores são rotulados de “ruins”, porque suas ações – intencionais ou não – têm a capacidade de afetar a disponibilidade de um ou mais serviços.

    A carga de atores ruins pode representar custos desnecessários para o provedor de serviço de dados e comprometer o acesso de consumidores que seguem fielmente os termos de uso e têm uma expectativa razoável do serviço, como descrito em um SLA. Consequentemente, os atores ruins devem ser tratados de uma maneira consistente e prescrita. As respostas típicas para atores ruins são limitação e lista de bloqueios.

  • Limitação

    As organizações devem definir uma estratégia para lidar com picos de uso pelos consumidores de serviço de dados. As intermitências significativas de tráfego de qualquer consumidor podem colocar uma carga inesperada no serviço de dados. Quando esses picos ocorrem, a organização talvez queira limitar o acesso para esse consumidor por um determinado período. Nesse caso, o serviço recusa todas as solicitações do consumidor por um período de tempo determinado, como um minuto, cinco minutos ou dez minutos. Durante esse período, as solicitações de serviço do consumidor de destino resultam em uma mensagem de erro alertando que elas estão sendo limitadas devido a uso excessivo.

    O consumidor que faz as solicitações pode responder adequadamente, por exemplo, alterar seu comportamento.

    A organização deve determinar se deseja implementar a limitação e definir as regras de negócio relacionadas. Se elas determinarem que os consumidores podem ser limitados, a organização também precisará decidir quais comportamentos devem acionar a resposta de limitação.

  • Lista de bloqueios

    Embora a limitação deva corrigir o comportamento de atores ruins, nem sempre pode haver êxito. Nos casos em que isso não funcionar, a organização talvez queira vetar um consumidor. A lista de bloqueios é o oposto de uma lista de permissões e identifica os consumidores que são barrados de acessar o serviço. O serviço atenderá corretamente as solicitações de acesso de clientes na lista de bloqueios e de maneira a minimizar o uso de recursos de serviço de dados.

    A lista de bloqueios, assim como a lista de permissões, é geralmente feita usando-se uma chave de API ou um intervalo de endereços IP.

    Ao estabelecer uma política de consumo, a organização deve especificar quais comportamentos colocarão um consumidor na lista de bloqueios, como a lista de bloqueios pode ser apelada e como um consumidor pode ser removido da lista de bloqueios.

Pessoas cometem erros. Seja você um desenvolvedor que faz uma alteração de código que possa ter consequências inesperadas, um DBA que coloca acidentalmente uma tabela em um banco de dados ou uma pessoa de operações que faz uma alteração mas não a documenta, haverá várias oportunidades para inadvertidamente tornar um serviço menos resiliente.

Para reduzir a falha humana, uma abordagem lógica é reduzir a quantidade de ações humanas no processo. Com a introdução da automação, você limita a possibilidade de as variações ad hoc inadvertidas do comportamento esperado comprometerem seu serviço.

Há um meme na comunidade de DevOps com um personagem de desenho animado falando “automatizar todas as coisas”. Na nuvem, a maioria dos serviços é exposta com uma API. Ferramentas de desenvolvimento, infraestruturas virtualizadas, serviços de plataforma, soluções entregues como o Software como um Serviço, tudo é criado por meio de scripts.

A criação de scripts é altamente recomendada. A criação de scripts torna a implantação e o gerenciamento consistentes e previsíveis e é lucrativa para o investimento.

Automatizando a implantação

Uma das principais áreas de automação está na criação e na implantação de uma solução. A automação pode facilitar o trabalho de uma equipe do desenvolvedor de testar e implantar em vários ambientes. O desenvolvimento, o teste, a preparação, a fase beta e a produção podem ser implantados de maneira rápida e consistente por meio de builds automatizados. A capacidade de implantar consistentemente em ambientes funciona porque garante que o que está em produção é representativo do que vem sendo testado.

Considere o seguinte como "código": scripts, arquivos de configuração e metadados relacionados à implantação. Código também inclui gerenciamento desses artefatos em controle de origem para:

  • Alterações de documentos.

  • Permitir controle de versão.

  • Fornecer controle de acesso baseado em função.

  • Assegurar que o conteúdo seja obtido em backup.

  • Fornecer uma única fonte de verdade.

Estabelecer e automatizar um aproveitamento de teste

O teste é outra área que pode ser automatizada. Como uma implantação automatizada, estabelecer testes automatizados é útil porque garante que o sistema seja resiliente e permaneça resiliente ao longo do tempo. À medida que o código e o uso do serviço evoluem, é importante que todos os testes apropriados sejam feitos, de maneira funcional e em escala.

Automatizando arquivamento e limpeza de dados

Uma das áreas que obtém menos atenção é a de arquivamento e limpeza de dados. O volume de dados está crescendo e continuará a crescer em um volume mais alto e em uma variedade maior do que em qualquer momento na história. Dependendo da tecnologia de banco de dados e dos tipos de consultas necessárias, os dados desnecessários podem reduzir o tempo de resposta de seu sistema e aumentar os custos desnecessariamente. Para que os planos de resiliência incluam uma ou mais réplicas de um repositório de dados, remover todos os dados desnecessários poderá agilizar atividades de gerenciamento, como backup e restauração de dados.

Identifique os requisitos para sua solução relativos aos dados necessários para a funcionalidade principal, os dados necessários para fins de conformidade mas que podem ser arquivados e os dados que não são mais necessários e podem ser limpos.

Use as APIs disponíveis de produtos e serviços relacionados para automatizar a implementação desses requisitos.

Ao criar uma arquitetura resiliente, também é importante entender os conceitos de domínios de falha e domínios de atualização.

Domínios com falha

Os domínios de falha restringem a colocação de serviços com base nos limites conhecidos de hardware e a probabilidade de um tipo específico de interrupção afetar um conjunto de computadores. Um domínio de falha é definido como uma série de computadores que pode falhar simultaneamente e geralmente é definido por propriedades físicas (um rack específico de computadores, uma série de computadores que compartilham a mesma fonte de energia etc.).

Domínios de atualização

Os domínios de atualização são semelhantes aos domínios de falha. Os domínios de atualização definem um conjunto físico de serviços que são atualizados pelo sistema ao mesmo tempo. O balanceador de carga no provedor de nuvem deve estar ciente dos domínios de atualização para garantir que, se um domínio específico estiver sendo atualizado, o sistema geral permanecerá balanceado e os serviços permanecerão disponíveis.

Upgrades podem ocorrer em:

  • Nível de hipervisor (“Atualização do sistema operacional do host”).

  • O nível de sistema operacional ("Atualização do sistema operacional convidado").

  • Como resultado da implantação de um aplicativo ou atualização de serviço para o ambiente.

Dependendo do provedor de nuvem e dos serviços de plataforma utilizados, os domínios de falha e os domínios de atualização podem ser fornecidos automaticamente, seja algo que seu serviço possa optar por meio de APIs, ou que exija uma solução interna ou de terceiros.

Resiliência durante uma falha de domínio durante uma atualização

Enquanto Falha de domínio e Atualização de domínio são diferentes, há um cenário em que elas se cruzam. Nesse cenário, uma falha de hardware deixa a máquina virtual desligada, enquanto uma atualização está sendo realizada em outra instância da VM simultaneamente. Nesse caso, as duas VMs seriam desligadas. Se a implantação de um serviço tiver somente duas máquinas virtuais, o serviço ficará desligado. Leve isso em consideração quando avaliar o número de instâncias necessárias para fornecer o SLA que deseja.

Plataformas em nuvem geralmente fornecem a capacidade de identificar um nível de afinidade de um grupo de recursos. Chamamos esses recursos de "grupo de afinidades” ou um “conjunto de afinidades”. Isso ajuda a plataforma subjacente com a colocação de recursos relacionados conjuntamente e a alocação de instâncias nos domínios em Falha e em Atualização.

As soluções locais geralmente dependem de redundância para garantir a disponibilidade e a escalabilidade. Do ponto de vista de disponibilidade, data centers redundantes fornecem a capacidade de aumentar a probabilidade da continuidade de negócios diante de falhas de infraestrutura em um determinado data center ou em parte de um data center.

Para aplicativos com consumidores distribuídos geograficamente, o gerenciamento de tráfego e as implementações redundantes roteiam os usuários para os recursos locais, geralmente com latência reduzida.

noteObservação
A resiliência de dados, que inclui a redundância, é abordada como um tópico separado na seção intitulada Estabelecendo uma abordagem de resiliência de dados.

Redundância e a nuvem

No local, a redundância historicamente tem sido obtida por meio de conjuntos duplicados de hardware, software e rede. Muitas vezes, isso é implementado em um cluster em um único local ou distribuído em vários data centers.

Ao elaborar uma estratégia para a nuvem, é importante racionalizar a necessidade de redundância em três vetores. Esses vetores incluem o código implantado dentro do ambiente de um provedor de nuvem, a própria redundância de provedores e a redundância entre a nuvem e o local.

Redundância de implantação

Quando uma organização tiver selecionado um provedor de nuvem, é importante estabelecer uma estratégia de redundância para a implantação no provedor.

Se for implantado na PaaS (Plataforma como um Serviço), grande parte disso pode ser tratado pela plataforma subjacente. Em um modelo IaaS (Infraestrutura como um Serviço), isso não é possível.

  • Implantar um número de funções em um data center

    A forma mais simples de redundância é implantar sua solução em várias instâncias em um único provedor de nuvem. Ao implantar em várias instâncias, a solução pode limitar o tempo de inatividade que ocorrerá quando apenas um único nó é implantado.

    Em muitos ambientes de Plataforma como um Serviço, o estado da máquina virtual que hospeda o código é monitorado e as máquinas virtuais que forem detectadas como não íntegras podem ser substituídas automaticamente por um nó íntegro.

  • Implantar em vários data centers

    Embora implantar vários nós em um único data center forneça benefícios, as arquiteturas devem considerar que um data center inteiro pode estar indisponível. Embora isso não seja uma ocorrência comum, eventos como desastres naturais, guerras etc. podem levar a uma interrupção do serviço em uma localização geográfica específica.

    Para obter seu SLA, talvez seja necessário implantar sua solução em vários data centers para o provedor de nuvem selecionado. Há várias abordagens para se fazer isso, conforme identificado abaixo.

    1. Implantações completamente redundantes em vários data centers

      A primeira opção é uma solução completamente redundante em vários data centers feita em conjunto com um provedor de gerenciamento de tráfego. Uma consideração importante para esta abordagem será o impacto aos custos relacionados à computação para esse tipo de redundância, que aumentará 100% para cada implantação de data center adicional.

    2. Implantação parcial em data center secundário para failover

      Outra abordagem é fazer uma implantação parcial em um data center secundário de tamanho reduzido. Por exemplo, se a configuração padrão utilizasse 12 instâncias de computação, o data center secundário conteria uma implantação com 6 instâncias de computação.

      Essa abordagem, feita em conjunto com o gerenciamento de tráfego, permitiria a continuidade de negócios com a degradação do serviço após um incidente que afetasse somente o data center primário.

      Considerando o número limitado de vezes que um data center fica offline completamente, isso é geralmente visto como uma abordagem econômica para a computação, especialmente se uma plataforma permitir que a organização incorpore rapidamente novas instâncias no segundo data center.

    3. Implantações divididas em vários data centers com nós de backup

      Para determinadas cargas de trabalho, especialmente as de serviços financeiros verticais, há uma quantidade significativa de dados que devem ser processados em uma janela de tempo curta e imóvel. Nestas circunstâncias, o trabalho é feito em intermitências mais curtas e os custos de redundância são justificados para fornecer resultados dentro dessa janela.

      Nesses casos, o código é implantado em vários data centers. O trabalho é dividido e distribuído nos nós para serem processados. Na instância em que um data center fica indisponível, o trabalho planejado para esse nó é entregue ao nó de backup que executará a tarefa.

    4. Várias implantações do data center com tamanho apropriado de geografia por data center

      Essa abordagem utiliza as implantações redundantes que existem em vários data centers, mas são dimensionadas apropriadamente para a escala de um público relevante geograficamente.

Redundância do provedor

Quando a redundância voltada para o data center for boa, os SLAs ocorrem no nível de serviço em relação ao data center. Muitos serviços comerciais hoje implantarão novas versões para uma “fatia” da produção para validar o código na produção. Entretanto, existe a possibilidade de que os serviços fornecidos por um provedor possam ficar indisponíveis por meio de vários ou todos os data centers.

Com base nos SLAs para uma solução, pode ser preferível inserir também a redundância do provedor. Para fazer isso, identifique os produtos implantáveis na nuvem ou os serviços em nuvem que funcionarão em várias plataformas de nuvem. O Microsoft SQL Server, por exemplo, pode ser implantado em uma máquina virtual dentro da infraestrutura como uma oferta de Serviço da maioria dos fornecedores.

Para serviços fornecidos na nuvem, isso é mais difícil porque não há nenhuma interface padrão, mesmo para os serviços principais como computação, armazenamento, filas etc. Se a redundância do provedor for desejada para esses serviços, geralmente ela ocorrerá somente por meio de uma camada de abstração. Uma camada de abstração pode fornecer funcionalidade suficiente para uma solução, mas não será inovada tão rápido quanto os serviços subjacentes e pode inibir uma organização de adotar rapidamente novos recursos entregues por um provedor.

Se os serviços redundantes de provedor forem garantidos, ele pode estar em um de vários níveis: um aplicativo inteiro, uma carga de trabalho ou um aspecto de uma carga de trabalho. No nível apropriado, avalie a necessidade de serviços de computação, dados e plataforma e determine o que de fato deve ser redundante e o que pode ser tratado pelas abordagens para fornecer a degradação de forma suave.

Redundância no local

Embora assumir uma dependência de um provedor de nuvem possa fazer sentido fiscal, poderá haver algumas considerações de negócios que exigem a redundância local para a conformidade e/ou a continuidade do negócio.

Com base nos SLAs para uma solução, pode ser preferível inserir também a redundância no local. Para fazer isso, identifique os produtos implantáveis em nuvem privada ou os serviços em nuvem que funcionarão em vários tipos de nuvem. Assim como no caso de redundância do provedor, o Microsoft SQL Server é um bom exemplo de produto que pode ser implantado no local ou em uma oferta de IaaS.

Para serviços fornecidos em nuvem, isso é mais difícil porque geralmente não há equivalentes locais com simetria de interfaces e recursos.

Se os serviços redundantes de provedor forem necessários no local, isso pode estar em um de vários níveis: um aplicativo inteiro, uma carga de trabalho ou um aspecto de uma carga de trabalho. No nível apropriado, avalie a necessidade de serviços de computação, dados e plataforma e determine o que de fato deve ser redundante e o que pode ser tratado pelas abordagens para fornecer a degradação de forma suave.

Abordagens de configuração de redundância

Ao identificar as abordagens de configuração de redundância, as classificações que existiam antes da nuvem também se aplicarão. Dependendo dos tipos de serviços utilizados em sua solução, alguns podem ser tratados pela plataforma subjacente automaticamente. Em outros casos, esse recurso é tratado por meio de tecnologias como o Windows Fabric.

  1. Ativo/ativo — o tráfego destinado para um nó com falha é passado para um nó existente ou terá a carga balanceada nos nós restantes. Isso geralmente é possível apenas quando os nós utilizam uma configuração de software homogênea.

  2. Ativo/passivo — fornece uma instância completamente redundante de cada nó, que somente será colocado online quando seu nó primário associado falhar. Essa configuração geralmente exige um hardware adicional.

  3. N+1 — fornece um único nó adicional que é colocado online para assumir a função do nó que falhou. No caso de configuração de software heterogênea em cada nó primário, o nó adicional deve ser universalmente capaz de assumir qualquer uma das funções dos nós primários pelas quais é responsável. Isso normalmente se refere aos clusters que têm vários serviços que são executados simultaneamente; no caso de serviço único, isso se degenera para ativo/passivo.

  4. N+M — nos casos em que um único cluster está gerenciando muitos serviços, ter apenas um nó de failover dedicado pode não oferecer a redundância suficiente. Nesses casos, mais de um servidor em espera (M) estão incluídos e disponíveis. O número de servidores em espera é um equilíbrio entre custos e requisitos de confiança.

  5. N-para-1 — permite que o nó em espera de failover torne-se ativo temporariamente, até o nó original poder ser restaurado ou colocado online, ao ponto em que os serviços ou as instâncias deverão fazer failback para ele a fim de restaurar a alta disponibilidade.

  6. N-para-N — uma combinação de ativo/ativo e de N+M, N para N redistribui os serviços, instâncias ou conexões do nó com problema entre os nós restantes ativos, eliminando assim (como ocorre com o ativo/ativo) a necessidade de um nó “em espera”, mas introduzindo uma necessidade de capacidade adicional em todos os nós ativos.

Seja o tráfego sempre distribuído geograficamente ou roteado para diferentes data centers para satisfazer cenários de continuidade de negócios, a funcionalidade de gerenciamento de tráfego é importante para assegurar que as solicitações para sua solução estão sendo roteadas para as instâncias apropriadas.

É importante observar que assumir uma dependência de um serviço de gerenciamento de tráfego apresenta um único ponto de falha. É importante investigar o SLA do serviço de gerenciamento de tráfego primário do seu aplicativo e determinar se a funcionalidade alternativa de gerenciamento de tráfego é garantida por seus requisitos.

Embora muitos aplicativos de nuvem de alta escala tenham feito um bom trabalho de particionar a camada da Web, eles têm menos êxito em dimensionar a camada de dados na nuvem. Com uma diversidade cada vez maior de dispositivos conectados, o nível de dados gerados e consultados está aumentando a níveis jamais vistos na história. A necessidade de ser capaz de dar suporte a 500.000 novos usuários por dia, por exemplo, agora é considerada razoável.

Ter uma estratégia de particionamento é criticamente importante em várias dimensões, inclusive armazenar, consultar ou manter esses dados.

Decomposição e particionamento

Devido aos benefícios e à compensação de tecnologias diferentes, é comum aproveitar tecnologias que forem mais ideais para a carga de trabalho determinada.

Ter uma solução que é decomposta por cargas de trabalho oferece a capacidade de escolher as tecnologias de dados que são ideais para uma determinada carga de trabalho. Por exemplo, um site pode usar o armazenamento de tabela para o conteúdo de um indivíduo, usando partições no nível do usuário para uma experiência de resposta. Essas linhas da tabela podem ser agregadas periodicamente em um banco de dados relacional para relatório e análise.

As estratégias de particionamento podem variar e geralmente variam com base nas tecnologias escolhidas.

Quando definir sua estratégia, é importante identificar exceções que podem precisar de uma estratégia modificada ou paralela. Por exemplo, se você estivesse desenvolvendo um site de rede social, um usuário normal pode ter 500 conexões, enquanto uma celebridade pode ter 5.000.000.

Se a expectativa do site é de 100M usuários e as celebridades constituem menos de 50.000, a estratégia de particionamento do núcleo seria otimizada para um usuário comum. Você poderia gerenciar as celebridades diferentemente. Enquanto você agruparia um grande número de usuários em uma única partição, pode alocar uma celebridade para uma partição própria.

Compreendendo os 3 Vs

Para elaborar corretamente uma estratégia de particionamento, uma organização deve primeiro compreendê-la.

Os 3 Vs, popularizados pelo Gartner, observam três aspectos de dados diferentes. Entender como os 3 Vs se relacionam com seus dados ajudará a tomar uma decisão informada sobre estratégias de particionamento.

  • Volume

    O volume refere-se ao tamanho dos dados. O volume tem impactos muito reais na estratégia de particionamento. As limitações de volume em uma tecnologia de dados específica podem forçar o particionamento devido a limitações de tamanho, velocidades de consulta por volume etc.

  • Velocidade

    A velocidade refere-se à taxa na qual os dados estão aumentando. Você provavelmente elaborará uma estratégia de particionamento diferente para um repositório de dados em crescimento lento versus um que precise acomodar 500.000 novos usuários por dia.

  • Variedade

    A variedade refere-se aos diferentes tipos de dados que são relevantes para a carga de trabalho. Sejam dados relacionais, pares de chave-valor, perfis de mídias sociais, imagens, arquivos de áudio, vídeos ou outros tipos de dados, é importante compreendê-lo. Isto é válido para escolher a tecnologia correta de dados e tomar decisões informadas para sua estratégia de particionamento.

Particionamento horizontal

Provavelmente a abordagem mais popular para particionar dados é particioná-la horizontalmente. Ao particionar horizontalmente, uma decisão é feita sobre os critérios para particionar um repositório de dados em vários fragmentos. Cada fragmento contém o esquema inteiro, com os critérios que levam à colocação de dados nos fragmentos apropriados.

Com base no tipo e no uso dos dados, isso pode ser feito de diferentes maneiras. Por exemplo, uma organização pode escolher particionar seus dados com base em um sobrenome de cliente. Em outro caso, a partição pode ser voltada para datas, particionando no intervalo de calendário relevante de hora, dia, semana ou mês.

Diagrama de particionamento horizontal

Figura 5: Um exemplo de particionamento horizontal por sobrenome

Particionamento vertical

Outra abordagem é o particionamento vertical. Isso otimiza a colocação de dados em repositórios diferentes, geralmente vinculados à variedade dos dados. A figura 5 mostra um exemplo onde os metadados sobre um cliente são colocados em um repositório enquanto que as miniaturas e as fotos são colocadas em repositórios separados.

O particionamento vertical pode resultar em armazenamento e entrega de dados otimizados. Na figura 5, por exemplo, se a foto for raramente exibida para um cliente, retornar 3 megabytes por registro pode adicionar um custo desnecessário em um modelo de pagamento proporcional ao uso.

Diagrama de particionamento vertical

Figura 6: Um exemplo de particionamento vertical.

Particionamento híbrido

Em muitos casos, será apropriado estabelecer uma estratégia de particionamento híbrido. Esta abordagem fornece as eficiências de ambas as abordagens em uma única solução.

A figura 6 mostra um exemplo disso, onde o particionamento vertical visto anteriormente agora é aumentado para aproveitar o particionamento horizontal dos metadados do cliente.

Diagrama de particionamento horizontal

Figura 7: Um exemplo de particionamento horizontal.

No centro da computação em nuvem está a rede. A rede também é essencial porque fornece a malha ou a estrutura para que os dispositivos se conectem aos serviços e para que os serviços se conectem a outros serviços. Há três limites de rede a serem considerados em qualquer aplicativo à prova de falhas.

Esses limites de rede são detalhados abaixo com o Azure usado como um exemplo para fornecer o contexto:

  1. Os limites de função são conhecidos tradicionalmente como camadas. Os exemplos comuns são uma camada da Web ou uma camada da lógica de negócios. Se nós olharmos o Azure como exemplo, ele introduziu formalmente as funções como parte de seu design principal para fornecer suporte de infraestrutura à natureza de várias camadas de aplicativos modernos e distribuídos. O Azure garante que as instâncias de função que pertencem ao mesmo serviço sejam hospedadas no escopo de um único ambiente de rede e gerenciadas por um único controlador da malha.

  2. Os limites de serviço representam as dependências da funcionalidade fornecidas por outros serviços. Os exemplos comuns são um ambiente do SQL para acesso de banco de dados relacional e um Service Bus para o suporte a mensagens de publicação/assinatura. Dentro do Azure, por exemplo, os limites de serviços são impostos por meio da rede: nenhuma garantia será dada de que uma dependência do serviço fará parte do mesmo ambiente de rede ou controlador da malha. Isso pode acontecer, mas a suposição de design para qualquer aplicativo responsável tem que ser que qualquer dependência do serviço esteja em uma rede diferente gerenciada por um controlador de malha diferente.

    Diagrama de instâncias de função de serviço de nuvem
    Figura 8

  3. Os limites de ponto de extremidade são externos à nuvem. Isso inclui qualquer ponto de extremidade de consumo, geralmente considerado um dispositivo, conectando-se à nuvem para consumir serviços. Você deve fazer considerações especiais nesta parte do design devido à natureza variável e não confiável da rede. Os limites de função e serviço estão dentro dos limites do ambiente de nuvem e pode-se pressupor um determinado nível de confiabilidade e largura de banda. Para as dependências externas, nenhuma suposição pode ser feita e precisa haver um cuidado adicional para a capacidade de o dispositivo consumir serviços, significando dados e interações.

    A rede, por sua própria natureza, introduz latência à medida que passa informações de um ponto da rede para outro. A fim de fornecer uma ótima experiência para os usuários e como serviços dependentes ou funções, a arquitetura do aplicativo e o design devem procurar maneiras para reduzir a latência o máximo possível e gerenciar explicitamente a latência inevitável. Um dos modos mais comuns de reduzir a latência é evitar as chamadas de serviço que envolvem a rede. O acesso local a dados e serviços é uma abordagem chave para reduzir a latência e enviar uma resposta mais alta. Usar dados e serviços locais também oferece outra camada de segurança contra falhas; contanto que as solicitações do usuário ou aplicativo possam ser atendidas no ambiente local, não há necessidade de interagir com outras funções ou serviços, removendo a possibilidade de indisponibilidade do componente dependente como um ponto de falha.

Caching

Caching é uma técnica que pode ser usada para melhorar a velocidade de acesso a dados quando não é possível armazenar dados localmente. O Caching é utilizado de maneira eficaz na maioria das operações de serviço em nuvem em escala hoje em dia. Como a definição fornecido pela Wikipedia descreve, um cache fornece acesso local a dados que são solicitados repetidamente por aplicativos. O Caching depende de dois fatores:

  • Os padrões de uso para os dados por usuários e aplicativos dependentes são predominantemente somente leitura. Em determinados cenários como sites de comércio eletrônico, a porcentagem de acesso somente leitura (às vezes chamado de procura) é até 95% de todas as interações do usuário com o site.

  • O modelo de informações do aplicativo fornece uma camada adicional de informações semânticas que dão suporte à identificação de dados estáveis e singulares que sejam ideais para caching.

Caching de dispositivos

Embora não seja o foco para a iniciativa à prova de falhas, o caching de dispositivos é uma das maneiras mais eficazes de aumentar a usabilidade e a robustez de qualquer aplicativo de dispositivos + serviços. Existem várias maneiras para fornecer serviços de caching na camada de dispositivo ou cliente, variando da especificação de HTML5 que fornece recursos nativos de caching implementados em todos os navegadores padrão até instâncias do banco de dados local como SQL Server Compact Edition ou semelhante.

Caching distribuído

O caching distribuído é um conjunto avançado de recursos, mas sua finalidade não é substituir um banco de dados relacional ou outro repositório persistente; em vez disso, sua finalidade é aumentar a resposta de aplicativos distribuídos que são centrados em rede por natureza e, portanto, sensíveis à latência. Um benefício extra de introduzir o caching é a redução do tráfego para o repositório de dados persistente, o que minimiza as interações com seu serviço de dados.

  • Modelos de informações otimizados para caching

    noteObservação
    Muito do conteúdo desta seção é baseado no ótimo trabalho feito por Pat Helland quando ele estava pensando sobre dados em um mundo de arquitetura orientada a serviços. Leia todo o artigo no Microsoft Developer Network.

    Os dados armazenados em cache são pela própria natureza obsoletos, ou seja, dados que não estão mais necessariamente atualizados. Um ótimo exemplo dos dados armazenados em cache, embora de um domínio muito diferente, é um catálogo de produtos que está sendo enviado para milhares de residências. Os dados usados para gerar o catálogo de produtos foram atualizados quando o catálogo foi criado. Assim que as impressoras começaram a funcionar, os dados, pela natureza da passagem de tempo durante o processo de produção do catálogo, ficaram obsoletos. Devido ao fato de os dados armazenados em cache serem obsoletos, os atributos dos dados em relação à estabilidade e à singularidade são críticos para o design do caching:

    • Estabilidade - dados que têm uma interpretação não ambígua através do espaço e do tempo. Isso geralmente significa valores de dados que não são alterados. Por exemplo, a maioria das empresas nunca reciclam identificações de cliente ou números de SKU. Outra técnica para criar dados estáveis é a adição de datas de validade aos dados existentes. O exemplo do catálogo de produtos impresso acima é um ótimo exemplo. Normalmente, os varejistas aceitam pedidos de qualquer catálogo determinado para 2 períodos de publicação. Se alguém publicar um catálogo quatro vezes por ano, os dados de catálogo de produto ficarão estáveis por 6 meses e poderão ser utilizados para o processamento de informações como realização e entrega de pedidos.

      Os dados estáveis são geralmente referenciados como mestre ou dados de referência. Na iniciativa à prova de falhas, utilizaremos o termo dados de referência porque é semanticamente mais inclusivo do que dados mestre. Em muitas empresas, os dados mestre têm um significado específico e muito mais estreito que dados de referência.

    • Singularidade - dados que podem ser isolados por meio de associação com instâncias exclusivamente identificáveis com pouca ou nenhuma atualização simultânea. Utilize o exemplo de um carrinho de compras. Embora o carrinho de compras será claramente atualizado, as atualizações ocorrem de maneira relativamente infrequente e podem ser completamente isoladas do armazenamento assim como da perspectiva de processamento.

      Os dados isoláveis, conforme descritos acima, são referenciados como dados da atividade ou dados da sessão.

      Com esses dois atributos em mente, surge o seguinte esquema:

      Diagrama de tipos de dados
      Figura 9

  • Modelagem de informações

    Muitos arquitetos ou desenvolvedores de aplicativos pensam em modelos de objeto ou entidade quando pensam em modelagem de informações. Embora os modelos de objeto ou entidade façam parte da arte e da ciência da modelagem de informações, muito mais entra em um modelo de informações para que se obtenha um aplicativo à prova de falhas.

    Uma primeira visão dos processos de pensamento necessários para o mundo distribuído de hoje em dia concentra-se na estabilidade e na singularidade. Outro elemento importante é entender como os dados estão sendo utilizados na interação com o usuário/dispositivo ou como parte dos processos empresariais a serem implementados. A modelagem orientada por objeto deve fazer parte do design de informações de várias maneiras:

    • Ocultação de informações - ocultar ou não fornecer acesso a informações que não são úteis para o usuário ou processo empresarial é uma das melhores maneiras de evitar conflitos com recursos ou dados compartilhados que são armazenados e gerenciados em um banco de dados relacional.

      Um ótimo exemplo de como ocultar informações é utilizado de maneira eficaz para melhorar a simultaneidade é a diferença entre um sistema típico de ERP e o modo como a Amazon.com gerencia a maioria dos cenários de estoque. Em uma implementação típica de um sistema de ERP, a tabela de estoque é uma das tabelas mais congestionadas ou ativas (se supormos uma implementação de banco de dados relacional). O aplicativo de ERP geralmente tenta bloquear o estoque até que o usuário conclua a transação, fornecendo a contagem exata de estoque para o aplicativo no momento do início da transação comercial. Alguns sistemas -- como o SAP -- evitam o bloqueio de banco de dados, mas adquirem um bloqueio de aplicativo em seu sistema de enfileiramento. Várias técnicas na camada de banco de dados foram desenvolvidas para ajudar com esse congestionamento: controle de simultaneidade otimista, leituras sujas etc. Nenhum realmente funciona corretamente e todos têm efeitos colaterais. Em determinados cenários, você quer bloquear a tabela, mas devem ser muito poucos e raros.

      A Amazon.com resolveu o problema de maneira muito mais simples: eles ofereceram ao usuário um SLO (objetivo de nível de serviço) em que o usuário pode optar e aceitar ou rejeitar. O SLO foi geralmente expresso como “geralmente disponível em N horários”: o usuário não viu a contagem real de livros ou outros itens disponíveis, mas foram fornecidas informações sobre a disponibilidade mesmo assim. Nenhum bloqueio de banco de dados foi necessário. De fato, não foi necessária nenhuma conectividade de banco de dados. Se o sistema não puder localizar o SLO, ele enviará uma desculpa para o comprador (normalmente por email) e oferecerá um SLO atualizado.

    • Recursos fungíveis: O dicionário define fungível como: "fungível (especialmente produtos) sendo de natureza ou tipo livremente substituível ou intercambiável, na totalidade ou em parte, por outro de natureza ou tipo semelhante". O núcleo da ideia, com o objetivo de mais uma vez reduzir a fricção de acessar dados compartilhados, é usar a modelagem de informações para fornecer uma maneira de fazer o usuário interagir com uma instância fungível de dados em vez de uma instância específica. Um ótimo exemplo é reservar um quarto de hotel. A pessoa pode expressar muita especificidade, como número de camas, vista para o mar, fumante/não fumante etc. sem nunca se referir ao quarto '123'. Usando modelagem desse jeito, é totalmente viável armazenar em cache as informações sobre pools de dados fungíveis, executar o processo comercial no pool e, apenas após a finalização do processo de check-in, atribuir uma sala específica fora desse pool. Os modelos híbridos de remover uma sala específica de um pool assim que o processo de check-in inicia também são completamente viáveis.

  • Gerenciando o cache

    O caching das informações certas no momento certo é uma parte fundamental de uma estratégia bem-sucedida de caching. Existem várias técnicas para carregar o cache: uma boa visão geral é descrita em “Cache em ambiente distribuído”. Além disso, as seções a seguir descrevem algumas considerações para a criação de aplicativo à prova de falhas que dependem de caching distribuído.

    • Dados de referência - se o ambiente de hospedagem (controlador de malha ou datacenter) encontrar um desastre, seu aplicativo será movido para outro ambiente. Nos casos em que uma instância ativa do seu aplicativo já estiver ativa (design ativo-ativo), a probabilidade de o cache já conter muitas informações relevantes (principalmente dados de referência) será alta. No caso de uma nova instância do aplicativo ser girada, nenhuma informação ficará nos nós de cache. Você deve criar seu aplicativo de modo que, se houver um erro de cache, ele automaticamente carregará os dados desejados. No caso de uma nova instância, você poderá ter uma rotina de inicialização que carrega em massa os dados de referência para o cache. Uma combinação dos dois é desejáveis para que os usuários possam estar ativos assim que o aplicativo estiver sendo servido pela infraestrutura em nuvem.

    • Dados da atividade - as técnicas básicas descritas para dados de referência também servem para os dados da atividade. No entanto, há um detalhe específico para os dados da atividade. Os dados de referência devem estar disponíveis em qualquer repositório persistente do aplicativo. Como eles serão alterados com menos frequência, a sincronização não deve ser um problema, embora precise ser considerada. No entanto, os dados da atividade, embora sejam atualizados em isolamento e com pouca frequência, serão mais voláteis que os dados de referência. Idealmente, o cache distribuído persiste dados da atividade com frequência e replica os dados entre as várias instâncias do aplicativo. Tome cuidado para garantir que os intervalos de persistência e sincronização sejam espaçados o suficiente para evitar a contenção, mas aproximados o suficiente para minimizar a possível perda de dados.

Um erro comum é a relação, especificamente as áreas de responsabilidade, entre a plataforma e o aplicativo. Uma das áreas onde isso é mais problemático é em relação aos dados.

Embora uma plataforma como o Azure entregue promessas de armazenar várias cópias de dados (e em alguns serviços, chegam a oferecer redundância geográfica), os dados que são armazenados são controlados pelo aplicativo, pela carga de trabalho e pelos serviços de componentes. Se o aplicativo executar uma ação que corrompa seus dados de aplicativo, a plataforma armazenará várias cópias deles.

Ao estabelecer os modos e os pontos de falha, é importante identificar as áreas do aplicativo que podem causar corrupção dos dados. Embora o ponto de origem possa variar de código incorreto ou mensagens suspeitas para seu serviço, é importante identificar os modos de falha e os pontos de falhas relacionados.

Solução de nível de aplicativo

  • Idempotência

    Um pressuposto central com serviços conectados é que eles não estarão 100% disponíveis e que o tratamento de falha transitória com lógica de repetição é uma abordagem central de implementação. Nos casos em que a lógica de repetição está implementada, há o potencial para que a mesma mensagem seja enviada mais de uma vez, para que as mensagens sejam enviadas fora de sequência etc.

    As operações devem ser criadas para serem idempotentes, garantindo que o envio da mesma mensagem várias vezes não resulte em um repositório de dados inesperado ou poluído.

    Por exemplo, inserir dados de todas as solicitações pode resultar na adição de vários registros se a operação de serviço for chamada várias vezes. Uma abordagem alternativa seria implementar o código como um “upsert” inteligente, que executará uma atualização se um registro existir ou uma inserção se não. Um carimbo de data/hora ou um identificador global podem ser usados para identificar mensagens novas e mensagens processadas previamente, inserindo somente as mais novas no banco de dados e atualizando registros existentes se a mensagem for mais nova do que a que foi recebida no passado.

  • Atividades de carga de trabalho e comportamento de compensação

    Além da idempotência, outra área a ser considerada é o conceito de comportamento de compensação.

    Um exemplo do mundo real de comportamento de compensação é visto ao devolver um produto que é pago com cartão de crédito. Neste cenário, um consumidor visita uma loja, fornece um cartão de crédito e uma cobrança é aplicada à conta de cartão de crédito dele. Se o consumidor devolver o produto para o fornecedor, uma política será avaliada e, se a devolução estiver de acordo com ela, a loja emitirá um crédito para o valor da compra para a conta de cartão de crédito do consumidor.

    Em um mundo de conjuntos de sistemas cada vez mais conectados e a emergência de serviços compostos, é importante entender como controlar o comportamento de compensação.

    Para muitos desenvolvedores de aplicativos de linha de negócios, os conceitos de transações não são novos, mas o quadro de referência é geralmente vinculado à funcionalidade transacional exposta por tecnologias de dados locais e por bibliotecas de código relacionadas. Ao examinar o conceito em termos de nuvem, essa mentalidade precisa fazer novas considerações relacionadas à orquestração de serviços distribuídos.

    Uma orquestração de serviço pode abranger vários sistemas distribuídos e ter execução longa e de estado. A própria orquestração raramente é síncrona e pode ir de segundos a anos com base no cenário de negócios.

    Em um cenário de cadeia de fornecimento, isso pode unir 25 organizações na mesma atividade de carga de trabalho. Por exemplo, pode haver um conjunto de 25 ou mais sistemas que estão interconectados em uma ou mais orquestrações de serviço.

    Se houver êxito, os 25 sistemas devem ser informados de que a atividade foi bem-sucedida. Para cada ponto de conexão na atividade, os sistemas participantes podem fornecer uma ID de correlação para as mensagens recebidas de outros sistemas. Dependendo do tipo de atividade, o recebimento dessa ID de correlação pode atender a parte da transação que está completa de forma nocional. Em outros casos, após a conclusão das interações de todas as 25 partes, uma mensagem de confirmação pode ser enviada para todas as partes (diretamente de um único serviço ou por pontos específicos da interação de orquestração para cada sistema).

    Para tratar as falhas na composição e/ou em atividades distribuídas, cada serviço deve expor uma interface de serviço e operações para receber solicitações para cancelar uma determinada transação por um identificador exclusivo. Por trás da fachada de serviço, os fluxos de trabalho devem ser utilizados para compensar o cancelamento dessa atividade. De modo ideal, eles seriam procedimentos automatizados, mas podem ser simples como o roteamento para uma pessoa na organização para reparar manualmente.

Backups

Além da solução no nível do aplicativo para evitar a corrupção de dados, também há a solução que é utilizada para fornecer opções se a solução do aplicativo não for bem-sucedida.

Os processos para criar e restaurar cópias de backup de seu repositório de dados – inteira ou parcialmente – devem fazer parte de seu plano de resiliência. Embora os conceitos de backup e restauração de dados não sejam novos, há detalhes para isso na nuvem.

Sua estratégia de backup deve ser definida com uma compreensão consciente dos requisitos do negócio para restaurar dados. Se um repositório de dados for corrompido ou ficar offline devido a um cenário de desastre, você precisará saber o tipo de dados e o volume que deve ser restaurado, e o ritmo necessário para negócios. Isso afetará o seu plano de disponibilidade geral e deve orientar seu planejamento de backup e restauração.

  • Bancos de dados relacionais

    Fazer backup de bancos de dados relacionais não é nada novo. Muitas organizações utilizam ferramentas, abordagens e processos para fazer backup dos dados para atender às necessidades de recuperação de desastres ou conformidade. Em muitos casos, as ferramentas de backup, as abordagens e os processos tradicionais podem funcionar com pouca ou nenhuma modificação. Além disso, existem alternativas novas ou variáveis que podem ser consideradas, como backup de dados e armazenamento de uma cópia em um armazenamento de blob baseado em nuvem.

    Ao avaliar os processos e as ferramentas existentes, é importante avaliar qual abordagem é apropriada para a solução baseada em nuvem. Em muitos casos, uma ou mais das abordagens listadas a seguir serão aplicadas para solucionar os diferentes modos de falha.

    1. Backup total - este é um backup de um repositório de dados em sua totalidade. Os backups totais devem ocorrer com base em uma agenda ditada pelo volume de dados e pela velocidade. Um backup total é o conjunto de dados completo necessário para entregar o contrato de nível de serviço para o serviço. Os mecanismos para esse tipo de backup estão geralmente disponíveis pelo banco de dados/provedor de serviços do banco de dados ou ecossistema de fornecedor.

    2. Pontual - um backup pontual é um backup que reflete um determinado ponto no tempo na existência do banco de dados. Se ocorrer um erro de corrupção do repositório de dados no período da tarde, por exemplo, um backup pontual feito ao meio-dia poderá ser restaurado para minimizar o impacto de negócios.

      Considerando o nível crescente de conectividade dos indivíduos, a expectativa de envolvimento com seu serviço a qualquer hora do dia transforma em necessidade a capacidade de restaurar rapidamente para um ponto recente no tempo.

    3. Sincronização - além dos backups tradicionais, outra opção é a sincronização de dados. Os dados podem ser armazenadas em vários data centers, por exemplo, com uma sincronização periódica de dados de um datacenter para outro. Além de fornecer dados sincronizados em soluções que utilizam o gerenciamento de tráfego como parte de um plano de disponibilidade normal, isso também pode ser usado para o failover em um segundo data center se houver um problema de continuidade de negócios.

      Considerando a conectividade constante dos indivíduos consumindo serviços, o tempo de inatividade se tornará cada vez menos aceitável para inúmeros cenários e a sincronização pode ser uma abordagem desejável.

      Os padrões para sincronização podem incluir:

      - data center para data center de um determinado provedor na nuvem

      - data center para data center entre provedores na nuvem

      - data center para data center do local para um determinado provedor na nuvem

      - data center para sincronização de dispositivo para fatias de dados específicas do consumidor

  • Bancos de dados relacionais fragmentados

    Para muitos, a mudança para a nuvem é orientada por uma necessidade de facilitar um grande número de usuários e cenários de tráfego intenso como os relacionados aos aplicativos móveis ou sociais. Nesses cenários, o padrão do aplicativo geralmente envolve migrar de um modelo de banco de dados único para vários fragmentos de banco de dados que contêm uma parte do conjunto de dados total e são otimizados para o envolvimento de grande escala. Um projeto recente de redes sociais criado no Azure foi iniciado com um total de 400 fragmentos de banco de dados.

    Cada fragmento é um banco de dados autônomo e sua arquitetura e gerenciamento devem facilitar os backups totais, backups pontuais e restauração de backups para os fragmentos individuais e um conjunto de dados completo incluindo todos os fragmentos.

  • Repositório de dados NoSQL

    Além dos repositórios de dados relacionais, as políticas de backup devem ser consideradas também para “não apenas SQL” ou repositórios de dados NoSQL. A forma mais popular de bancos de dados NoSQL fornecidos pelos principais provedores na nuvem seria uma forma de repositório de pares de valor-chave de alta disponibilidade, geralmente denominado de repositório de tabela.

    Os repositórios NoSQL podem ser altamente disponíveis. Em alguns casos, eles também podem ser redundantes geograficamente, o que pode ajudar a evitar a perda no caso de uma falha catastrófica em um data center específico. Esses repositórios normalmente não fornecem proteções contra substituições ou exclusões não intencionais de conteúdo. Os erros de aplicativo ou de usuário não são tratado automaticamente por serviços de plataforma como armazenamento de blob e uma estratégia de backup deve ser avaliada.

    Enquanto os bancos de dados relacionais geralmente têm ferramentas existentes e bem conhecidas para executar backups, muitos repositórios NoSQL não têm. Uma abordagem arquitetônica popular é criar uma cópia duplicada de dados em um repositório NoSQL de réplica e usar uma tabela de pesquisa de um determinado tipo para identificar quais linhas de repositório de origem foram colocadas no repositório da réplica. Para restaurar dados, essa mesma tabela será utilizada, lendo a tabela para identificar o conteúdo no repositório da réplica disponível para ser restaurado.

    Dependendo das preocupações de continuidade de negócios, a colocação desta réplica pode ser hospedada com o mesmo provedor de nuvem, no mesmo data center e/ou o mesmo repositório de dados NoSQL. Ela também pode residir em um data center diferente, em um provedor de nuvem diferente e/ou em um repositório de dados NoSQL variável. O que definirá a colocação será em grande parte influenciado pelo SLA desejado do serviço da sua carga de trabalho e por todas as considerações reguladoras de conformidade relacionadas.

    Um fator a considerar ao fazer essa determinação é o custo, especificamente porque ele se relaciona com o ingresso e a saída de dados. Os provedores de nuvem podem fornecer um movimento de dados livre dentro de seus data centers e permitir a passagem livre dos dados em seu ambiente. Nenhum provedor de nuvem oferece saída gratuita de dados e o custo de mover dados para um provedor secundário de plataforma de nuvem pode representar custos significativos na escala.

    noteObservação
    A tabela de pesquisa torna-se um ponto de falha potencial e uma réplica dela deve ser considerada como parte do planejamento de resiliência.

  • Armazenamento de blob

    Como repositórios de dados relacionais e NoSQL, um equívoco comum é que os recursos de disponibilidade implementados para uma opção de armazenamento de blob removerá a necessidade de implementar uma política de backup.

    O armazenamento de blob também pode ser redundante geograficamente, como descrito anteriormente, mas não protege contra erros de aplicativo. Os erros de aplicativo ou de usuário não são tratado automaticamente por serviços de plataforma como armazenamento de blob e uma estratégia de backup deve ser avaliada.

    As estratégias de backup podem ser muito semelhantes às usadas para repositórios NoSQL. Devido ao tamanho potencialmente grande dos blobs, os custos e o tempo para mover os dados serão partes importantes de uma estratégia de backup e restauração.

  • Restaurando backups

    A maioria das pessoas já deve ter ouvido a história preventiva da organização que estabelecia e seguia diligentemente as polticas de backup, mas nunca testaram a restauração de dados. Naquele dia fatídico quando um desastre ocorreu, foram restaurar o backup do banco de dados para descobrir que configuraram o backup incorretamente e as fitas que eles vinham enviando para fora por anos não continham as informações necessárias.

    Não importa os processos de backup que estão em uso, é importante estabelecer testes para verificar se os dados podem ser restaurados corretamente e garantir que a restauração ocorra de maneira oportuna e com impacto mínimo nos negócios.

As CDNs (Redes de Fornecimento de Conteúdo) são uma forma popular de proporcionar disponibilidade e experiência de usuário aprimorada para arquivos solicitados com frequência. O conteúdo em uma CDN é copiado para um nó local no primeiro uso e, em seguida, servido desse nó local para as solicitações subsequentes. O conteúdo expirará depois de um período de tempo designado, depois do qual o conteúdo deverá ser copiado novamente para o nó local na próxima solicitação.

Usar uma CDN oferece inúmeras vantagens, mas também adiciona uma dependência. Como ocorre com qualquer dependência, a solução de uma falha de serviço deve ser verificada de maneira proativa.

Uso apropriado de uma CDN

Um equívoco comum é que as CDNs são uma cura para a escala. Em um cenário, um cliente estava seguro de que essa era a solução certa para uma loja online de livros eletrônicos. Não era. Por quê? Em um catálogo de milhões de livros, havia um pequeno subconjunto de livros que eram solicitados com frequência (as "ocorrências") e uma cauda muito longa de livros que eram solicitados com uma previsibilidade muito pequena. Os títulos solicitados com frequência seriam copiados para o nó local na primeira solicitação e forneceriam uma escala local econômica e uma experiência do usuário agradável. Para a cauda longa, quase todas as solicitações são copiadas duas vezes – uma vez no nó local e, em seguida, no cliente – já que as solicitações raras resultam em conteúdo expirado regularmente. Essa é evidência de que um CDN utilizado de forma incorreta teria o oposto do efeito desejado: uma solução mais lenta e mais cara.

Em muitos casos, as operações de uma solução não podem ser planejadas até posteriormente no ciclo de vida. Para criar aplicativos de fato resilientes, eles devem ser criados para operações. Criar para operações geralmente inclui atividades importantes como estabelecer um modelo de integridade, capturar informações de telemetria, inserir serviços de monitoramento de integridade e fluxos de trabalho e tornar esses dados acionáveis por operações e desenvolvedores.

Equipes de desenvolvimento geralmente desconsideram e muitas vezes ignoram completamente a “integridade” do aplicativo. Como resultado, os serviços geralmente vão para produção com dois estados conhecidos: ativos ou inativos. Os designers de serviços resilientes devem desenvolver modelos de integridade que definem critérios de integridade do aplicativo, e dependências reduzidas de estado de integridade e falha.

Desenvolver de maneira proativa um modelo de integridade descreve os modos e os pontos de falha, exigindo que os desenvolvedores identifiquem e estudem os cenários hipotéticos nas fases de concepção do aplicativo. Para operacionalizar um modelo de integridade, um serviço deverá ser capaz de comunicar sua integridade. Ele deve ter uma maneira programática de divulgar essas informações, fornecer uma interface para o estado de integridade a ser consultado interativamente, fornecer mecanismos (ou ganchos em mecanismos existentes) por meio dos quais os administradores possam monitorar a integridade do aplicativo em tempo real e estabelecer os mecanismos pelos quais os administradores poderão, quando for necessário, providenciar medidas corretivas para retornar o aplicativo para um estado íntegro.

Definir as características

Para um determinado serviço ou aplicativo, os diagnósticos devem ser feitos para identificar pontos de dados e intervalos de valores que indicam pelo menos três categorias de integridade: íntegro, integridade diminuída e não íntegro. Essas informações podem ser utilizadas para automatizar a autorrecuperação dos serviços.

Definir interfaces

Com os estados de integridade definidos, um serviço deve expor as interfaces relacionadas à integridade. Essas interfaces fornecerão as seguintes categorias de operações.

  • Emitir o status de integridade para serviços de parceiros assinados

    Um serviço deve emitir as informações de integridade para serviços de parceiros assinados. Esse status de integridade deve ser conciso, com integridade de alto nível e diagnóstico básico.

    O serviço deve fornecer o recurso para um serviço do parceiro assinar as mensagens de integridade. A entrega de mensagens de integridade pode ocorrer pelos caminhos apropriados à solução. Um caminho pode ter as atualizações de estado de integridade do local do serviço em uma fila que pode ser recuperada por assinantes.

    Uma abordagem alternativa é permitir que os assinantes forneçam um ponto de extremidade no qual uma interface conhecida do relatório de integridade seja exposta. Quando as informações de integridade são alteradas, ele pode emitir as informações para os assinantes em seus pontos de extremidade fornecidos.

  • Expor interfaces para entregar dados de telemetria

    A telemetria é ótima para operações porque ajuda a identificar a integridade atual do aplicativo e/ou serviços em vários níveis. Ela também pode ajudar a identificar rapidamente quando algo atípico está ocorrendo no ambiente. Isso fornece uma exibição consideravelmente granular do serviço e está exposto para as equipes de operações e painéis do provedor de serviços.

    Para as operações, as métricas da telemetria podem incluir, por exemplo, a porcentagem média de CPU, os erros, as conexões e as filas para as diferentes funções, serviços e os aplicativos compostos integrados nos serviços.

    A telemetria específica de aplicativo geralmente não é habilitada e monitorada automaticamente diretamente pela própria plataforma. Portanto, a telemetria deve ser habilitada pelo serviço e pelo aplicativo.

  • Expor interfaces para interrogar o serviço para obter informações adicionais de diagnóstico de integridade

    Um serviço deve idealmente também fornecer interfaces para interrogar informações adicionais de diagnóstico de integridade. Os serviços do assinante, com base nas informações de alto nível recebidas no status de integridade, podem solicitar informações adicionais para determinar um direcionamento com sua relação com o serviço que fornece seus detalhes de integridade.

    Especificamente, se o serviço parece estar em um estado de integridade inadequado, informações adicionais podem permitir que um serviço consumidor tome uma decisão de continuar a usar o serviço ou realizar failover para um provedor alternativo.

  • Expor interfaces para solucionar integridade de serviço no nível do aplicativo e do serviço

    Se o consumidor de informações de integridade for um serviço interno ou relacionado, você poderá habilitar o serviço para solucionar por conta própria os problemas conhecidos. Assim como ocorre com a medicina humana, a compreensão da integridade do serviço evoluirá com o passar do tempo e os dados de integridade podem levar em cursos de tratamento diferentes.

    Um serviço deve expor uma interface para permitir a realização desse tratamento. Em sua forma mais simples, isso poderia variar de acionar uma reinicialização ou criação de nova imagem de um serviço para realizar failover para um provedor de serviços ou de dados internos diferente.

    Compreender a integridade de um serviço pode habilitar o provedor de serviços para identificar rapidamente se um serviço não está íntegro. As operações automatizadas podem fornecer soluções rápidas, consistentes e prescritivas de problemas conhecidos e fazer a recuperação do serviço. Esta seção examina os aspectos diferentes de integridade com mais detalhes.

Telemetria é “o processo de usar equipamento especial para fazer medições de algo (como pressão, velocidade ou temperatura) e enviá-las por rádio para outro lugar.”

É importante que você colete dados de telemetria de seu serviço. A telemetria geralmente é categorizada como um dos quatro tipos: Usuário, Negócios, Aplicativo e Infraestrutura.

Telemetria do usuário destina o comportamento de um usuário individual em questão. Isso oferece uma compreensão do comportamento de um usuário e pode facilitar a entrega de uma experiência individualizada como resultado.

Telemetria dos negócios contém dados relacionados às atividades de negócios e indicadores chave de desempenho (KPIs) para os negócios. Exemplos de telemetria dos negócios incluem o número de usuários ativos exclusivos em um site, o número de vídeos assistidos, etc.

Telemetria do aplicativo contém detalhes sobre integridade, desempenho e atividade da camada do aplicativo e seus serviços dependentes. A telemetria de aplicativo poderia conter detalhes, por exemplo, sobre dados que o cliente chama e registra, exceções, chamadas de API, sessões, etc.

Telemetria de infraestrutura inclui detalhes sobre a integridade da infraestrutura do sistema subjacente. Isso pode incluir dados sobre recursos como CPU, memória, rede, capacidade disponível, etc.

Quando identificar quais dados coletar e como coletá-los, é importante entender os dados e o que pretende fazer com eles.

Primeiro, determine se o objetivo dos dados que estão sendo coletados é informar ou iniciar uma ação. A pergunta é, “quão rapidamente eu deveria reagir?” Você usaria os dados quase que em tempo real para possivelmente iniciar uma ação? Como alternativa, você usaria os dados em um relatório de tendência mês a mês? A resposta a essas perguntas informaria a abordagem da telemetria e as tecnologias usadas na arquitetura.

Em seguida, identifique o tipo de pergunta(s) que você pretende aplicar aos dados da telemetria que está coletando. Você usará a telemetria para responder perguntas conhecidas ou usará a telemetria para exploração. Por exemplo, para um negócio, os KPIs são respostas a perguntas conhecidas. Entretanto, um fabricante que deseja explorar os dados do dispositivo para padrões que resultam em falhas, deveria arriscar o desconhecido. Para o fabricante, as falhas são derivadas de um ou mais itens no sistema. O fabricante está fazendo explorações e precisará de dados adicionais.

Quando usar a telemetria para obter percepção, deve considerar o tempo necessário para obter essa percepção. Em alguns casos, você melhorará a telemetria para detectar um pico em uma leitura de sensor do dispositivo que tem um intervalo de segundos ou minutos. Em outros casos, pode usar a telemetria para identificar crescimento de usuário semana por semana de um site que possui uma janela maior.

Finalmente, considere a quantidade de dados que deseja reunir de uma fonte de sinal dentro do cronograma para obter a percepção. Você deve saber a quantidade certa de sinal fonte de que necessita. Você então pode determinar a melhor maneira de particionar esse sinal e estabelecer a mistura apropriada de computação local e global.

Outra consideração é como registrar a sequência de eventos em sua telemetria. Muitas organizações padronizarão para carimbo de data/hora. O carimbo de data/hora entretanto pode ser um desafio, porque os relógios do servidor e vários data centers são inconsistentes. Enquanto o tempo pode ser sincronizado periodicamente, há evidência documentada que ocorre dessincronização dos relógios do servidor (lentamente, eles se tornam mais imprecisos). Essa dessincronização resulta em mudanças que podem prejudicar a análise efetiva. Para cenários que requerem precisão, considere soluções alternativas, como melhorar uma implementação de relógio de vetor.

Depois de identificar uma abordagem de telemetria, avance para caracterizar o sinal.

Você pode classificar o sinal como contínuo ou discreto. Um exemplo de sinal contínuo é dados de evento em tempo real. Entradas de arquivos de log são partes de um sinal discreto.

Para satisfazer as necessidades de sua abordagem, você deve identificar quantos dados estão no sinal. Se a informação for contínua, você deve estabelecer uma taxa de amostragem. Se for discreta, deve identificar os registros a manter ou filtrar.

Você também deve identificar o tipo de acesso. Em muitos casos, será apropriado usar os dados da telemetria. Em outros casos, recuperará os dados da telemetria por extração.

Em sistemas mais evoluídos, você pode encontrar essa percepção obtida de telemetrias existentes que podem resultar em extração de informações adicionais. Por exemplo, se telemetria enviada por push indica um estado abaixo do ideal, você pode recuperar dados diagnósticos adicionais por extração.

Todos os dados coletados podem ser relevantes sob certas condições, mas nem todos os dados de telemetria devem ser enviados sempre. De acordo com o tipo de telemetria e a quantidade de dados necessários para derivar a percepção, talvez você possa recuperar pequenas quantidades de dados. Você pode usar computação local para gerar agregados, exemplos e subconjuntos, e enviar esses dados ao serviço. Se os dados recebidos da telemetria padrão indicam um estado abaixo do ideal, por exemplo, o serviço pode precisar de dados adicionais.

Quando desenvolver uma estratégia de telemetria, considere quais políticas são apropriadas. A telemetria requer conectividade disponível e há um custo para enviar dados nessa conexão. Crie políticas que consideram contexto, conectividade e custo e ajuste a telemetria conforme apropriado.

Suas políticas devem considerar o contexto do estado atual para determinar qual telemetria é apropriada para envio no exato momento. Essa percepção é obtida de telemetria recebida anteriormente e os negócios associados precisam informar o contexto. Esse contexto ajuda a direcionar e priorizar a coleta da telemetria.

Esses dispositivos podem ter vários tipos de conectividade (WiFi, LTE, 4G, 3G, etc.), e essa conectividade pode ser variável. A conectividade do dispositivo agora é relevante para determinar quais dados devem ser transmitidos. Em cenários onde a conectividade é pouco confiável ou a velocidade da conectividade é baixa, a política pode priorizar a telemetria transmitida.

Conectividade geralmente é fornecida a um custo. As políticas considerarão se uma conexão é atualmente uma medida ou não medida. Se for uma conexão medida, as políticas identificarão os custos associados e, se disponível, os limites de uso. Muitos dispositivos utilizam diferentes tipos de conexões durante o curso de um dia. Você pode priorizar ou não priorizar uma telemetria específica de acordo com o custo para fornecê-la.

Diferentes públicos geralmente utilizam e visualizam dados de telemetria. Operações e desenvolvedores são dois públicos para os quais a visualização é importante. No entanto, conforme destacado abaixo, as necessidades de cada público requerem diferentes níveis de granulidade.

Visualizar status de operação de alto nível e uma telemetria de baixo nível é importante para a equipe de operações. Notificações automatizadas provavelmente serão entregues de acordo com os dados da telemetria. Todavia, Operações podem desejar um painel que ajude a visualizar o desempenho do serviço atual e histórico.

Para aplicativos de escala significativa, essas informações podem ajudar a identificar um problema atual rapidamente ou prever um problema futuro. Isso também pode ajudar o setor de Operações a identificar possíveis impactos e causas raiz.

Diagrama de painel de desempenho

Figura 10

O diagrama acima de um grande site social observa a % média de CPU de função de API, os erros de API, usuários online, conexões ativas da Web, % de CPU de função da Web, erros da Web, conexões de hardware da Web, conexões agrupadas da Web, fila de aplicativos da Web, conexões de software da Web.

A telemetria e o tipo de relatório mostrado acima são particularmente úteis nos casos em que as operações podem solucionar os erros sem alterações de código para os próprios serviços. Os exemplos de atividades que as operações podem realizar podem incluir implantar mais funções e reciclar instâncias.

Você pode melhorar a visualização de dados de telemetria históricos e em tempo real para:

  • Solução de problemas.

  • Post-mortems feitas após problemas de sites ativos.

  • Treinamento de novos funcionários para Operações.

Além da equipe de operações, os desenvolvedores de software são consumidores importantes de dados de telemetria. Os erros não podem ser vinculados ao ambiente operacional e por isso podem estar vinculados ao código do aplicativo subjacente. Ter um painel de telemetria para desenvolvedores permite que eles tomem uma medida direcionada.

Abaixo estão capturas de telas de um utilitário de exemplo que foi criado para esse fim. O painel fornece detalhes sobre o número de erros, de quais categorias os erros fazem parte e os dados específicos relacionados a cada uma dessas categorias. Isso inclui um exame dos dados que inclui o número total de erros, o número total de função de instâncias de função que apresentam erros e o número total de bancos de dados que têm o erro.

Diagrama de painel

Figura 11

Diagrama de painel

Figura 12

Para grandes sites com milhões de usuários envolvidos, contas de erro mais altas ocorrerão e podem ser perfeitamente aceitáveis. Ter um painel voltado para o desenvolvedor que interprete a telemetria pode ajudar a identificar se há um problema de fato, se é apropriado se envolver e onde no código o problema está ocorrendo.

Consulte também

Mostrar:
© 2015 Microsoft