This autumn I will be back at the Serverless Architecture Con, this time in Berlin, to talk about serverless databases. The title of my session? The Future of Relational Databases on the Cloud.
Abstract
The major cloud providers offer different options to run a relational database on the cloud. A recent approach is to rely on so-called serverless databases that offer both traditional TCP connections and HTTP API access. In a short journey to databases on the cloud, we will compare different approaches and services, explore the main benefits and limitations of a serverless RDBMS versus a more traditional managed database.
AWS ha recentemente introdotto le istanza I4i, EC2 progettate per carichi di lavoro che richiedono prestazioni elevate di lettura e scrittura sequenziali per insiemi di dati di grandi dimensioni sullo storage locale. Le nuove istanze sono pensate per casi d’uso come database relazionali, file system distribuiti, data warehouse.
Le istanze EC2 I4i hanno processori Intel Xeon Scalable (Ice Lake) di terza generazione e storage locale Nitro SSD, fornendo elevate prestazioni di I/O, bassa latenza e minima variabilità della latenza. Jeff Barr, vicepresidente e chief evangelist di AWS, suggerisce possibili casi d’uso:
Database transazionali come MySQL, Oracle DB e Microsoft SQL Server, nonché database NoSQL: MongoDB, Couchbase, Aerospike, Redis e simili. Sono inoltre istanze ideali per carichi di lavoro che possono trarre vantaggio da prestazioni di calcolo molto elevate per TB di storage, come l’analisi dei dati e i motori di ricerca.
Rispetto alle precedenti I3, le nuove istanze introducono una dimensionle nuove istanze e massima dell’istanza maggiore (i4i.32xlarge), con 1 TB di memoria e 30 TB di storage NVMe locale. Secondo AWS, forniscono una latenza di I/O di archiviazione inferiore fino al 60% e una variabilità di latenza di I/O di archiviazione inferiore fino al 75% rispetto alle istanze I3.
Abbiamo osservato un throughput in lettura per vCPU fino a 2,7 volte superiore sulla nuova I4i rispetto alle istanze I3. Con un mix di letture e scritture, abbiamo osservato un throughput per vCPU 2,2 volte superiore, con una riduzione del 40% della latenza media rispetto alle istanze I3 (…) Bastano tre nodi I4i.16xlarge per supportare ben oltre un milione richieste al secondo – con un carico di lavoro realistico.
L’I4i non è l’unica opzione EC2 ottimizzata per lo storage in scrittura rilasciata da AWS: all’ultimo re:Invent, AWS ha rilasciato le Im4gn/Is4gen. Le istanze I4i supportano solo AMI con i driver ENA più recenti e NVMe 1.4. Le nuove istanze sono attualmente disponibili solo in alcune regioni negli Stati Uniti e in Europa. E i costi? La nuova classe parte da $ 0,172/ora on-demand per le i4i.large, un aumento del 10% rispetto alle i3.large ($ 0,156/ora).
Amazon ha recentemente annunciato che SageMaker Serverless Inference è ora GA. La nuova opzione serverless è progettata per flussi di lavoro intermittenti o poco frequenti e gestisce il sizing in funzione delle richieste di inferenza.
In modo simile ad altri servizi serverless su AWS, con SageMaker Serverless gli endpoint di inferenza gestiscono automaticamente le risorse di calcolo in base al traffico, senza aver bisogno di scegliere a priori un tipo di istanza o gestire il sizing. Sagemaker Serverless Inference è in grado di scalare da decine a migliaia di inferenze in pochi secondi ed è anche possibile specificare i requisiti di memoria per l’endpoint. Antje Barth, principal developer advocate presso AWS, spiega i vantaggi della nuova opzione:
in molti incontri con i professionisti del ML, ho recepito la richiesta di un’opzione di inferenza ML completamente gestita che consenta agli sviluppatori di concentrarsi sullo sviluppo del codice di inferenza senza gestire l’infrastruttura. SageMaker Serverless Inference ora offre questa possibilità.
La preview dell’opzione serverless era stata annunciata a re:Invent 2021 e da allora il AWS ha aggiunto il supporto per Amazon SageMaker Python SDK e Model Registry per integrare gli endpoint di inferenza serverless con i workload MLOps.
Se l’endpoint non riceve traffico per un po’, riduce le risorse a zero. Se l’endpoint riceve improvvisamente nuove richieste, potresti notare che è necessario del tempo prima che l’endpoint sia in grado di elaborare le richieste. Questo tempo di avviamento dipende molto dalle dimensioni del modello e dal tempo di avvio del container. Per ottimizzare i tempi di cold start, puoi provare a ridurre al minimo le dimensioni del tuo modello, ad esempio applicando tecniche come knowledge distillation, quantization, o model pruning.
Oltre all’ultima aggiunta serverless, Amazon SageMaker ha altre tre opzioni per supportare diversi casi d’uso: SageMaker Real-Time Inference, progettata per carichi di lavoro con latenza nell’ordine dei millisecondi, SageMaker Asynchronous Inference, consigliata per inferenze di grandi dimensioni o che richiedono lunghi tempi di elaborazione e SageMaker Batch Transform per eseguire previsioni su batch di dati.
E’ possibile creare e aggiornare un endpoint di inferenza serverless utilizzando la console SageMaker, la SDK AWS, l’SDK Python SageMaker, l’AWS CLI o AWS CloudFormation. Il prezzo di Sagemaker Serverless Inference dipende dal tempo di calcolo e dalla quantità di dati elaborati.
AWS ha recentemente annunciato che Amazon MSK Serverless è GA. L’opzione serverless per gestire Apache Kafka su AWS elimina la necessità di monitorare il sizing del cluster e gestisce automaticamente le partizioni.
Amazon MSK Serverless è un cluster per Amazon MSK progettato per il provisioning e la scalabilità automatica delle risorse di calcolo e dello storage. Marcia Villalba, Senior Developer Advisor presso AWS, spiega il vantaggio principale dell’opzione serverless:
MSK Serverless è la soluzione perfetta per iniziare con un nuovo progetto che usa Apache Kafka in cui non conosci a priori quanta capacità ti servirà o se le tue applicazioni producono carichi imprevedibili e non desideri pagare per la capacity inattiva. Inoltre, è ottimo se vuoi evitare il provisioning, il ridimensionamento e la gestione dell’utilizzo delle risorse dei tuoi cluster.
Secondo Amazon, un cluster MSK Serverless supporta qualsiasi tool compatibile con Apache Kafka per elaborare i dati e si integra con Amazon Kinesis Data Analytics per Apache Flink e AWS Lambda.
Amazon MSK Serverless supporta AWS IAM per l’autenticazione e l’autorizzazione client e, per garantire HA, crea due repliche di una partizione in AZ differenti.
Introdotto da AWS nel 2018, Amazon MSK è un servizio gestito per applicazioni basate su Apache Kafka per elaborare i dati in streaming. L’opzione serverless per MSK era una funzionalità richiesta dalla community ed era stata presentata in preview all’ultimo re:Invent, insieme alle versioni serverless di Redshift e EMR.
Amazon MSK non è l’unico servizio serverless per l’elaborazione e l’analisi dati su AWS: Kinesis è un servizio di streaming di dati in cui la quantità di dati che può essere processata è determinata dal numero di shard assegnati a uno stream. Esistono anche altre opzioni per avere una managed version di Kafka su un cloud pubblico: Confluent Cloud è una piattaforma di streaming di eventi distribuita nativa del cloud creata dagli sviluppatori originali di Apache Kafka. Il prezzo dell’offerta serverless di MSK si basa, tra gli altri fattori, sul throughput. Ogni cluster Amazon MSK Serverless fornisce fino a 200 MBps di throughput in scrittura e 400 MBps di throughput in lettura e alloca fino a 5 MBps di throughput in scrittura e 10 MBps di throughput in lettura per ogni partizione.
IaSQL, l’azienda che ha creato un servizio per gestire l’infrastruttura AWS utilizzando SQL, ha recentemente annunciato che IaSQL è disponibile come progetto open source e come software as a service.
Mappando i servizi AWS in tabelle SQL, IaSQL gestisce una connessione bidirezionale tra un account AWS e un database PostgreSQL per descrivere un deployment su AWS. LuisFer De Pombo, co-fondatore e CEO, spiega:
I tradizionali software di gestione Infrastructure as Code non hanno un buon modo per gestire le dipendenze tra le parti dell’infrastruttura in un’architettura di microservizi, il che rende davvero difficile apportare e ripristinare le modifiche. Una rappresentazione SQL risolve il problema principale degli strumenti di infrastruttura basati su YAML.
Il servizio può essere configurato anche per gestire deployment AWS esistenti: collegando un account AWS a un’istanza IaSQL, il database viene popolato con le risorse cloud disponibili e nuovi servizi possono essere definiti utilizzando i moduli IaSQL, ad esempio aws_ec2 o aws_elb.
IaSQL non è l’unico servizio che si propone di gestire l’infrastruttura cloud tramite SQL: altre opzioni sono CloudQuery, Steampipe, trino-cloud, e StackQL. De Pombo descrive con un esempio un vantaggio dell’approccio SQL:
Non è possibile definire il tipo di istanza EC2 come “t2.mucro” e fare in modo che IaSQL tenti di crearla. L’istruzione insert fallirà, ti dirà che sono state inserite zero righe e potrai rapidamente capire il problema.
Uno dei vantaggi dell’utilizzo di SQL è l’ampia adozione del linguaggio: SQL è già utilizzato nella maggior parte dei team di sviluppo, quindi gli ingegneri del cloud non devono imparare un nuovo linguaggio per gestire l’infrastruttura.
Secondo i creatori, uno dei vantaggi di un’istanza PostgreSQL come repository è la possibilità di sostituire completamente il database IaSQL in esecuzione con uno snapshot da AWS, ripristinando l’intero deployment a uno stato precedente.
La versione corrente di IaSQL supporta solo alcuni servizi AWS: EC2, Elastic Container Register (ECR), ECS + Fargate, ELB, RDS, VPC e IAM. IaSQL prevede di supportare Google Cloud, Azure e altri provider in futuro.
From Fauna transactional database to infrastructure as SQL on AWS, from RDS and Aurora PostgreSQL vulnerabilities to AWS Firewall Manager: a recap of my articles for InfoQ in April.
Infrastructure as SQL on AWS: IaSQL is Now Open Source and SaaS
IaSQL, the company behind a service that models AWS infrastructure using SQL, has recently announced that IaSQL is available as open source and software as a service.
Amazon EC2 Introduces Automatic Recovery of Instances by Default
Amazon recently announced that EC2 instances will now automatically recover in case they become unreachable due to underlying hardware issues. Automatic recovery migrates the instance to a different hardware while retaining instance ID, private IP addresses, Elastic IP address, and metadata.
RDS and Aurora PostgreSQL Vulnerability Leads to AWS Deprecating Many Minor Versions
A researcher at the security company Lightspin recently explained how she obtained credentials to an internal AWS service using a PostgreSQL extension and exploiting a local file read vulnerability on RDS. AWS confirmed the issue and deprecated dozens of minor versions of Amazon Aurora and RDS for PostgreSQL.
AWS Introduces Lambda Function URLs to Simplify Serverless Deployments
AWS recently announced the general availability of Lambda Function URLs, a feature that lets developers directly configure a HTTPS endpoint and CORS headers for a Lambda function without provisioning other services.
Fauna, the company behind the Fauna transactional database, recently announced the general availability of event streaming, a push-based stream that sends changes at both the document and collection levels to subscribed clients.
More news? A recap of my articles for InfoQ in March.
Today I was a speaker at the DevOps Conference London 2022 and I discuss the AWS Free Tier: the Good, the Bad, and the Ugly. Below the slides of my presentation.
