Een financiële onderneming draait een bedrijfskritische applicatie op huidige generatie Linux EC2-instances met een zelfbeheerde MySQL-database die veel I/O heeft. De applicatie verwerkt het grootste deel van de maand matig verkeer, maar vertraagt tijdens de laatste drie dagen vanwege maandafsluitingsrapportage. De infrastructuur gebruikt al ELB's en Auto Scaling voor compute. Welke actie zorgt ervoor dat de database de maandafsluitingsbelasting aankan met de minste prestatie-impact?

De correcte optie is om de database te migreren naar Amazon RDS en read replicas te gebruiken. RDS beheert de database-infrastructuur, wat de operationele last vermindert. Read replicas verdelen de leesbelasting, wat essentieel is voor rapportage met veel I/O, en kunnen dynamisch worden opgeschaald zonder de primaire database te beïnvloeden. Dit minimaliseert de prestatie-impact op de bedrijfskritische applicatie. De andere opties zijn minder effectief: Het pre-warmen van ELB's en het vergroten van EC2-instances helpt de compute-laag, maar lost het database-knelpunt niet op. GP2-volumes zijn niet altijd voldoende voor zeer hoge I/O. Het dynamisch wijzigen van EBS-volumetypes met CloudWatch en Lambda is complex en kan downtime veroorzaken of onvoldoende zijn voor de piekbelasting. Het vervangen van EBS-volumes door PIOPS-volumes door snapshots te maken en terug te zetten is een handmatig, foutgevoelig proces dat downtime vereist en niet schaalbaar is voor de piekbelasting.