Solution API7 : Haute disponibilité pour les services B2B

Au cours de la communication avec les clients, une question clé revient fréquemment : "Offrez-vous une haute disponibilité ? Et comment ?"

API7 Enterprise fournit les composants nécessaires aux déploiements haute disponibilité gérés par le client. La disponibilité dépend de l'architecture de déploiement, des dépendances d'infrastructure et des opérations du client ; API7 Enterprise autohébergé n'est assorti d'aucun pourcentage de disponibilité au niveau du produit.

Dans l'environnement commercial, la haute disponibilité des services API est particulièrement critique, car elle impacte directement la continuité et la fiabilité des clients. Pourquoi la haute disponibilité est-elle si cruciale pour les entreprises B2B ? Parce que, en tant que métrique clé, toute interruption ou défaillance des services API pendant des moments critiques peut gravement affecter les activités des clients, entraînant non seulement des pertes financières, mais aussi potentiellement endommageant la réputation et la crédibilité des clients.

Comment API7 prend-elle en charge les déploiements à haute disponibilité ?

La haute disponibilité est un objectif d'architecture et d'exploitation, et non une propriété qu'un produit peut garantir à lui seul. Les sections suivantes décrivent les composants fournis par API7 Enterprise pour aider les clients à créer des déploiements à haute disponibilité. Le résultat effectif dépend du nombre d'instances, de la conception du basculement, des dépendances d'infrastructure et de l'exploitation du client.

Plan de Contrôle Sans État

Le plan de contrôle d'API7 Enterprise utilise une conception sans état pour gérer les configurations d'API. Le client ou une plateforme d'orchestration peut ainsi exécuter plusieurs instances et remplacer celles qui sont défaillantes sans transférer d'état applicatif entre elles. Cette conception peut réduire l'impact de la perte d'une instance, à condition que le client configure la redondance, les contrôles d'état, la répartition du trafic et la capacité de remplacement appropriés.

PostgreSQL comme Centre de Configuration par Défaut

API7 Enterprise utilise PostgreSQL pour stocker les données de configuration. PostgreSQL peut être déployé avec les mécanismes de réplication et de basculement choisis par le client, afin qu'une instance de secours puisse prendre le relais en cas de défaillance de l'instance principale. Le client ou le fournisseur d'infrastructure configure, surveille et teste le basculement de la base de données ; la disponibilité des données de configuration dépend donc de l'architecture PostgreSQL, du stockage, du réseau et des opérations mis en œuvre.

Plan de Données Sans État

Le plan de données repose sur APISIX, et les instances de passerelle sont sans état pour le traitement du trafic. Plusieurs instances peuvent ainsi être exécutées, mises à l'échelle et remplacées à l'aide d'un équilibreur de charge ou d'une plateforme d'orchestration. Cette conception peut réduire l'impact de la perte d'une instance, mais ne garantit pas la continuité du service en cas de défaillance de la capacité, du réseau, des services dépendants ou de la répartition du trafic.

Plan de Données et Plan de Contrôle Indépendants

API7 Enterprise sépare le traitement du trafic dans le plan de données de la gestion des configurations dans le plan de contrôle. Le plan de données utilise la configuration synchronisée et n'a pas besoin d'interroger le plan de contrôle pour chaque requête. Si le plan de contrôle est indisponible dans certains scénarios, une instance du plan de données peut traiter des requêtes avec la dernière configuration connue, mais ne recevra pas de nouvelle mise à jour avant le rétablissement de la connexion. Le résultat dépend toujours de l'état des instances de passerelle, de leurs dépendances et de l'architecture du client.

Scénarios d'Utilisation et Avantages de l'Architecture à Haute Disponibilité

Pour les déploiements avec Docker ou sur une machine virtuelle, les clients peuvent exécuter plusieurs instances API7 Gateway derrière un équilibreur de charge doté de contrôles d'état, puis retirer et remplacer les instances défaillantes à l'aide des outils d'exploitation de leur choix. Dans Kubernetes, les réplicas, les sondes de disponibilité et de vivacité et les contrôleurs peuvent remplacer les pods défaillants. Ces mécanismes ne sont efficaces que si le client configure correctement le nombre de réplicas, la capacité, la planification, le stockage, le réseau et les tests de basculement.

Lorsque ces mécanismes sont correctement conçus, exploités et testés, ils peuvent réduire l'impact de certaines défaillances, accélérer la récupération et aider à poursuivre le traitement d'une partie du trafic. Ils n'empêchent toutefois pas toutes les interruptions d'activité et ne garantissent pas une réduction des coûts de maintenance. Les résultats dépendent des objectifs de reprise, de la redondance, des dépendances externes, de la supervision et des procédures d'exploitation du client.

Conclusion

API7 Enterprise fournit des mécanismes de haute disponibilité pour les déploiements gérés par le client. Ces mécanismes peuvent réduire l'impact des pannes, mais la disponibilité effective du service dépend de l'architecture de déploiement, des dépendances d'infrastructure et des opérations du client.