Здесь, в awe.sm, мы с самого начала использовали Amazon AWS для . За последние три года мы изучили, что хорошо, а что не очень и сформулировали для себя свой собственный набор правил для запуска высоко доступной, высоко производительной системы, которые в некоторых случаях отличаются от того, что советует Amazon.
Мы собираемся поговорить о следующих родственных понятиях:
- Для людей, которые слышали об Amazon, но еще не имели возможности его использовать, мы покажем все преимущества и недостатки этого сервиса, с которыми мы столкнулись в своей работе.
- Для тех, кто уже использует AWS, мы проясним некоторые детали и расскажем о лучшей практике использования Amazon для таких высокопроизводительных сервисов, как наш, где непрерывная работа системы является самым высоким критерием.
Не будет преувеличением сказать, что Amazon радикально изменил экономический аспект запуска IT стартапов, это происходило медленно и постепенно, но сейчас это факт. Никто не осознает, как много компаний используют Amazon EC2 где-либо в своей инфраструктуре, до тех пор, пока не случится сбой и не создастся впечатление, что половина Интернета перестала работать. Это не значит, что Amazon просто повезло, на самом деле у них очень хороший продукт. Все пользуются этим сервисом, потому что он очень сильно упростил запуск приложений и сервисов, значительно уменьшив количество необходимых знаний, шагов, которые нужно предпринять и денег, которые необходимы, чтобы запустить стартап.
EC2 это новый способ запуска ПО.
Первое и самое главное, что нужно знать о EC2 это то, что это не просто . Лучше думать об этом, как о найме системного и сетевого администратора на частичную занятость. Вместо того, чтобы нанять высокооплачиваемого сотрудника, который выполнит полный объем работ и автоматизирует все для вас, вы платите немного больше за каждый сервер, но избавляетесь от целого ряда проблем. Электропитание, сетевая топология, стоимость аппаратного обеспечения, несовместимость оборудования разных производителей, сетевые хранилища данных — обо всех этих вещах приходилось думать в далеком 2004 году (или выбросить эту идею из головы). С AWS его конкурентами, количество которых быстро растет, у вас отпадает необходимость думать о подобных вещах, до тех пор пока вы не захотите чего-то большего.
Основное отличие и преимущество использования EC2 это гибкость. Мы можем запустить новый сервер быстро, очень быстро, это займет около 5-ти минут, с момента появления мысли «мне необходимо новое оборудование» до момента, когда вы можете зайти в систему в первый раз. Это дает нам возможность делать такие вещи, которые еще несколько лет назад казались невозможными, например:
- мы можем установить самые последние обновления аппаратного обеспечения. Когда у нас происходит большое обновление мы запускаем новый сервер, устанавливаем на него всё необходимое программное обеспечение, устанавливаем все зависимости, переносим конфигурационные файлы, а затем просто включаем этот сервер в наш балансировщик нагрузки, если всё в порядке мы просто убираем из балансировщика старые сервера и выключаем их, если же что-то пошло не так, мы можем легко переключить балансировщик обратно. Можно держать запущенными дубликаты старых и новых серверов в нужном нам количестве, необходимое нам время и потом выключить те, которые не нужны, без необходиомсти покупать новое оборудование.
- для некоторых не критичных систем, где один час простоя является приемлым, мы использовали следущий алгоритм: сервер мониторился и в случае появления проблем, мы просто поднимали новый хост вручную
- мы можем расширять нашу инфраструктуру в момент роста нагрузки, вместо того, чтобы устанавливать новое оборудование заранее. В слуае возростания нагрузки мы запускаем новые мощности, которые нам нужны как раз в определенный момент времени, для того чтобы справиться с текущей нагрузкой
- мы не должны заботиться о предварительном вычислении мощностей, которые нам могут понадобиться. Когда нам необходимо мы запускаем новый сервер, если он не справляется с нагрузкой мы запускаем более мощный, или наоборот, мы можем запустить более слабый, если его мощности достаточно. Это одна из лучших возможностей AWS, которая предоставляется на уровне оборудования, и это возможно только потому, что предоставление новых серверов и удаление старых происходит почти мгновенно.
EC2 является финансово выгодным для стартапов
Самая очевидная экономическая выгода состоит в том, что мы в буквальном смысле можем стартовать с нулевыми затратами. Вы используете тот же Amazon аккаунт, который вы используете для покупки разнообразных не нужных вещей через Интернет, нажимаете кнопку и начинаете играть со своими серверами в течение часа. Вы платите только за те сервера, которые запущены и только за те дисковые накопители, которые используются, так, что стоимость старта для вас является минимальной. Это дает возмодность проводить эксперименты с оборудованием: запустить в 10 раз больше мощностей чем вам необходимо, запустить нагрузочные тесты и затем всё выключить, пока такие мощности нам действительно не понадобятся. Это не просто удобство, это революционный прорыв, на равне с другими преимуществами AWS, эта количественная особенность становится качественной.
Как я уже упоминал, AWS резко снижает операционные затраты. Вплоть до 2012 года, более двух лет с того момента как мы запустили нашу компанию у нас небыло выделенного системного администратор. Это было плохой тенденцией, мы должны были нанять хотя бы одного человека в 2011 году или раньше. Сейчас у нас работает только один системный администратор, который работает на полной занятости и управляет всей нашей инфраструктурой, состоящей из сотен серверов. Это довольно высокое отношение количества людей к количеству обслуживаемых машин. Усиливает эффект то, что у нас нет необходимости беспокоится о сети, электропитании и многом другом и как только вы привыкнете к такому, вы начинаете это недооценивать.
Конечно, это не просто , он стоит дороже обычного . Но Амазон старается убрать этот недостаток и периодически снижает цены: на 18% в октябре, на 10% в марте, и это только в этом году. Так же для экономии вы можете использовать запасные сервера, которые запускаются, при наличии свободных мощностей и стоят дешевле, вместо тех, которые запускаются по требованию. Так же при долгосрочном использовании вы можете платить заранее и пользоваться зарезервированными машинами, таким образом можно сохранить до 50%. Мы в awe.sm помешаны на надежности и используем избыточное количество оборудования, так что резервирование было большим выигрышем для нас.
EC2 имеет ряд проблем.
В этом месте хвалебное письмо заканчивается и настает время пересмотреть отношение к Amazon. Пока мы любим EC2 и не можем себе представить жизнь без него важно быть честным и понимать, что этот путь не безоблачный и не выложен лепестками роз. EC2 имеет серьезные ограничения по производительности и надежности, которых нужно остерегаться и которые нужно учитывать в своих планах.
В первую очередь это заявленная независиомсть инфраструктуры и её отказов пределах зоны доступности. Сервисы AWS расположены в нескольких локациях по всему миру, которые называются регионами доступности. Каждый регион состоит из нескольких зон доступности, которые в теории изолированы друг от друга, являются самостоятельным датацентрами, имеют самостоятельную сетевую инфраструктуру, электропитание и тому подобное. Есть несколько важных фактов, которые необходимо учесть при использовании регионов и зон доступности:
- Виртуальное оборудование это не реальное физическое оборудование.
Наши трехлетние наблюдения показали, что средний жизненный цикл виртуальной машины на EC2 — 200 дней. После этого шанс, что сервер уйдет на пенсию, сильно возрастает. И этот процесс непредсказуем: иногда тех. поддержка информирует нас заранее за 10 дней, о том, что машина будет выключена, иногда сообщение, о том, что машина будет выключена приходит через два часа после того как её выключили. Внезапно пропадающее оборудование не самая большая проблема — легко можно запустить новое, но важно учитывать этот факт и заранее потратить время на автоматизацию этого процесса, чтобы сэкономить время затрачиваемое на регулярный запуск нового оборудования. - Ваши сервера должны находиться в более чем одной зоне доступности и иметь все необходимые сервисы в обеих зонах. Наш опыт показал, что с большей вероятностью может отказать целая зона, чем отдельный сервер. Так что, если вы планируете использовать основной и резервный сервера в одной зоне доступности, в случае проблем с основным сервером вы потеряете и резервный из-за общих проблем в пределах всей зоной. ваша система в таком случае будет единой точкой отказа и вы не сможете ни востановить свои данные из резервной копии ни извлечь ваши файлы из серверов, так как при проблемах с зоной, вы даже не сможете увидеть ваши сервера, не то что извлечь из них какие-либо данные.
- Проблемы с несколькими зонами в пределах региона тоже случаются. Так что, если вы можете себе это позволить, используйте также разные регионы. US-East регион, который является самым популярным, потому что он самый старый и самый дешевый, испытывал проблемы в июне 2012, марте 2012 и самый сильный сбой был в апреле 2011, который был назван облачным апокалипсисом. Наше мнение по этому поводу, из-за которого мы возможно потеряем друзей в Amazon, нестабильная работа целых регионов случается довольно часто и случается она по одной и той же причине. Это привело нас к следующему решению.
Для обеспечения высокой надежности мы должны перестать доверять EBS.
Это тот пункт, в которым мы категорически не согласны с маркетологами Amazon и с их советами. Amazon предполагает, что использование EBS является основополагающим при пользовании EC2. Вы должны хранить все данные на EBS диске, вы можете его подключать к новым серверам, вы можете сделать снимок EBS диска для создания резервных копий базы данных и потом использовать его для восстановления. Amazon так же хочет, чтобы вы использовали EBS в качестве корневого дискового устройства системы, используя EBS-backed образы. EBS привнес нам несколько основных проблем:
- Скорость ввода-вывода на EBS неудовлетворительная
Скорость ввода-вывода на виртуальном оборудовании гораздо ниже, чем на чистом аппаратном оборудовании, но наш опыт показал, что производительность EBS гораздо ниже, чем производительность локальных дисков на виртуальной машине, которые Amazon называет ephemeral storage. EBS диски по существу являются сетевыми дисками. Производительность, которую следует ожидать от любого сетевого диска не очень большая. AWS также предоставляет диски с гарантированным количеством операций ввода-вывода, но они довольно дорогие и не подходят в качестве чуть более привлекательного компромисса. - EBS отказывает на уровне региона, а не на уровне отдельного диска.
Наш опыт показал, что EBS имеет две модели поведения: все диски доступны или все диски недоступны. Двое из трех отказов в рамках региона, которые были описаны ранее, были связаны с проблемами на уровне EBS, проблемы начались в одной зоне и распространились на другие. Если ваш план по восстановлению завязан на работу с EBS дисками, а отказ в работе обусловлен проблемами на уровне EBS, у вас ничего не выйдет, мы сталкивались с подобной проблемой несколько раз. - Проблемы с EBS на системе Ubuntu сказываются крайне тяжело: потому что EBS это сетевой диск, который эмулируется в системе под видом реального жесткого диска, это нарушает работу на уровне операционной системы. Это имело ужасные последствия для нас. Как только происходят проблемы с EBS — полностью недоступен весь сервер, к которому присоединен EBS диск, и это влияет на функциональность, которая никак не связана с дисковой активностью.
По этой причине, а так же по причине того, что наша основная цель это наибольшее время безотказной работы системы, мы полностью отказались от EBS около 6-ти месяцев назад. Мы потратили некоторое время на реализацию сложных операций, в основном связанных с резервным копированием и восстановлением, но это того стоило, учитывая увеличившееся время безотказной работы системы.
Будьте осторожны. Другие сервисы Amazon тоже могут использовать EBS.
Из-за того, что некоторые сервисы Amazon используют EBS, при проблемах на уровне EBS эти сервисы тоже недоступны. Это справедливо для балансировщика нагрузки ELB, сервиса баз данных RDS, сервиса облачных приложений Elastic Beanstalk и других.
Основываясь на нашем опыте, мы пришли к выводу, что при серьезных проблемах с Amazon, сервис EBS тоже почти всегда недоступен. Так что если EBS не работает, и вам нужно переключить балансировщик на другой регион, вы не сможете этого сделать, так как он завязан на EBS. Так же вы не сможете запустить новое оборудование, потому что консоль Amazon запущена на EBS. Так что мы любим EC2 и очень любим S3, но не используем никаких дополнительных сервисов.
Выгодной стороной нашего подхода является то, что мы легко можем переключиться на использование другого провайдера и не сильно привязываемся к AWS.
Уроки, которые мы извлекли.
Если бы мы стартовали awe.sm завтра, я бы использовал Amazon без лишних раздумий. Для стартапа с маленькой командой и с ограниченным бюджетом это то, что нужно, чтобы быстро стартовать. AWS на самом деле не предоставляет никакой угрозы, он не является чем-то страшным и плохим.
Такие IaaS провайдеры, как Joyent и Rackspace наступают на пятки Amazon: у нас есть хорошие друзья в обеих компаниях и мы собираемся сотрудничать с ними. Когда количество наших серверов вырастет с 100 до 1000, нам придется разнообразить нашу инфраструктуру этими провайдерами, а также такими, как Carpathia, которые используют AWS Direct Connect для предоставления услуг с низким временем доступа к AWS, что делает создание гибридных облачных инфраструктур более легким.
Я надеюсь, эта информация была полезна для вас.
Оригинал статьи: http://blog.awe.sm/2012/12/18/aws-the-good-the-bad-and-the-ugly/
Автор: Laurie Voss (seldo)
Автор: helldesigner
