Configurer la prise en charge des charges utiles de message volumineuses dans Apigee hybrid

Présentation

À partir de la version 1.14.2, Apigee hybrid est compatible avec les charges utiles de messages volumineuses (jusqu'à 30 Mo). À partir de la version 1.14.3, Apigee hybrid peut autoriser les charges utiles de messages volumineuses (jusqu'à 75 Mo). La taille de charge utile des messages par défaut est de 10 Mo. Consultez Taille de la charge utile des messages.

Configurer la prise en charge des charges utiles de messages jusqu'à 30 Mo

Pour permettre aux environnements de votre installation hybride de prendre en charge les charges utiles de messages volumineuses, vous devez apporter les modifications suivantes à votre configuration d'exécution :

  • Augmentez la taille du tas de mémoire à au moins 4 Gio.
  • Augmentez les limites de mémoire à au moins 6 Gio.
  • Augmentez les demandes de ressources mémoire à au moins 4 Gio.

Vous pouvez configurer ces paramètres pour des environnements individuels ou pour tous les environnements de votre installation.

Configurer des environnements individuels pour prendre en charge les charges utiles de messages volumineux

Si les proxys configurés pour accepter les charges utiles de messages volumineux n'ont des points de terminaison que dans un ou plusieurs environnements de votre installation, vous pouvez configurer les environnements pour qu'ils acceptent les charges utiles volumineuses. Cela évite d'ajouter de la mémoire supplémentaire aux environnements qui n'auront pas besoin de prendre en charge des charges utiles volumineuses.

Pour configurer des environnements individuels afin qu'ils acceptent les charges utiles de messages volumineux, vous pouvez utiliser les propriétés envs.components.runtime. Apportez les modifications suivantes à votre fichier overrides.yaml :

  1. Ajoutez le stanza suivant à votre fichier 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

    Consultez les pages suivantes :

  2. Mettez à niveau le chart apigee-env pour chaque environnement que vous mettez à jour :

    Effectuez un dry run :

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
    • ENV_RELEASE_NAME est un nom utilisé pour suivre l'installation et les mises à niveau du graphique apigee-env. Ce nom doit être unique par rapport aux autres noms de version Helm de votre installation. Il s'agit généralement de la même valeur que ENV_NAME. Toutefois, si votre environnement porte le même nom que votre groupe d'environnements, vous devez utiliser des noms de version différents pour l'environnement et le groupe d'environnements (par exemple, dev-env-release et dev-envgroup-release). Pour en savoir plus sur les versions dans Helm, consultez Trois grands concepts dans la documentation Helm.
    • ENV_NAME est le nom de l'environnement que vous mettez à niveau.
    • OVERRIDES_FILE est votre fichier overrides.yaml modifié.
  3. Mettez à niveau le graphique :

    Effectuez un dry run :

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

Configurer tous les environnements pour qu'ils acceptent les charges utiles de messages volumineuses

Les modifications apportées à votre strophe runtime définiront les limites de tas et de mémoire pour tous les environnements de votre installation. Vous pouvez remplacer ces paramètres pour des environnements individuels à l'aide des propriétés envs.components.runtime.

  1. Ajoutez le stanza suivant à votre fichier overrides.yaml : 
    runtime:
  cwcAppend:
    bin_setenv_max_mem: 4096Mi   # Increase max heap size to 4 gigs
  resources:
    requests:
      memory: 4Gi
    limits:
      memory: 6Gi

    Consultez les pages suivantes :

  2. Mettez à niveau le chart apigee-env pour chaque environnement de votre installation :

    Effectuez un dry run :

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

    Mettez à niveau le graphique :

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

Consignes concernant les charges utiles de messages comprises entre 30 Mo et 75 Mo

La détermination de la taille de tas optimale pour un processeur de messages dans les scénarios de charge utile volumineuse dépend de votre cas d'utilisation spécifique. Toutefois, Apigee propose des consignes générales pour vous aider dans ce processus.

Pour calculer la taille du tas par processeur de messages (MP), utilisez les valeurs suivantes :

  • Q : RPS max. par pod MP
  • L : latence aller-retour par requête (95e centile de la latence attendue)
  • C : simultanéité totale par MP, nombre maximal de requêtes pouvant persister simultanément dans le MP à un moment donné. Le mode de calcul est le suivant : C = Q * L.
  • P_req : taille de la charge utile (en Mo) de la requête envoyée par le client à Apigee
  • P_resp : taille (en Mo) de la charge utile de la réponse reçue de la cible
  • S : facteur de sécurité (Apigee recommande une plage de 1,5 à 2)
  • BASE_HEAP : taille de tas de base pour tenir compte des ressources non liées aux requêtes, telles que les configurations de proxy. (Apigee recommande 3072Mi)

En tenant compte du facteur de sécurité S et d'une taille de tas de base, le tas total par MP est calculé comme suit :

Taille du tas par MP = BASE_HEAP + C * (P_req + P_resp) * S

La configuration de remplacement de base pour le scénario de charge utile volumineuse est la suivante :

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

Exemple de calcul

Voici un exemple de calcul avec les valeurs suivantes :

  • RPS max., Q : 2
  • Latence, L : 7 s
  • Taille de la charge utile de la requête, P_req : 40 Mo
  • Taille de la charge utile de la réponse, P_resp : 40 Mo
  • Facteur de sécurité, S : 1,5
  • Taille de tas de base, BASE_HEAP : 3072Mi

Taille du tas = 3072 + (2 * 7) * (40+40) * 1.5 = 4752Mi

limits.memory doit être supérieur de 1 Gio au tas recommandé pour tenir compte de la surcharge de l'OS et de l'utilisation de la mémoire non-tas.

Dans cet exemple, vous ajouteriez les éléments suivants à votre overrides.yaml :

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

Remarques

Pics de trafic

L'autoscaler horizontal de pods garantit que les MP évoluent à mesure que le RPS augmente. Toutefois, vous pouvez vous attendre à ce que AHP mette environ 60 secondes à déclencher le scaling-up. Un pic de trafic déraisonnablement élevé peut entraîner des erreurs de mémoire insuffisante sur votre MP.

Si vous prévoyez de tels pics de trafic, veuillez augmenter l'utilisation du tas en utilisant un facteur de sécurité qui vous semble approprié. Par exemple, S = 2.

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

Utilisation des règles

Le calcul ci-dessus n'inclut pas l'utilisation des règles. Apigee permet aux clients de copier leurs charges utiles de requête / réponse, ce qui peut modifier considérablement l'utilisation du tas.

Par exemple, si vous disposez d'une stratégie JavaScript qui crée trois copies de l'intégralité de votre réponse cible, l'équation à utiliser est la suivante :

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

Voici des exemples de règles qui pourraient potentiellement augmenter l'utilisation de la mémoire :

  • AssignMessage
  • Appel JavaScript
  • JavaCallout

Surveillance

Les consignes fournies ici sont destinées à servir de point de départ. Nous vous recommandons vivement de surveiller l'utilisation de la mémoire et de configurer des alertes. Utilisez un facteur de sécurité plus élevé si l'utilisation du tas est constamment élevée.

Voir également :