De NGINX à APISIX – Redéfinir la dynamique des passerelles aériennes

Aperçu

À propos

Nommée compagnie aérienne 5 étoiles par Skytrax, cette compagnie aérienne leader opère en toute sécurité depuis 30 ans, couvrant près de 1 900 routes internationales, incluant le transport de passagers régulier, les vols charters pour la reprise du travail et des écoles, ainsi que des vols passagers en Asie, Europe, Afrique, Amérique du Nord et Océanie.

En tant que compagnie aérienne en pleine croissance, cette entreprise leader avait besoin d'une passerelle API pour faciliter les processus de réservation de vols, intégrer et connecter différents systèmes et services, et gérer des scénarios de haute concurrence ainsi que des données financières et de risque.

Défis

La montée en puissance des microservices et des déploiements conteneurisés rend difficile la gestion des instances NGINX croissantes et des configurations de domaines diversifiées.
La coexistence de nombreuses versions de NGINX augmente la complexité de la mise à niveau, de la compilation et de l'adaptation des plugins.
La précédente passerelle API ne pouvait répondre qu'aux besoins de base de cette compagnie aérienne leader, mais ne fournissait pas de fonctionnalités avancées comme le circuit breaker, les déploiements canaris, etc.

Résultats

La configuration multi-nœuds est simplifiée, améliorant grandement l'efficacité de développement et réduisant les coûts de gestion grâce à la fonctionnalité de rechargement à chaud d'APISIX.
La compagnie aérienne leader exploite l'écosystème de plugins inclusif d'APISIX pour exécuter des fonctions plus avancées, simplifiant la mise à niveau des plugins et des systèmes.
La mise à niveau améliore l'efficacité et la maintenabilité de la passerelle—un changement crucial vers une gestion de configuration organisée, modulaire et réutilisable.

Contexte

Cette compagnie aérienne leader utilisait NGINX comme passerelle nord-sud depuis un certain temps. Cependant, malgré une gestion efficace de ses besoins de trafic avec l'expansion de ses activités et de son portefeuille de produits, l'entreprise a rencontré des points de douleur croissants dans divers aspects.

1. Multiples instances et domaines NGINX

Au sein de cette entreprise, il y avait plusieurs instances NGINX et des ensembles de domaines différents, ce qui augmentait la difficulté de gestion. Le cœur de NGINX réside dans ses fichiers de configuration. Avec l'augmentation du nombre d'instances NGINX, la gestion des configurations par simple copie de fichiers via SCP est devenue de plus en plus difficile. Surtout avec l'utilisation généralisée des microservices et des déploiements conteneurisés en backend, la demande de flexibilité dans la configuration du proxy inverse a considérablement augmenté, entraînant une augmentation significative de la charge de travail pour la cohérence des configurations.

2. Diverses versions de NGINX et mises à niveau de plugins problématiques

Pour des raisons historiques, l'équipe utilisait plusieurs versions de NGINX simultanément ainsi que de nombreux plugins NGINX. Bien que la mise à niveau de NGINX elle-même ne posait pas de défis majeurs, la difficulté résidait dans la mise à niveau, la compilation et l'adaptation des divers plugins. Beaucoup de ces plugins étaient non officiels, rendant le dépannage lors de la compilation difficile. De plus, la compatibilité avec les versions de NGINX n'était pas garantie.

3. Absence de normes pour les configurations NGINX

L'héritage des systèmes de diverses équipes a conduit à une multitude de pratiques de configuration NGINX, montrant de nombreuses approches sans configuration standardisée. L'absence d'une norme de configuration unifiée a mis en évidence la diversité des méthodes d'implémentation entre les équipes, soulignant le besoin d'une approche cohérente et standardisée des configurations NGINX.

4. Fonctionnalités modernes de passerelle insuffisantes

Bien que NGINX réponde efficacement aux demandes de base de la passerelle nord-sud comme le proxy inverse et l'équilibrage de charge, les besoins dynamiques de l'entreprise nécessitaient des fonctionnalités avancées. La mise en œuvre de services comme le circuit breaker, les contrôles de sécurité et les déploiements canaris est devenue difficile en s'appuyant uniquement sur NGINX, incitant à explorer des solutions plus robustes.

Sélection de la passerelle pour des besoins métier précis

Pour répondre aux défis rencontrés avec NGINX, cette compagnie aérienne leader a soigneusement défini trois exigences fondamentales pour une nouvelle solution de passerelle :

Facilité de gestion et de configuration : Ils ont besoin d'une solution qui facilite la gestion et le déploiement unifiés des configurations comme les routes et les services en amont sur plusieurs nœuds de passerelle.
Fonctionnalités avancées de la passerelle API : La nouvelle passerelle doit répondre aux besoins métier modernes de la passerelle API, incluant le circuit breaker, les contrôles de sécurité et les déploiements canaris.
Facilité d'utilisation et faible courbe d'apprentissage : En tenant compte de la réduction des coûts de gestion, l'équipe s'attend à ce que la nouvelle solution de passerelle réponde à la plupart des besoins de base par configuration et méthodes low-code sans effort.

Après avoir clarifié les mises à niveau itératives et les exigences de base pour sa passerelle nord-sud existante, l'entreprise a recherché divers produits populaires sur le marché et a finalement choisi APISIX comme nouvelle passerelle.

Pourquoi pas OpenResty

Lors de la recherche, OpenResty a été considéré en premier, une solution largement adoptée par certaines entreprises. Son principal avantage était la compatibilité totale des fichiers de configuration avec NGINX. La migration de NGINX vers OpenResty n'était pas si difficile pour l'entreprise, bien qu'il existait des configurations de domaines complexes.

Cependant, comparé à Kong et APISIX, la version open-source d'OpenResty manquait de plugins complets et d'un tableau de bord pour la configuration visuelle. Les utilisateurs devaient coder pour répondre à certaines fonctionnalités de base.

Pourquoi pas Kong

La compagnie aérienne a considéré Kong comme une alternative. Bien que ses plugins par défaut répondaient à la plupart des exigences, l'interface visuelle (Dashboard) de la version open-source n'avait pas évolué depuis plusieurs années, incitant à préférer des solutions avec des interfaces plus récentes et conviviales.

Dans les tests de stress, APISIX a surpassé Kong, montrant des performances impressionnantes—deux fois supérieures à Kong sans plugins et jusqu'à dix fois meilleures avec les plugins de limitation de débit et Prometheus activés. De plus, APISIX, basé sur OpenResty, a démontré d'excellentes capacités de routage, renforçant la confiance de l'équipe.

Pourquoi pas Envoy

Malgré les fonctionnalités impressionnantes d'Envoy, le langage C++ et la courbe d'apprentissage plus raide, en particulier pour les limitations de l'équipe technique, ont conduit l'équipe à ne pas choisir Envoy comme solution de passerelle préférée.

Finalement, l'équipe technique a opté pour APISIX comme nouvelle passerelle en raison de sa fonctionnalité et de ses performances reconnues.

Pourquoi APISIX se distingue-t-il ?

APISIX s'est distingué par rapport à Kong pour deux raisons principales.

APISIX Dashboard

Avec le Dashboard, l'équipe technique peut gérer facilement diverses configurations de routes et de plugins. Notamment, le Dashboard APISIX est une partie open-source du projet, assurant des mises à jour continues en ligne avec le développement d'APISIX, offrant une expérience de gestion améliorée.
Projet Open Source Apache

En tant que projet de premier plan dans la fondation Apache Software Foundation, APISIX a rendu plus facile pour les utilisateurs de trouver la documentation technique pertinente par rapport à Kong. Le soutien de la communauté Apache a fourni une assistance technique fiable face aux défis, faisant d'APISIX un choix plus adapté pour la compagnie aérienne.

De plus, APISIX répond efficacement aux points de douleur mentionnés précédemment concernant NGINX.

APISIX stocke les configurations dans etcd, permettant aux développeurs de gérer plusieurs nœuds APISIX pour différents domaines avec facilité en déployant un seul cluster etcd.
APISIX est livré avec des plugins communs, incluant des vérifications de santé et d'autres plugins de surveillance, éliminant les préoccupations de compatibilité et de mise à niveau similaires à celles rencontrées avec NGINX.
APISIX inclut divers plugins de sécurité et de contrôle de trafic, permettant facilement des fonctionnalités comme le circuit breaker, les contrôles de sécurité, les déploiements canaris, et plus encore.

Globalement, APISIX se distingue comme le produit le plus adapté pour l'équipe technique.

Migration de NGINX à APISIX : Explorer des solutions avancées mais plus simples

Dans NGINX, la gestion des domaines et la mise en œuvre des fonctionnalités sont principalement réalisées via les fichiers de configuration NGINX. Bien que toujours basé sur NGINX et OpenResty, APISIX adopte une approche complètement différente, n'utilisant plus les fichiers de configuration NGINX pour gérer les domaines et implémenter les fonctionnalités.

Au lieu de cela, APISIX configure les routes et les services en amont basés sur les noms de domaine et implémente diverses fonctionnalités supplémentaires sur ces routes via des plugins. Le plugin CORS intégré d'APISIX peut être adopté pour réaliser des configurations inter-régions, épargnant la nécessité de le convertir ligne par ligne.

Voici une comparaison de code entre la configuration dans NGINX et APISIX.

#   NGINX  conf
    add_header 'Access-Control-Allow-Origin' $corsHost;
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS';
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver';
    if ($request_method = 'OPTIONS') {
            return 204;
     }

#  APISIX  plugins config
    "cors": {
      "allow_credential": true,
      "allow_headers": "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver",
      "allow_methods": "GET,POST,PUT,OPTIONS",
      "allow_origins": "https://wap.test.com,http://wap.test.com,",
    },
    "response-rewrite": {
      "status_code": 204,
      "vars": [
        [
          "request_method",
          "==",
          "OPTIONS"
        ]
      ]
    }

En comparant NGINX et APISIX, il est facile de constater que la configuration NGINX peut sembler plus concise, mais pour les personnes non familières avec NGINX et CORS, comprendre la signification sous-jacente pourrait ne pas être si simple. En revanche, APISIX encapsule différentes fonctions dans des plugins, rendant la configuration plus modulaire. Par conséquent, il devient plus évident de trouver des fonctionnalités et de comprendre les fonctions. Des exemples similaires de migration de configuration de NGINX à APISIX existent pour divers scénarios, comme la configuration de WebSocket dans NGINX.

Réalisations

Gestion simplifiée de la configuration multi-nœuds

APISIX améliore le stockage des configurations avec etcd, facilitant la gestion des divers nœuds APISIX sur plusieurs domaines. Cela simplifie les tâches en utilisant un seul cluster etcd, assurant un contrôle efficace sur les différentes instances APISIX avec des configurations de domaines spécifiques. De plus, la méthode centralisée réduit la complexité, favorise une gestion fluide et améliore l'évolutivité et l'efficacité d'APISIX dans divers scénarios de domaines. Par conséquent, dans la compagnie aérienne, le déploiement d'un seul cluster etcd suffit pour superviser les différentes instances APISIX liées à des configurations de domaines distinctes.

Opérations rationalisées avec les plugins APISIX

APISIX est livré avec des plugins intégrés comme les vérifications de santé communes, similaires aux plugins fréquemment utilisés dans NGINX. Cette fonctionnalité élimine le besoin pour la compagnie aérienne de s'inquiéter des problèmes liés aux mises à niveau et à la compatibilité. L'inclusion de ces plugins dans APISIX assure une fonctionnalité fluide et soulage les préoccupations associées à la mise à niveau et au maintien de la compatibilité, offrant une expérience sans tracas pour la compagnie aérienne.

De plus, dans APISIX, des fonctionnalités comme le partage de ressources inter-origines (CORS) et le support WebSocket peuvent être implémentées de manière transparente via des plugins. Cette approche simplifie non seulement le processus de développement, mais contribue également à une résolution plus sophistiquée et efficace des défis de la compagnie aérienne.

Établissement d'une passerelle API complète

APISIX est équipé de divers plugins de sécurité et de contrôle de trafic, facilitant la mise en œuvre facile de la limitation de service, des mesures de sécurité et des déploiements graduels. Cela permet à la compagnie aérienne d'exploiter une gamme plus large de fonctionnalités de base et avancées. L'adoption d'APISIX représente une réalisation significative pour la compagnie aérienne, permettant une fiabilité accrue des services, des contrôles de sécurité robustes et des stratégies de déploiement efficaces comme les déploiements graduels, contribuant finalement à une capacité opérationnelle et à des performances améliorées.

Refonte des configurations héritées en modules réutilisables

Tout au long du processus de mise à niveau, l'équipe technique a découvert de nombreuses configurations obsolètes dans la configuration NGINX existante, dont beaucoup impliquaient un copier-coller insensé. Cette mise à niveau a servi de révision complète de l'ensemble de leur passerelle nord-sud, se concentrant particulièrement sur les fonctionnalités fournies par APISIX, comme plugin_config. Ces fonctionnalités ont grandement facilité la gestion modulaire et la réutilisation des configurations au niveau de la passerelle. La mise en œuvre de plugin_config d'APISIX et des capacités associées a non seulement rationalisé le processus de configuration, mais a également amélioré l'efficacité globale et la maintenabilité de notre passerelle nord-sud. Cette mise à niveau a marqué un changement crucial vers une approche de gestion de configuration plus organisée, modulaire et réutilisable.

Résumé

Depuis avril 2023, cette compagnie aérienne leader a initialement rencontré APISIX, jusqu'à la migration réussie de NGINX à APISIX dans l'environnement de production en juillet de la même année, l'ensemble du processus de migration a donné des résultats satisfaisants.

Dans les premières étapes de la migration, l'équipe technique a traité diverses configurations historiques et s'est inquiétée de savoir si les plugins APISIX pouvaient reproduire entièrement toutes les fonctionnalités de notre NGINX existant. Cependant, le résultat final a démontré que les plugins APISIX étaient plus que capables de relever ce défi.

En résumé, APISIX a fourni une solution plus élégante et a aidé la compagnie aérienne leader à entrer dans une nouvelle phase technique. Il a parfaitement résolu les divers points de douleur rencontrés avec NGINX et son riche ensemble de plugins permet à la compagnie aérienne de répondre facilement à diverses nouvelles exigences posées par les clients.