{"id":3560,"date":"2021-09-17T13:59:00","date_gmt":"2021-09-17T11:59:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=3560"},"modified":"2021-09-17T12:00:35","modified_gmt":"2021-09-17T10:00:35","slug":"ottimizzazione-sul-cloud-aws-di-un-document-management-system-basato-su-mongodb","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/ottimizzazione-sul-cloud-aws-di-un-document-management-system-basato-su-mongodb\/","title":{"rendered":"Ottimizzazione sul Cloud AWS di un document management system basato su MongoDB"},"content":{"rendered":"\n

In questi anni una moltitudine di applicazioni sono sviluppate in ottica Cloud-native: una architettura ben progettata non \u00e8 per\u00f2 l\u2019unico aspetto da considerare per arrivare al successo. <\/p>\n\n\n\n

Nell\u2019articolo di oggi vedremo come dedicare la giusta quantit\u00e0 di tempo all\u2019esplorazione delle tecnologie cloud-native sia fondamentale per trovare la soluzione migliore, anche nel caso in cui scegliere un servizio al posto di un altro pu\u00f2 implicare un refactor dell\u2019applicazione.<\/p>\n\n\n\n

Lo storage \u00e8 un esempio che calza a pennello per la nostra discussione: oggi \u00e8 disponibile una gamma vastissima di servizi di memorizzazione e archiviazione dei dati e utilizzare quello pi\u00f9 adatto pu\u00f2 essere la chiave giusta per riuscire a ridurre le attivit\u00e0 di manutenzione e tenere bassi i costi dell\u2019intera applicazione<\/p>\n\n\n\n

Alcuni mesi fa ci \u00e8 stato chiesto di migliorare le performance e ridurre i costi di un software per la memorizzazione di documenti. L\u2019applicazione, basata su una architettura a microservizi e gi\u00e0 in esecuzione su AWS, era stata sviluppata per essere ospitata sia On-Prem, che in Cloud e progettata per fornire alta affidabilit\u00e0 e scalabilit\u00e0. Sul Cloud di AWS un cluster ECS Fargate era utilizzato per l\u2019esecuzione dei container in autoscaling, mentre un cluster MongoDB Atlas con tre nodi dedicati alla memorizzazione dei documenti.<\/p>\n\n\n\n

Gli oggetti erano memorizzati in formato BSON<\/a>. Essendo in previsione la gestione e la memorizzazione di una enorme quantit\u00e0 di oggetti, l\u2019elasticit\u00e0 \u00e8 stata uno dei fattori determinanti per l\u2019adozione del Cloud. <\/p>\n\n\n\n

La crescita del numero di documenti gestiti ad alcuni milioni ha presto causato un notevole aumento dei costi, specialmente per lo storage e il traffico tra le diverse Availability Zone.<\/p>\n\n\n\n

I costi per il trasferimento dati erano dovuti alla sincronizzazione del cluster: al fine di mantenere l\u2019alta affidabilit\u00e0, le istanze contenenti i dati erano in esecuzione in AZ differenti, per cui gli addebiti<\/a> riflettevano la quantit\u00e0 di traffico di rete che il cluster doveva mantenere per la replica e la sincronizzazione.<\/p>\n\n\n\n

Inoltre, i costi per lo Storage sono proporzionali alla dimensione dei volumi EBS necessari per la memorizzazione ed al parametro \u201creplicationSpecs\u201d di MongoDB.<\/p>\n\n\n\n

In aggiunta \u00e8 stato necessario procedere con il deploy di due nodi aggiuntivi per mantenere adeguati i livelli di performance durante i picchi di traffico. <\/p>\n\n\n\n

Un ulteriore problema era dato dal lavoro richiesto per il mantenimento dei livelli di servizio durante le finestre di manutenzione o in caso di fallimento di un nodo del cluster. <\/p>\n\n\n\n

Andava quindi trovata una strategia per ridurre i costi ed il lavoro necessario. <\/p>\n\n\n\n

A volte la soluzione migliore ad un problema complesso \u00e8 anche la pi\u00f9 semplice: abbiamo deciso di utilizzare Amazon S3, uno dei primi servizi disponibili sul cloud AWS. Amazon S3 \u00e8 uno storage ad oggetti progettato per offrire performance, alta disponibilit\u00e0 (con gli ormai famosi \u201cundici 9\u201d di affidabilit\u00e0) e scalabilit\u00e0. Mette a disposizione una ampia variet\u00e0 di classi di storage con un ottimo rapporto qualit\u00e0\/prezzo ed API per la gestione dei dati che sono diventate lo standard de-facto.<\/p>\n\n\n\n

La scelta \u00e8 caduta proprio su S3 perch\u00e9: <\/p>\n\n\n\n