Configure o suporte de payload de mensagens grandes no Apigee Hybrid

Vista geral

A partir da versão 1.14.2, o Apigee hybrid suporta payloads de mensagens grandes até 30 MB. A partir da versão 1.14.3, o Apigee Hybrid pode permitir payloads de mensagens grandes até 75 MB. O tamanho predefinido da carga útil da mensagem é de 10 MB. Consulte o tamanho do payload da mensagem.

Configure o suporte para payloads de mensagens até 30 MB

Para permitir que os ambientes na sua instalação híbrida suportem payloads de mensagens grandes, tem de fazer as seguintes alterações à configuração de tempo de execução:

  • Aumente o tamanho da memória dinâmica para, pelo menos, 4 Gi.
  • Aumente os limites de memória para, pelo menos, 6 Gi.
  • Aumente os pedidos de recursos de memória para, pelo menos, 4 Gi.

Pode configurar estas definições para ambientes individuais ou para todos os ambientes na sua instalação.

Configure ambientes individuais para suportar payloads de mensagens grandes

Se os proxies configurados para suportar grandes payloads de mensagens tiverem pontos finais apenas num ou em alguns ambientes na sua instalação, pode configurar os ambientes para suportarem grandes payloads. Isto evita adicionar memória adicional a ambientes que não precisam de suportar grandes payloads.

Para configurar ambientes individuais de modo a suportarem payloads de mensagens grandes, pode usar as propriedades envs.components.runtime. Faça as seguintes alterações ao ficheiro overrides.yaml:

  1. Adicione a seguinte estrofe ao ficheiro overrides.yaml:
    envs:
    - name: ENV_NAME
      components.
        runtime:
          cwcAppend:
            bin_setenv_max_mem: 4096Mi   # Increase max heap size to 4 gigs
          resources:
            requests:
              memory: 4Gi
            limits:
              memory: 6Gi
    

    Consulte:

  2. Atualize o gráfico apigee-env para cada ambiente que está a atualizar:

    Execução de ensaio:

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      --set env=ENV_NAME \
      -f OVERRIDES_FILE \
      --dry-run=server
    
    • ENV_RELEASE_NAME é um nome usado para monitorizar a instalação e as atualizações do gráfico apigee-env. Este nome tem de ser exclusivo dos outros nomes de lançamentos do Helm na sua instalação. Normalmente, este valor é igual a ENV_NAME. No entanto, se o seu ambiente tiver o mesmo nome que o seu grupo de ambientes, tem de usar nomes de lançamentos diferentes para o ambiente e o grupo de ambientes, por exemplo, dev-env-release e dev-envgroup-release. Para mais informações sobre lançamentos no Helm, consulte Três grandes conceitos na documentação do Helm.
    • ENV_NAME é o nome do ambiente que está a atualizar.
    • OVERRIDES_FILE é o ficheiro overrides.yaml editado.
  3. Atualize o gráfico:

    Execução de ensaio:

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      --set env=ENV_NAME \
      -f OVERRIDES_FILE
    

Configure todos os ambientes para suportarem payloads de mensagens grandes

As alterações à secção runtime definem os limites de memória e de heap para todos os ambientes na sua instalação. Pode substituir estas definições para ambientes individuais com as propriedades envs.components.runtime.

  1. Adicione a seguinte estrofe ao ficheiro overrides.yaml:
    runtime:
      cwcAppend:
        bin_setenv_max_mem: 4096Mi   # Increase max heap size to 4 gigs
      resources:
        requests:
          memory: 4Gi
        limits:
          memory: 6Gi
    

    Consulte:

  2. Atualize o gráfico apigee-env para cada ambiente na sua instalação:

    Execução de ensaio:

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      --set env=ENV_NAME \
      -f OVERRIDES_FILE \
      --dry-run=server
    

    Atualize o gráfico:

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
      --install \
      --namespace APIGEE_NAMESPACE \
      --set env=ENV_NAME \
      -f OVERRIDES_FILE
    

Diretrizes para payloads de mensagens entre 30 MB e 75 MB

A determinação do tamanho da memória dinâmico ideal para um processador de mensagens para cenários de carga útil grande depende do seu exemplo de utilização específico. No entanto, o Apigee oferece diretrizes gerais para ajudar neste processo.

Para calcular o tamanho da memória dinâmica por processador de mensagens (MP), use os seguintes valores:

  • Q: CPS máx. por agrupamento de MP
  • L – Latência de ida e volta por pedido (percentil 95 da latência esperada)
  • C - Concorrência total por MP, o número máximo de pedidos que podem persistir simultaneamente no MP em qualquer altura. É calculado da seguinte forma: C = Q * L.
  • P_req - Tamanho do payload (em MB) do pedido enviado pelo cliente para o Apigee
  • P_resp – Tamanho do payload (em MB) da resposta recebida do Target
  • S - Fator de segurança (o Apigee recomenda um intervalo de 1,5 a 2)
  • BASE_HEAP: tamanho da memória de base para ter em conta os recursos não relacionados com pedidos, como configurações de proxy. (A Apigee recomenda 3072Mi)

Tendo em conta o fator de segurança S, juntamente com um tamanho da área de memória temporária base, a área de memória temporária total por MP é calculada da seguinte forma:

Tamanho da memória por MP = BASE_HEAP + C * (P_req + P_resp) * S

A configuração de substituições base para o cenário de payload grande é:

envs:
  components:
    runtime:
      resources:
        requests:
          cpu: 2000m
          memory: 2Gi
        limits:
          cpu: 4000m
          memory: 4Gi
      cwcAppend:
        bin_setenv_max_mem: 3072Mi # base heap size

Exemplo de cálculo

Segue-se um exemplo de cálculo com os seguintes valores:

  • CPS máx., Q: 2
  • Latência, L: 7 s
  • Tamanho do payload do pedido, P_req: 40 MB
  • Tamanho do payload da resposta, P_resp: 40 MB
  • Fator de segurança, S: 1,5
  • Tamanho da memória de acesso aleatório base, BASE_HEAP: 3072Mi

Tamanho da área de memória dinâmica = 3072 + (2 * 7) * (40+40) * 1.5 = 4752Mi

Espera-se que limits.memory seja 1 Gi superior ao heap recomendado para ter em conta a sobrecarga do SO e outra utilização de memória não pertencente ao heap.

Neste exemplo, adicionaria o seguinte ao seu overrides.yaml:

envs:
  components:
    runtime:
      resources:
        requests:
          memory: 4Gi
        limits:
          memory: 5.75Gi # approximately 1Gi over 4.75Gi
      cwcAppend:
        bin_setenv_max_mem: 4752Mi

Considerações

Picos de tráfego

O HPA garante que os MPs são dimensionados à medida que o CPS aumenta. No entanto, pode esperar que o HPA demore cerca de 60 segundos a acionar o aumento da escala. Um pico de tráfego excessivamente elevado pode originar erros de falta de memória (OOM) na sua propriedade de medição.

Se prevê esses picos de tráfego, aumente a utilização da memória dinâmica usando um fator de segurança que pareça adequado. Por exemplo, S = 2.

Heap = BASE_HEAP + (Q * L) * (P_req + P_resp) * 2

Utilização de políticas

O cálculo acima não inclui a utilização de políticas. O Apigee permite que os clientes façam cópias dos respetivos payloads de pedido / resposta, o que pode alterar significativamente a utilização da memória.

Por exemplo, se tiver uma política de JavaScript que faça 3 cópias de toda a resposta do alvo, a equação a usar seria:

Heap per MP = Base Heap + (Q * L) * (P_req + P_resp * 4) * S

Exemplos de políticas que podem aumentar potencialmente a utilização da memória:

  • AssignMessage
  • Texto explicativo de JavaScript
  • JavaCallout

Monitorização

As diretrizes aqui fornecidas destinam-se a servir como ponto de partida. A monitorização e os alertas da utilização de memória são altamente recomendados. Use um fator de segurança aumentado se a utilização da memória dinâmica for consistentemente elevada.

Veja também: