Antimodèle : équilibrer la charge avec un seul serveur cible tout en définissant MaxFailures sur une valeur non nulle

Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Consultez la documentation d'Apigee Edge.

La configuration TargetEndpoint définit la façon dont Apigee se connecte à un service ou à une API de backend. Il envoie les requêtes et reçoit les réponses vers/depuis le service de backend. Le service de backend peut être un serveur HTTP/HTTPS ou NodeJS.

Le service de backend dans le point d'extrémité cible peut être appelé de l'une des manières suivantes :

Rediriger une URL vers un serveur HTTP ou HTTPS
Configuration de serveur cible

De même, la règle ServiceCallout peut être utilisée pour appeler n'importe quel service externe à partir du flux de proxy d'API. Cette règle permet de définir des URL cibles HTTP/HTTPS directement dans la règle elle-même ou en utilisant une configuration de serveur cible.

Configuration de serveur cible

La configuration de serveur cible dissocie les URL de points de terminaison concrètes des configurations de point d'extrémité cible ou dans les règles d'appel de service. Un serveur cible est référencé par un nom au lieu de l'URL dans le point d'extrémité cible. La configuration de serveur cible comporte le nom d'hôte du service de backend, le numéro de port et d'autres détails.

Voici un exemple de configuration de serveur cible :

<TargetServer name="target1">
  <Host>www.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>

Le serveur cible vous permet d'avoir des configurations différentes pour chaque environnement. Une règle de point d'extrémité cible/d'appel de service peut être configurée avec un ou plusieurs serveur cibles à l'aide d'un équilibreur de charge. La compatibilité intégrée pour l'équilibrage de charge améliore la disponibilité des API et le basculement entre les instances de serveur de backend configurées.

Voici un exemple de configuration de point d'extrémité cible utilisant des serveurs cibles :

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

MaxFailures

La configuration MaxFailures spécifie le nombre maximal d'échecs de requêtes vers le serveur cible après lequel le serveur cible est marqué comme étant en panne et supprimé de la rotation pour toutes les requêtes suivantes.

Exemple de configuration avec MaxFailures spécifié :

<TargetEndpoint name="default">
    <HTTPTargetConnection>
      <LoadBalancer>
        <Server name="target1"/>
        <Server name="target2"/>
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

Dans l'exemple ci-dessus, si cinq requêtes consécutives échouent pour la cible "target1", la valeur "target1" est supprimée de la rotation et toutes les requêtes suivantes ne sont envoyées qu'à la cible target2.

Antimodèle

Il n'est pas recommandé d'avoir un seul serveur cible dans une configuration LoadBalancer de la règle de point d'extrémité cible ou d'appel de service avec MaxFailures défini sur une valeur non nulle, car cela peut avoir des conséquences négatives.

Prenons l'exemple de configuration suivant ayant un serveur cible unique nommé "target1" avec MaxFailures défini sur 5 (valeur non nulle) :

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
  </HTTPTargetConnection>

Si les requêtes adressées au serveur cible "target1" échouent cinq fois (nombre spécifié dans MaxFailures), le serveur cible est supprimé de la rotation. Étant donné qu'il n'y a pas d'autre serveurs cibles vers lesquels basculer, toutes les requêtes ultérieures envoyées au proxy d'API ayant cette configuration échouent avec une erreur 503 Service Unavailable.

Même si le serveur cible "target1" revient à son état normal et est capable d'envoyer des réponses réussies, les requêtes adressées au proxy d'API continuent à renvoyer des erreurs 503. En effet, Apigee ne remet pas automatiquement le serveur cible en rotation, même une fois la cible opérationnelle. Pour résoudre ce problème, le proxy d'API doit être redéployé pour qu'Apigee remette le serveur cible en rotation.

Si la même configuration est utilisée dans la règle d'appel de service, les requêtes API affichent une erreur 500 lorsque les requêtes au serveur cible "target1" ont échoué 5 fois.

Impact

L'utilisation d'un seul serveur cible dans une configuration LoadBalancer de la règle de point d'extrémité cible ou d'appel de service avec MaxFailures défini sur une valeur différente de zéro a les effets suivants :

Les requêtes API échouent continuellement avec des erreurs 503/500 (lorsque les requêtes échouent le nombre maximal d'échecs) jusqu'à ce que le proxy d'API soit redéployé.
Une panne plus longue, car diagnostiquer la cause du problème est compliqué et peut prendre plus de temps (sans connaissance préalable de cet antimodèle).

Bonne pratique

Avoir plusieurs serveurs cibles dans la configuration LoadBalancer pour une meilleure disponibilité.
Définissez toujours un objet HealthMonitor lorsque MaxFailures est défini sur une valeur non nulle. Dès que le nombre d'échecs sur un serveur cible atteint la valeur spécifiée dans MaxFailures, ce serveur est supprimé de la rotation. L'objet HealthMonitor permet de s'assurer que le serveur cible est remis en rotation lorsqu'il est de nouveau disponible. Il n'est donc pas nécessaire de redéployer le proxy.

Pour vous assurer que la vérification d'état est effectuée sur le numéro de port qu'Apigee utilise pour se connecter aux serveurs cibles, Apigee vous recommande d'omettre l'élément enfant <Port> sous <TCPMonitor>, sauf s'il est différent du port du serveur cible. Par défaut, <Port> est identique au port de serveur cible.

Exemple de configuration avec HealthMonitor :
```
<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>
      </TCPMonitor>
    </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>
```
S'il existe une contrainte telle qu'un seul serveur cible et si l'objet HealthMonitor n'est pas utilisé, ne spécifiez pas MaxFailures dans la configuration LoadBalancer.

La valeur par défaut de MaxFailures est 0. Cette valeur implique qu'Apige tente toujours de se connecter à la cible pour chaque requête et ne supprime jamais le serveur cible de la rotation.