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

Descripció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 del mensaje es de 10 MB. Consulta Tamaño de la carga útil del mensaje.

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

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

  • Aumenta el tamaño del montón a, al menos, 4 Gi.
  • 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 parámetros para entornos individuales o para todos los entornos de tu instalación.

Configura entornos individuales para admitir cargas útiles de mensajes grandes

Si los proxies configurados para admitir cargas útiles de mensajes grandes tienen extremos en solo uno o algunos entornos de tu instalación, puedes configurar los entornos para que admitan cargas útiles grandes. Esto evita agregar memoria adicional a los entornos que no necesitarán admitir cargas útiles grandes.

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

  1. Agrega 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 vínculos:

  2. Actualiza el gráfico apigee-env para cada entorno que actualices:

    Prueba de validación:

    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 versiones de Helm en tu instalación. Por lo general, es igual a ENV_NAME. Sin embargo, si tu entorno tiene el mismo nombre que tu grupo de entornos, debes usar nombres de versión 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 en Helm, consulta Tres conceptos importantes en la documentación de Helm.
    • ENV_NAME es el nombre del entorno que estás actualizando.
    • OVERRIDES_FILE es tu archivo overrides.yaml editado.
  3. Actualiza el chart:

    Prueba de validación:

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

Configura todos los entornos para admitir cargas útiles de mensajes grandes

Los cambios en tu sección runtime establecerán los límites de memoria y montón para todos los entornos de tu instalación. Puedes anular esta configuración para entornos individuales con las propiedades envs.components.runtime.

  1. Agrega 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 vínculos:

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

    Prueba de validación:

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

    Actualiza el chart:

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

Lineamientos para cargas útiles de mensajes de entre 30 MB y 75 MB

Determinar el tamaño de montón óptimo para un Message Processor en situaciones de cargas útiles grandes depende de tu caso de uso específico. Sin embargo, Apigee ofrece lineamientos generales para ayudarte en este proceso.

Para calcular el tamaño del montón por Message Processor (MP), usa los siguientes valores:

  • Q: QPS máx. por Pod de MP
  • L: Latencia de ida y vuelta por solicitud (percentil 95 de la latencia esperada)
  • C: Es la simultaneidad total por MP, la cantidad máxima de solicitudes que pueden persistir de forma simultánea en el MP en cualquier momento. Esto se calcula como C = Q * L.
  • P_req: Tamaño de la carga útil (en MB) de la solicitud que envió el cliente a Apigee
  • P_resp: Tamaño de la carga útil (en MB) de la respuesta recibida del destino
  • S: Factor de seguridad (Apigee recomienda un rango de 1.5 a 2)
  • BASE_HEAP: Tamaño base del heap para tener en cuenta los recursos no relacionados con la solicitud, como las configuraciones de proxy. (Apigee recomienda 3072Mi).

Si se tiene en cuenta el factor de seguridad S, junto con un tamaño de montón base, el montón total por MP se calcula de la siguiente manera:

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

La configuración de anulaciones básicas para la situación 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:

  • QPS máx., 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 de montón base, BASE_HEAP: 3072 Mi

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

Se espera que limits.memory sea 1 Gi superior al heap recomendado para tener en cuenta la sobrecarga del SO y otros usos de memoria que no son de heap.

En este ejemplo, agregarí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

Consideraciones

Ráfagas de tráfico

El HPA garantiza que los MPs se ajusten a medida que aumentan las QPS. Sin embargo, puedes esperar que el HPA tarde alrededor de 60 segundos en activar el aumento de la escala. Un aumento repentino e irrazonablemente alto del tráfico puede generar errores de memoria insuficiente (OOM) en tu MP.

Si prevés estos aumentos de actividad de tráfico, aumenta el uso del heap con un factor de seguridad que parezca adecuado. Por ejemplo, S = 2.

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

Uso de la política

El cálculo anterior no incluye el uso de la política. Apigee permite a los clientes hacer copias de sus cargas útiles de solicitud y respuesta, lo que puede alterar significativamente el uso de la memoria dinámica.

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

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

Estas son algunas políticas de ejemplo que podrían aumentar el uso de memoria:

  • AssignMessage
  • Texto destacado de JavaScript
  • JavaCallout

Supervisión

Los lineamientos que se proporcionan aquí tienen como objetivo servir como punto de partida. Se recomienda supervisar el uso de memoria y configurar alertas. Usa un factor de seguridad mayor si el uso del montón es constantemente alto.

Consulta lo siguiente: