Расходы Cronitor на AWS за последние 12 месяцев
В первые 30 дней после перевода Cronitor на AWS в январе 2015 года мы собрали платежей на $535 и заплатили $64,47 за , передачу данных и доменное имя. С тех пор мы наращивали потребление услуг, апгрейдили инстансы, добавляли сервисы. Несмотря на репутацию AWS как дорогого пистолета, чтобы выстрелить себе в ногу, наши счета сохранялись на уровне 12,5% от дохода. Смотрите сами.
Синяки и шишки от дешёвого AWS
Вскоре стало ясно, что наша идея имеет некоторую перспективу. Мы поняли, что нужно поднять планку с побочного проекта до полноценного малого бизнеса. Целью была не высокая доступность, а только повышение доступности по сравнению с предыдущей конфигурацией на единственном 2 ГБ Linode. Мы реально хотели только перезапустить базу данных без потери входящей телеметрии. Ничего особенного. Первоначальная установка была довольно простой:
- ELB
- SQS
- Пара инстансов t2.small с веб-приложением и сбором данных, оба на us-west-2
- Один инстанс m3.medium, где работали MySQL и наш демон, который определял сбои и рассылал оповещения
Мы закончили миграцию за два часа практически без даунтайма и были по-настоящему довольны собой. Полилось пиво. Отправились поздравительные твиты.
Радость оказалась недолгой.
Проблема 1: сбой ELB
Наши пользователи присылают пинги телеметрии, когда у них работают задания, процессы и демоны. С NTP сегодня у среднего сервера есть очень точные часы, и мы видим всплески трафика в начале каждой секунды, минуты, часа и дня — вплоть до 100-кратного превышения нашего базового трафика.
Немедленно после миграции пользователи начали жаловаться на периодические таймауты, так что мы решили перепроверить серверную конфигурацию и историю логов ELB. Со скачками трафика пока что менее 100 запросов в секунду мы отказались от мысли, что проблема в ELB, и стали искать ошибки в нашей собственной конфигурации. В конце концов, мы запустили тест для непрерывного пингования сервиса. Он начинался за несколько моментов до 00:00 UTC и заканчивался через мгновений после полуночи — и увидели неудачные запросы, которые вообще не попадают в логи ELB. Отдельные инстансы были доступны, а очередь запросов не создавалась. Стало ясно, что соединения обрывались на уровне балансировщика нагрузки, вероятно, потому что наши скачки трафика оказались слишком большими и были слишком кратковременными, чтобы он разогрелся на бóльшую нагрузку. Из-за дороговизны плана с техподдержкой на AWS мы не могли попросить их вручную увеличить размер нашего ELB, так что вместо этого решили запустить циклические запросы, используя DNS, чтобы вообще устранить необходимость балансировщика нагрузки.
Извлечённый урок:
- Облачные решения вроде эластичного балансировщика нагрузки в целом спроектированы для обычного, среднего использования. Думайте, в каком отношении вы отличаетесь от среднего.
Проблема 2: знакомство с балансом кредитов CPU
Линейка инстансов T2 с поддержкой всплесков нагрузки экономически выгодна, если нагрузка изредка возрастает, как говорит официальный сайт. Но вот я бы хотел, чтобы там было написано: если вы запускаете свой инстанс на постоянной нагрузке 25% CPU, то у вас начинает истощаться баланс кредитов CPU, а когда он заканчивается, у вас по сути остаётся вычислительная мощность Rasperry Pi. Никаких предупреждений об этом вы не получите, а ваш CPU% не будет отражать уменьшенную мощность. В первый раз, исчерпав баланс кредитов, мы решили, что соединения обрываются по какой-то другой причине.
Извлечённые уроки:
- Если нечто предлагается очень дёшево, на это есть хорошая причина, нужно понимать это
- Инстансы T2 следует использовать только в группе автомасштабирования
- Просто на всякий случай создайте уведомление CloudWatch, которое предупредит в случае падения баланса кредитов ниже 100
Проблема 3: что написано мелким шрифтом
В прошлом году на конференции re:Invent компания Amazon обновила своё предложение Reserved Instance, вероятно, в ответ на более выгодные условия от Google Cloud. В пресс-релизе говорилось, что зарезервированные инстансы станут дешевле и их можно будет переносить между зонами. Это же отлично!
Когда в октябре пришло время закрывать наши последние инстансы T2, мы выкатили новые M3 с этими подешевевшими и более гибкими 12-месячными резервациями. После появления нескольких крупных клиентов в апреле мы решили снова поднять уровень инстансов, теперь до M4.large. Оставалось шесть месяцев с октябрьской брони, так что я решил продать их, как всегда делал раньше. И тогда я узнал горькую правду, что ценой за эти подешевевшие и более гибкие резервации было то, что… вы не можете перепродать их.
Извлечённые уроки:
- Если нечто предлагается очень дёшево, на это есть хорошая причина, нужно понимать это
- Всегда дважды читайте условия предложения. Биллинг AWS невероятно сложный.
Взгляд на реальные цены AWS
Сегодня наша инфраструктура остаётся довольно простой:
- Кластер M4.large занимается сбором входящей телеметрии
- Кластер M3.medium обслуживает веб-приложение и API
- Воркер M4.large с нашим демоном мониторинга и системой оповещений
- M4.xlarge для MySQL и Redis
Мы продолжаем использовать ряд управляемых сервисов, в том числе SQS, S3, Route53, Lambda и SNS.
Elastic Compute
Мы используем частичное авансовое бронирование для всех наших сервисов.
Можете заметить, что из наших ежемесячных счетов 2/3 тратится на обеспеченные IOPS (операций ввода/вывода в секунду), как мы делаем для инстансов. В отличие от гарантированных IOPS в большинстве облачных метрик, которые являются просто записью в условиях договора, это реальная услуга, которая имеет себестоимость. Они также составят существенную часть вашего бюджета EC2 для любого хоста, где важна дисковая производительность. Если не будете платить за IOPS, ваши задачи будут стоять в очереди и ожидать освобождения ресурсов.
Пожалуйста, не спрашивайте, что означает “alarm-month”
SQS
Мы интенсивно используем SQS для постановки в очередь входящих пингов телеметрии и результатов от сервиса проверки состояния системы. Через несколько месяцев после миграции мы сделали одну оптимизацию — max-batching чтений. Вы платите за количество запросов, а не за количество сообщений, так что это снижает затраты и значительно ускоряет обработку сообщений.
Во время миграции мы беспокоились, что SQS представляет собой единственную точку отказа для нашего конвейера сбора данных. Чтобы избежать риска, мы запустили маленьких демонов на каждом хосте для буферизации и повторных попыток записи SQS в случае сбоя. Буферизация сообщений потребовалась только однажды за 2,5 года, так что 1) его на 100% стоило запускать; 2) SQS доказал невероятную надёжность в регионе us-west-2.
Lambda
Наш сервис Healthchecks построен частично на воркерах Lambda в регионах, указанных ниже. Нужно заметить, что у Lambda есть щедрый бесплатный уровень (Free Tier), который применяется к каждому региону отдельно. В данное время бесплатный уровень рекламируется как «неопределённый».
S3
Мы делаем резервные копии снимков БД и логов на S3 с репликацией в us-east-1 для восстановления в случае катастрофы.
Профессиональным советом для AWS является то, что резервные копии и снимки EBS жизненно важны в случае восстановления после катастрофы, но по-настоящему серьёзные сбои в регионе обычно не ограничиваются единственным сервисом. Если вы не можете запустить инстанс, то скорее всего не сможете и скопировать свои файлы в другой регион. Так что делайте это заблаговременно!
В завершение
Поработав с большими корпоративными и получившими инвестиции проектами на AWS, я могу лично поручиться, что вы можете запускать здесь большое дело. Они создали сказочный набор инструментов и блестящих объектов, которые все схвачены вместе — и с вас берут деньги за всё, к чему вы прикоснётесь. Это опасно, нужно быть сдержанным и ограничивать свои аппетиты, но вы будете вознаграждены возможностью вырастить маленький бизнес в нечто большее, когда любые ресурсы доступны вам по заказу, как только понадобятся. Иногда хорошо остановиться на секунду и задуматься о том, насколько это здорово — а затем снова возвращаться к работе.
Автор: m1rko
