Livello dati (Amazon Aurora e Amazon ElastiCache)

Con l'installazione di WordPress archiviata su un file system di rete distribuito, scalabile e condiviso e le risorse statiche fornite da Amazon S3, è possibile concentrare l'attenzione sul componente con stato rimanente: il database. Come per il livello archiviazione, il database non dovrebbe dipendere da un singolo server, per cui non può essere ospitato su uno dei server Web. Il database di WordPress deve invece essere ospitato su Amazon Aurora.

Amazon Aurora è un database relazionale compatibile con MySQL e PostgreSQL creato per il cloud che unisce le prestazioni e la disponibilità dei database commerciali di fascia alta alla semplicità e al costo ridotto dei database open source. Aurora MySQL potenzia le prestazioni e la disponibilità di MySQL mediante la stretta integrazione tra il motore di database e un sistema di archiviazione distribuito appositamente progettato supportato da SSD. È tollerante ai guasti e si ripara automaticamente, replica sei copie dei dati in tre zone di disponibilità, è progettato per garantire una disponibilità superiore al 99,99% ed esegue continuamente il backup dei dati in Amazon S3. Amazon Aurora è stato sviluppato in modo da rilevare automaticamente gli arresti anomali dei database e riavviarsi automaticamente senza la necessità di alcuna operazione di ripristino o di creazione di una nuova cache del database.

Amazon Aurora offre vari tipi di istanze per adattarsi a diversi profili applicativi, tra cui istanze ottimizzate per la memoria ed espandibili. Per migliorare le prestazioni del database, è possibile selezionare un tipo di istanza di grandi dimensioni che fornisca più risorse di CPU e memoria.

Amazon Aurora gestisce automaticamente il failover tra l'istanza primaria e le repliche di Aurora, in modo che le applicazioni possano ripristinare le operazioni del database il più rapidamente possibile senza interventi manuali di tipo amministrativo. Il failover richiede in genere meno di 30 secondi.

Dopo aver creato almeno una replica di Aurora, occorre collegarsi all'istanza primaria utilizzando l'endpoint cluster per consentire il failover automatico dell'applicazione in caso di errore dell'istanza primaria. È possibile creare fino a 15 repliche di lettura a bassa latenza in tre zone di disponibilità.

Man mano che il database si ridimensiona, anche la cache del database deve scalare. Come discusso in precedenza nella sezione Caching di database, per garantire una maggiore disponibilità, ElastiCache offre funzionalità per ridimensionare la cache su più nodi in un cluster ElastiCache e su più zone di disponibilità in una regione. Quando si ridimensiona il cluster ElastiCache, occorre assicurarsi di configurare il plug-in di caching per la connessione utilizzando l'endpoint di configurazione, in modo che WordPress possa utilizzare i nuovi nodi del cluster man mano che vengono aggiunti e smetta di utilizzare quelli che vengono rimossi. È inoltre necessario configurare i server Web per l'utilizzo del client del cluster ElastiCache per PHP e aggiornare l'AMI per archiviare questa modifica.