Витрати 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 з нашим демоном моніторингу та системою оповіщень
- 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, які отримали інвестиції, я можу особисто поручитися, що ви можете запускати тут велику справу. Вони створили казковий набір інструментів і блискучих об'єктів, які всі схоплені разом - і з вас беруть гроші за все, до чого ви доторкнетеся. Це небезпечно, потрібно бути стриманим і обмежувати свої апетити, але ви будете винагороджені можливістю виростити маленький бізнес в щось більше, коли будь-які ресурси доступні вам на замовлення, як тільки знадобляться. Іноді добре зупинитися на секунду і задуматися про те, наскільки це здорово - а потім знову повертатися до роботи.
