In un’architettura basata su microservizi per un sistema di livello aziendale come Clumio, non è pratico avere un endpoint pubblico per ogni microservizio. Uno dei problemi principali è lo stretto accoppiamento che ciò comporta tra client e server. Inoltre, ogni microservizio deve implementare e gestire le componenti comuni quali la registrazione degli eventi, la tracciabilità e la sicurezza (autenticazione, autorizzazione, limitazione della frequenza).
Un API Gateway si colloca tra un client e un server per fungere da proxy per le richieste e le risposte tra i due.
Disporre di un API Gateway offre un punto di accesso unificato per tutti i client esterni e un framework che si occupa di tutti gli elementi comuni sopra menzionati. Ciò consente inoltre a ciascun microservizio di implementare il proprio protocollo di comunicazione che meglio si adatta alle proprie esigenze, indipendentemente dal Gateway.
AWS API Gateway
Oltre ai vantaggi sopra citati offerti dagli API Gateway, avevamo anche ulteriori requisiti che hanno influenzato la scelta:
- Disporre di un meccanismo di integrazione con l’API Gateway che garantisca l’introduzione di nuove API e la manutenzione di quelle esistenti senza ostacoli o con ostacoli minimi, in modo da consentire agli sviluppatori di concentrarsi principalmente sulla propria logica di business
- Poiché un API Gateway potrebbe potenzialmente rappresentare un singolo punto di guasto, dovrebbe trattarsi di una soluzione completamente gestita, resiliente e altamente scalabile
- Supporto per WebSocket
AWS API Gateway soddisfa tutti questi requisiti e offre un’ottima integrazione con altri servizi AWS, consentendo di sviluppare soluzioni basate su di esso.
Sfruttare AWS API Gateway
Specifiche Swagger
Swagger offre una potente rappresentazione delle API RESTful.
Abbiamo utilizzato lo strumento go-swagger, in grado di generare una specifica Swagger a partire da codice Go annotato.
Di conseguenza, gli sviluppatori devono semplicemente annotare la propria API REST secondo le specifiche sopra indicate e lasciare che sia il nostro framework (di cui parleremo più avanti) a occuparsi dell’integrazione con AWS API Gateway.
Integrazione con AWS API Gateway
In Clumio, tutta la nostra infrastruttura AWS viene gestita come codice tramite Terraform. AWS API Gateway può essere configurato utilizzando le risorse Terraform che mette a disposizione.
Utilizziamo la risorsa `aws_api_gateway_rest_api`, che ci permette di inserire l’intera specifica Swagger nell’AWS API Gateway. L’AWS API Gateway, tuttavia, non è in grado di elaborare una specifica Swagger “grezza”. Richiede infatti che varie estensioni (come x-amazon-apigateway-integration) facciano parte della specifica Swagger, in modo da poter configurare un’API senza intoppi. È qui che abbiamo implementato un framework che inserisce le estensioni richieste in una specifica Swagger non elaborata per renderla compatibile con AWS API Gateway!
Tipo di integrazione del collegamento VPC
AWS API Gateway offre diverse integrazioni con i server di backend per gestire le richieste API in entrata tramite proxy.
Poiché tutti i nostri microservizi sono associati a una VPC per garantire una maggiore sicurezza, utilizziamo l’ VPC Link integrazione. Ciò consente ad AWS API Gateway di accedere in modo sicuro agli endpoint API privati all’interno della VPC.
Nomi di dominio personalizzati e mappature API
Per impostazione predefinita, AWS API Gateway genera un nome di dominio univoco per l’API, del tipo aabbccdd12.execute-api.us-west-2.amazonaws.com. Per un’azienda di grandi dimensioni, è ovviamente preferibile personalizzare il nome di dominio pubblico delle API per i propri utenti. AWS API Gateway consente di farlo tramite i nomi di dominio personalizzati.
Inoltre, creiamo anche API separate in API Gateway corrispondenti ad alcuni dei nostri percorsi API di base più intensi. Tutte queste API vengono poi integrate tra loro tramite mappature API, come illustrato di seguito. Questo ci permette di scalare orizzontalmente le nostre API pur mantenendo un unico nome di dominio pubblico per esse.
Lambda Authorizer, piani di utilizzo e chiavi API
Come accennato in precedenza, uno dei principali casi d’uso di un API Gateway consiste nell’applicare l’autenticazione e l’autorizzazione sin dall’inizio del ciclo di vita della richiesta API, in modo che solo il traffico pertinente raggiunga i server di backend.
Utilizziamo Lambda Authorizer per l’autenticazione e l’autorizzazione, mentre i piani di utilizzo e le chiavi API servono ad applicare limiti di velocità alle nostre API.
Abbiamo implementato un Lambda Authorizer basato su token che richiede il seguente input:
il authorizationToken (sotto forma di JWT) può essere utilizzato per implementare la logica di autenticazione/autorizzazione richiesta all’interno dell’autorizzatore Lambda, in modo da restituire l’output come indicato di seguito:
La decisione relativa all’autenticazione/autorizzazione dipende dal valore di Effect (Allow|Deny) e la decisione relativa alla limitazione è determinata dall’identificatore della chiave API contenuto in usageIdentifierKey. La chiave API deve essere associata a un piano di utilizzo che stabilisce il limite di richieste da applicare (in termini di richieste al secondo). Emettiamo una chiave API per ciascun cliente e siamo quindi in grado di applicare la limitazione per singolo cliente.
Un altro aspetto interessante dell’output è context che può contenere qualsiasi coppia chiave-valore in base alle esigenze dell’applicazione. Ne facciamo ampio uso per acquisire le informazioni sul cliente, che poi trasmettiamo durante l’intero ciclo di vita della richiesta API. Ciò elimina la necessità di ricercare i dettagli del cliente mentre la richiesta passa attraverso diversi microservizi nel backend.
Conclusione
Ci auguriamo che abbiate potuto farvi un’idea di come utilizziamo AWS API Gateway in Clumio e che abbiate avuto anche un assaggio delle più ampie iniziative ingegneristiche che portiamo avanti. Dedichiamo la massima attenzione alla sicurezza, alla scalabilità e, soprattutto, all’adozione di processi su misura per gli sviluppatori. Ciò semplifica la manutenzione dei prodotti man mano che maturiamo e cresciamo, garantendo al contempo un’estensibilità sufficiente per soddisfare le esigenze di nuove funzionalità.
