Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Pilastro dell'affidabilità
Il pilastro dell'affidabilità di AWS Well-Architected Framework comprende la capacità di un carico di lavoro di svolgere la funzione prevista in modo corretto e coerente quando previsto. Ciò include la capacità di gestire e testare il carico di lavoro durante l'intero ciclo di vita.
Un carico di lavoro affidabile comincia con decisioni iniziali di progettazione sia per il software sia per l'infrastruttura. Le tue scelte di architettura influiscono sul comportamento del carico di lavoro in tutti i pilastri di Well-Architected. Per quanto riguarda l'affidabilità, è necessario seguire degli schemi specifici, come illustrato in questa sezione.
Il pilastro dell'affidabilità si concentra sulle seguenti aree chiave:
-
Architettura del carico di lavoro, incluse quote di servizio e modelli di implementazione
-
Gestione delle modifiche
-
Gestione dei guasti
Comprendi le quote di servizio di Neptune
Il tuo AWS account ha delle quote predefinite (precedentemente denominate limiti) per ciascuna di esse. Servizio AWS Salvo diversa indicazione, ogni quota si applica a una regione specifica. Puoi richiedere aumenti per alcune quote, ma non per tutte.
Per trovare le quote per Neptune Analytics, apri la console Service Quotas.
Se la memoria massima fornita non è sufficiente per il set di dati, valuta quali tipi di nodi e edge sono essenziali per l'utilizzo analitico previsto. Carica un sottoinsieme di dati in modo che le analisi siano possibili entro una capacità prevista consentita. Molti carichi di lavoro di analisi, in particolare quelli che eseguono algoritmi grafici, richiedono solo la topologia con un set limitato di proprietà anziché il grafico transazionale completo. (Per una discussione sulle differenze tra i carichi di lavoro transazionali e analitici, consulta la sezione relativa al pilastro dell'efficienza delle prestazioni).
Se il numero massimo di grafici non è sufficiente per l'uso previsto:
-
Prendi in considerazione la possibilità di combinare grafici con usi simili.
-
Valuta quanti grafici devono essere eseguiti in un determinato momento. Se hai un caso d'uso temporaneo di analisi, crea un'istantanea ed elimina un grafico quando non è più necessario. Ciò riduce il numero di grafici rispetto alla quota.
-
Prendi in considerazione la possibilità di fornire grafici in diversi modi. Account AWS
Comprendi i modelli di implementazione di Neptune
Comprendi i seguenti punti decisionali quando prevedi di implementare un grafico di Neptune Analytics:
-
Seeding: decidi se creare un grafico vuoto o caricare dati al suo interno al momento della creazione con dati provenienti da Amazon S3, un cluster di database Neptune esistente o uno snapshot del database Neptune esistente.
Raccomandazione: se l'origine è un cluster o un'istantanea di Neptune, è necessario caricarne i dati al momento della creazione del grafico. Se l'origine è Amazon S3, carica i dati al momento della creazione se lo sforzo di caricamento è significativo e viene eseguito al meglio come attività di provisioning dell'infrastruttura. Se preferisci caricare i dati come attività di ingegneria dei dati o applicativa, crea un grafico vuoto e carica i dati da Amazon S3 in un secondo momento.
-
Capacità: stima la capacità fornita richiesta per un grafico, in base alla dimensione dei dati e all'utilizzo previsto dell'applicazione.
Raccomandazione: al momento della creazione, specificate la quantità massima di memoria disponibile per limitare la dimensione del grafico. Questa impostazione è obbligatoria. È possibile modificare la capacità in un secondo momento, se necessario.
-
Disponibilità e tolleranza agli errori: decidi se le repliche sono necessarie per la disponibilità. Una replica funge da standby a caldo per il ripristino in caso di errore del grafico. Un grafico con repliche viene ripristinato più rapidamente di un grafico senza repliche. Considerate anche per quanto tempo è necessario il grafico, se è destinato esclusivamente all'analisi effimera e, in caso affermativo, quando verrà rimosso.
Consiglio: prima di creare un grafico, stabilisci i requisiti di disponibilità, ad esempio per quanto tempo il grafico può non essere disponibile e quando può essere rimosso.
-
Rete e sicurezza: stabilite se avete bisogno di connettività pubblica, privata o entrambe e se desiderate crittografare i dati.
Consiglio: prima di creare un grafico, comprendi i requisiti organizzativi, ad esempio se è consentita la connettività pubblica e dove verranno distribuite le applicazioni client Graph.
-
Backup e ripristino: stabilisci se creare le istantanee e, in caso affermativo, quando o in quali condizioni. Valuta se la tua organizzazione ha requisiti di disaster recovery (DR).
Raccomandazione: la creazione di istantanee è un'attività manuale. Decidi quando creare le istantanee e considera i requisiti di DR prima di creare un grafico.
Gestisci e ridimensiona i cluster Neptune
Un grafico di Neptune Analytics è costituito da un'unica istanza ottimizzata per la memoria. La capacità (m-NCU) dell'istanza viene impostata al momento della creazione. L'istanza può essere scalata verticalmente aumentando la capacità fornita tramite un'azione amministrativa; la capacità fornita può anche essere ridotta. Le repliche sono obiettivi di failover passivi, quindi non aumentano la scala di un grafico. A questo proposito, una replica grafica differisce da una replica di lettura del database Neptune, che è un'istanza attiva in un cluster Neptune in grado di elaborare le operazioni di lettura dalle applicazioni.
Le repliche comportano dei costi. Il prezzo della replica è pari alla tariffa m-NCU del grafico. Ad esempio, se un grafico è predisposto per 128 m-NCU e ha una sola replica, il costo è il doppio di quello di un grafo equivalente senza repliche.
Nell'analisi, ci sono due ragioni principali per aumentare la scalabilità:
-
Per fornire più memoria e CPU per le query e gli algoritmi analitici, poiché la singola query è costosa, l'algoritmo grafico da eseguire è intrinsecamente complesso e richiede più risorse in base all'input, oppure la frequenza di richieste simultanee è elevata. Se tali query presentano out-of-memory errori, la scalabilità è un rimedio ragionevole.
-
Per supportare un grafico di dimensioni maggiori di quelle previste. Ad esempio, se la capacità attualmente fornita è di 128 m-NCU per supportare 60 GB di dati di origine e sono necessari altri 40 GB di dati di origine, è garantito un aumento a 256 m-NCU.
Monitora le CloudWatch metriche per Neptune Analytics, NumQueuedRequestsPerSec come,,, CPUUtilization e NumOpenCypherRequestsPerSec GraphStorageUsagePercentGraphSizeBytes, per determinare se è necessario il ridimensionamento. Puoi aggiornare la configurazione di un grafico tramite la console, oppure. AWS CLI SDKs (Per esempi e best practice, consulta la sezione relativa al pilastro dell'eccellenza operativa).
Gestisci i backup e gli eventi di failover
Utilizza le repliche per garantire che un grafico rimanga disponibile in caso di errore. Un grafico utilizza la persistenza basata su log per confermare le modifiche tra le zone di disponibilità in un. Regione AWS La replica funge da standby a caldo e ha accesso a questi dati. In caso di errore, il grafico riprende le operazioni sulla replica. L'applicazione continua a utilizzare lo stesso endpoint per connettersi al grafico. Le richieste in corso durante l'errore generano errori con un'eccezione del servizio non disponibile. Prendi in considerazione l'utilizzo di un pattern retry with backoff nel codice dell'applicazione per catturare l'errore e riprova dopo un breve intervallo. Le nuove richieste effettuate durante il failover vengono messe in coda e potrebbero presentare una latenza maggiore.
Se non è configurata alcuna replica e il grafico fallisce, Neptune Analytics esegue il ripristino da uno storage durevole, ma il ripristino richiede più tempo perché Neptune deve reinizializzare le risorse.
Crea istantanee del grafico. (Neptune Analytics non scatta istantanee automatiche). Se il grafico viene modificato regolarmente dopo la creazione, scatta istantanee frequenti per acquisire lo stato corrente. Eliminate le vecchie istantanee se non è necessario il ripristino a un punto temporale precedente.
Puoi condividere le istantanee con altri account e tra di loro. Regioni AWS Se hai requisiti di disaster recovery, valuta se il ripristino del grafico in un'altra regione da un'istantanea soddisfa i requisiti del Recovery Time Objective (RTO) e del Recovery Point Objective (RPO).
