Configurar la compatibilidad con cargas útiles de mensajes grandes en Apigee Hybrid

Información general

A partir de la versión 1.14.2, Apigee hybrid admite cargas útiles de mensajes grandes de hasta 30 MB. A partir de la versión 1.14.3, Apigee Hybrid puede permitir cargas útiles de mensajes grandes de hasta 75 MB. El tamaño predeterminado de la carga útil de los mensajes es de 10 MB. Consulta Tamaño de la carga útil del mensaje.

Configurar la compatibilidad con cargas útiles de mensajes de hasta 30 MB

Para habilitar los entornos de tu instalación híbrida para que admitan cargas útiles de mensajes grandes, debes hacer los siguientes cambios en la configuración del tiempo de ejecución:

  • Aumenta el tamaño del montículo a 4 Gi como mínimo.
  • Aumenta los límites de memoria a al menos 6 Gi.
  • Aumenta las solicitudes de recursos de memoria a al menos 4 Gi.

Puedes configurar estos ajustes para entornos concretos o para todos los entornos de tu instalación.

Configurar entornos individuales para admitir cargas útiles de mensajes grandes

Si los proxies configurados para admitir cargas útiles de mensajes grandes solo tienen endpoints en uno o varios entornos de tu instalación, puedes configurar los entornos para que admitan cargas útiles grandes. De esta forma, no se añade memoria adicional a los entornos que no necesiten admitir cargas útiles grandes.

Para configurar entornos individuales de forma que admitan cargas útiles de mensajes grandes, puedes usar las propiedades envs.components.runtime. Haz los siguientes cambios en tu archivo overrides.yaml:

  1. Añade la siguiente estrofa a tu archivo 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

    Consulta los siguientes artículos:

  2. Actualiza el gráfico apigee-env de cada entorno que quieras actualizar:

    Prueba de funcionamiento:

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
    • ENV_RELEASE_NAME es un nombre que se usa para hacer un seguimiento de la instalación y las actualizaciones del gráfico apigee-env. Este nombre debe ser único y diferente de los demás nombres de lanzamientos de Helm de tu instalación. Normalmente, es la misma que ENV_NAME. Sin embargo, si tu entorno tiene el mismo nombre que tu grupo de entornos, debes usar nombres de lanzamiento diferentes para el entorno y el grupo de entornos (por ejemplo, dev-env-release y dev-envgroup-release). Para obtener más información sobre las versiones de Helm, consulta la sección Tres conceptos importantes de la documentación de Helm.
    • ENV_NAME es el nombre del entorno que vas a actualizar.
    • OVERRIDES_FILE es el archivo overrides.yaml editado.
  3. Actualiza el gráfico:

    Prueba de funcionamiento:

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

Configurar todos los entornos para que admitan cargas útiles de mensajes grandes

Los cambios que hagas en la stanza de runtime definirán los límites de montículo y memoria de todos los entornos de tu instalación. Puede anular estos ajustes en entornos concretos con las propiedades envs.components.runtime.

  1. Añade la siguiente estrofa a tu archivo overrides.yaml: 
    runtime:
  cwcAppend:
    bin_setenv_max_mem: 4096Mi   # Increase max heap size to 4 gigs
  resources:
    requests:
      memory: 4Gi
    limits:
      memory: 6Gi

    Consulta los siguientes artículos:

  2. Actualiza el gráfico apigee-env de cada entorno de tu instalación:

    Prueba de funcionamiento:

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

    Actualiza el gráfico:

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

Directrices para las cargas útiles de mensajes de entre 30 y 75 MB

Determinar el tamaño de montículo óptimo para un procesador de mensajes en escenarios de cargas útiles grandes depende de tu caso práctico específico. Sin embargo, Apigee ofrece directrices generales para ayudarte en este proceso.

Para calcular el tamaño del montículo por procesador de mensajes (MP), usa los siguientes valores:

  • Q: CPS máximo por pod de MP
  • L: latencia de ida y vuelta por solicitud (percentil 95 de la latencia esperada)
  • C: concurrencia total por MP, el número máximo de solicitudes que pueden persistir simultáneamente en el MP en un momento dado. Se calcula de la siguiente manera: C = Q * L.
  • P_req: tamaño de la carga útil (en MB) de la solicitud enviada por el cliente a Apigee.
  • P_resp: tamaño de la carga útil (en MB) de la respuesta recibida de Target.
  • S: factor de seguridad (Apigee recomienda un intervalo de 1,5 a 2)
  • BASE_HEAP: tamaño del montículo base para tener en cuenta los recursos no relacionados con las solicitudes, como las configuraciones de proxy. (Apigee recomienda 3072Mi)

Teniendo en cuenta el factor de seguridad S, junto con el tamaño del montículo base, el montículo total por MP se calcula de la siguiente manera:

Tamaño del montículo por MP = BASE_HEAP + C * (P_req + P_resp) * S

La configuración de anulaciones base del escenario de carga útil grande es la siguiente:

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

Ejemplo de cálculo

A continuación, se muestra un ejemplo de cálculo con los siguientes valores:

  • Máximo de CPS, Q: 2
  • Latencia, L: 7 s
  • Tamaño de la carga útil de la solicitud, P_req: 40 MB
  • Tamaño de la carga útil de la respuesta, P_resp: 40 MB
  • Factor de seguridad, S: 1,5
  • Tamaño del montículo base, BASE_HEAP: 3072 Mi

Tamaño del montón = 3072 + (2 * 7) * (40+40) * 1.5 = 4752Mi

limits.memory debe ser 1 Gi superior al montón recomendado para tener en cuenta la sobrecarga del SO y otros usos de memoria que no sean del montón.

En este ejemplo, añadirías lo siguiente a tu overrides.yaml:

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

Cuestiones importantes

Ráfagas de tráfico

HPA se asegura de que los MPs se escalen a medida que aumenta el QPS. Sin embargo, el HPA tardará unos 60 segundos en activar el escalado vertical. Un pico de tráfico excesivamente alto puede provocar errores de falta de memoria en tu MP.

Si prevés este tipo de picos de tráfico, aumenta el uso del montículo con un factor de seguridad que te parezca adecuado. Por ejemplo, S = 2.

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

Uso de las políticas

El cálculo anterior no incluye el uso de políticas. Apigee permite a los clientes hacer copias de las cargas útiles de sus solicitudes y respuestas, lo que puede alterar significativamente el uso del montículo.

Por ejemplo, si tienes una política de JavaScript que hace 3 copias de toda tu respuesta de destino, la ecuación que debes usar es la siguiente:

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

Ejemplos de políticas que podrían aumentar el uso de memoria:

  • AssignMessage
  • JavaScript Callout
  • JavaCallout

Supervisión

Las directrices que se proporcionan aquí tienen como objetivo servir de punto de partida. Te recomendamos que monitorices y configures alertas sobre el uso de la memoria. Usa un factor de seguridad mayor si el uso de montículo es constantemente alto.

Consulta también: