Eine relationale Datenbank auf einer burstfähigen EC2-Instance zeigt periodische Latenzzeiten. Sie verwendet ein 350 GB großes gp2 EBS-Volume. CloudWatch zeigt, dass VolumeReadOps während der langsamen Perioden auf unter 10 % des Spitzenwerts fällt. Welche Änderung sollte der SysOps-Administrator vornehmen, um eine gleichmäßig hohe I/O-Leistung zu erzielen?

Die Migration des gp2-Volumes auf ein gp3-Volume ist die beste Lösung. gp2-Volumes bieten eine Baselin-Leistung von 3 IOPS pro GB, mit einer Burst-Leistung von bis zu 3.000 IOPS für Volumes unter 1 TB. Bei 350 GB beträgt die Basisleistung 1.050 IOPS. Wenn die VolumeReadOps unter 10 % des Spitzenwerts fallen, deutet dies darauf hin, dass die Burst-Guthaben aufgebraucht sind und das Volume auf seine Basisleistung zurückfällt, was zu Latenzzeiten führt. gp3-Volumes bieten eine garantierte Baseline-Leistung von 3.000 IOPS und einen Durchsatz von 125 MB/s unabhängig von der Volume-Größe, was eine konsistentere Leistung gewährleistet. Die Migration zu einem Cold HDD (sc1)-Volume ist ungeeignet, da diese für selten genutzte Daten konzipiert sind und die schlechteste Leistung aller EBS-Typen bieten, was die Latenzprobleme verschärfen würde. Eine Umstellung der EC2-Instanz auf eine speicheroptimierte Familie würde die Rechenressourcen für die Datenbank verbessern, aber nicht direkt das Problem der EBS-I/O-Leistung lösen. Das Aktivieren des unbegrenzten Burst-Modus auf der EC2-Instanz ist irrelevant, da die Burst-Leistung des EBS-Volumes das Problem ist, nicht die der Instanz.