Équilibrage de charge sur les serveurs de backend

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d'Apigee Edge.

Apigee améliore la disponibilité de vos API en fournissant une compatibilité intégrée avec l'équilibrage de charge et le basculement sur plusieurs instances de serveurs de backend.

Les serveurs cibles dissocient les URL de point de terminaison concrètes des configurations de points de terminaison cibles. Au lieu de définir une URL concrète dans la configuration, vous pouvez configurer un ou plusieurs serveurs cibles nommés. Ensuite, chaque serveur cible est référencé par son nom dans la configuration HTTPConnection d'un point de terminaison cible.

Vidéos

Regardez les vidéos suivantes pour en savoir plus sur le routage des API et l'équilibrage de charge à l'aide de serveurs cibles.

À propos de la configuration de serveur cible

Une configuration de serveur cible se compose d'un nom, d'un hôte, d'un protocole et d'un port, avec un élément supplémentaire pour indiquer si le serveur cible est activé ou désactivé. Un serveur cible peut également avoir un objet <sSLInfo> facultatif.

Le code suivant fournit un exemple de configuration de serveur cible :

{
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true"
}

Pour en savoir plus sur l'API TargetServers, consultez la page organizations.environments.targetservers.

Consultez le schéma de TargetServer et d'autres entités sur GitHub.

Créer des serveurs cibles

Créez des serveurs cibles à l'aide de l'UI ou de l'API Apigee, comme décrit dans les sections suivantes.

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'
 

{
  "host" : "1.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

{
  "host" : "2.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

[ "target2", "target1" ]

Configurer un point de terminaison cible de manière à effectuer un équilibrage de charge sur des serveurs cibles nommés

Maintenant que deux serveurs cibles sont disponibles, vous pouvez modifier l'élément <HTTPTargetConnection> du point de terminaison cible pour référencer ces deux serveurs cibles par leur nom :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

La configuration ci-dessus est la configuration d'équilibrage de charge la plus basique. L'équilibreur de charge accepte trois algorithmes d'équilibrage de charge : Round robin (à tour de rôle), Weighted (pondération) et Least Connection (plus faible nombre de requêtes). Round robin est l'algorithme par défaut. Étant donné qu'aucun algorithme n'est spécifié dans la configuration ci-dessus, les requêtes sortantes du proxy d'API vers les serveurs de backend s'alternent à tour de rôle entre target1 et target2.

L'élément <Path> constitue le chemin de base de l'URI du point de terminaison cible pour tous les serveurs cibles. Il n'est utilisé que lorsque <LoadBalancer> est utilisé. Sinon, il est ignoré. Dans l'exemple ci-dessus, une requête adressées à target1 se présente au format http://target1/test, et ainsi de suite pour d'autres serveurs cibles.

Configurer les options de l'équilibreur de charge

Vous pouvez ajuster la disponibilité en configurant les options d'équilibrage de charge et de basculement au niveau de l'équilibreur de charge et du serveur cible, comme décrit dans les sections suivantes.

Algorithme

Définit l'algorithme utilisé par <LoadBalancer>. Les algorithmes disponibles sont RoundRobin, Weighted et LeastConnections. Ils sont décrits ci-dessous.

Round robin (à tour de rôle)

L'algorithme par défaut Round robin transfère une requête à chaque serveur cible, dans l'ordre dans lequel les serveurs sont répertoriés dans la connexion HTTP du point de terminaison cible. Exemple :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Pondération

L'algorithme d'équilibrage de charge Weighted vous permet de configurer des charges de trafic proportionnelles pour vos serveurs cibles. L'équilibreur de charge pondéré répartit les requêtes dans vos serveurs cibles proportionnellement à la pondération de chaque serveur cible. Par conséquent, l'algorithme Weighted vous oblige à définir un attribut weight pour chaque serveur cible. Exemple :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Dans cet exemple, deux requêtes seront acheminées vers target2 pour chaque requête acheminée vers target1.

Least Connection

Les équilibreurs de charge configurés avec l'algorithme Least Connection routent les requêtes sortantes vers le serveur cible qui compte le plus petit nombre de connexions HTTP ouvertes. Exemple :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Nombre maximal d'échecs

Nombre maximal de requêtes en échec entre le proxy d'API et le serveur cible, ayant pour effet de rediriger la requête vers un autre serveur cible.

Une réponse en échec signifie qu'Apigee ne reçoit aucune réponse d'un serveur cible. Lorsque cela se produit, le compteur d'échecs augmente d'une unité.

Toutefois, lorsque Apigee reçoit une réponse d'une cible, même s'il s'agit d'une erreur HTTP (par exemple, une erreur 404 ou 500), celle-ci est comptabilisée comme une réponse du serveur cible, et le compteur d'échecs est réinitialisé. Pour vous assurer que les réponses HTTP incorrectes (telles que les erreurs 500) incrémentent également le compteur d'échecs visant à retirer dès que possible un serveur non opérationnel de la rotation d'équilibrage de charge, vous pouvez ajouter l'élément <ServerUnhealthyResponse> avec des éléments enfants <ResponseCode> à la configuration de votre équilibreur de charge. Apigee comptabilise alors comme des échecs les réponses comportant ces codes.

Dans l'exemple suivant, target1 sera supprimé de la rotation après cinq requêtes en échec, y compris 404 et certaines réponses 5XX du serveur cible.

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>404</ResponseCode>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Par défaut, le nombre maximal d'échecs est défini sur 0. Cela signifie qu'Apigee tente toujours de se connecter à la cible pour chaque requête et ne supprime jamais le serveur cible de la rotation.

Il est préférable d'utiliser une valeur MaxFailures (nombre maximal d'échecs) supérieure à 0 avec un moniteur d'intégrité. Si vous la configurez sur une valeur supérieure à 0, le serveur cible est supprimé de la rotation lorsque la cible échoue le nombre de fois que vous avez indiqué. Lorsqu'un moniteur d'intégrité est en place, Apigee replace automatiquement le serveur cible en rotation une fois que la cible est à nouveau opérationnelle, en fonction de la configuration de ce moniteur d'intégrité. Pour en savoir plus, consultez la section Surveillance d'état.

Notez que les appels d'API standards et les appels initiés par un moniteur d'intégrité sont comptabilisés dans le nombre de MaxFailures.

Notez également que le nombre d'échecs en cours pour chaque serveur cible est conservé par équilibreur de charge. Par exemple, supposons qu'un proxy dispose de deux points de terminaison cibles, chacun ayant un équilibreur de charge, et que les deux équilibreurs de charge soient configurés pour utiliser le même ensemble de serveurs cibles. Dans ce cas, les échecs d'un point de terminaison cible ne sont comptabilisés que pour l'équilibreur de charge correspondant. Ils n'affectent pas la rotation de l'autre point de terminaison cible.

Si vous configurez une valeur MaxFailures supérieure à 0 et que vous ne configurez pas de moniteur d'intégrité, Apigee retire automatiquement le serveur cible de la rotation lorsque le premier échec est détecté. Apigee vérifie l'état du serveur cible toutes les cinq minutes et le remet en rotation lorsqu'il répond normalement.

Réessayer

Si les nouvelles tentatives sont activées, une requête fera l'objet d'une nouvelle tentative en cas d'échec de réponse (erreur d'E/S ou expiration du délai HTTP) ou si la réponse correspond à une valeur définie par <ServerUnhealthyResponse>. Pour en savoir plus sur la définition de <ServerUnhealthyResponse>, consultez la section Nombre maximal d'échecs ci-dessus.

Par défaut, <RetryEnabled> est défini sur true. Définissez la valeur sur false pour désactiver les nouvelles tentatives. Exemple :

<RetryEnabled>false</RetryEnabled>

IsFallback

Un (et un seul) serveur cible peut être défini comme serveur de remplacement. L'équilibreur de charge n'utilisera le serveur de remplacement que lorsque tous les autres serveurs cibles auront été retirés de la rotation par l'équilibreur de charge. Dans ce cas, tout le trafic est acheminé vers le serveur de remplacement jusqu'à ce que l'un des autres serveurs cibles soit à nouveau opérationnel et qu'il soit renvoyé à la rotation. Exemple :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

La configuration ci-dessus entraîne un équilibrage de charge de type Round robin entre target1 et target2 jusqu'à ce que target1 et target2 deviennent indisponibles. Lorsque target1 et target2 sont indisponibles, tout le trafic est acheminé vers target3.

Si le serveur de remplacement n'est pas opérationnel, Apigee ne redirige pas le trafic vers celui-ci. Au lieu de cela, les appels d'API renvoient une erreur 503 "Le service est temporairement indisponible".

Chemin

Le chemin définit un fragment d'URI qui sera ajouté à toutes les requêtes émises par le serveur cible au serveur de backend.

Cet élément accepte un chemin sous forme de chaîne littérale ou un modèle de message. Un modèle de message vous permet de remplacer une chaîne de variable au moment de l'exécution. Par exemple, dans la définition de point de terminaison cible suivante, la valeur de {mypath} est utilisée pour le chemin :

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Configurer un serveur cible pour TLS/SSL

Si vous utilisez un serveur cible pour définir le service de backend et que celui-ci nécessite une connexion au protocole HTTPS, vous devez activer TLS/SSL dans la définition du serveur cible. Cette opération est nécessaire, car le tag host ne vous permet pas de spécifier le protocole de connexion.

Configurer une connexion TLS/SSL unidirectionnelle

Utilisez la configuration suivante pour définir un serveur cible avec TLS/SSL unidirectionnel. Dans cet exemple, Apigee envoie des requêtes HTTPS au service de backend :

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

Configurer l'application stricte du protocole SSL

Pour spécifier l'application stricte de SSL dans la définition du serveur cible, définissez enforce sur true dans le bloc sSLInfo, comme illustré dans l'exemple suivant :

  {
    "name": "target1",
    "host": "mocktarget.apigee.net",
    "protocol": "http",
    "port": "443",
    "isEnabled": "true",
    "sSLInfo": {
      "enabled": "true",
      "enforce": "true"
    }
  }
  

Configurer le protocole TLS/SSL bidirectionnel

Si le service de backend requiert une approche bidirectionnelle, ou mutuelle, pour les protocoles TLS/SSL, vous pouvez configurer le serveur cible avec les mêmes paramètres de configuration TLS/SSL que ceux des points de terminaison cibles :

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

Configurer le SSL strict à l'aide de l'API

Pour créer un serveur cible avec une application stricte du protocole SSL à l'aide d'un appel d'API :

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "enforce":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

Surveillance d'état

Cette fonctionnalité vous permet d'améliorer les configurations de l'équilibrage de charge en interrogeant activement les URL du service de backend définies dans les configurations de serveur cible. Lorsque la surveillance de l'état est activée, les serveurs cibles inaccessibles ou renvoyant une réponse d'erreur sont marqués comme non opérationnels. Un serveur cible en échec est automatiquement renvoyé en rotation lorsque l'objet HealthMonitor détermine que le serveur cible est actif. Aucun redéploiement de proxy n'est requis.

Un moniteur d'intégrité agit comme un client simple qui appelle un service de backend via TCP ou HTTP :

• Un client TCP garantit simplement qu'un socket peut être ouvert.
• Vous devez configurer le client HTTP pour qu'il envoie une requête HTTP valide au service de backend. Vous pouvez définir des opérations HTTP GET, PUT, POST ou DELETE. La réponse de l'appel de surveillance HTTP doit correspondre aux paramètres configurés dans le bloc <SuccessResponse>.

Succès et échecs

Lorsque vous activez la surveillance de l'état, Apigee commence à envoyer des vérifications d'état à votre serveur cible. Une vérification d'état est une requête envoyée au serveur cible qui détermine si celui-ci est opérationnel ou non.

Une vérification d'état peut générer l'un des deux résultats suivants :

• Succès : le serveur cible est considéré comme opérationnel lorsqu'une vérification d'état réussit. Cela se produit généralement dans l'un ou plusieurs des cas suivants :
  • Le serveur cible accepte une nouvelle connexion au port spécifié, répond à une requête sur ce port, puis ferme le port dans le délai spécifié. La réponse du serveur cible contient Connection: close.
  • Le serveur cible répond à une requête de vérification d'état avec un code 200 (OK) ou un autre code d'état HTTP que vous déterminez comme acceptable.
  • Le serveur cible répond à une requête de vérification d'état avec un corps de message qui correspond à celui attendu.

  Lorsqu'Apigee détermine qu'un serveur est opérationnel, Apigee continue ou reprend l'envoi de requêtes à ce serveur.

• Échec : le serveur cible peut échouer à une vérification d'état de différentes manières, en fonction du type de vérification. Un échec peut être enregistré lorsque le serveur cible :
  • refuse la connexion d'Apigee au port de la vérification d'état ;
  • ne répond pas à une requête de vérification d'état dans le délai spécifié ;
  • renvoie un code d'état HTTP inattendu ;
  • répond avec un corps de message qui ne correspond pas à celui attendu.

  Lorsqu'un serveur cible est défaillant lors d'une vérification de l'état, Apigee incrémente le nombre d'échecs associé au serveur. Si le nombre d'échecs de ce serveur atteint ou dépasse un seuil prédéfini (<MaxFailures>), Apigee interrompt l'envoi de requêtes à ce serveur.

Activer un moniteur d'intégrité

Pour créer un moniteur d'intégrité pour un proxy d'API, ajoutez l'élément <HealthMonitor> à la configuration de l'élément <HTTPTargetConnection du point de terminaison cible pour le proxy.

Vous ne pouvez pas créer de moniteurs d'intégrité dans l'interface utilisateur. Au lieu de cela, vous créez une configuration de proxy puis vous l'importez dans Apigee en tant que fichier ZIP. Une configuration de proxy est une description structurée de l'ensemble des aspects d'un proxy d'API. Les configurations de proxy sont constituées de fichiers XML organisés une structure de répertoires prédéfinie. Pour plus d'informations, consultez la documentation de référence sur la configuration des proxys d'API.

Éléments de configuration <HealthMonitor>

Le tableau suivant décrit les éléments de configuration <HealthMonitor> :

En plus de ces éléments, l'activation d'un moniteur d'intégrité nécessite que vous définissiez l'élément <MaxFailures> dans le bloc <HTTPTargetConnection> de l'élément <TargetEndpoint> sur une valeur supérieure à 0. <MaxFailures> permet de spécifier le nombre maximal de requêtes en échec entre le proxy d'API et le serveur cible avant que la requête ne soit redirigée vers un autre serveur cible.

La valeur <MaxFailures> est définie par défaut sur 0, ce qui signifie qu'Apigee n'effectue aucune action corrective. Lors de la configuration d'un moniteur d'intégrité, veillez à définir <MaxFailures> sur une valeur non nulle.

Moniteur d'intégrité à l'aide du moniteur TCP

L'exemple de moniteur d'intégrité décrit dans la configuration suivante utilise un moniteur TCP pour interroger chaque serveur cible en ouvrant une connexion sur le port 80 toutes les cinq secondes. (Le port est facultatif. S'il n'est pas spécifié, le port du moniteur TCP est le port du serveur cible.

Dans cet exemple de configuration du moniteur d'intégrité :

• Si la connexion échoue ou prend plus de 10 secondes, le nombre d'échecs augmente d'une unité pour ce serveur cible.
• Si la connexion réussit, le nombre d'échecs pour le serveur cible est réinitialisé à zéro.

Vous pouvez ajouter un moniteur d'intégrité en tant qu'élément enfant de l'élément <HTTPTargetConnection> du point de terminaison cible, comme illustré ci-dessous :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>

Éléments de configuration <TCPMonitor>

Le tableau suivant décrit les éléments de configuration <TCPMonitor> :

Moniteur d'intégrité à l'aide du moniteur HTTP

L'exemple de moniteur d'intégrité décrit dans la configuration suivante utilise un moniteur HTTP qui envoie une requête GET au service de backend toutes les cinq secondes et ajoute un en-tête d'autorisation HTTP de base au message de requête.

Dans cet exemple de configuration du moniteur d'intégrité :

• La réponse attendue du service de backend est un code de réponse HTTP 200.
• La valeur attendue pour l'en-tête d'autorisation de base HTTP personnalisé ImOK est YourOK.
• L'élément <UseTargetServerSSLInfo> est défini sur true pour utiliser les paramètres SSL du bloc <SSLInfo> du serveur cible.

Avec cette configuration, les codes de réponse et les valeurs d'en-tête attendus seront comparés aux réponses réelles du service de backend. Si la réponse ne correspond pas, la requête est alors traitée comme un échec par la configuration de l'équilibreur de charge.

Par défaut, les moniteurs d'intégrité ne peuvent pas accéder aux keystores, aux truststores ni à d'autres paramètres SSL à partir de leurs serveurs cibles. Pour autoriser l'accès à ces paramètres pour votre moniteur d'intégrité afin de prendre en charge le protocole TLS mutuel, par exemple, ajoutez <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> dans le bloc <Request>.

    <TargetEndpoint name="default">
      <HTTPTargetConnection>
        <LoadBalancer>
          <Algorithm>RoundRobin</Algorithm>
          <Server name="target1" />
          <Server name="target2" />
          <MaxFailures>5</MaxFailures>
        </LoadBalancer>
        <Path>/test</Path>
        <HealthMonitor>
          <IsEnabled>true</IsEnabled>
          <IntervalInSec>5</IntervalInSec>
          <HTTPMonitor>
            <Request>
              <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
              <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
              <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
              <Port>80</Port>
              <Verb>GET</Verb>
              <Path>/healthcheck</Path>
              <Header name="Authorization">Basic 12e98yfw87etf</Header>
              <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
            </Request>
            <SuccessResponse>
              <ResponseCode>200</ResponseCode>
              <Header name="ImOK">YourOK</Header>
            </SuccessResponse>
          </HTTPMonitor>
        </HealthMonitor>
      </HTTPTargetConnection>
    </TargetEndpoint>
  

Éléments de configuration <HTTPMonitor>

Le tableau suivant décrit les éléments de configuration <HTTPMonitor> de premier niveau :

Éléments de configuration <HTTPMonitor>/<Request>

Options de configuration pour le message de requête sortant envoyé par le moniteur d'intégrité aux serveurs cibles figurant dans la rotation. Notez que <Request> est un élément obligatoire.

Éléments de configuration <HTTPMonitor>/<SuccessResponse>

(Facultatif) Options de correspondance pour le message de réponse HTTP entrant généré par le service de backend interrogé. Les réponses qui ne correspondent pas incrémentent le nombre d'échecs de 1.