Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Super-scaling Magento with Docker, micro-services and micro-costs
Ähnlich wie Super-scaling Magento with Docker, micro-services and micro-costs (20)
Super-scaling Magento with Docker, micro-services and micro-costs
- 1. 1
- 2. Di cosa parleremo? • Come partire in cloud con costi infrastrutturali contenuti • Riservarsi la possibilità di crescere a seconda dei volumi di traffico • Mitigare il costo di cambiamento da cloud a “on-premise” oppure tra diversi cloud vendor • Scalare in maniera mirata rispetto alla tipologia di carico 2
- 3. Costi di un progetto in Cloud • Risorse computazionali (CPU, Ram) • Traffico in ingresso / uscita • Manutenzione e configurazione (gestione sistemistica delle macchine virtuali) • Costi di downtime (anche durante un deploy) 3
- 5. Perchè parliamo di Microservices • Ci abilitano a ragionare da subito in ottica di un sistema scalabile • Consentono l’utilizzo di tecnologie diverse per ogni microservice • Ogni microservice idealmente è capace di scalare con il minimo impatto sul resto dell’infrastruttura • Incrementando cosi la stabilità dell’intero sistema e diminuendo il costo di cambiamento del singolo servizio. 5
- 6. Microservices e Costi • I microservices ci consentono di ottimizzare costi e risorse in modo più mirato • Bisogna fare attenzione a non esagerare perchè inducono un costo operativo e di manutenzione (aumenta la complessita dell’intero sistema) 6
- 7. 7
- 8. Docker® che cos’è? • Docker® è uno strumento che può pacchettizzare un'applicazione e le sue dipendenze in un container virtuale che può essere eseguito su qualsiasi server Linux. 8
- 9. VM classica vs Docker® 9
- 10. Docker® come “enabler” per i Microservices • Docker® consente di ragionare da subito in un’ottica di un sistema distribuito • Più microservices istanziabili anche sulla stessa macchina grazie all’isolamento dei processi • Permette di controllare le risorse allocate per un container sulla stessa macchina • Di conseguenza permette di combinare opportunamente scaling orizzontale e verticale 10
- 11. “Micro-costi”: si tratta di granularità • Traffico in/out: si può pagare a consumo (MB, GB) • Risorse computazionali in ambito VirtualMachine di solito è 1 CPU e 1 GB di RAM • Containers (Docker®) ci abilitano ad un approcio pay-per-use anche sulle risorse computazionali 11
- 12. 12
- 13. Costo VM vs Costo Container • Grafico microcosti 13
- 14. Magento & Microservices • Web/Frontend • Database • Sessioni • Caching • Ricerca • Catalogo • Carrello 14
- 17. Problematiche di un sistema distribuito • Bilanciamento web • Bilanciamento containers sui nodi fisici / vm • High Availability • Service Discovery • Autoscaling 17
- 18. Soluzioni • AutoDiscovery: Etcd, Consul • Piattaforme di Orchestration: Jelastic, Docker Cloud 18
- 19. Conclusioni • Le soluzioni a Containers/Docker rappresentano l’evoluzione dei concetti delle VirtualMachine perchè rispondono in modo più efficente alle esigenze di scaling verticale / pay-per-use • Partire fin da subito con la costruzione di un sistema distribuito e scalabile comporta la riduzione dei costi delle risorse e di gestione, anche quando si tratta di sviluppi futuri • Docker/Containers è una tecnologia che ci abilita a ragionare in quest’ottica con costi potenzialmente contenuti, lasciandoci liberi di fare nuove scelte infrastrutturali (cambiare I vendor cloud, o passare a soluzioni on-premise) 19
- 20. Follow us 20 facebook.com/neen.datacenter @neendatacenter youtube.com/neendatacenter linkedin.com/company/1732369 neen s.r.l Via Mecenate 76/20A - 20138 Milano T: (+39) 02.45485420 E: info@neen.it Web: www.neen.it
- 21. 21
Hinweis der Redaktion
- Sono Mikhail PM Tecnico in Neen Neen fornisce il servizio cloud hosting fully managed e tutti servizi correlati (cdn, dns, domini)
- Obiettivi della presentazione sono due: - Introdurre dei concetti architetturali / tecnologici che ci permettono di aumentare la granularità dei costi infrastrutturali (micro-costi) - Dare una panoramica del tooling / piattaforme disponibili Quando ha senso? In prospettiva di crescita
- Quali sono i costi "tipici" di un qualsiasi progetto in cloud? CPU/RAM, traffico, manutenzione, downtime Problema: come ottimizzare i costi in un sistema monolitico (e.g Magento) senza compromettere la stabilità? Due fronti sui quali possiamo agire: infrastruttura e software. Pattern architetturale che ci abilita a farlo: microservices.
- Cosa sono i microservices? é un pattern architetturale che promuove la filosofia dei macro-componenti che in modo modulare compongono il sistema completo. Di conseguenza non abbiamo più un sistema monolitico che ricopre tutte le funzionalità, ma N sistemi che si occupano ognuno del suo compito e si integrano tra di loro. Filosofia molto UNIX.
- - Ogni servizio potenzialmente può scalare per conto suo, minimizzando l'impatto di compromettere il resto del sistema. Esempio: quando scaliamo il servizio della Ricerca le sessioni rimangono invariate. - I servizi possono usare tecnologie diverse (php 5 e php 7 ad esempio) - Dal punto di vista operativo si semplifica la gestione del sistema nel suo complesso.
- Dal punto di vista dei costi di conseguenza possiamo agire sui singoli macro-componenti del sistema facendo down o up scaling. Visto che viene introdotta ulteriore complessità al sistema bisogna stare attenti a non trasformare microservices in nanoservices. Il costo del servizio non deve superare la sua utilità.
- In questa slide possiamo vedere che il pattern dei microservices si può applicare anche all'infrastruttura: separiamo istanza web (con Magento sopra) dai servizi di Ricerca (che potrebbe essere ElasticSearch) e delle Sessioni (Memcached). Ma quante macchine fisiche o virtuali servono per questo setup (altri costi)? Parliamo di containers
- Sistema di virtualizzazione "leggero", che permette di isolare processi al livello del sistema operativo (kernel). Prodotto principale: Docker engine, è un demone che fa da connettore degli ambienti virtualizzati. Docker client che permette di interagire con demone. Ecosistema: Docker Hub, Docker Cloud Tooling: Docker Compose, Docker Toolbox
- Più leggero come risorse consumate: CPU, RAM, spazio disco Più veloce ad avviarsi (minuti contro secondi) Ovviamente è meno isolato Ma per "astrarre" i vari servizi dal punto di vista software è più che sufficente. Si può avviare un numero elevato di container su un host (1000?). 1000 macchine virtuali è un problema.
- Docker dunque ci permette di "simulare" tutta la nostra infrastruttura su una macchina (anche virtuale) singola - non dobbiamo più avere N macchine virtuali / fisiche. Visto che diversi provider lo supportano (AWS Beanstalk/ECS, Kubernetes, Jelastic), il costo di trasportalo poi in un ambiente di produzione è minimizzato - perchè viene usata la stessa tecnologia.
- Tornando sul tema della granularità dei costi, le tecnologie di virtualizzazione basate sui containers ci abilitano a una granularità maggiore rispetto alle macchine virtuali. L'esempio di un provider di questo tipo è Jelastic, basato sui container che permette scaling verticale a Cloudlet (200mhz + 128mb) - unita più granulare rispetto a 1 CPU e 1GB.
- Come esempio di piattaforma che ci abilita ai costi più granulari possiamo elencare Jelastic. Su questa slide vediamo il configuratore di topologia infrastrutturale che Jelastic mette a nostra disposizione. Possiamo configurare scaling verticale (automatico) e scaling orizzontale (di base manuale)
- Questo grafico ci da un'idea di massima qual'è il vantaggio, in termini di costi, di usare una piattaforma come Jelastic. Grazie al pricing più granulare e scaling verticale automatico non dobbiamo più aggiungere / togliere macchine virtuali, ma facciamo resize dei container.
- Due approci per l'applicativo: scalare le istanze di magento con nomi diverse (cart.example.com), oppure astrarre parte delle funzionalità che poi si integrano con servizio principale di magento. Dipende ovviamente dalle esigenze. Esempio: app mobile che usa Magento sotto Esempio 2: Single Page Application che usa Magento https://github.com/AOEpeople/Aoe_CartApi
- Come si "Dockerizza" un magento? Si parte dal Dockerfile, un file che contiene le informazioni su come fare build dell'immagine. Le istruzioni sono "cachate" in modo intelligente, come anche tutto il resto. Dopo che eseguiamo il docker build viene prodotta un'immagine e registrata nel docker engine locale. si può vedere con docker images. L'immagine può essere messa su DockerHub (docker push) o su un repository custom (Docker datacenter?) Di conseguenza scaricata ed eseguita come container su altre macchine (importanto credenziali del repository)
- Come collegare i vari container tra di loro? Sistema dei "link", e docker compose che si prende il carico di avviare tutti container necessari e di collegarli insieme durante l'avvio. Con docker-compose up tiriamo su tutta l'infrastruttura necessaria. docker-compose scale web=2 worker=3 Cosa succede se vogliamo avere più istanze di un servizio utilizzando host diversi?
- Problema principale: come comunicare al resto del sistema che è apparso un nuovo nodo? Ad esempio, come facciamo a dire al bilanciatore che è apparso un nuovo nodo web? Autodiscovery (etcd) + https://github.com/jwilder/docker-register Monitoraggio: Newrelic, Sentry / Rollbar
- Come funzionano i meccanismi di autodiscovery? Usando il protocollo di "gossip" (raft, swim) forniscono un sistema dove i nuovi servizi possono registrarsi (ip+porta+cname?) con poi la possibilità di fare introspezione sui questi servizi. Un esempio di paragone è ec2-describe-instances
- In questa presentazione abbiamo visto come è possibile ottenere maggiore granularità dei costi nel contesto di un sistema complesso. è obbligatorio ragionare a microservices per farlo? Si è obbligatorio usare container? Dipende dal use case
- Vi ringrazio per la vostra attenzione, seguiteci sui social e se vi interessa la tematica della scalabilità Magento venite a parlarci allo stand
- E ricordatevi che domani c'è MagentoRun