Come si distribuisce l'app su più server utilizzando EC2?

Question

Per la prima volta sto sviluppando un'applicazione che richiede un po 'di ridimensionamento, non ho mai avuto un'applicazione che deve essere eseguita su più istanze prima.

Come si ottiene normalmente? Creo cluster di server SQL, quindi eseguo il mirroring della programmazione su tutti i server e utilizzo il bilanciamento del carico?

Oppure separo la funzionalità per eseguirne alcuni su un server su un altro?

Inoltre, come si invia il codice a tutte le istanze di finestre EC2?

Answer 1

Disclaimer - Non ho intenzione di menzionare le specifiche di Windows perché ho sempre lavorato su macchine Unix. Queste linee guida sono abbastanza generiche.

Questa è una domanda soggettiva e ognuno personalizzerebbe il proprio sistema in uno stile unico. Ecco alcune linee guida che seguo.

Se si tratta di un'applicazione Web, separare i livelli di presentazione (front-end), middleware (API) e database. Un'architettura a fette scala il meglio rispetto a un'applicazione monolitica.

1. Database - Amazon offre servizi eccellenti e altamente disponibili (se non si è su di noi-est zona di disponibilità) per SQL e archivi di dati NoSQL. È possibile controllare RDS per i database relazionali e DynamoDb per NoSQL. Entrambi si adattano bene e non è necessario preoccuparsi di gestire e caricare sharding/clustering degli archivi dati una volta avviati.
2. API middleware - Questa è una parte cruciale. È importante disporre di un set di API (preferibilmente REST, ma qui puoi praticamente utilizzare qualsiasi cosa) che esponga la tua funzionalità di back-end come un servizio. Un'architettura orientata ai servizi può essere ridimensionata molto facilmente per soddisfare più client front-face come web, mobile, desktop, widget di terze parti, ecc. Le API middleware NON devono essere in genere dove viene elaborata la logica aziendale, la maggior parte (o tutto) dovrebbero essere tradotti in ricerche/ricerche di database per prestazioni più elevate. Questi servizi potrebbero essere bilanciati in termini di carico per l'alta disponibilità. Amazon Elastic Load Balancers (ELB) sono buoni per i principianti. Se vuoi entrare in qualche più personalizzazione come bloccare il traffico per determinati set di indirizzi IP, eseguendo Blue/Green deployments, allora forse dovresti considerare i bilanciatori di carico HAProxy implementati per separare le istanze.
3. Front-end - Questo è il punto in cui deve risiedere il livello di presentazione. Dovrebbe evitare qualsiasi interrogazione diretta del database eccetto per quelli che sono limitati all'ambito del front-end, per esempio: una semplice chiamata Redis per ottenere le ultime chiavi della cache per i frammenti front-end. Qui è dove è possibile eseguire un sacco di memorizzazione nella cache, direttamente dalle chiamate di servizio ai frammenti front-end. È possibile utilizzare AWS CloudFront per la consegna di asset statici e AWS ElastiCache per l'archivio cache. ElastiCache non è altro che un cluster memcached gestito. Si dovrebbe anche considerare il bilanciamento del carico dei nodi front-end dietro un ELB.

Tutto questo può essere fornito in bundle e distribuito con AutoScaling utilizzando AWS Elastic Beanstalk. Attualmente supporta i contenitori ASP .NET, PHP, Python, Java e Ruby. AWS Elastic Beanstalk ha ancora i suoi limiti, ma è un modo molto interessante per gestire la tua infrastruttura con il minimo problema di monitoraggio, ridimensionamento e bilanciamento del carico.

Suggerimento: l'identificazione delle aree intensive di lettura e scrittura della tua applicazione aiuta molto. È quindi possibile procedere e suddividere l'infrastruttura di conseguenza ed eseguire le ottimizzazioni richieste con un focus di lettura o scrittura alla volta.

Per riassumere tutto, Amazon AWS ha praticamente tutto ciò che è possibile utilizzare per creare la topologia del server. Spetta a te scegliere i componenti.

Spero che questo aiuti!

Answer 2

Questo dipenderà dai requisiti che avete. Ma come linea guida generale (presumo un sito web) separerei db, server web, server di memorizzazione nella cache ecc. A diverse istanze e uso s3 (+ cloudfont) per le risorse statiche. Mi assicuro inoltre che sia in atto una corretta limitazione della velocità in modo che sull'infrastruttura si trovi solo il carico legittimo.

Per il server RDBMS, è possibile configurare un'impostazione db master-slave (RDS rende più semplice), utilizzare db sharding ecc. Esistono anche soluzioni cluster DB che saranno più complesse da configurare ma semplificano l'accesso al database per il programmatore dell'applicazione. Vorrei anche controllare tutte le query db e le query db/sql di conseguenza. In alcuni casi i puri database di tipo NoSQL potrebbero essere migliori di RDBMS o un mix di entrambi i casi in cui l'applicazione passa da una all'altra a seconda dei dati richiesti.

Per il server Web, configuro un loadbalancer e quindi utilizzo la scalabilità automatica sulle istanze del server Web dietro il loadbalancer. Qualcosa di simile si applicherà al server delle app, se presente. Controllerò anche le impostazioni dei server web.

Il server di memorizzazione nella cache verrà inoltre separato nel relativo cluster di istanze. ElastiCache sembra un bel servizio. Redis ha prestazioni paragonabili a memcache ma ha più funzioni (come liste, insiemi, ecc.) Che potrebbero rivelarsi utili durante il ridimensionamento.

Answer 3

Il modo in cui vorrei farlo sarebbe avere 1 server come server DB con mysql in esecuzione su di esso. Tutti i miei dati su memcached, che possono estendersi su più server e i miei clienti con un semplice "se non su memcached, leggi da db, metterlo su memcached e restituire".

Memcached è molto semplice da scalare rispetto a un DB. Un ridimensionamento db richiede molto sforzo amministrativo. È un dolore per farlo bene e lavorare. Quindi scelgo memcached. Infatti, ho dei server memcached extra, solo per gestire i server di downtime (se qualcuno dei miei memcached).

I miei dati vengono letti principalmente e poche sono le scritture. E quando avvengono le scritture, spingo anche i dati alla memcached. Tutto sommato funziona meglio per me, codice, amministrazione, fallback, failover, loadbalancing way. Tutti vincono. Hai solo bisogno di codificare un "po '" un po' meglio.

Il cluster mysql è più allettante, in quanto sembra più facile codificarlo, distribuirlo, mantenerlo e continuare a funzionare. Ricorda che mysql è basato su hard disk, e memcached è basato sulla memoria, quindi per sua natura è molto più veloce (10 volte almeno). E dal momento che prende tutto il carico di lettura dal db, la tua configurazione di db può essere REALMENTE semplice.

Spero davvero che qualcuno punti a un argomento contrario, mi piacerebbe sentirlo.