Tag Archives: AWS

Altro

Le tecnologie dietro ad un sito che serve milioni di utenti

Interessante l’elenco delle tecnologie che Foursquare utilizza per servire i sui 15 milioni e passa di utenti, si trova nella pagina about: “I’m really into technology. What’s Foursquare built on?“.

Si tratta prevalentemente di soluzioni open-source, ci sono un po’ tutte le tecnologie più in voga del momento, dai database NoSQL, alle analisi sui dati con Hadoop, a Backbone.js e tutto sta su Amazon Web Services.

Per maggiori informazioni c’è il loro blog tecnico.

foursquare

Copio e incollo da Foursquare:

I’m really into technology. What’s Foursquare built on?

A causa della nostra crescita piuttosto folle, abbiamo progettato il nostro software su vari livelli in uno stack, in modo che risultasse il più possibile flessibile e scalabile. Questo ci ha permesso di crescere da poche migliaia di utenti ad oltre 15 milioni, ed anche di permettere a nuovi e fantastici tecnici di entrare a farne parte e collaborare da subito.

Foursquare è attualmente ospitato all’interno del servizio di Amazon EC2 , utilizzando centinaia di server che eseguono una versione base di CentOS Linux . Usiamo NGINX per indirizzare le richieste e servire contenuti statici e HAProxy per bilanciare le richieste web e API da molte macchine.

Ora arriviamo alla parte divertente. Salendo di livello nello stack, i dati in tempo reale del sito vengono memorizzati in MongoDB (anche se usiamo Memcache per memorizzare in cache un piccolo insieme di calcoli dispendiosi). Per l’analisi off-line dei dati effettuiamo regolarmente un’istantanea dei nostri dati in tempo reale e la importiamo in un cluster Hadoop. Abbiamo alcune operazioni personalizzate MapReduce, ma ci affidiamo soprattutto alla semplice sintassi di Hive e di uno scheduler delle attività realizzato appositamente per i calcoli abituali. Usiamo Solr e Elasticsearch per far funzionare la ricerca di luoghi, consigli, utenti. La nostra indicizzazione geografica usa la libreria s2 di Google per memorizzare gli identificativi di cella all’interno del nostro indice di ricerca. Usiamo PostGIS e il meraviglioso insieme dati digeonames.org per convertire a ritroso gli indirizzi codificati geograficamente in coordinate, il che ci consente di collocare i luoghi su una mappa e renderli disponibili per una ricerca basata sulla posizione. Kestrel costituisce la nostra coda per attività asincrone che intendiamo eseguire su gruppi di richieste degli utenti. Le foto realizzate dagli utenti vengono memorizzate su Amazon S3 con invio dei contenuti tramite Akamai. L’intero meccanismo è un po’ più complesso di così se si scava più a fondo, ma in sostanza tutto questo è il suo cuore.

Quasi tutto il codice per il sito web, le API e l’elaborazione in batch è scritto in Scala. Il web e le API si basano su Lift web framework. Inoltre, utilizziamo un bel po’ di Python e Bash script per l’automazione delle build, la distribuzione ed altre attività operative. Infine, il contenuto dinamico sul sito è scritto in javascript con un mix di jQuery, Backbone.js per i modelli di oggetti e Soy per i template.

We use beautiful maps by MapBox created using data provided by the wonderful © OpenStreetMap and contributors, and licensed Open Data Commons Open Database License. The interactive maps are generated using the open-source library Leaflet.

Altro

TamTamy.com e il cloud computing, un anno di storia: benefici, scelta architetturale ed esperienze

Un paio di settimane fa ho partecipato all’evento di Milano organizzato da Nextvalue sui temi del Cloud Computing. Qui sotto le slide della mia breve presentazione in cui ho portato la mia esperienza maturata nel corso di un anno abbondante di lavoro con TamTamy.com sulle tematiche del Cloud Computing, in particola riguardante l’offerta degli Amazon Web Services.

Altro

Amazon lancia tre nuovi servizi CloudWatch, Elastic Load Balancing, Auto Scaling

logo awsAmazon Web Serivces (AWS) ha rilasciato quest’oggi tre nuovi servizi che vanno ad arricchire la propria offerta di Cloud Computing.
AWS dimostra di essere in questo momento leader indiscusso nel mercato del Cloud Computing ed in particolare per ciò che riguarda la proposizione IaaS (Infrastucture-as-a-Service).
I tre servizi sono:

  • CloudWatch: servizio che permette di monitorare le risorse “fisiche” delle istanze EC2 (utilizzo CPU, accessi in lettura/scrittura, traffico di rete, etc.);
  • Elastic Load Balancing: servizio che permette di distribuire il traffico in ingresso tra un pool di istanze EC2;
  • Auto Scaling: servizio che permette di aumentare o diminuire automaticamente il numero di istanze EC2 attive basandosi sulle metriche monitorate da CloudWatch.

Si capisce come questi servizi siano strettamente legati fra loro, CloudWatch monitora il carico, Auto Staling permette di definire logiche per fare operazioni di scale up/down ed il Load Blancer non fa altro che distribuire il carico applicativo.
Le modalità di pricing, sono ovviamente di tipo pay-as-you-go (si paga solo quello che si utilizza), tutti i dettagli si trovano sul sito degli AWS.
Fantastico, semplice e geniale, ma … e si c’è un ma, come per tutti i servizi di Amazon, per trarne realmente vantaggio, bisogna pensare, rivedere le proprie applicazione secondo i principi base che Amazon ha individuato per la realizzazione di applicazioni distribuite e realmente scalabili.
Ho seguito la presentazione che Werner Vogels, il CTO di Amazon.com, ha tenuto allo scorso Web 2.0 Expo di San Francisco, ecco un breve resoconto, provo a riassumere quelli che sono i principi base di una “vera” architettura cloud in questi 3 punti:

  1. i guasti possono succedere, progettare una architettura in modo che un guasto sia una considerato un evento “normale”
  2. disaccoppiare i servizi, ragionare in modalità black-box e fare in modo che un modulo non sia sincronicamente dipendente da un altro
  3. la simmetria e la semplicità devono essere fattori importanti quanto si progetto un’architettura
Altro

Falling in love with Cloud Computing

I Spy Sky Eyes

Photo by Fort Photo

Seppur qui non ne abbia parlato molto è da qualche mese che ormai utilizzo gli Amazon Web Service (AWS), in particolare EC2 e S3, anche io, come Andrea, ne sono rimasto folgorato.

I tempi di provisioning praticamente nulli sono effettivamente sconvolgenti per chi come noi sul lavoro si deve spesso imbattere nei tempi imposto dai fornitori di hardware e di servizi.

Andrea nel suo post pone la questione di come il modello delle licenze Oracle non sia al passo con i nuovi modelli di business resi possibile da AWS e come invece il mondo open source sia più pronto:

[…] Questi processori virtuali sono paragonati ad uno Xeon 1.0Ghz. Visto che Oracle si licenzia tipicamente sulla base del numero di processori… se si dovesse licenziare per 20 processori equivalenti ad uno Xeon 1.0Ghz… beh, diventerebbe quantomeno poco conveniente. E ancora di più: ma se io la macchina virtuale la voglio usare solo per 1 ora al giorno nella configurazione da 20 processori?

Mi son fatto l’idea che gli AWS sono così innovativi che solo il mondo open source può stargli dietro al momento. […]

Secondo me il modello di business che verrà via via attuato, anche dai big vendor, assomiglierà alla proposizione che Red Hat ha fatto per EC2, ossia pagamento orario on top ai servizi Amazon, proprio vero il mondo open source è sempre più pronto a seguire i cambiamenti, anche MySQL ed OpenSolaris si sono mossi!

Per la verità Oracle potrebbe anche in futuro proporre una propria soluzione di virtualizzazione on demand simile a quella di Amazon, stiamo a vedere ….

Altro

Articoli improvvisati o maliziosi?

Leggo su Punto Informatico questo articolo su un presunto black-out dei servizi di virtualizzazione di Amazon, riporto la sintesi:

Lo sospetta qualcuno all’indomani del black out che ha costretto Amazon.com a due ore di indisponibilità, e a mancati incassi per milioni di dollari. I segnali di un grave problema per la rete, mai davvero risolto, ci sono tutti.

Allora, visto che ho 3 macchine EC2 che stanno girando su AWS e che non ho riscontrato nessun problema decido di informami un attimo … ecco sembra che sia stato un piccolo problema in un unico datacenter di Amazon, un fulmine ha provocato la rottura dell’impianto di condizionamento e, a causa di un surriscaldamento, un numero limitato di server ha inziato la procedura di shutdown, in un paio di ore tutto quanto riprestinato … ecco prima di gridare “al lupo, al lupo” magari informasi un attimo.

P.S.: su Amazon (EC2 e/o S3) girano ormai la metà dei servizi 2.0 che usiamo quotidianamente …