5 типових помилок при роботі з Amazon Web Services



Ми в «Латере» займаємося створенням білінгу для операторів зв'язку. В блозі на Хабре ми не тільки розповідаємо про особливості нашої системи і деталі її розробки (наприклад, забезпечення відмовостійкості), але і публікуємо матеріали про роботу з інфраструктурою в цілому. Розробник і системний архітектор Міхаель Віттіг (Michael Wittig) написав у блозі Cloudonout цікавий матеріал про найбільш поширених помилок сервісу AWS (Amazon Web Services). Ми представляємо вашій увазі основні думки цієї замітки.

Віттіг працює консультантом по AWS і побачив багато варіантів розгортання ПЗ, незалежно від розміру — здебільшого, це стандартні веб-додатки. Інженер склав список з 5 найбільш частих помилок користувачів, яких слід уникати.

Як виглядає типовий веб-додаток

Стандартне веб-додаток складається з:

  • балансувальника навантаження;
  • масштабованої серверної частини (web backend'а);
  • сховища.
На схемі це виглядає приблизно так:



Це загальноприйнята схема. На використання якогось іншого способу конструювання додатки повинні бути вагомі причини.

Помилка 1. Управління інфраструктурою вручну

Якщо установки в AWS були зроблені за допомогою кліків на консолі, значить, управління інфраструктурою здійснюється вручну. Головна проблема з таким варіантом управління – ці установки неможливо відтворити, вони ніде не зареєстровані. Як результат – вірогідна маса помилок. На щастя, є AWS CloudFormation, за допомогою якого можна вирішити цю проблему задурно.

Замість створення ресурсів (инстансов EC2, груп безпеки, підмереж) вручну можна описати їх у шаблоні, створити свій власний або використовувати готовий. CloudFormation сам подбає про те, як інтегрувати їх у діючий стек. Сервіс створить ресурси в правильному порядку, як показано на картинці:



Шаблон можна оновлювати. Подивитися приклад стандартного шаблону для веб-додатки можна тут. Віттіг переконаний, що керувати інфраструктурою вручну непрофесійно — занадто багато проблем може принести такий спосіб роботи.

Помилка 2. Невикористання Auto Scaling Groups

Деякі наївно вважають, що можуть масштабувати ресурси самостійно, не вдаючись до допомоги спеціальної функції. Кожен EC2 інстанси повинен бути запущений в Auto Scaling Group. Навіть якщо це окремий інстанси. Auto Scaling Group контролює запуск необхідного числа инстансов. По суті, він веде себе як логічна група віртуальних машин. Функцією можна користуватися безкоштовно.

У стандартному веб-додатку сервери запускаються на віртуальних машинах всередині Auto Scaling Group. Існує можливість варіювання обсягів обчислювальних ресурсів, виходячи з завантаження, орієнтуючись на підвищення або зниження попиту. Адміністратор може прописати умови, за яких буде запускатися автоматичне масштабування. Це може бути поріг продуктивності CPU логічної групи або кількість запитів у балансування завантаження.

Помилка 3. Зневага до аналітики Amazon Cloud Watch

Цікаві дані про роботу сервісів AWS можна отримувати через Cloud Watch. Віртуальні машини сповіщають про завантаження процесора, мережі, роботи диска. Сховища надають інформацію про використання пам'яті та кількості операцій введення/виводу. Вам залишається тільки правильно використовувати цю статистику. Давайте подивимося на графік роботи CPU за добу:



Бачите пік завантаження? Віттіг переконаний, що цей стрибок відбувався кожен день в один і той же час:

Схоже на витівки планувальника завдань. Так воно і є. Врахуйте, що з цієї машини запускався веб-сервер. Значить, кожен день час очікування збільшувалася за планувальника. Запустіть його на окремій віртуальній машині, і проблема буде вирішена. Без Cloud Watch виявити її було б важко.
Як тільки дані проаналізовані, слід поставити маркери оповіщення граничних значень. Ніяк не навпаки!

Помилка 4. Ігнорування Trusted Advisor

Інструмент Trusted Advisor виробляє перевірку середовища AWS, на відповідність кращим практикам роботи з сервісом. Перевіряються параметри:

  • оптимізація витрат;
  • продуктивність;
  • безпека;
  • стійкість до збоїв.
Якщо консоль управління Trusted Advisor виглядає наступним чином:



Можна сміливо почати оптимізувати процеси в середовищі вже зараз, вважає Віттіг.

Я б порадив, в першу чергу, звернути увагу на безпеку. Ви можете спробувати функцію щотижневої зворотного зв'язку, і Trusted Advisor буде доповідати про всіх поточних і вирішених проблемах. Ви можете активувати безкоштовну версію програми. Платна підтримка відкриє додаткові можливості для перевірки.

Помилка 5. Недооцінка можливостей віртуальних машин

Немає сенсу не знижувати розмір инстанса (кількість машин або категорію з c3.xlarge до c3.large), якщо з'ясовується, що існуючі EC2-инстансы недовикористовуються. Дізнатися про це можна, звірившись з даними Cloud Watch. Якщо проект застосовує Auto Scaling Groups, його адміністраторам потрібно переналаштувати параметри автоматичного масштабування, масштабування ресурси на користь збільшення пізніше, а в бік зменшення раніше.

Інші цікаві статті в блозі «Латеры»:


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.