L'esecuzione di qualsiasi piattaforma distribuita scalabile richiede un impegno per l'affidabilità, per garantire ai clienti ciò di cui hanno bisogno quando ne hanno bisogno. Le dipendenze potrebbero essere piuttosto complesse, specialmente con una piattaforma grande come Roblox. Costruire servizi affidabili significa che, indipendentemente dalla complessità e dallo stato delle dipendenze, un determinato servizio sarà ininterrotto (cioè altamente disponible), funzionerà senza bug (es. verso la qualità) e senza errori (es. tolleranza agli errori).
Perché l'affidabilità è importante
Il nostro team di Account Identity si impegna a raggiungere una maggiore affidabilità, poiché i servizi di conformità che abbiamo creato sono componenti fondamentali della piattaforma. Il mancato rispetto può avere gravi conseguenze. Il costo del blocco del funzionamento naturale di Roblox è molto elevato, con risorse aggiuntive necessarie per il ripristino da un'interruzione e un'esperienza utente compromessa.
L'approccio tipico all'affidabilità si concentra principalmente sulla disponibilità, ma in alcuni casi i termini sono confusi e utilizzati in modo improprio. La maggior parte delle metriche di disponibilità valuta semplicemente se i servizi sono attivi e in esecuzione, mentre aspetti come la tolleranza e la coerenza delle partizioni vengono talvolta trascurati o fraintesi.
Secondo il teorema CAP, qualsiasi sistema distribuito può garantire solo due di questi tre aspetti. I nostri servizi di conformità sacrificano quindi un po' di coerenza per essere altamente disponibili e tolleranti alle partizioni. Tuttavia, i nostri servizi hanno sacrificato poco e trovato meccanismi per ottenere una buona coerenza con ragionevoli modifiche all'architettura spiegate di seguito.
Il processo per ottenere una maggiore affidabilità è iterativo, con misure precise corrispondenti a un lavoro continuo per prevenire, trovare, rilevare e correggere i guasti prima che si verifichino incidenti. Il nostro team ha identificato un forte valore nelle seguenti pratiche:
- Misurazione accurata – Costruire la piena osservabilità di come la qualità viene fornita ai clienti e di come le dipendenze ci forniscono la qualità.
- Anticipazione proattiva – Eseguire attività come revisioni dell'architettura e valutazioni del rischio di dipendenza.
- Dai priorità alla riparazione – Prestare maggiore attenzione alla risoluzione dei rapporti sugli incidenti per il servizio e le dipendenze relative al nostro servizio.
Costruire una maggiore affidabilità richiede una cultura della qualità. Il nostro team stava già investendo nello sviluppo orientato alle prestazioni e sa che il successo di un processo dipende dalla sua adozione. Il team ha abbracciato questo processo nella sua interezza e ha applicato le pratiche come standard. Il diagramma seguente evidenzia le componenti del processo:
Il potere della buona misura
Prima di approfondire le metriche, c'è un rapido chiarimento sulle metriche del livello di servizio.
- Lo SLO (Service Level Objective) è l'obiettivo di affidabilità a cui punta il nostro team (99,999%).
- Lo SLI (Service Level Indicator) è l'affidabilità raggiunta in un dato periodo (ovvero 99,975% lo scorso febbraio).
- Lo SLA (Service Level Agreement) è l'affidabilità che ci impegniamo a fornire e che i nostri consumatori si aspettano entro un determinato lasso di tempo (ovvero il 99,99% a settimana).
L'SLI dovrebbe riflettere la disponibilità (nessuna risposta non gestita o mancante), la tolleranza ai guasti (nessun errore di servizio) e la qualità raggiunta (nessun errore imprevisto). Pertanto, abbiamo definito il nostro SLI come il "tasso di successo" di risposte riuscite rispetto al numero totale di richieste inviate a un servizio. Le risposte riuscite sono richieste che sono state inviate in tempo e nella forma, il che significa che no
si sono verificati errori di connettività, servizio o imprevisti.
Questo SLI o Success Ratio viene raccolto dal punto di vista dei consumatori (ovvero i clienti). L'intento è quello di misurare l'effettiva esperienza end-to-end fornita ai nostri consumatori in modo da essere certi che gli SLA vengano rispettati. In caso contrario, creerebbe un falso senso di affidabilità che ignora tutti i problemi di infrastruttura per connettersi con i nostri clienti. Analogamente all'SLI consumer, raccogliamo SLI di dipendenza per tenere traccia di qualsiasi rischio potenziale. In pratica, tutti gli SLA di dipendenza devono essere allineati con lo SLA di servizio e con essi esiste una dipendenza diretta. Il fallimento di uno implica il fallimento di tutti. Tracciamo e segnaliamo anche le metriche del servizio stesso (ovvero il server), ma questa non è la fonte pratica di alta affidabilità.
Oltre agli SLI, ogni build raccoglie le metriche di qualità riportate dal nostro flusso di lavoro CI. Questa pratica può rafforzare fortemente le barriere di qualità (ad es. copertura del codice) e segnalare altre metriche significative, come la conformità agli standard di codifica e l'analisi del codice statico. Questo argomento è già stato trattato in un altro articolo, Crea microservizi basati sulle prestazioni. La diligente aderenza alla qualità aumenta l'affidabilità, perché più investiamo nel raggiungimento di punteggi eccellenti, più siamo sicuri che il sistema non fallirà in condizioni avverse.
Il nostro team ha due dashboard. Uno fornisce visibilità completa sull'SLI consumer e SLI dipendente. Il secondo mostra tutte le metriche di qualità. Stiamo lavorando per unire il tutto in un'unica dashboard, in modo che tutti gli aspetti a cui teniamo siano consolidati e pronti da segnalare in qualsiasi momento.
Anticipare il fallimento
Action Revisioni architettoniche è un elemento fondamentale per essere affidabili. Innanzitutto, determiniamo se la ridondanza è presente e se il servizio ha i mezzi per sopravvivere quando le dipendenze cadono. Oltre alle tipiche idee di replica, la maggior parte dei nostri servizi ha applicato tecniche avanzate di idratazione della doppia cache, strategie di doppio ripristino (come le code locali di failover) o strategie di perdita di dati (come il supporto transazionale). Questi argomenti sono sufficientemente estesi da giustificare un altro post sul blog, ma in definitiva la migliore raccomandazione è quella di implementare idee che tengano conto degli scenari di emergenza e riducano al minimo qualsiasi penalizzazione delle prestazioni.
Un altro aspetto importante da anticipare è tutto ciò che potrebbe migliorare la connettività. Ciò significa essere aggressivi sulla bassa latenza per i client e prepararli a un traffico molto elevato utilizzando tecniche di controllo della cache, sidecar e criteri di prestazione per timeout, interruttori di circuito e tentativi. Queste pratiche si applicano a tutti i client, inclusi cache, archivi, code e client interdipendenti in HTTP e gRPC. Significa anche migliorare i segnali di servizio integri e comprendere che i controlli dello stato svolgono un ruolo importante in tutta l'orchestrazione dei container. La maggior parte dei nostri servizi fornisce segnali meglio degradati come parte del feedback del controllo dello stato e verifica che tutti i componenti critici siano funzionali prima di inviare segnali sani.
La suddivisione dei servizi in elementi critici e non critici si è rivelata utile per concentrarsi sulla funzionalità che conta di più. In passato avevamo endpoint di solo amministratore nello stesso servizio e, sebbene non venissero utilizzati spesso, influivano sulle metriche di latenza complessive. Spostarli al proprio servizio ha avuto un impatto positivo su ogni metrica.
Valutazione del rischio di dipendenza è uno strumento importante per identificare potenziali problemi di dipendenza. Ciò significa che identifichiamo le dipendenze con SLI basso e richiediamo l'allineamento degli SLA. Queste dipendenze richiedono un'attenzione particolare durante i passaggi di integrazione. Quindi dedichiamo più tempo a valutare e testare se le nuove dipendenze sono sufficientemente mature per i nostri piani. Un buon esempio è l'adozione anticipata di Roblox Storage-as-a-Service. L'integrazione con questo servizio richiedeva l'archiviazione di ticket di bug e riunioni periodiche di sincronizzazione per comunicare risultati e feedback. Tutto questo lavoro utilizza il tag "affidabilità" in modo da poterne identificare rapidamente l'origine e le priorità. La caratterizzazione avveniva spesso finché non eravamo sicuri che la nuova dipendenza fosse pronta per noi. Questo lavoro aggiuntivo ha contribuito a portare la dipendenza al livello di affidabilità richiesto che ci aspettiamo di fornire agendo insieme per un obiettivo comune.
Struttura il caos
Non è mai desiderabile avere incidenti. Ma quando accadono, ci sono informazioni significative da raccogliere e sfruttare per essere più affidabili. Il nostro team ha un rapporto sugli incidenti del team che viene creato oltre il tipico rapporto a livello aziendale, quindi ci concentriamo su tutti gli incidenti, indipendentemente dall'entità del loro impatto. Indichiamo la causa principale e diamo la priorità a tutto il lavoro per mitigarla in futuro. Nell'ambito di questo rapporto, coinvolgiamo altri team per risolvere gli incidenti di dipendenza con priorità elevata, dare seguito a una risoluzione adeguata, eseguire una retrospettiva e cercare modelli che potrebbero applicarsi a noi.
La squadra produce a Rapporto mensile di affidabilità per servizio questo include tutti gli SLI spiegati qui, tutti i ticket che abbiamo aperto a causa dell'affidabilità e tutti i possibili incidenti associati al servizio. Siamo così abituati a generare questi rapporti che il passo successivo naturale è automatizzare la loro estrazione. Svolgere periodicamente questa attività è importante e ci ricorda che l'affidabilità è costantemente monitorata e presa in considerazione nel nostro sviluppo.
La nostra strumentazione include metriche personalizzate e avvisi avanzati in modo da essere avvisati il prima possibile quando si verificano problemi noti e previsti. Tutti gli avvisi, compresi i falsi positivi, vengono rivisti settimanalmente. A questo punto, è importante rifinire tutta la documentazione in modo che i nostri consumatori sappiano cosa aspettarsi quando si attivano gli avvisi e quando si verificano errori, e quindi tutti sanno cosa fare (ad es. l'integrazione di playbook e linee guida è allineata e aggiornata spesso).
finalement, abbracciare la qualità nella nostra cultura è il fattore più critico e decisivo per ottenere una maggiore affidabilità. Possiamo osservare come queste pratiche applicate al nostro lavoro quotidiano stiano già dando i loro frutti. Il nostro team è ossessionato dall'affidabilità ed è il nostro risultato più importante. Abbiamo aumentato la nostra consapevolezza dell'impatto che potrebbero avere potenziali difetti e quando potrebbero essere introdotti. I servizi che hanno implementato queste pratiche hanno costantemente soddisfatto i propri SLO e SLA. I rapporti sull'affidabilità che ci aiutano a tenere traccia di tutto il lavoro svolto sono una testimonianza del duro lavoro svolto dal nostro team e sono lezioni inestimabili per informare e influenzare gli altri team. È così che la cultura dell'affidabilità tocca tutti i componenti della nostra piattaforma.
La strada verso una maggiore fiducia non è facile, ma è necessaria se vuoi creare una piattaforma di fiducia che reinventi il modo in cui le persone si uniscono.
Alberto è un Senior Software Engineer nel team Account Identity di Roblox. Ha una lunga storia nel settore dei giochi, con crediti su numerosi titoli di giochi AAA e piattaforme di social media con una forte attenzione alle architetture altamente scalabili. Ora aiuta Roblox a raggiungere la crescita e la maturità applicando le migliori pratiche di sviluppo.
