Antipattern: respostas de erro de cache

Está a ver a documentação do Apigee e do Apigee Hybrid.
Ver documentação do Apigee Edge.

O armazenamento em cache é um processo de armazenamento de dados temporariamente numa área de armazenamento denominada cache para referência futura. O armazenamento de dados em cache oferece vantagens significativas em termos de desempenho porque:

  • Permite uma obtenção mais rápida de dados
  • Reduz o tempo de processamento, evitando a regeneração dos dados repetidamente
  • Impede que os pedidos da API atinjam os servidores de back-end e, assim, reduz a sobrecarga nos servidores de back-end
  • Permite uma melhor utilização dos recursos do sistema/aplicação
  • Melhora os tempos de resposta das APIs

Sempre que tivermos de aceder frequentemente a alguns dados que não se alteram com muita frequência, recomendamos vivamente que use uma cache para armazenar estes dados.

O Apigee oferece a capacidade de armazenar dados numa cache no momento da execução para persistência e obtenção mais rápida. A funcionalidade de colocação em cache é disponibilizada através da política PopulateCache, política LookupCache, política InvalidateCache e política ResponseCache.

Nesta secção, vamos analisar a política de cache de respostas. A política de cache de respostas na plataforma Apigee permite colocar em cache as respostas dos servidores de back-end. Se as aplicações cliente fizerem pedidos ao mesmo recurso de back-end repetidamente e o recurso for atualizado periodicamente, podemos colocar estas respostas em cache através desta política. A política de cache de respostas ajuda a devolver as respostas em cache e, consequentemente, evita o encaminhamento desnecessário dos pedidos para os servidores de back-end.

A política de cache de respostas:

  • Reduz o número de pedidos que chegam ao back-end
  • Reduz a largura de banda da rede
  • Melhora o desempenho da API e os tempos de resposta

Antipattern

A política ResponseCache permite-lhe colocar em cache respostas HTTP com qualquer código de estado possível, por predefinição. Isto significa que as respostas de êxito e de erro podem ser colocadas em cache.

Segue-se um exemplo de uma política de cache de respostas com a configuração predefinida:

<!-- /antipatterns/examples/1-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServer ResponseCache</DisplayName>
  <CacheKey>
    <Key Fragment ref="request.uri" /></CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
      <TimeoutInSec ref="flow.variable.here">600</TimeoutInSec>
    </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
</ResponseCache>

A política de cache de respostas armazena em cache as respostas de erro na respetiva configuração predefinida. No entanto, não é aconselhável colocar em cache respostas de erro sem ponderar as implicações adversas, porque:

  • Cenário 1: ocorrem falhas durante um período temporário desconhecido e podemos continuar a enviar respostas de erro devido ao armazenamento em cache, mesmo depois de o problema ter sido corrigido

    OU

  • Cenário 2: as falhas vão ser observadas durante um período fixo. Em seguida, temos de modificar o código para evitar respostas de colocação em cache assim que o problema for corrigido

Vamos explicar isto analisando estes dois cenários mais detalhadamente.

Cenário 1: falha temporária de recursos/servidor

Tenha em atenção que a falha no servidor de back-end se deve a um dos seguintes motivos:

  • Uma falha de rede temporária
  • O servidor de back-end está extremamente ocupado e não consegue responder aos pedidos durante um período temporário
  • O recurso de back-end pedido pode ser removido/estar indisponível durante um período temporário
  • O servidor de back-end está a responder lentamente devido ao elevado tempo de processamento durante um período temporário, etc.

Em todos estes casos, as falhas podem ocorrer durante um período desconhecido e, em seguida, podemos começar a receber respostas bem-sucedidas. Se colocarmos em cache as respostas de erro, podemos continuar a enviar respostas de erro aos utilizadores, mesmo que o problema com o servidor de back-end tenha sido corrigido.

Cenário 2: falha prolongada ou fixa de recursos/servidor

Tenha em atenção que sabemos que a falha no back-end é por um período fixo. Por exemplo, sabe que:

  • Um recurso específico do back-end vai ficar indisponível durante 1 hora

    OU

  • O servidor de back-end é removido/não está disponível durante 24 horas devido a uma falha súbita do site, problemas de escalabilidade, manutenção, atualização, etc.

Com estas informações, podemos definir o tempo de expiração da cache adequadamente na política de cache de respostas para não armazenarmos em cache as respostas de erro durante mais tempo. No entanto, assim que o servidor/recurso de back-end estiver novamente disponível, temos de modificar a política para evitar o armazenamento em cache de respostas de erro. Isto deve-se ao facto de, se existir uma falha temporária/única do servidor de back-end, armazenarmos em cache a resposta e acabarmos por ter o problema explicado no cenário 1 acima.

Impacto

  • As respostas de erro de colocação em cache podem fazer com que sejam enviadas respostas de erro mesmo depois de o problema ter sido resolvido no servidor de back-end
  • Os utilizadores podem despender muito esforço na resolução de problemas da causa de um problema sem saber que este é causado pelo armazenamento em cache das respostas de erro do servidor de back-end

Prática recomendada

  • Não armazene as respostas de erro na cache de respostas. Certifique-se de que o elemento <ExcludeErrorResponse> está definido como true na política ResponseCache para evitar que as respostas de erro sejam colocadas em cache, conforme mostrado no fragmento de código abaixo. Com esta configuração, apenas as respostas para os códigos de êxito predefinidos 200 a 205 (a menos que os códigos de êxito sejam modificados) são colocadas em cache. 
    <!-- /antipatterns/examples/1-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServerResponseCache</DisplayName>
  <CacheKey>
    <KeyFragment ref="request.uri" />
  </CacheKey>
  <Scope>Exclusive</Scope>
  <ExpirySettings>
    <TimeoutinSec ref="flow.variable.here">600</TimeoutinSec>
  </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
  <ExcludeErrorResponse>true</ExcludeErrorResponse>
</ResponseCache>
  • Se tiver o requisito de colocar em cache as respostas de erro por algum motivo específico, pode determinar a duração máxima/exata do tempo durante o qual a falha será observada (se possível):
    • Defina o tempo de expiração adequadamente para garantir que não coloca em cache as respostas de erro durante mais tempo do que o tempo durante o qual a falha pode ser vista.
    • Use a política ResponseCache para colocar em cache as respostas de erro sem o elemento <ExcludeErrorResponse>.

    Faça isto apenas se tiver a certeza absoluta de que a falha do servidor back-end não é por um período breve/temporário.

  • O Apigee não recomenda o armazenamento em cache de respostas 5xx de servidores de back-end.