In questo paragrafo viene illustrato come gestire le varie istanze di database PostgreSQL nei server della piattaforma Instant Developer Cloud, ovvero nei Server IDE e nei Server App IDC (server di produzione). Per ulteriori informazioni su questi tipi di server, vedere “Composizione della piattaforma” nel capitolo “Introduzione”.
Istanze IDE e di produzione #
Ogni database contenuto in un progetto può avere diverse istanze, a seconda dei server su cui l’applicazione corrispondente viene installata. In particolare:
- Sui server IDE è presente un’istanza del database per ogni programmatore che partecipa al gruppo di lavoro. Avere istanze separate permette ai vari collaboratori di continuare il proprio lavoro senza essere influenzati dalle modifiche apportate da altri e non ancora rese pubbliche.
- Sui server di produzione in cui è installata l’applicazione sarà presente un’istanza del database relativa all’ambiente di produzione dell’applicazione.
Per gestire le varie istanze, nella console di Instant Developer Cloud è presente la pagina App e Dati relativa ad un progetto, come si vede nell’immagine seguente:
Gestire le istanze di database dell’applicazione
Tramite questa videata è possibile verificare quali istanze esistono per ogni database e gestire ognuna di esse.
Per le istanze contenute nei server IDE è possibile effettuare il backup di un database, ripristinare un database da un backup precedente o effettuare il download del file di backup al fine di gestire i dati in un ambiente diverso. Infine è possibile aprire la pagina di gestione query per il database desiderato.
Le operazioni di manipolazione che coinvolgono i server di produzione potranno essere effettuate tramite le pagine di gestione server a cui è possibile accedere dalla pagina App e Dati. È necessario possedere i permessi di gestione del server per accedere a tali operazioni.
Tramite la pagina App e Dati si possono affrontare facilmente alcuni passaggi del lavoro quotidiano di un gruppo di sviluppo software.
Allineamento dei database fra i membri del gruppo di lavoro: mentre l’aggiornamento della struttura del database fra i membri del gruppo avviene tramite il sistema di team working, quest’ultimo non gestisce allo stesso modo il contenuto dei database. Per gestire gli aggiornamenti del contenuto è possibile effettuare un backup dell’istanza IDE che contiene i dati aggiornati e poi effettuare il ripristino sulle altre istanze dei membri del gruppo di lavoro usando il backup aggiornato.
Caricamento dei dati in produzione: dopo aver installato l’applicazione in produzione per la prima volta, l’istanza del database di produzione sarà vuota. Anche in questo caso le operazioni di backup dall’istanza IDE e restore su quella di produzione permetteranno di spostare i dati nel server di produzione.
Ispezione dei dati di produzione tramite server IDE: in alcuni casi può essere interessante lavorare sui dati del server di produzione dal server IDE. È possibile ottenere questo risultato semplicemente effettuando il backup dell’istanza del server di produzione per poi ripristinarla nel server IDE.
Impostazione stringa di connessione nel server di produzione #
Dalla versione 25.0 di Instant Developer Cloud è possibile impostare una stringa di connessione al database, nel server di produzione, specifica per ogni installazione della stessa applicazione.
In alcuni casi, infatti, si ha l’esigenza di fare in modo che diverse installazioni della stessa app su uno stesso server possano usare istanze diverse dello stesso database, ad esempio se si vuole installare sia l’ambiente di test che quello di produzione sullo stesso server mantenendo separata la gestione dei dati.
Esempio di utilizzo
Immaginiamo la situazione in cui abbiamo un progetto in cui sono presenti un’applicazione MyApp e un database MyDB.
Si vuole fare in modo di installare l’app con nome MyApp-test in modo che utilizzi il database MyDB-test. Inoltre, sullo stesso server si vuole avere un’altra installazione della stessa applicazione denominata MyApp-prod che usi il database MyDB-prod.
Per ottenere questo risultato dovremo aggiungere un parametro di runtime all’installazione MyApp-test con nome MyDB_connectionString e con valore MyDB-test. Allo stesso modo tra i parametri di runtime dell’installazione MyApp-prod si dovrà aggiungere il parametro MyDB_connectionString usando come valore MyDB-prod.
I passaggi con cui si ottengono queste associazioni sono i seguenti:
- Si installa l’applicazione sul server con un determinato nome (nell’esempio MyApp-test) specificando di non aggiornare lo schema del database durante l’installazione:
- Si aggiunge il parametro di runtime all’installazione con nome MyDB_connectionString e valore MyDB-test.
- Si installa nuovamente l’applicazione e questa volta si chiede l’aggiornamento del database. In questo modo verrà creato e aggiornato il database MyDB-test.
Infine, occorre tenere presente che è possibile specificare la connessione al database anche con una stringa in formato JSON contenente tutte o parte delle opzioni relative alla connectionString del tipo di database utilizzato.
Ad esempio, se il database è di tipo PostgreSQL è possibile impostare come valore del parametro una stringa di questo tipo:
{“host”: “{hostname}”, “database”: “{databaseName}”, “user”: “{username}”, “password”: “{password}”, “connectionTimeoutMillis”: 30000, “max”: 100}.
Disaster recovery dei database di produzione #
Le operazioni di backup, restore e download relative alle istanze di database non sono pensate per garantire un servizio di disaster recovery dei dati dei server, ma semplicemente per automatizzare le operazioni di copia e spostamento dati nei vari ambienti.
Per gestire la problematica di disaster recovery è invece disponibile il servizio di backup automatico dei server di produzione che è in grado di effettuare uno snapshot coerente dell’intero server su base giornaliera o oraria, mantenendo in linea un mese di dati. È possibile attivare il servizio di backup automatico dalla pagina di gestione del server o durante il processo di configurazione iniziale.
Nota importante: lo snapshot coerente dei server di produzione avviene automaticamente ogni volta che si installa una nuova versione dell’applicazione, indipendentemente dai servizi acquistati o dalla configurazione del server. In questo modo, se l’installazione fosse in qualche modo causa di perdite di dati, sarà possibile ritornare allo stato precedente ripristinando lo snapshot automatico creato prima dell’installazione tramite la pagina di gestione dei server della console di Instant Developer Cloud.
Esecuzione di query tramite la console #
Tramite il link Query presente nella pagina App e Dati è possibile aprire la pagina di gestione query per l’istanza di database desiderata, sia essa presente in un server IDE che in uno di produzione.
Database browser della console
Questa pagina permette di preparare ed eseguire query su qualunque istanza di database. Le query possono essere salvate ed eseguite in un secondo tempo.
Oltre alle query è possibile effettuare operazioni di modifica e cancellazione, sia dalla griglia dati che tramite comandi SQL specifici. Le funzioni di esportazione e importazione dati completano le funzioni di manipolazione dati a livello di tabella.
Nota importante: modificando manualmente i dati di un’istanza contenuta in un server di produzione, viene bypassato il framework di sincronizzazione differenziale che serve per distribuire tali dati ai dispositivi mobile. Se sul server di produzione sono presenti applicazioni che utilizzano questo framework, si deve tenere conto che le modifiche dei dati tramite console non verranno propagate ai dispositivi.
Monitoraggio delle performance #
Un accesso ai dati non ottimizzato è la causa più comune di applicazioni che presentano performance insufficienti. I motivi di questa criticità sono molteplici: possono risiedere anche in errori di progetto nello schema entità-relazioni, ma più spesso l’errore che ne rappresenta la causa è quello di misurare le performance dell’applicazione in un ambiente di test monoutente. In questo caso, infatti, anche se l’applicazione esegue un numero elevato di query o se esse sono poco performanti, le performance complessive possono sembrare adeguate.
Nei casi reali potremo avere decine, centinaia, o persino migliaia di utenti collegati all’applicazione e operanti sul database. In questi casi i tempi ottenuti nel caso monoutente si moltiplicano: se, ad esempio, una query richiede 100ms per essere eseguita nel caso monoutente (tempo largamente accettabile), la medesima query può richiedere 10 secondi se ci sono 100 utenti collegati (tempo non più accettabile).
Quando un server è sotto carico, oltre ai problemi di velocità di accesso ai dati si potrebbero incontrare problemi legati all’occupazione di memoria o anche ad altri colli di bottiglia non facilmente evidenziabili nel caso monoutente.
Test di carico #
Per tutte queste ragioni, prima di rilasciare un’applicazione in ambiente di produzione reale, è consigliabile utilizzare il sistema di test di carico incluso in Instant Developer Cloud che consente di misurare le performance del sistema nei casi più vicini alla realtà.
Per realizzare i test di carico è necessario installare l’applicazione su un server di produzione di Instant Developer Cloud e poi utilizzare il sistema dei test automatici per registrare una o più sessioni di utilizzo che verranno usate come sessioni campione durante il periodo di carico.
A questo punto è possibile passare al test di carico vero e proprio, in cui il server viene caricato in modo da eseguire le varie sessioni campione fino al numero di sessioni totali richieste nel tempo previsto.
Al termine del test si potranno visualizzare i risultati in termini di grafici di CPU e di memoria utilizzata in funzioni del numero di sessioni attive e una lista di eventuali errori incontrati.
Esempio di risultati di un test di carico con 400 utenti contemporanei
Tipicamente le prime sessioni di test di carico rilevano molte criticità. Per capire quali processi sono più critici è possibile registrare le sessioni campione in modo che ognuna esegua un singolo processo; a questo punto sarà possibile effettuare test di carico puri, cioè con una sola sessione campione alla volta. Solo al termine dell’ottimizzazione dei singoli processi si potrà procedere ad un test di carico misto, in cui tutti i processi vengono eseguiti contemporaneamente.
Monitoraggio in tempo reale #
Dopo aver ottimizzato l’applicazione tramite i test di carico si può essere confidenti che il sistema possa reggere il carico desiderato. A questo punto è consigliabile continuare l’analisi delle reali prestazioni del sistema tramite gli strumenti di monitoraggio dell’attività del server.
L’immagine seguente mostra la pagina dedicata a questa attività all’interno della console di Instant Developer Cloud.
Esempio di monitoraggio in tempo reale delle attività di un server
La schermata è suddivisa in due zone principali. La zona dei grafici mostra i dati relativi al numero di sessioni e all’utilizzo di CPU e RAM nel periodo specificato.
La zona dei processi mostra in tempo reale il risultato del comando top linux eseguito sul server. Questa zona è particolarmente importante perché permette di conoscere la reale allocazione delle risorse del server per le varie applicazioni e istanze di database in esso presenti. Sarà quindi più semplice comprendere a quale applicazione o a quale database possono essere imputati i cali di performance del sistema.
Log strutturato e delle query #
Uno strumento molto utile per la comprensione del comportamento delle applicazioni in produzione è il cosiddetto log strutturato. Esso si attiva tramite la pagina delle installazioni nella sezione della console dedicata alla gestione dei server e richiede che il codice dell’applicazione valorizzi la proprietà app.sessionName per attivare la funzione di log strutturato per una determinata sessione.
Accedere al log strutturato per un’installazione
La configurazione del log strutturato permette di attivare la registrazione dei messaggi di log, dei warning e degli errori delle sessioni applicative che sono state nominate tramite la proprietà app.sessionName, nonché la registrazione di tutte le query eseguite sul database.
Configurazione del log strutturato e attivazione della registrazione delle query
Dopo aver eseguito le analisi richieste, si consiglia di disattivare la registrazione delle query in quanto può richiedere l’uso di uno spazio significativo nel disco del server.
Tramite i filtri nella visualizzazione della lista delle sessioni è facile verificare quali sessioni sono state eseguite e in quali di esse sono avvenuti errori o warning. Cliccando sugli appositi comandi sarà mostrata anche la console della sessione.
Lista filtrabile delle sessioni presenti nel log strutturato
Si segnala infine che se l’applicazione è stata compilata attivando l’opzione debug a runtime, dalla lista delle sessioni del log strutturato sarà possibile collegare una sessione IDE ad una sessione in esecuzione nel server per controllare in real time il suo funzionamento.
Log applicativo dell’interfaccia rispetto al database #
Un ultimo strumento dedicato all’analisi del funzionamento del database riguarda il tracciamento a basso livello dei comandi inviati al database. Questo tipo di log può essere attivato sia sui server di sviluppo che su quelli di produzione impostando a true la proprietà logEnabled della classe di database interessata. Se, ad esempio, si desidera attivare il log per il database MyDB, nell’evento onStart dell’applicazione sarà possibile scrivere:
App.MyDB.logEnabled = true;
Questa istruzione attiva la scrittura di tutti i comandi inviati al database da parte di tutte le sessioni in un unico file di testo memorizzato nel file system dell’applicazione di nome temp/[nomeDB].log. Per ogni comando vengono riportati la connessione su cui viene inviato, il testo, il numero di righe su cui agisce, quanti altri comandi erano già in coda sulla connessione e quanto tempo complessivo viene utilizzato per completarlo. Questo file permette di verificare il modo con cui le varie sessioni si interfacciano con il database momento per momento ed è quindi uno strumento utile per controllarne il funzionamento.
Nota importante: il file può diventare anche molto grande e non vengono imposti vincoli alla sua crescita. È quindi necessario disabilitare la funzione di log dopo un determinato tempo per evitare che il disco del server si riempia.