Antipadrão: respostas a erros de cache

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X.
informações

Cache é um processo de armazenamento temporário de dados em uma área de armazenamento chamada cache para referência futura. Armazenar dados em cache traz benefícios de desempenho significativos porque:

  • Permite a recuperação mais rápida de dados
  • Reduz o tempo de processamento ao evitar a geração de dados novamente
  • Impede que as solicitações de API cheguem aos servidores de back-end e, assim, reduz a sobrecarga nos servidores de back-end.
  • Melhor utilização dos recursos do sistema/aplicativo
  • Melhora os tempos de resposta das APIs

Sempre que precisarmos acessar com frequência dados que não mudam com muita frequência, recomendamos o uso de um cache para armazenar esses dados.

O Apigee Edge permite armazenar dados em um cache no ambiente de execução para persistência e recuperação mais rápida. O recurso de armazenamento em cache é disponibilizado por meio da política PopulateCache, política LookupCache, política InvalidateCache e política ResponseCache.

Nesta seção, vamos conhecer a política do cache de resposta. A política de cache de resposta na plataforma Apigee Edge permite armazenar em cache as respostas dos servidores de back-end. Se os aplicativos clientes fizerem solicitações ao mesmo recurso de back-end repetidamente e o recurso for atualizado periodicamente, poderemos armazenar essas respostas em cache usando essa política. A política de cache de resposta ajuda a retornar as respostas armazenadas em cache e, portanto, evita o encaminhamento desnecessário de solicitações aos servidores de back-end.

A política de cache de resposta:

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

Antipadrão

Com a política ResponseCache, você armazena em cache as respostas HTTP com qualquer código de status possível, por padrão. Isso significa que as respostas de sucesso e erro podem ser armazenadas em cache.

Confira um exemplo de política de cache de resposta com a configuração padrão:

<!-- /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 do Cache de resposta armazena em cache as respostas de erro na configuração padrão. No entanto, não é aconselhável armazenar em cache as respostas de erro sem considerar sobre as implicações adversas porque:

  • Cenário 1: as falhas ocorrem por um período temporário desconhecido e poderemos continuar enviando respostas de erro devido ao armazenamento em cache, mesmo depois que o problema tiver sido corrigido

    OU

  • Cenário 2: as falhas serão observadas por um período fixo, então será necessário modificar o código para evitar o armazenamento em cache de respostas quando o problema for corrigido

Vamos explicar isso analisando esses dois cenários em mais detalhes.

Cenário 1: falha temporária de back-end/recurso

Considere que a falha no servidor de back-end se deve a um dos seguintes motivos:

  • Uma falha temporária de rede
  • O servidor de back-end é muito ocupado e não pode responder às solicitações por um período temporário
  • O recurso de back-end solicitado pode ser removido/indisponível por um período temporário
  • O servidor de back-end está respondendo lentamente devido ao tempo de processamento alto de um período temporário etc.

Em todos esses casos, as falhas podem ocorrer por um período desconhecido e podemos começar a receber respostas bem-sucedidas. Se armazenarmos as respostas de erro em cache, poderemos continuar enviando respostas de erro aos usuários, mesmo que o problema com o servidor de back-end tenha sido corrigido.

Cenário 2: falha gradual ou corrigida de recurso

Considere que sabemos que a falha no back-end é por um período fixo. Por exemplo, você está ciente de que:

  • Um recurso de back-end específico ficará indisponível por uma hora

    OU

  • O servidor de back-end é removido/indisponível por 24 horas devido a uma falha repentina do site, problemas de escalonamento, manutenção, upgrade etc.

Com essas informações, podemos definir o prazo de validade do cache corretamente na política de cache de resposta para que as respostas de erro não sejam armazenadas em cache por mais tempo. No entanto, assim que o servidor/recurso de back-end estiver disponível novamente, precisaremos modificar a política para evitar respostas de erro de armazenamento em cache. Isso ocorre porque, se houver uma falha temporária/única no servidor de back-end, a resposta será armazenada em cache e, em seguida, haverá o problema explicado no cenário 1 acima.

Impacto

  • As respostas de erro em cache podem fazer com que as respostas de erro sejam enviadas mesmo após o problema ser resolvido no servidor de back-end.
  • Os usuários podem gastar muito esforço resolvendo a causa de um problema sem saber que ele é causado pelo armazenamento em cache das respostas de erro do servidor de back-end

Prática recomendada

  • Não armazene as respostas de erro no cache de respostas. Verifique se o elemento <ExcludeErrorResponse> está definido como true na política ResponseCache para evitar que as respostas de erro sejam armazenadas em cache, conforme mostrado no snippet de código abaixo. Com essa configuração, apenas as respostas para os códigos de sucesso padrão 200 a 205 (a menos que os códigos de sucesso sejam modificados) serão armazenadas 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 for necessário armazenar as respostas de erro em cache por algum motivo específico, determine a duração máxima/exata em que a falha será observada (se possível):
    • Defina o prazo de validade corretamente para garantir que as respostas de erro não sejam armazenadas em cache por um período maior do que o tempo de exibição da falha.
    • Use a política ResponseCache para armazenar as respostas de erro em cache sem o elemento <ExcludeErrorResponse>.

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

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