Configurazione della tua applicazione: come scegliere la migliore configurazione del server?

Introduzione

La tecnologia e internet sono diventati presenze centrali nella nostra vita quotidiana, accademica e professionale. Ecco perché l'enorme numero di siti web e applicazioni che coesistono non sorprende affatto. Se sei un'azienda, vorrai avere una piattaforma web associata. Un'applicazione ti consente di commercializzare e fornire i tuoi servizi ai tuoi clienti target con facilità.

Indipendentemente dal motivo per cui stai creando un' applicazione web, devi determinare come costruirla. Ci sono molte opzioni a tua disposizione quando si tratta di scegliere la migliore configurazione del server. L'architettura del server per cui opti determinerà il modo in cui esegui e gestisci tutto nel tuo ambiente. Ecco perché la decisione deve essere presa dopo un'attenta considerazione.

Come scegliere la giusta configurazione del server

Quindi, come decidi quale architettura è 'giusta' per la tua applicazione? Per farlo, devi prima pensare a quali sono i requisiti per la tua applicazione web. Devono esserci determinate funzionalità che devi incorporare affinché funzioni in modo efficiente per il tuo caso d'uso specifico. Ad esempio, forse stai cercando un'applicazione che sia facile da scalare. O forse hai bisogno che la tua applicazione funzioni senza problemi sia sui browser che sui dispositivi mobili. Allo stesso tempo, anche il tuo budget potrebbe essere la tua preoccupazione principale.

Indipendentemente da quali siano i tuoi requisiti, devi sapere che puoi creare una soluzione personalizzata per la tua applicazione. In questo tutorial esploreremo i vari tipi di server che molte persone usano comunemente per le loro applicazioni web. Parleremo dei vari casi d'uso e di quando sia meglio utilizzare una determinata configurazione. Per aiutarti a decidere se è adatta a te, ti forniremo anche alcuni pro e contro di ciascuna architettura server.

1. Tutto su un unico server

Come suggerisce il nome, carichi l'intero ambiente su un unico server. L'ambiente include il server web, il server applicativo e il server del database. Ad esempio, funziona sulla configurazione dello stack Linux, Apache, MySQL, e PHP (LAMP). Puoi seguire i nostri tutorial su come installare lo stack LAMP su un server Ubuntu e su come installare lo stack LAMP su CentOS.

Quando usarlo:

Questo tipo di disposizione funziona al meglio se hai poco tempo. È semplice e veloce da configurare. Ecco perché funziona per applicazioni web semplici.

Vantaggi:

• Semplice e facile da capire e implementare.
• Richiede poco tempo per essere configurato nella sua interezza.

Svantaggi:

• Non consente la scalabilità orizzontale.
• Offre pochissimo in termini di isolamento dei componenti.
• L'applicazione e il database competono essenzialmente per le stesse risorse poiché si trovano su un singolo server.
• Di conseguenza, potresti riscontrare prestazioni scadenti.

2. Server database separato

Il problema principale con l'utilizzo di un singolo server è la competizione per risorse limitate. Questa configurazione mira a risolvere questo problema. Qui, il sistema di gestione del database, o DBMS, è tenuto separato dal server applicativo. Il server del database si trova in una rete privata e dispone di risorse proprie. Ciò si traduce in prestazioni migliori e maggiore sicurezza.

Quando usarlo:

Ancora una volta, se desideri implementare una configurazione rapida, questa è piuttosto semplice da configurare. È la soluzione ideale se temi che il database e l'applicazione competano per le stesse risorse.

Vantaggi:

• Risorse di sistema separate e dedicate per l'applicazione e il database, inclusi CPU, memoria, I/O, ecc.
• Maggiore potenziale di scalabilità sia nel livello applicativo che in quello del database.
• Puoi aggiungere e rimuovere risorse in base alle tue esigenze.
• Se rimuovi il database dall'internet pubblico, puoi anche aumentare la tua sicurezza.

Svantaggi:

• Un po' più complesso rispetto alla configurazione con un singolo server.
• Una connessione di rete a bassa larghezza di banda o ad alta latenza tra i due server può causare problemi di prestazioni.

3. Reverse Proxy o bilanciatore di carico

Questo è il punto in cui i bilanciatori di carico entrano in gioco. I load balancer sono tipicamente utilizzati negli ambienti server per migliorare le prestazioni e l'affidabilità. Lo fanno 'bilanciando il carico', ovvero distribuendo il carico di lavoro su una serie di server.

Quando usarlo:

I load balancer sono estremamente utili quando è necessario eseguire il ridimensionamento orizzontale. Il ridimensionamento orizzontale significa fondamentalmente aggiungere più server all'ambiente. È anche possibile utilizzare un reverse proxy a livello applicativo per servire più applicazioni contemporaneamente utilizzando un unico dominio e una sola porta. HAProxy, Nginx, e Varnish sono esempi di software che consentono il bilanciamento del carico tramite reverse proxy.

Vantaggi:

• Nel caso in cui un server della linea si guasti, gli altri server compensano la sua funzione bilanciando il carico di lavoro.
• Consente di eseguire il ridimensionamento orizzontale per aumentare o diminuire la capacità dell'ambiente.
• Limita inoltre le connessioni dei client, offrendo protezione contro gli attacchi DDOS.

Svantaggi:

• Nel caso in cui le risorse di sistema non siano sufficienti, il load balancer potrebbe limitare le prestazioni dell'applicazione.
• È necessaria una configurazione corretta per garantire prestazioni adeguate.
• Significativamente più complesso rispetto alle configurazioni con server singolo o server separati.
• È necessario tenere conto di fattori quali la terminazione SSL e le applicazioni che necessitano di sessioni persistenti.
• Il principale motivo di preoccupazione nell'uso dei load balancer è che rappresentano un singolo punto di guasto. Ciò significa che se il load balancer smette di funzionare, l'intero servizio andrà offline.

4. Acceleratore HTTP o Reverse Proxy di Caching

Questa è una configurazione che puoi utilizzare per aumentare la velocità con cui distribuisci i contenuti a un utente della tua applicazione. Impiega varie tecniche per ridurre questo tempo. La più importante consiste nel memorizzare nella cache la risposta del server applicativo. L'acceleratore salva il contenuto nella sua memoria quando un utente lo richiede per la prima volta. Pertanto, quando arrivano richieste future simili, serve il contenuto rapidamente senza interagire con il server applicativo. Nginx, Varnish e Squid sono in grado di effettuare l'accelerazione HTTP.

Quando usarlo:

Comprensibilmente, questa configurazione è più adatta per i file e i contenuti che gli utenti richiedono molto frequentemente. Funziona molto bene anche per le applicazioni web dinamiche ricche di contenuti.

Vantaggi:

• La memorizzazione nella cache e la compressione aumentano significativamente la velocità dell'applicazione e dell'elaborazione delle richieste.
• La riduzione del carico sulla CPU migliora anche le prestazioni del sito.
• Puoi anche usarlo come load balancer reverse proxy.

Svantaggi:

• È necessario configurarlo e ottimizzarlo bene per ottenere le migliori prestazioni.
• Potresti riscontrare prestazioni scadenti nel caso in cui il tasso di cache-hit sia basso.

5. Replica del database Primary-Replica

Una configurazione di replica del database primary-replica è in genere molto utile per i sistemi che eseguono più letture che scritture. Ad esempio, i sistemi di gestione dei contenuti possono trarre grande vantaggio da un'architettura di questo tipo. Per la replica sono necessari un nodo primario e uno o più nodi di replica. Distribuisce le letture su tutti i nodi. Gli aggiornamenti vanno solo al nodo primario.

Quando usarlo:

Come abbiamo menzionato, una configurazione di database basata sulla replica aiuta a migliorare le prestazioni di lettura di un sistema. Puoi usarla per applicazioni come i CMS.

Vantaggi:

• Migliora le prestazioni di lettura del database poiché le distribuisce tra le repliche.
• Se utilizzi il nodo primario solo per gli aggiornamenti, puoi anche migliorare le prestazioni di scrittura.

Svantaggi:

• Qualsiasi applicazione che tenta di accedere al database deve essere in grado di decidere a quale nodo inviare gli aggiornamenti e le richieste di lettura.
• Nel caso in cui la replica primaria si guasti, gli aggiornamenti si interrompono. È necessario risolvere il problema per consentire la continuazione degli aggiornamenti.
• Non esiste un meccanismo di failover per gestire un potenziale guasto del nodo primario.

Utilizzo combinato delle configurazioni server

Fortunatamente, è anche possibile combinare varie tecniche per ottenere il risultato desiderato. Ciò significa che puoi bilanciare il carico dei server applicativi con i server di caching in un unico ambiente e replicare il database. In questo modo puoi sfruttare le funzionalità di entrambi i server. Tuttavia, ciò non rende la configurazione più complicata o problematica.

Esempio:

Cercheremo di comprendere un simile ambiente con un esempio:

In un ambiente del genere, il bilanciatore di carico invierà le richieste statiche ai server di caching. Il contenuto statico include elementi come CSS, immagini e Javascript, tra gli altri. Indirizzerà invece qualsiasi altro tipo di richiesta di contenuto ai server applicativi.

Ipotizziamo che un utente stia richiedendo del contenuto statico dall'ambiente. Ecco cosa accadrebbe:

• Il bilanciatore di carico determinerà innanzitutto se il contenuto è un cache-hit o un cache-miss. Il contenuto cache-hit è presente nella cache, mentre il contenuto cache-miss non lo è. Lo fa effettuando una verifica con il backend della cache.
• In caso di cache-hit, il bilanciatore di carico invia il contenuto all'utente.
• In caso di cache-miss, il server di cache inoltra la richiesta al backend dell'applicazione.
• Il backend dell'app troverà e invierà il contenuto dal database.
• Il backend della cache riceve il contenuto dal bilanciatore di carico. Inoltre, memorizza nella cache questo contenuto prima di restituirlo al bilanciatore di carico.
• Quest'ultimo inoltra poi la risposta all'utente.

D'altra parte, ecco cosa accadrà se l'utente richiede contenuti dinamici:

• La richiesta arriverà dall'utente al bilanciatore di carico.
• Questa richiesta arriva al backend dell'app.
• Il backend dell'app individua il contenuto richiesto e lo restituisce al bilanciatore di carico.
• L'utente riceve il contenuto.

Uno dei principali vantaggi di un tale ambiente combinato è che è più affidabile. Non solo, ma ha anche capacità prestazionali superiori. Tuttavia, ci sono ancora due singoli punti di guasto: il bilanciatore di carico e il server di database primario.

Conclusione

Puoi utilizzare ciascuna configurazione di server da sola nel tuo ambiente. D'altra parte, potresti anche combinarne un paio insieme per creare una soluzione personalizzata. Non esiste una risposta ‘corretta’. Tutto dipende dalle funzionalità che desideri ottenere dall'architettura.

Avere una conoscenza di base sul funzionamento di ciascuna configurazione di server ti aiuterà a prendere la decisione migliore per la tua applicazione. La cosa migliore da fare è iniziare in modo semplice e su piccola scala. Puoi continuare ad aumentare la complessità della tua configurazione man mano che acquisisci esperienza.

Buon computing!