Q&A: Migrazione di un'Architettura Ibrida a Laravel Cloud | Laravel - Lo stack pulito per Artisans e agenti

Trybe gestisce software di prenotazione per spa di hotel in Regno Unito, Europa, Australia e Stati Uniti. Elaborano 500 milioni di richieste al mese, memorizzano dati medici sensibili e non possono permettersi tempi di inattività. Hanno appena migrato la loro complessa architettura ibrida da Laravel Vapor a Laravel Private Cloud senza perdere una singola richiesta.

Devon Garbalosa e il Head of Engineering di Trybe, Dan Johnson, hanno ospitato un webinar tecnico per illustrarci come hanno fatto. Ecco la registrazione, insieme alle risposte alle domande tecnicamente più interessanti del pubblico, incluse quelle che non hanno ricevuto risposta dal vivo per motivi di tempo.

Guarda il webinar completo su YouTube. Ecco ulteriori informazioni su come Cloud e Vapor differiscono.

I Numeri Dietro la Migrazione di Trybe

• 500 milioni di richieste al mese
• 1.6 TB di database primario (MongoDB Atlas, ospitato in eu-west-1)
• 2.7 milioni di job in coda al giorno
• 1.440 esecuzioni di attività pianificate al giorno
• Quattro applicazioni distribuite su tre ambienti Laravel Private Cloud completamente isolati
• 400 negozi con white-label serviti tramite routing con sottodomini wildcard

Introduzione all'Architettura Ibrida di Trybe

Trybe gestisce quattro applicazioni separate dietro un unico dominio: una Shop API, una Customer API, una Inventory API e una Auth API. Tutte e quattro si trovano dietro Cloudflare Workers, che analizzano il percorso dell'URL e instradano ogni richiesta all'applicazione corretta.

Ciascuno dei tre ambienti Private Cloud completamente isolati (staging, playground e produzione) esegue una copia di tutte e quattro le app, senza condivisione di rete o dati tra di loro.

Architettura di Trybe

L'isolamento tra gli ambienti è un requisito fondamentale. Trybe memorizza moduli di accettazione che contengono la storia clinica dei pazienti. Un ambiente di staging che tocca i dati di produzione sarebbe una responsabilità legale per i dati.

L'intera storia della migrazione, inclusa la risoluzione dei conflitti di blocco CIDR, i problemi di routing IPv6 e l'audit delle variabili d'ambiente, sarà trattata in una prossima customer story.

Q&A: Il Passaggio di Trybe da Vapor a Cloud

Avete Dovuto Modificare del Codice per Migrare a Laravel Cloud?

Domanda di Jerome Bajou

Per la maggior parte, no. Dan ha detto che alcuni endpoint eseguivano "esattamente lo stesso codice" su Laravel Cloud e avevano prestazioni significativamente migliori. I job in coda non hanno richiesto alcuna modifica al codice. Hanno puntato i worker di Cloud agli stessi nomi di coda SQS, e tutto qui.

L'unica area che vale la pena controllare prima di qualsiasi migrazione da Vapor a Cloud sono le astrazioni specifiche di Vapor. L'helper vapor() e gli URL di upload firmati temporanei di Vapor sono funzionalità esclusive di Vapor. Laravel Cloud utilizza object storage compatibile con S3 basato su Cloudflare R2.

Se la tua applicazione utilizza già Storage::temporaryUrl() o la facade Storage standard di Laravel, non sono necessarie modifiche al codice. Basta aggiornare le variabili d'ambiente. Se fai affidamento su helper di upload specifici di Vapor, questi devono essere sostituiti con l'API Storage standard di Laravel.

Le variabili d'ambiente sono il rischio maggiore. Vapor iniettava automaticamente un gran numero di variabili (credenziali del database, URL delle code, dettagli S3) senza molta visibilità su quali fossero quelle da cui dipendevano i tuoi file di configurazione. Su Laravel Cloud, ogni variabile viene impostata esplicitamente nel dashboard.

La mancanza di una variabile è la causa più comune di errori post-migrazione. Trybe li ha individuati grazie a Laravel Nightwatch, che ha evidenziato eccezioni inaspettate nelle prime ore dopo ogni aumento del traffico. Dan ha descritto l'audit e il trasferimento delle variabili d'ambiente come il punto più doloroso dell'intera migrazione.

Quanto è Grande la Codebase del Monolite? Influisce sul Tempo di Bootstrap? State Usando Octane?

Domanda di Ariffin

Dan ha condiviso questo dopo la sessione: il monolite ha oltre 1.000 route, con un tempo di bootstrap di 23 ms. Non stanno ancora usando Laravel Octane, ma ha detto che gli piacerebbe attivarlo un giorno, una volta apportate le modifiche necessarie all'applicazione per supportarlo.

Questa è un'avvertenza importante perché Octane mantiene l'applicazione avviata in memoria tra le richieste, il che significa che qualsiasi stato statico, riutilizzo di singleton o caching in memoria che persiste tra le richieste può causare problemi difficili da debuggare. Per un team che sta ancora consolidando i microservizi in un monolite, vale la pena aspettare che la codebase sia stabile prima di introdurre questi vincoli.

Quando saranno pronti ad aggiungere Octane, Laravel Cloud lo supporta nativamente. È un'interruttore nelle impostazioni del cluster di calcolo dell'app, e Cloud lo esegue su FrankenPHP. L'unico requisito è che laravel/octane sia installato tramite Composer prima di attivarlo. Alla scala di Trybe, il risparmio sul tempo di bootstrap si accumulerebbe in modo significativo su 500 milioni di richieste mensili.

Migrare da Serverless con Laravel Vapor a Container con Laravel Cloud Comporta una Perdita di Prestazioni?

Domanda di SBT Joao

È successo il contrario. Alcuni endpoint di generazione report di Trybe superavano regolarmente il timeout di 30 secondi di Lambda su Vapor. Lo stesso codice, sugli stessi dati, girava in circa 10 secondi su Laravel Cloud.

Il motivo è che i cold start di Lambda, il sovraccarico per invocazione e i prezzi basati su memoria e invocazione scompaiono con un container caldo e sempre attivo.

Laravel Cloud gira su istanze EC2 AWS Graviton con tre strategie di autoscaling: una singola istanza fissa, un intervallo personalizzato con minimo e massimo di repliche configurabili, o scaling orizzontale illimitato. Tutte si basano su CPU e memoria.

Perché Usare il DNS con Pesi per Dividere il Traffico Invece di un Load Balancer?

Domanda di Santhosh A

Un application load balancer vive all'interno di una VPC. Può instradare tra target all'interno di un singolo provider di infrastruttura. Non può inviare una percentuale di traffico a AWS Lambda (Vapor) e un'altra percentuale a una piattaforma cloud completamente diversa (Laravel Cloud) allo stesso tempo.

Il routing DNS con pesi in Route 53 opera prima che la richiesta raggiunga entrambe le piattaforme. Crei due record per lo stesso hostname, punti ciascuno a un endpoint diverso e assegni i pesi. Route 53 risolve verso uno di essi in base a quei pesi. È l'unico approccio che funziona quando si migra tra due provider di infrastruttura separati e si ha bisogno di dividere il traffico live tra di loro.

Trybe ha anche testato il comportamento di rollback all'inizio. Dopo aver portato il traffico di produzione all'1%, lo hanno ridotto allo 0% e hanno misurato quanto tempo ci è voluto perché le richieste smettessero di arrivare a Cloud. La risposta è stata circa 30 minuti. Questo ha confermato che potevano aumentare il traffico con sicurezza, sapendo che un rollback sarebbe stato efficace entro mezz'ora se qualcosa fosse andato storto.

Come si Confronta Laravel Nightwatch con Sentry?

Domanda di Dylan

Entrambi gli strumenti coprono lo stesso terreno a livello superficiale: eccezioni, trace delle prestazioni e monitoraggio delle query. La vera differenza è la profondità dell'integrazione con Laravel. Laravel Nightwatch tratta i primitivi di Laravel come entità di prima classe. Sentry li tratta come eventi applicativi generici.

Per Dan, la salute dello scheduler è un esempio. Nightwatch monitora se le attività pianificate vengono eseguite in tempo e se vanno a buon fine senza configurazione aggiuntiva. Sentry ha Cron Monitors, ma richiedono strumentazione esplicita per ogni attività.

Il comportamento della cache è un altro aspetto: Nightwatch si aggancia direttamente agli eventi di cache di Laravel e cattura tassi di hit, pattern di chiavi ed eventi di invalidazione automaticamente. Sentry non mostra affatto il comportamento della cache.

Lo stesso vale per mail e notifiche. Nightwatch tratta la posta in uscita come un tipo di evento interrogabile, inclusi destinatario, prestazioni di rendering e successo dell'invio. Sentry vede il job che ha inviato la mail, non la mail stessa, come un elemento interrogabile.

Per Trybe, il vantaggio più immediato è stato il monitoraggio delle query. Poiché Nightwatch vede ogni query all'interno di una richiesta tracciata, può identificare automaticamente i pattern N+1. Trybe ha trovato una richiesta che eseguiva 96 query e l'ha ridotta a 12. Hanno usato i dati di Nightwatch alimentati direttamente in Claude tramite il server MCP di Nightwatch per risolvere il problema.

Trybe esegue Nightwatch con un tasso di campionamento del 10%. Con 500 milioni di richieste al mese, si tratta comunque di 50 milioni di eventi completamente tracciati.

Quando Ha Senso Usare Private Cloud Invece di Laravel Cloud Normale?

Domanda di Michael

Private Cloud fornisce un account AWS dedicato e una VPC gestita interamente da Laravel. All'interno di quell'account, si ottiene un cluster Kubernetes privato, nodi di calcolo dedicati, IP in uscita statici per la whitelist e la scelta dei metodi di connettività privata per raggiungere risorse nei tuoi account AWS: VPC Peering, PrivateLink, VPC Lattice o Transit Gateway. Si ottiene anche una rete edge dedicata con un costruttore di regole per traffico personalizzato e regole di cache.

I casi in cui Private Cloud è la scelta giusta:

Conformità e isolamento dei dati: Settori finanziario, sanitario e industrie regolamentate che necessitano di infrastruttura completamente isolata. Trybe è l'esempio esatto: i dati medici richiedono isolamento a livello di ambiente, non solo controllo degli accessi.

Connettività privata a risorse esterne: Se hai un database, un'API o un servizio nella tua VPC AWS che non può essere esposto a internet pubblico, Private Cloud è il modo per connetterti. È così che Trybe ha mantenuto il suo database MongoDB da 1.6 TB mentre spostava l'applicazione su Laravel Cloud.

Prestazioni prevedibili: Hardware dedicato senza vicini rumorosi.

Dan ha anche sottolineato un altro motivo, una funzionalità a cui Trybe ha avuto accesso anticipato: ElastiCache. I cluster ElastiCache gestiti compatibili con Redis sono disponibili solo in Private Cloud.

C'è un Vero Risparmio sui Costi Usando Laravel Cloud Rispetto a Vapor?

Domanda di Scott Foster e Zaid

La cifra preliminare di Dan è stata circa il 40% in meno rispetto a quello che pagavano su Vapor, con il numero esatto in attesa del loro primo ciclo di fatturazione completo.

Quando i clienti di Trybe erano solo nel Regno Unito, il prezzo pay-per-invocation di Vapor era un buon affare: l'applicazione era per lo più inattiva durante la notte e pagavano quasi nulla in quelle ore. Man mano che sono cresciuti fino a diventare una base di clienti globale, il loro profilo di traffico si è appiattito in un flusso continuo 24/7. Non ci sono più ore di inattività. Pagare per invocazione Lambda 24 ore su 24 è significativamente più costoso che riservare compute container prevedibile.

Devon ha aggiunto che una richiesta HTTP su Vapor non equivale sempre a un'invocazione Lambda. A seconda della durata e dell'allocazione di memoria, una singola richiesta può contare come nove invocazioni. Con 500 milioni di richieste al mese, i numeri si accumulano.

La stessa logica si applica ancor più fortemente ai queue workers. Lambda addebita per invocazione e durata. Un job a lunga esecuzione che elabora centinaia di elementi è molto costoso su Lambda. Su Cloud, i queue workers sono container sempre attivi che estraggono continuamente i job. Paghi per il tempo di calcolo indipendentemente dal numero di job.

Come Funzionano i Deploy su Laravel Cloud Rispetto a Vapor?

Domanda di Stevan Aleksic

Su Vapor, i deploy erano controllati da vapor.yml. Eseguivi vapor deploy dalla CLI, Vapor leggeva il file, impacchettava l'applicazione come zip Lambda, lo caricava su S3 e AWS prendeva il controllo. Ogni dettaglio (queue workers, limiti di concorrenza, timeout, variabili d'ambiente) viveva in quel file.

Su Laravel Cloud, i deploy sono guidati da git. Connetti il tuo repository, assegni un ramo a ogni ambiente e ogni push su quel ramo attiva un deploy automatico. Cloud crea un'immagine Docker con la versione PHP corretta e le estensioni, esegue i comandi di build e deploy configurati e poi esegue un passaggio graduale senza tempi di inattività. Le istanze vecchie completano le richieste correnti prima di andare offline. Le nuove istanze si avviano immediatamente.

Trybe mappa master su staging (ogni merge viene deployato automaticamente su staging) e un ramo di produzione separato su produzione (un merge di una pull request attiva un deploy di produzione). I queue workers sono configurati nel dashboard di Cloud come cluster di worker che puntano ai nomi delle code SQS. Cache, database, attività pianificate e variabili d'ambiente vivono tutti nel dashboard piuttosto che in un file YAML nel repository.

Laravel Cloud ha anche una CLI per i team che preferiscono lavorare da riga di comando. Supporta l'attivazione di deploy, il tailing dei log e l'esecuzione di comandi su ambienti live, incluso php artisan tinker direttamente su un'istanza Cloud in esecuzione. Dan ha citato il supporto a Tinker come qualcosa che il team usa e di cui vuole di più.

Dan ha descritto Cloud come più semplice da gestire rispetto a Vapor una volta completata la configurazione iniziale. Non c'è YAML da mantenere e il dashboard offre piena visibilità sullo stato attuale di ogni ambiente.

Guarda il Webinar Completo

La registrazione copre l'intera panoramica dell'architettura, la configurazione del routing Cloudflare, il processo di peering VPC di MongoDB, i miglioramenti delle prestazioni con Nightwatch e l'intera sessione Q&A.

Guardalo su YouTube.

Se stai valutando un passaggio da Laravel Vapor a Laravel Cloud, consulta la nostra guida alla migrazione.