Pianificazione della capacità per i database

Nota: questo post è ispirato dal recente post di Julia Evans sulla pianificazione della capacità.

RDBMS

Innanzitutto, stabiliamo alcune regole di base. Sì... questo post è rivolto a quelli di noi che usano MySQL con un singolo writer alla volta e 2 o più repliche di lettura. Gran parte di ciò di cui parlerò qui si applica in modo diverso, o per niente, ai datastore in cluster multi-scrittore, sebbene anche quelli siano dotati di una propria serie di compromessi e avvertenze. Quindi... il tuo chilometraggio varierà sicuramente.

Tuttavia, questo post del blog SI APPLICA indipendentemente dal fatto che utilizzi host fisici self-hosted o ti trovi in ​​AWS dove puoi utilizzare istanze riservate magiche e quasi istantaneo. Essere nel "cloud" non ti precluderà di conoscere le capacità ei limiti della tua infrastruttura e non ti esonera da tale responsabilità nei confronti del tuo team e dei tuoi clienti.

Frammentazione

Ho già trattato ampi tratti di questo in uno dei miei post precedenti, mi sono concentrato principalmente sui vantaggi del partizionamento orizzontale o funzionale. Sì, questo è un prerequisito assoluto, dal momento che ciò che usi per accedere al livello del database DECIDE quanta flessibilità devi ridimensionare.

Se sei un'azienda nuova di zecca, potresti non aver bisogno dello sharding funzionale il giorno 1 ma, se speri (e sospetto che tu lo faccia) di crescere, non rinchiuderti in un ORM open source che non ti permetta di dividere i tuoi dati su base funzionale su tutta la linea. Punti bonus anche se non avvii la tua azienda con tutti i tuoi dati relazionali in un unico schema.

Possibilità di dividere letture e scritture

Questo è qualcosa che dovrai essere in grado di fare, ma non necessariamente applicare come regola fissa. Ci saranno casi d'uso in cui una scrittura deve essere letta molto presto e in cui la tolleranza per cose come lag/eventuale coerenza è bassa. Quelli vanno bene, ma nelle stesse applicazioni avrai anche scenari per letture che possono tollerare un arco di tempo più lungo di eventuale coerenza. Quando tali letture sono ad alto volume, vuoi davvero che quel volume vada al tuo singolo scrittore se non è proprio necessario? Fatti un favore e assicurati presto nei tuoi giorni di crescita di poter controllare l'uso di un IP di lettura o scrittura nel tuo codice.

Passiamo ora al processo di pianificazione della capacità effettiva... Un cluster di database non sta al passo, cosa devo fare?

Determina il collo di bottiglia del sistema

• Hai un collo di bottiglia nelle scritture o nelle letture?
• Il problema si presenta come una CPU alta?
• Viene visualizzato come capacità IO?
• Sta crescendo il ritardo sulle repliche senza un chiaro colpevole della query di lettura?
• Sono serrature?
• Come faccio a sapere qual è?

Ognuno di questi può essere un post a sé stante. Il punto che sto cercando di sottolineare è che devi avere familiarità con il tuo sistema e le metriche specifiche del DB per essere in grado di scoprire quale pezzo è il collo di bottiglia.

Hai bisogno di una linea di base

Assicurati sempre di avere a disposizione le metriche di sistema di base da visualizzare per almeno alcune settimane fa. Molti strumenti forniscono questo (Cacti, Munin, Grafite... ecc.). Una volta che sai a quale metrica di sistema sei principalmente legato, devi stabilire i valori di base e di picco. In caso contrario, determinare se il tuo problema attuale è un nuovo bug originato dall'applicazione rispetto alla crescita reale sarà molto più soggetto a errori di quanto vorresti.

Tuttavia, le metriche del server di base possono arrivare solo così lontano: a un certo punto scoprirai che avrai bisogno anche di metriche basate sul contesto. Le prestazioni delle query e le prestazioni percepite lato app ti diranno cosa vede l'applicazione come tempo di risposta alle query. Esistono molti strumenti per eseguire questo monitoraggio pesante del contesto. Alcuni sono open source come Anemometer e strumenti commerciali come Vivid Cortex (li usiamo su SendGrid. Vedetene parlare qui.) Anche solo monitorare queste metriche dal punto di vista dell'app e lanciarle come metriche statsd sarà un buon primo passo. Ma all'inizio devi abituarti al fatto che ciò che percepisce la tua app è ciò che percepiscono i tuoi clienti. E prima devi trovare un modo per saperlo.

Scopri i modelli di traffico della tua attività

Sei un'azienda soggetta a picchi estremi in determinati giorni feriali (es. marketing)? Hai lanci regolari che triplicano o quadruplicano il tuo traffico come i giochi? Questo tipo di domande determinerà la quantità di margine riservato che dovresti mantenere o se devi investire in una crescita elastica.

Determinare il rapporto tra i numeri di traffico non elaborati in relazione alla capacità in uso

Questa è semplicemente la risposta a "Se non abbiamo ottimizzato il codice, quante email/vendite/utenti online/qualunque cosa" possiamo servire con le istanze di database che abbiamo in questo momento?

Idealmente, questo è un valore specifico che rende la matematica per la pianificazione della crescita di un anno una semplice equazione matematica. Ma la vita non è mai l'ideale e questo valore varierà a seconda della stagione o di fattori felici completamente esterni come la firma di un nuovo cliente importante. Nelle prime startup questo numero è un obiettivo in rapido movimento, ma dovrebbe stabilizzarsi man mano che l'azienda passa dai primi giorni a un'attività più consolidata con modelli di crescita aziendale più prevedibili.

Devo davvero acquistare più macchine?

È necessario trovare un modo per determinare se si tratta veramente di capacità: è necessario dividere le scritture per supportare un carico di scrittura più simultaneo o aggiungere più repliche di lettura rispetto a. collo di bottiglia delle prestazioni basato sul codice (questa nuova query da una distribuzione recente può davvero avere i risultati memorizzati nella cache in qualcosa di più economico e non battere tanto il database).

Come si fa a farlo? Devi familiarizzare con le tue domande. Il piccolo passo per questo è una combinazione di innotop, registro lento e pt-query-digest di Percona Toolkit. Puoi automatizzare questa operazione inviando i log del database a una posizione centrale e automatizzando la parte digest.

Ma anche questo non è l'intero quadro, i registri lenti richiedono prestazioni elevate se si abbassa troppo la soglia. Se puoi vivere con un campionamento meno selettivo, dovrai rilevare le intere conversazioni tra l'applicazione e il datastore. Nella terra dell'open source puoi usare le basi come tcpdump o puoi usare prodotti ospitati come Datadog, New Relic o VividCortex.

Effettuare una chiamata

La pianificazione delle capacità può essere composta per il 90% da scienza e per il 10% da arte, ma quel 10% non dovrebbe significare che non dovremmo impegnarci per ottenere il maggior numero possibile di immagini. Come ingegneri, a volte possiamo fissarci sul 10% mancante e non renderci conto che, se abbiamo fatto il lavoro, quel 90% può farci avere un'idea migliore dello stato di salute del nostro stack, un uso più efficiente del nostro tempo ottimizzando le prestazioni e la capacità di pianificazione aumenta con attenzione che alla fine si traduce in un ritorno sull'investimento molto migliore per i nostri prodotti.