Costruire un sistema distribuito su Amazon Web Services

Ci sono (almeno) due linee di pensiero sui sistemi distribuiti, e a seconda del tuo ambiente il tuo sistema può o meno qualificare come tale:

1. Computer Science: in questo caso, un sistema distribuito risolve un problema algoritmico tale che ogni nodo fa parte dell'elaborazione, in alcuni casi anche senza un controller che coordina l'attività. Di solito l'obiettivo è trovare un algoritmo distribuito per risolvere un problema in modo più efficiente.

2. Sistemi informativi: in questo caso, un sistema distribuito è uno che distribuisce presentazione, applicazione e database tra più entità autonome che comunicano tramite una rete (passando messaggi tra loro).

(Si noti che su un livello sinceramente astratto è la stessa definizione - qualsiasi problema computazionale è in realtà un problema algoritmico, ma salviamo questo argomento per una discussione diversa).

Quindi sì, puoi considerare il tuo un sistema distribuito, e possiamo argomentare così dato la definizione come trovata in Wikipedia :

1. There are several autonomous computational entities, each of which has its own local memory.[7]

2. The entities communicate with each other by message passing.[8]

Nel tuo caso, il server web insieme al codice dell'applicazione, al server database e al server immagini sono tutti entità computazionali autonome con la propria memoria locale e comunicano per trasmissione di messaggi (cioè , inviando messaggi avanti e indietro attraverso la rete).

Lo stesso articolo di Wikipedia elenca anche diverse architetture per la costruzione di sistemi distribuiti, uno dei quali è n-tier Architettura :

In software engineering, multi-tier architecture (often referred to as n-tier architecture) is a client–server architecture in which presentation, application processing, and data management functions are logically separated.

Inoltre, il tuo sistema ha chiaramente più livelli (l'applicazione, il database e l'archivio di immagini). Probabilmente ha anche più livelli, cioè se hai seguito il modello MVC di Symfony . MVC per definizione separa la presentazione e la logica dell'applicazione, e dal momento che (almeno in parte) il livello di presentazione è sicuramente eseguito da un browser web, questo è in realtà un architettura 3-tier :

Three tier systems move the client intelligence to a middle tier so that stateless clients can be used. This simplifies application deployment. Most web applications are 3-Tier.

Le risorse sono distribuite ma la logica no. Sia il database che il repository S3 sono controllati dall'applicazione e non vi è parallelismo nell'attività che l'applicazione esegue tra macchine diverse. Secondo wikipedia ci sono due requisiti per un sistema distribuito, entrambi mancanti dal sistema che hai descritto (o non chiarito):

• Esistono diverse entità computazionali autonome, ognuna delle quali ha una propria memoria locale
• Le entità comunicano tra loro tramite il messaggio che passa.

In questo senso non è un sistema distribuito e richiederebbe diversi server EC2 che eseguono questa applicazione per coordinare le loro azioni su come accedere e sincronizzare le risorse.

Modifica: dalla domanda non è chiaro se viene utilizzata una sola istanza EC2 o molte. Nella mia risposta di cui sopra presumo una singola istanza.

EDIT: la domanda aggiornata dall'OP chiarisce che si tratta di una singola istanza EC2. Accademicamente tali applicazioni sono considerate a più livelli. Il livello client si trova sulla macchina dell'utente finale, il livello Web è il server EC2 e il livello EIS (Enterprise Information System) è il database e il repository S3. Ancora una volta, per distribuire un'applicazione è necessario distribuire l'elaborazione del livello Web su più server. Tuttavia, nel settore tali applicazioni possono essere considerate distribuite a causa della separazione delle posizioni. Quindi direi che l'app stessa che viene eseguita nel server EC2 non è un sistema distribuito, ma l'intera configurazione (browser del client < - > web app < - > database / s3) può essere considerata come una distribuzione architettura / applicazione.

Controlla anche questa domanda: link

Il tuo design è leggermente distribuito, ma in modi molto semplici e minimi. Hai funzionalmente decomposto il tuo carico di lavoro su più server. Nel 1980, questo sarebbe stato considerato un sistema distribuito. Ma non distribuisci (aka, partizione, shard) nessuna delle singole parti del tuo carico di lavoro su più server. Non esiste una parcellizzazione sostanziale del lavoro, né una replica significativa su più nodi o datacenter. La tua memoria (S3 e CloudFront CDN) è l'unica eccezione; questi servizi distribuiscono in modo inerente l'accesso allo storage.

Sentiti libero di chiamarlo "app cloud" o "servizio cloud", ma secondo gli standard odierni, non è molto distribuito.

Il tuo esempio descrive la delega, non la distribuzione. La delega assegnerebbe un'attività specifica a un sottosistema appropriato, dove la distribuzione divide un processo in parti approssimativamente simili che possono essere eseguite in parallelo. Una semplice cartina di tornasole: chiedete a voi stessi, se ho bisogno di scalare questo sistema, lo ridimensiono "su" (un computer più grande) o "fuori" (altri piccoli computer). Potrei ridimensionare questo 10x? 1000x? Queste sono preoccupazioni del mondo reale risolte dai sistemi distribuiti.