De top 3 van AWS EC2-problemen diagnosticeren (en vermijden)

Er is een duizelingwekkend aantal bedrijven die hun kernapplicaties bouwen rond het cloudaanbod van Amazon Web Services, zoals hun Elastic Compute Cloud (EC2). In 2010 rapporteerde Amazon een EC2-groeipercentage van 35%. Het is voor van alles gebruikt, van het creëren van een on-demand supercomputingcluster voor farmaceutisch onderzoek tot het versterken van de backend voor de muziekherkenningsapp Shazam.

EC2 is uitermate handig voor zakelijke IT-teams die enorme rekenkracht willen verzamelen zonder fysieke infrastructuur aan te schaffen, en voor degenen die zich moeten voorbereiden op regelmatige pieken in de vraag van klanten. Dat gezegd hebbende, EC2 is een tool als alle andere. Het is vatbaar voor misbruik of verkeerd geconfigureerd, en als dat gebeurt, kan uw bedrijf geen schaal meer hebben. Hier leest u hoe u de meest voorkomende EC2-fouten kunt vermijden voordat uw toepassing begint te crashen.

1. Verwarrende opslaglatentie

De opslagvolumes van Amazon EC2 (genaamd Elastic Block Storage of EBS) zijn er in twee smaken. Standaardvolumes leveren gegevens met ongeveer dezelfde snelheid als een standaard desktop harde schijf, maar ingerichte volumes zijn ontworpen om gegevens veel sneller te verwerken. Als u een doorvoer nodig heeft met een snelheid tot 4.000 IOPS (invoer-/uitvoerbewerkingen per seconde), kunnen ingerichte volumes dat voor u regelen, ervan uitgaande dat u door verschillende hoepels springt.

De gebruikte instance moet bijvoorbeeld compatibel zijn met het aantal IOPS dat u nodig hebt. U moet de blokgrootte instellen op 16 KB of minder en de blokken moeten minstens één keer zijn geopend. Uw volumes worden langzamer als er een back-up wordt gemaakt. Ten slotte bevat Amazon EC2 blijkbaar geen tool die u realtime IOPS-gegevens van een bepaald volume geeft (hoewel dit kan worden berekend met behulp van monitoringtoepassingen van derden).

Deze laatste beperking kan tot moeilijkheden leiden. Het volgende kan gebeuren:

• IOPS neemt toe zonder medeweten van de beheerder totdat het de drempel voor een volume bereikt,
• Behandelingen beginnen vervolgens in de rij te staan,
• De hele applicatie wordt dan gelimiteerd door de EBS,
• De toepassing mislukt volledig.

Om dit probleem op te lossen, moeten andere manieren worden gevonden om IOPS te volgen. De VolumeQueueLength-metriek houdt het aantal openstaande I/O-verzoeken bij. Als u merkt dat uw EBS-volumes langzamer worden en u een hoge bijbehorende VolumeQueueLength vindt, kan dit duiden op een probleem met IOPS.

2. Inactieve EC2-instanties

Amazon kan nu per seconde kosten in rekening brengen voor het gebruik van een EC2-instantie. Voor sommige ondernemingen, bijvoorbeeld degenen die minder dan twee minuten flexibele capaciteit per keer nodig hebben, is dit een goede deal. In andere gevallen kan het een langzaam straaltje verspild geld zijn. Overgebleven testomgevingen, slecht presterende applicaties en andere use-cases lenen zich voor onderbenutte EC2-instances. Hoe spoor je ze op?

Metrieken zijn een manier om dit probleem op te lossen, maar ze zijn een bewegend doel. Verschillende toepassingen gebruiken bijvoorbeeld verschillende hoeveelheden CPU, dus u kunt niet alleen naar het CPU-gebruik kijken om te zien waar de onderpresteerders zijn. U moet instanties verwijderen waarin alle gebruiksstatistieken laag zijn, waarbij 'laag' betekent 'lager dan het basisgebruik van al uw EC2-instanties'. Instanties met gebruiksstatistieken die over de hele linie laag zijn, kunnen worden afgesplitst of geconsolideerd.

3. EC2-geheugenlekken

Het is mogelijk dat EC2-instanties onvoldoende geheugen hebben. Aangezien sommige EC2-instanties geen swapvolumes bevatten, kunnen de bijbehorende toepassingen geen geheugen vrijmaken op hetzelfde moment dat het wordt toegewezen. Aangezien dit gebeurt in tijden van bijzonder zwaar gebruik van applicaties, is het daarom mogelijk dat EC2 vastloopt terwijl het een piekbelasting ondergaat - min of meer volledig het doel om EC2-instanties te kopen in de eerste plaats teniet te doen.

Zoals het geval is met IOPS, kan het moeilijk zijn om onder de motorkap van EC2 te kijken om erachter te komen welke applicaties te veel geheugen gebruiken. Hoewel EC2 automatisch geheugen-hogging-processen zal doden, is het beter om deze processen in de eerste plaats niet te hoeven doden. Het is ook mogelijk om meer EC2-instances toe te voegen om als swapvolume te functioneren, of als failover in het geval dat een vitaal proces wordt afgebroken. Het toevoegen van deze instanties is echter duur. Er is een betere manier.

Bewaak AWS EC2 met AppNeta

Eén ding is duidelijk:AWS EC2-instanties bieden beheerders niet veel ingebouwde tools om de prestaties te bekijken. Met slim programmeren, het plannen van failover en het handmatig monitoren van implementaties kom je maar zo ver. AppNeta biedt een prestatiezichtbaarheidsoplossing voor AWS waarmee beheerders proactief fouten kunnen opsporen.

Neem een ​​kijkje in de Amazon SDN (ja, het is echt mogelijk) en begrijp knelpunten en vertragingen met onmiddellijke duidelijkheid. Probeer vandaag nog onze demo voor meer informatie.