Попробовать
демоверсию
Бесплатная демоверсия позволяет ознакомиться со всеми возможностями нашего биллинга
+7 499 940-95-05

5 типичных ошибок при работе с Amazon Web Services

Наша адаптация заметки разработчика и системного архитектора Михаэля Виттига о наиболее распространенных ошибках в использовании Amazon Web Services.

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

Как выглядит типичное веб-приложение

Стандартное веб-риложение состоит из:

1. балансировщика нагрузки;
2. масштабируемой серверной части (web backend'a);
3. хранилища

На схеме это выглядит примерно так:

Это общепринятая схема. На испльзование какого-то другого способа конструирования приложения должны быть веские причины.

Ошибка 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, его администраторам нужно перенастроить параметры автоматического масштабирования, масштабировать ресурсы в пользу увеличения позже, а в сторону уменьшения раньше.

Подписывайтесь на наш блог, чтобы не пропустить ничего интересного!

28.01.2016

Другие публикации

По определению консалтинговой компании Deloitte, текущий период в мировой экономике характеризуется неопределенностью. Поэтому бизнес во всем мире стремится к оптимизации и снижению издержек. Сегодня мы рассмотрим несколько способов, с помощью которых компании из разных стран экономят уже сейчас.
В новой версии Гидры мы по традиции продолжили работу над коммерческими возможностями биллинга. Встречайте контрактные тарифы! Другие мелкие улучшения упрощают интеграцию Гидры с внешними системами.
Компании из самых разных отраслей бизнеса сталкиваются с часто повторяющимися бизнес-процессами, связанными с обработкой заявок. В большинстве отраслей выполнение типовых работ и услуг — это сложный и разветвленный бизнес-процесс. Мы много размышляли об этих проблемах и создали инструмент, который каждая компания могла бы легко адаптировать под себя — новый продукт Гидра OMS
В одном из наших постов мы уже описывали ситуацию, в которой бесконтрольный рост таблиц в базе данных одной компании-пользователя нашей системы привел к настоящему DoS. Сегодня речь пойдет о еще одном интересном случае внезапного сбоя, который сделал «день смеха» 1 апреля этого года совсем не смешным для службы поддержки «Латеры».
В Instagram развертывание backend-кода (основная программно-аппаратная часть, с которой работают клиенты) происходит от 30 до 50 раз в день, каждый раз, когда инженеры подтверждают изменение оригинала. И, по большей части, без участия человека — сложно в это поверить, особенно учитывая масштабы соцсети, но факт остается фактом.
В этой заметке речь пойдет о масштабировании. Разработчики open-source почтового приложения Nylas опубликовали в своем блоге материал о том, как им удалось масштабировать систему в 20 раз за три недели с помощью инструмента ProxySQL. Для этого им пришлось переехать с Amazon RDS на MySQL на EC2.
Интересный материал о работе с JSON, и в частности, о применении ограничений опубликовал в своем блоге разработчик Магнус Хагандер (Magnus Hagander) — в нашем блоге мы решили представить его основные идеи.
Успешно завершили интеграцию биллинга Гидра с порталом NEXT TV.
В этой заметке мы рассказываем о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkušić) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки и делимся своим опытом.
Разработчики из американской компании Gaslight написали интересный материал о том, почему организация, известная своей любовью к Ruby и Ruby on Rails, решила инвестировать в освоение новых технологий — например, Clojure. Мы тоже работаем с этим языком программирования, поэтому решили выделить главные тезисы команды Gaslight в отдельный материал.
Разработчик и сотрудник проекта CouldBoost.io Наваз Дандала (Nawaz Dhandala) написал материал о том, почему в некоторых случаях не стоит использовать MongoDB. Мы в «Латере» уже много лет работаем с этой СУБД, поэтому решили представить и свое мнение по данному вопросу.
Немецкий журналист и хакер Ляйф Риге (Leif Ryge) написал для издания Ars Technica интересный материал о том, что современный подход к организации обновлений программного обеспечениях несет в себе серьезные риски информационной безопасности. Мы представляем вашему вниманию главные мысли этой заметки.
Инженер проекта Haleby.se написал материал, в котором рассказал о причинах выбора в качестве инструмента оркестрации Docker-контейнеров технологии Kubernetes. Мы представляем основные мысли этой заметки.
Адаптация заметки бывшего сотрудника Amazon про то, почему плохие продукты пользуются большим успехом, опубликованная в авторской колонке Дмитрия Копловича на Rusbase.
Поучительная история из жизни нашей техподдержки про то почему операторам нужно мониторить размеры таблиц в своих базах.
Инженер компании Akalak & Neo Technology Горка Садаковски (Gorka Sadakowski) написал интересный материал о том, как использование графовых баз данных может в режиме реального времени предотвращать мошенничество в сфере электронной коммерции. Мы представляем вашему вниманию основные мысли этой заметки.
Платежные протоколы уязвимы — об этом рассказали немецкие исследователи информационной безопасности на конференции Chaos Computing Club. Предлагаем вам адаптированный перевод их выступления.
Наш адаптированный перевод заметки главного разработчика Azure Джеффа Уилкокса, о том, как более двух тысяч членов команды проекта переезжали на GitHub.
Представляем вашему вниманию адаптированный перевод одной из глав книги «Архитектура open-source-приложений», в которой описываются предпосылки появления, архитектура и организация работы популярного веб-сервера nginx.
Наш сегодняшний пост посвящен тому как мы писали софт для контроля работы удаленных сотрудников.
Сегодня мы расскажем про устройство системы подпольного банкинга Хавала, которая возникла еще в VIII веке и до сих пор пользуется большой популярности в странах Среднего Востока, Азии и Африки.
Мы уже рассказывали о том какие проблемы могут возникнуть у компании при саомостоятельной разработке сложных систем. Сегодня мы поговорим о том, как мы работали над повышением отказоустойчивости «Гидры».
Адаптированный перевод заметки главного инженера LinkedIn Джоша Клемма о процессе масштабирования инфраструктуры социальной сети.
Адаптированный перевод заметки инженера финансового стартапа Stripe о том, как его команда мигрировала огромное количество записей в базе данных.
По нашим оценкам, около половины российских операторов связи используют самописный (или переписанный до неузнаваемости простенький «покупной») софт. Сегодня мы поговорим о возможных минусах такого подхода.
Появились маркетинговые инструменты для сегментации абонентской базы, управления скидками и пакетными предложениями.
Подробнее читайте в блоге.
В новой версии мы полностью переработали механизм работы с услугами. Это сразу дало несколько серьезных улучшений, но полностью все заложенные в новой версии возможности будут раскрыты в следующих версиях.
В новой версии была полностью переработана система прав доступа. Новая система уникальна и позволяет реализовать самые смелые замыслы по разграничению доступа сотрудников к биллингу.

Начните знакомство с Гидрой прямо сейчас

Попробовать демоверсию Купить Гидру

Оформление демоверсии

Пожалуйста, укажите реальный email, на него придут данные для доступа в демо.
Все поля являются обязательными для заполнения.
.hydra-billing.com

Для вас будет развернута персональная облачная версия Гидры.
Нажимая кнопку "создать демоверсию" вы соглашаетесь с
Политикой обработки персональных данных.

Мы можем вам перезвонить

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Напишите нам!

Ваша компания

Услуги, которые вы предоставляете:

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Скачать буклет

Ваш адрес:

Хотите узнать больше?

Рассылка делается примерно раз в месяц. Мы обещаем бережно хранить ваш электронный адрес и никому его не выдавать даже под пытками.