Dans une architecture basée sur les microservices pour un système d’entreprise tel que Clumio, il n’est pas réaliste de disposer d’un point de terminaison public par microservice. L’un des principaux problèmes réside dans le couplage étroit que cela entraîne entre le client et le serveur. De plus, chaque microservice doit mettre en œuvre et maintenir les composants communs tels que la journalisation, la traçabilité et la sécurité (authentification, autorisation, limitation de débit).
Une passerelle API s’interpose entre un client et un serveur pour servir de proxy aux requêtes et aux réponses échangées entre les deux.
Le fait de disposer d’une passerelle API offre un point d’entrée unifié pour tous les clients externes et un cadre prenant en charge tous les éléments communs mentionnés ci-dessus. Cela permet également à chaque microservice de mettre en œuvre son propre protocole de communication, celui qui correspond le mieux à ses besoins, indépendamment de la passerelle.
API Gateway d’AWS
Outre les avantages mentionnés ci-dessus offerts par les passerelles API, d’autres critères ont influencé notre choix :
- Disposer d’un mécanisme permettant de s’intégrer à API Gateway de manière à ce que l’introduction de nouvelles API et la maintenance des API existantes ne posent aucun problème ou très peu, afin de permettre aux développeurs de se concentrer principalement sur leur logique métier
- Étant donné qu’une passerelle API pourrait constituer un point de défaillance unique, elle doit être une offre entièrement gérée, résiliente et hautement évolutive.
- Prise en charge des WebSockets
AWS API Gateway répond à toutes ces exigences et offre une bonne intégration avec les autres services AWS, ce qui permet de développer des applications en s’appuyant sur cette plateforme.
Tirer parti d’AWS API Gateway
Spécification Swagger
Swagger offre une représentation performante des API RESTful.
Nous avons utilisé l’outil go-swagger, qui permet de générer une spécification Swagger à partir d’un code Go annoté.
Par conséquent, les développeurs n’ont qu’à annoter leur API REST conformément à la spécification ci-dessus et à laisser notre framework (évoqué plus loin) se charger de l’intégrer à AWS API Gateway.
Intégration avec AWS API Gateway
Chez Clumio, l’ensemble de notre infrastructure AWS est gérée sous forme de code via Terraform. AWS API Gateway peut être configuré à l’aide des ressources Terraform qu’il propose.
Nous utilisons la ressource `aws_api_gateway_rest_api`, qui nous permet d’intégrer l’intégralité de la spécification Swagger dans AWS API Gateway. Cependant, AWS API Gateway ne peut pas traiter une spécification Swagger « brute ». Il nécessite diverses extensions (telles que x-amazon-apigateway-integration) pour pouvoir configurer une API en toute transparence. C’est là que nous avons mis en place un framework qui injecte les extensions requises dans une spécification Swagger brute afin de la rendre compatible avec AWS API Gateway !
Type d’intégration VPC Link
AWS API Gateway propose diverses intégrations avec vos serveurs backend afin de servir de proxy pour les requêtes API entrantes.
Comme tous nos microservices sont associés à un VPC pour renforcer la sécurité, nous utilisons l’ VPC Link intégration. Cela permet à AWS API Gateway d’accéder en toute sécurité aux points de terminaison d’API privés au sein du VPC.
Noms de domaine personnalisés et mappages d’API
Par défaut, AWS API Gateway génère un nom de domaine unique pour l’API, du type aabbccdd12.execute-api.us-west-2.amazonaws.com. Pour une grande entreprise, il va de soi que nous souhaitons personnaliser le nom de domaine public des API destinées à nos utilisateurs. AWS API Gateway nous permet de le faire grâce à la fonctionnalité « Noms de domaine personnalisés ».
De plus, nous créons également des API distinctes dans API Gateway, correspondant à certains de nos chemins d’accès les plus fréquentés. Toutes ces API sont ensuite regroupées via des mappages d’API, comme indiqué ci-dessous. Cela nous permet de faire évoluer nos API à l’horizontale tout en conservant un seul nom de domaine public pour l’ensemble.
Lambda Authorizer, forfaits d’utilisation et clés API
Comme mentionné précédemment, l’un des principaux cas d’utilisation d’une passerelle API consiste à appliquer l’authentification et l’autorisation dès le début du cycle de vie d’une requête API, afin que seul le trafic pertinent atteigne les serveurs backend.
Nous utilisons Lambda Authorizer pour l’authentification et l’autorisation, tandis que les forfaits d’utilisation et les clés API servent à mettre en œuvre la limitation de débit pour nos API.
Nous avons mis en place un autoriseur Lambda basé sur des jetons qui attend les données d’entrée suivantes :
Le authorizationToken (sous la forme d’un JWT) peut être utilisé pour implémenter la logique d’authentification/d’autorisation requise au sein de l’autoriseur Lambda afin de renvoyer le résultat ci-dessous :
La décision d’authentification/d’autorisation dépend de la valeur de Effect (Allow|Deny) et la décision de limitation est régie par l’identifiant de la clé API figurant dans usageIdentifierKey. La clé API doit être associée à un forfait d’utilisation qui définit le quota de requêtes à appliquer (en nombre de requêtes par seconde). Nous émettons une clé API pour chaque client et sommes ainsi en mesure d’appliquer la limitation par client.
Un autre élément intéressant dans la sortie est context qui peut contenir toutes les paires clé-valeur requises par l’application. Nous y recourons largement pour capturer les informations client, que nous transmettons ensuite tout au long du cycle de vie de la requête API. Cela évite d’avoir à rechercher les détails du client lorsque la requête transite par plusieurs microservices au niveau du backend.
Conclusion
Nous espérons que vous avez pu mieux comprendre comment nous tirons parti d’AWS API Gateway chez Clumio et que vous avez également eu un aperçu des efforts plus généraux que nous déployons en matière d’ingénierie. Nous accordons la plus grande attention à la sécurité, à l’évolutivité et, surtout, à la mise en place de processus adaptés aux développeurs. Cela facilite la maintenance de nos produits à mesure que nous mûrissons et que nous nous développons, tout en offrant suffisamment de flexibilité pour intégrer de nouvelles fonctionnalités.
