Un'azienda esegue un'applicazione che memorizza i dati su un'istanza database Multi-AZ di Amazon RDS for PostgreSQL. L'aumento del traffico sta causando problemi di prestazioni e le query del database sono state identificate come il collo di bottiglia principale. Cosa dovrebbe fare un architetto di soluzioni per migliorare le prestazioni dell'applicazione?

L'opzione corretta è creare una replica di lettura e servire il traffico di lettura da essa. Le repliche di lettura di Amazon RDS sono progettate specificamente per scaricare il carico di lavoro di lettura dall'istanza database principale, migliorando così le prestazioni complessive dell'applicazione quando le query di lettura sono il collo di bottiglia. Servire il traffico di lettura dalla replica di standby Multi-AZ non è possibile perché la replica di standby è destinata al failover automatico e non è accessibile per le operazioni di lettura/scrittura dirette. Configurare l'istanza DB per utilizzare Transfer Acceleration è irrilevante in questo scenario. Transfer Acceleration è un servizio di Amazon S3 che velocizza i trasferimenti di dati verso e da S3, non ha alcun impatto sulle prestazioni delle query di un database RDS. Utilizzare Amazon Kinesis Data Firehose tra l'applicazione e Amazon RDS non è la soluzione appropriata. Kinesis Data Firehose è un servizio di streaming di dati che può essere utilizzato per raccogliere e caricare grandi volumi di dati in destinazioni come S3, Redshift o OpenSearch Service. Non è progettato per migliorare la concorrenza delle richieste a un database relazionale o per risolvere colli di bottiglia nelle query.