The Pulse
Microsoft ha trasferito il runtime in produzione di Copilot Cowork da Python a Rust
Microsoft descrive il passaggio del runtime in produzione di Copilot Cowork da Python a Rust, con il traffico di produzione trasferito un cluster alla volta e l’ultimo cluster spostato il 10 ottobre. Il resoconto illustra il confronto delle
AI.info Team · Scritto con l’IA · verificato ·
Python ha aiutato Microsoft a portare Copilot Cowork alla disponibilità generale a giugno; alla scala raggiunta successivamente dal servizio, afferma l’azienda, il runtime Python ha causato blocchi dell’event loop, timeout nascosti e problemi di memoria. Microsoft ha pubblicato i dettagli del passaggio a Rust il 2 novembre, descrivendo una migrazione che ha trasferito il traffico di produzione per gradi e si è conclusa il 10 ottobre.
Il resoconto, scritto da Bas Brekelmans, partner software engineer di Microsoft, espone chiaramente il compromesso:
«Python ci ha permesso di arrivare rapidamente alla disponibilità generale e non credo che saremmo riusciti a rispettare la scadenza di giugno con nessun’altra tecnologia.»
Bas Brekelmans, partner software engineer, Microsoft
La riscrittura non implicava che Rust da solo spiegasse i miglioramenti delle prestazioni. Brekelmans ha scritto che, a suo avviso, lo spostamento del ciclo dell’agente da un container lento ad avviarsi al servizio Rust ha contribuito in larga parte al miglioramento.
L’event loop di Python è diventato un collo di bottiglia in produzione
Microsoft afferma che ogni processo Python aveva un solo event loop e che, sotto carico, ha misurato blocchi fino a 11,9 secondi. Durante un blocco, il lavoro di quel processo rimaneva in attesa, compresi i rinnovi dei lock; alcuni turni perdevano i propri lock prima di concludersi. Il team ha anche scoperto che il 16,7% delle configurazioni delle sessioni richiedeva esattamente cinque secondi: la causa era un timeout che scattava, anziché lavoro utile.
La pressione sulla memoria ha aggiunto un altro segnale d’allarme: quando il sistema esauriva la memoria, il processo che veniva terminato era quasi sempre quello Python, 539 volte in una settimana su un singolo cluster. Spostare il lavoro bloccante fuori dall’event loop ha aiutato, ha scritto Brekelmans, ma ha messo in luce quello che il team considerava il limite di fondo: l’unico loop, non una particolare operazione bloccante.
Le fixture hanno fornito un test comportamentale per la conversione a Rust
Invece di cercare di confrontare Rust e Python riga per riga, il team ha generato fixture di test eseguendo il codice Python esistente su input selezionati. Questi record JSON acquisiscono output come corpi delle risposte, codici di stato, righe di log e scritture nello storage; i test Rust li riproducono e devono corrispondere. Microsoft afferma di avere avuto circa 430 fixture e che i generatori potevano verificare che ciascuna corrispondesse ancora al comportamento di Python.
Le fixture hanno anche preservato il comportamento del vecchio runtime dopo la rimozione del suo codice. Durante la migrazione è emersa una lacuna: Python aveva consegnato alcuni eventi in ordine, senza che questa regola fosse documentata, mentre la prima versione Rust non lo faceva. Nessuna fixture ha rilevato la differenza perché il team non aveva registrato l’ordine degli eventi. Microsoft afferma di aver risolto il problema, insieme a un altro che faceva sì che il primo punto di ingresso Rust impiegasse circa sei volte più tempo per confermare la ricezione di un nuovo messaggio.
Il traffico è stato trasferito per cluster, con la possibilità di tornare indietro
Il primo tentativo interno, il 23 settembre, è stato annullato. Rust ha gestito i suoi primi turni in produzione il giorno successivo e Microsoft afferma di aver trasferito il traffico un cluster alla volta, usando flag che consentivano di tornare indietro. Il team ha eliminato il runtime Python il 9 ottobre — circa 8000 file e 4,9 milioni di righe, inclusi test e codice generato — e ha spostato l’ultimo cluster il 10 ottobre.
In un confronto tra cluster Python e Rust nello stesso intervallo di 12 ore a fine settembre, il tempo al primo token nel primo turno di una sessione è sceso, al valore mediano, da 7,9 a 2,7 secondi. Al 90º percentile è sceso da 14,5 a 6,2 secondi. Microsoft afferma che i blocchi dell’event loop e le configurazioni di cinque secondi sono scomparsi, ma non ha misurato adeguatamente il costo per turno e non fa alcuna affermazione sui costi.
L’aumento di velocità si inseriva in un processo di sviluppo più ampio
La migrazione faceva parte di un più ampio lavoro di sviluppo nel quale, secondo Microsoft, gli agenti hanno scritto la maggior parte del codice di Copilot Cowork, mentre gli ingegneri hanno definito specifiche, limiti e regole di revisione. Il 21 ottobre, nove ingegneri hanno integrato 1.211 pull request nel branch principale del backend. Il team afferma che gli agenti potevano proporre modifiche, ma non decidere cosa fosse autorizzato ad arrivare in produzione; le decisioni su distribuzione e configurazione sono rimaste alle persone.
Il resoconto di Microsoft presenta la migrazione come una prova di questo approccio, non come la dimostrazione che la scrittura automatizzata del codice elimini la necessità del giudizio degli ingegneri. L’azienda afferma che, prima del trasferimento del traffico, erano stati redatti un runbook e documenti di progettazione per il passaggio, e che il team ha registrato il comportamento e trasferito il traffico in fasi reversibili. Il post descrive anche un comportamento relativo all’ordine degli eventi che le fixture non avevano rilevato. L’ultimo cluster Python è stato spostato il 10 ottobre.