Predizione long-range di traffico e utilizzo di CPU di un router
4.1.1 Dati utilizzat
Per prima cosa si considera il set di dati utilizzato in questo capitolo.
In tutti i capitoli precedenti si sono considerati i dati relativi alle 4 settimane di maggio, campionate con una frequenza pari ad un minuto. Tale scelta era giustificata dal fatto che, volendo ottenere una predizione short-range, era necessario avere un campionamento abbastanza fitto del segnale; non avrebbe avuto infatti senso, dal punto di vista del load balancing all’interno di una server farm, campionare con un tempo di campionamento, per esempio, di 10 minuti, dal momento che si era interessati ad una previsione per i minuti immediatamente successivi in modo da poter capire quali, tra le macchine a disposizione, fossero le più sollecitate nell’immediato. Utilizzare un set di dati campionati poco frequentemente nel tempo avrebbe quindi portato a non avere una granularità sufficiente per lo scopo che ci si era prefissati.
In questo capitolo invece ci si pone l’obiettivo di prevedere con ragionevole affidabilità l’andamento futuro di traffico e utilizzo di CPU su un orizzonte predittivo esteso: si vuole cioè prevedere il comportamento dei segnali per più settimane a partire dall’ultimo dato disponibile; da ciò si capisce come non si sia interessati all’andamento puntuale che si può assumere minuto per minuto, ma all’andamento generale assunto dai segnali presi in esame. Non importa quindi se ad un determinato istante ci sia stata un’impennata di traffico della durata di qualche decina di secondi, ma quale sia il comportamento di traffico e CPU per lassi prolungati di tempo.
Lo scopo del capacity planning è capire in quali punti della rete si ha bisogno di potenziare le componenti hardware maggiormente stressate, dal momento che tali device possono diventare dei colli di bottiglia e portare a un rallentamento del traffico lungo tutta una parte o addirittura la totalità della rete. E’ noto che per poter mostrare rallentamenti sensibili, un router deve avere valori alti di utilizzo di CPU per un numero prolungato di minuti: se tale circostanza si verifica, il router satura, diminuendo la quantità di traffico che è in grado di processare e spedire sulle proprie interfacce; ciò porta ad un “effetto domino” per cui il router immagazzina sempre più un maggior numero di megabyte da smaltire, innalzando ulteriormente l’utilizzo delle proprie risorse fino a quando il router cessa del tutto di rispondere, ed è considerato essere in uno stato di “down”. E’ chiaro a questo punto come, in funzione del capacity planning, gli spikes improvvisi di traffico non siano influenti, in quanto portano ad un incremento di utilizzo di risorse solamente puntuale; e si sia invece interessati a trend e stagionalità di traffico e utilizzo di CPU.
Alla luce di quanto detto, si è scelto quindi di utilizzare un set di dati con una granularità differente rispetto a quella dei dati usati fino ad ora. A nostra disposizione per questa tesi vi erano due set di dati: un primo, utilizzato nei capitoli precedenti, composta da 4 settimane campionate con una frequenza pari ad un minuto, ed un secondo, composto da 16 settimane, comprese tra il 7 maggio ed il 29 agosto. Ricordando il codice RRDTool utilizzato per creare i database in cui salvare i dati (presente in appendice 2.1), si può ricavare la granularità del secondo set di dati a disposizione, variabile a seconda di quanto i dati siano recenti: per le 4 settimane dal 2 agosto al 29, la
frequenza di campionamento risulta essere nuovamente pari a 1 sample al minuto; i 3 giorni precedenti si ha un campione ogni 6 minuti; per i dati dal 17 al 31 luglio si ha un campione ogni 24 minuti e per quelli precedenti (a partire dal 7 maggio, giorno in cui si è cominciato a popolare il database) la frequenza è pari ad un sample ogni 144 minuti.
I fattori che influiscono nella scelta del campionamento da utilizzare sono 2: l’avere un numero di punti in grado di caratterizzare fedelmente l’andamento giornaliero del segnale unito alla necessità di disporre di un numero di settimane di dati sufficiente.
Il primo requisito deriva dal fatto che, se si considerassero troppo pochi campioni per giorno, si potrebbero avere dei dati non in grado di descrivere i valori massimi di traffico e CPU raggiunti nelle ore di punta: se ad esempio si considerassero solo 3-4 punti per tutto il giorno (ore diurne), considerando che ogni dato viene ottenuto come la media dell’andamento giornaliero, si avrebbe un andamento con valori inferiori a quelli reali, dal momento che mediare valori dell’ora di punta con valori registrati nelle prime ore della mattina (bassi in modulo) porterebbe ad avere un andamento più basso dei primi e più alto dei secondi, andando di fatto a distorcere il segnale. Il secondo deriva dal fatto che, per poter predire per un buon numero di settimane, occorre poter disporre di un buon set di dati, usati per ricavare con precisione la stagionalità (nel caso del modello ARMA) e per poter avere due set di dati distinti per l’inizializzazione e l’identificazione dei parametri (modello di Holt-Winters).
Tenendo a mente questo, si può capire come i dati, così come sono disponibili, risultano essere inadeguati:
Per prima cosa non si possono considerare le settimane di agosto, in quanto presentano valori medi più bassi che nel resto dell’anno: se si scegliesse di usarle per valutare la bontà della predizione, si avrebbe una performance della predizione pessima, in quanto la predizione si attesterebbe a valori più alti rispetto ai dati. Ciò non sarebbe dovuto ad un errore, ma al fatto che i dati considerati per l’identificazione mostrano valori uniformemente maggiori rispetto a quelli di agosto; conseguentemente anche la predizione mostrerebbe valori simili che, confrontati con i dati di agosto, porterebbe a ritenere ingiustamente pessimo il predittore ricavato. Per tale motivo le ultime 4 settimane di dati non possono essere considerate.
Considerando i dati campionati ogni 6 e 24 minuti, essi soddisfano il primo requisito, ma non il secondo: tali dati coprono infatti solamente 2 settimane in totale, essendo quindi insufficienti per poter essere utilizzati senza far ricorso al resto del set di dati a disposizione.
Prendendo in esame i dati campionati ogni 144 minuti, ci si ritrova nella situazione opposta: combinati con i dati precedenti si ottengono un totale di 12 settimane di dati utili; purtroppo però avere un sample ogni 144 minuti porta ad avere un totale di 10 campioni ogni 24 ore, insufficiente a descrivere in maniera soddisfacente i segnali considerati.
Si è quindi deciso di ricorrere ad un artificio: a partire dai dati campionati ogni 144 minuti, ci si riconduce ad un segnale campionato ogni 24 minuti, ripopolando dapprima il set di dati andando ad interpolare una retta per ciascuna coppia di sample consecutivi e individuando su questa retta dei nuovi campioni equispaziati, e aggiungendo in un secondo momento un rumore per rappresentare l’andamento fortemente oscillatorio dei dati.
122 Predizione long-range di traffico e utilizzo di CPU di un router
In particolare si è scelto di considerare un campionamento pari a 24 minuti poiché tale periodo è stato considerato in grado di soddisfare entrambi i requisiti qui sopra illustrati, ottenendo una buona approssimazione degli andamenti giornalieri del segnale e un numero di dati sufficiente su cui poter lavorare.
In questo modo si genera un segnale fittizio non direttamente riconducibile ai dati, ma che ci consente di poter considerare un caso di studio con dati sufficienti per poter identificare dei modelli che descrivano traffico e CPU e in un secondo momento poter fare predizione long-range. In caso contrario, non sarebbe stato possibile effettuare tale lavoro. Inoltre, scegliendo con attenzione il modo in cui si è ripopolato il set di dati e l’ampiezza del rumore, si è potuto ottenere un segnale ragionevolmente simile ad un traffico in ingresso ad un router con il medesimo tempo di campionamento. Si è infine ritenuto tale metodo migliore rispetto ad una simulazione in cui il segnale fosse generato partendo da zero, in quanto l’andamento alla base del segnale proviene da un caso reale.
In appendice 4.1 sono riportate più approfonditamente le operazioni effettuate sul segnale che sono state qui descritte.