Диагностика (и устранение) трех основных проблем AWS EC2

Огромное количество компаний создают свои основные приложения на основе облачных предложений Amazon Web Services, таких как Elastic Compute Cloud (EC2). В 2010 году Amazon сообщил о темпах роста EC2 на 35%. Он использовался для всего, от создания суперкомпьютерного кластера по запросу для фармацевтических исследований до усиления серверной части приложения Shazam для распознавания музыки.

EC2 чрезвычайно полезен для бизнес-ИТ-групп, которые хотят собрать огромные вычислительные мощности без покупки физической инфраструктуры, а также для тех, кто должен готовиться к регулярным скачкам потребительского спроса. При этом EC2 - такой же инструмент, как и любой другой. Он склонен к неправильному использованию или неправильной настройке, и если это произойдет, вашему бизнесу будет некуда расширяться. Вот как избежать наиболее распространенных ошибок EC2 до того, как ваше приложение начнет аварийно завершать работу.

1. Непонятная задержка при хранении

Тома хранения Amazon EC2 (так называемые Elastic Block Storage или EBS) бывают двух видов. Стандартные тома обслуживают данные примерно с той же скоростью, что и стандартный жесткий диск настольного компьютера, но подготовленные тома предназначены для гораздо более быстрого обслуживания данных. Если вам нужна пропускная способность до 4000 IOPS (операций ввода-вывода в секунду), подготовленные тома могут обеспечить это за вас - при условии, что вы перепрыгнете через несколько этапов.

Например, используемый экземпляр должен быть совместим с необходимым количеством операций ввода-вывода в секунду. Вам необходимо установить размер блока равным 16 КБ или меньше, и к блокам должен быть осуществлен доступ хотя бы один раз. Ваши тома будут замедляться, если будет выполнено резервное копирование. Наконец, Amazon EC2, по-видимому, не включает инструмент, который предоставил бы вам данные об IOPS в реальном времени с заданного объема (хотя это можно рассчитать с помощью сторонних приложений для мониторинга).

Это последнее ограничение может вызвать некоторые трудности. Возможно следующее:

• IOPS увеличивается без ведома администратора, пока не достигнет порогового значения для тома,
• Операции впоследствии начинают выстраиваться в очередь,
• Скорость всего приложения ограничивается EBS,
• Приложение полностью не работает.

Решение этой проблемы означает поиск других способов отслеживания операций ввода-вывода в секунду. Метрика VolumeQueueLength отслеживает количество ожидающих запросов ввода-вывода. Если вы обнаружите, что ваши тома EBS замедляются, и вы обнаружите высокий связанный VolumeQueueLength, это может указывать на проблему с IOPS.

2. Неактивные экземпляры EC2

Amazon теперь может взимать посекундную плату за использование инстанса EC2. Для некоторых предприятий - например, тех, кому необходимо использовать менее двух минут гибкой емкости за раз, - это выгодная сделка. В других случаях это может представлять собой медленную струйку потраченных впустую денег. Оставшиеся тестовые среды, неэффективные приложения и другие варианты использования поддаются малоиспользуемым экземплярам EC2. Как вы их выслеживаете?

Метрики - один из способов решить эту проблему, но они - подвижная цель. Например, разные приложения используют разное количество ЦП, поэтому вы не можете просто посмотреть на использование ЦП, чтобы увидеть, где находятся отстающие. Вам необходимо отсеять случаи, в которых все показатели использования низкие, где «низкий» означает «ниже, чем базовое использование всех ваших экземпляров EC2». Экземпляры с низкими показателями использования могут быть выделены или объединены.

3. Утечки памяти EC2

Экземплярам EC2 может не хватить памяти. Поскольку некоторые экземпляры EC2 не включают тома подкачки, связанные приложения не смогут освободить память одновременно с ее выделением. Поскольку это происходит во время особенно интенсивного использования приложений, EC2 может зависнуть прямо во время пиковой нагрузки, что более или менее полностью противоречит цели покупки инстансов EC2 в первую очередь.

Как и в случае с IOPS, может быть трудно заглянуть под капот EC2, чтобы выяснить, какие приложения используют слишком много памяти. Хотя EC2 автоматически убивает процессы, занимающие много памяти, лучше вообще не убивать эти процессы. Также можно добавить больше экземпляров EC2 для работы в качестве тома подкачки или в качестве аварийного переключения в случае остановки жизненно важного процесса. Однако добавление этих экземпляров обходится дорого. Есть способ получше.

Мониторинг AWS EC2 с помощью AppNeta

Ясно одно:инстансы AWS EC2 не предоставляют администраторам многих встроенных инструментов для отслеживания производительности. Умное программирование, планирование аварийного переключения и мониторинг реализации вручную - это далеко не все. AppNeta предлагает решение для мониторинга производительности AWS, которое позволяет администраторам заранее выявлять ошибки.

Загляните внутрь Amazon SDN (да, это действительно возможно) и мгновенно поймите узкие места и замедления. Для получения дополнительной информации попробуйте нашу демонстрацию сегодня.