Комментарии 21
эта количественная особенность становится качественной.
как только вы привыкнете к такому, вы начинаете это недооценивать.
истинные слова.
Будьте осторожны. Другие сервисы Amazon тоже могут использовать EBS.
не задумывался над этим. Выходит, что на надёжности EBS основывается надёжность других сервисов, а это уже «бутылочное горлышко» и повод опасаться падения сразу нескольких сервисов.
Вообще Amazon оперирует очень обтекамемыми понятиями о предоставляемых услугах, эдакое доверительное SLA, «поверьте, все будет более или менее работать». При информации о том, как именно работает инфраструктура Амазона далеко не исчерпывающая.
Гарантируемая производительность сетевого и дискового I/O вообще ни о чем. Гарантированного времени запуска инстанса нет, только относительные попугаи.
(Буквально на днях одна мастер-нода почему-то захлебнулась по сетевому I/O и проект лег. Потом также без каких либо предупреждений снова зашевелилась.)
Вообще Амазон, при всех его плюсах, не предоставляет вам никаких особых гарантий, ну кроме гарантрованного снятия денег. Это важно понимать.
Также Амазон вас поимеет на деньги при любой попытке построить вертикальную структуру. У вас есть большая и активно используемая реляционка? Тогда плохие новости, RDS — это очень дорого. Держать отдельные инстансы под БД — дорого. Организовать репликацию между зонами… лол, помните, у вас нет никакого внятного SLA, придется сегментировать данные.
Или у вас, допустим, достаточно типичный набор постоянно запущенных служб для среднего размера интернет проекта — кэши, брокер, деплой-сервер и так далее. Это будут неприятные статьи расходов. На любом постоянно запущенном инстансе вы теряете относительно содержания VPS-ок и обычных серверов у других не-облачных хостеров. И они будут работать не очень надежно. См весьма доходчивый текст поста.
Экономить вам предлагается за счет автомасштабирования. Если ваша нагрузка достаточно ровная — опять плохие новости. Если она у вас недостаточно большая — тоже.
Гарантируемая производительность сетевого и дискового I/O вообще ни о чем. Гарантированного времени запуска инстанса нет, только относительные попугаи.
(Буквально на днях одна мастер-нода почему-то захлебнулась по сетевому I/O и проект лег. Потом также без каких либо предупреждений снова зашевелилась.)
Вообще Амазон, при всех его плюсах, не предоставляет вам никаких особых гарантий, ну кроме гарантрованного снятия денег. Это важно понимать.
Также Амазон вас поимеет на деньги при любой попытке построить вертикальную структуру. У вас есть большая и активно используемая реляционка? Тогда плохие новости, RDS — это очень дорого. Держать отдельные инстансы под БД — дорого. Организовать репликацию между зонами… лол, помните, у вас нет никакого внятного SLA, придется сегментировать данные.
Или у вас, допустим, достаточно типичный набор постоянно запущенных служб для среднего размера интернет проекта — кэши, брокер, деплой-сервер и так далее. Это будут неприятные статьи расходов. На любом постоянно запущенном инстансе вы теряете относительно содержания VPS-ок и обычных серверов у других не-облачных хостеров. И они будут работать не очень надежно. См весьма доходчивый текст поста.
Экономить вам предлагается за счет автомасштабирования. Если ваша нагрузка достаточно ровная — опять плохие новости. Если она у вас недостаточно большая — тоже.
К сожалению, о том, что на самом деле стоит за сервисами Amazon приходиться только догадываться, вычислять экспериментальным путем, тестами или узнавать случайно из общение с их поддержкой.
Гарантии провайдера — в прошлом. Сейчас важна правильная отказоустойчивая архитектура и правильный финансовый подход.
RDS совсем недорогие при резевации. Например самый жирный инстанс Oracle с лицензией, в двух зонах, с 1,000 ГБ диском и 10,000 IOPS on-demand в месяц стоит:
744 * $3.140 + 1,000 * $0.250 + 10,000 * $0.20 = $4586.16 по идее не так уж и дорого в принципе для таких параметров.
А если зарезервировать эту машинку на 3 года, и 3 года её использовать, то будет:
($19,866 + 36 * ( 744 * $1.394 + 1,000 * $0.250 + 10,000 * $0.20) / 36 = $3838.96 — это ещё дешевле.
Напомню, что параметры такие:
High-Memory Quadruple Extra Large DB Instance: 68 GB of memory, 26 ECUs (8 virtual cores with 3.25 ECUs each), 64-bit platform, High I/O Capacity
В общем, если правильно подойти в к вопросу, можно сэкономить очень даже. В нашем варианте ~$750 в месяц, что составляет 15%. А можно и больше.
RDS совсем недорогие при резевации. Например самый жирный инстанс Oracle с лицензией, в двух зонах, с 1,000 ГБ диском и 10,000 IOPS on-demand в месяц стоит:
744 * $3.140 + 1,000 * $0.250 + 10,000 * $0.20 = $4586.16 по идее не так уж и дорого в принципе для таких параметров.
А если зарезервировать эту машинку на 3 года, и 3 года её использовать, то будет:
($19,866 + 36 * ( 744 * $1.394 + 1,000 * $0.250 + 10,000 * $0.20) / 36 = $3838.96 — это ещё дешевле.
Напомню, что параметры такие:
High-Memory Quadruple Extra Large DB Instance: 68 GB of memory, 26 ECUs (8 virtual cores with 3.25 ECUs each), 64-bit platform, High I/O Capacity
В общем, если правильно подойти в к вопросу, можно сэкономить очень даже. В нашем варианте ~$750 в месяц, что составляет 15%. А можно и больше.
За два месяца можно купить такой же по мощности сервер. Только единоразово и больше платить не надо.
Прикрутить этот сервер в стойку — стоит сравнительно копейки. Накладные расходы на администраторов плюсанем, но все равно выйдет дешевле, даже если такой сервер менять каждый год.
Так зачем платить дороже за что-то, что не дает гарантий? Как бизнесу объяснить, что вот мы сейчас накупим попугаев, но возможно что-то работать всегда не будет, а чтобы всегда работало — умножьте попугаев на три.
Да еще и подстраховываться, подпирая уже оплаченные сервисы своими, которые по старинке, но надежнее. Здесь уже можно вычесть из пункта «экономим на админе».
Прикрутить этот сервер в стойку — стоит сравнительно копейки. Накладные расходы на администраторов плюсанем, но все равно выйдет дешевле, даже если такой сервер менять каждый год.
Так зачем платить дороже за что-то, что не дает гарантий? Как бизнесу объяснить, что вот мы сейчас накупим попугаев, но возможно что-то работать всегда не будет, а чтобы всегда работало — умножьте попугаев на три.
Да еще и подстраховываться, подпирая уже оплаченные сервисы своими, которые по старинке, но надежнее. Здесь уже можно вычесть из пункта «экономим на админе».
Опять холиварим? Ок.
Интересны стратегии наращивания инфраструктуры в связи с праздниками или временем суток. Ну и как потом избавиться от лишнего незадействованного железа.
Интересны стратегии наращивания инфраструктуры в связи с праздниками или временем суток. Ну и как потом избавиться от лишнего незадействованного железа.
Вот только за этим лезть в облако амазона? Вы так говорите, как будто в облаке эта проблема действительно решена. Залил туда базу данных, а она сама как-нибудь автоматически размасштабируется.
Если качает широко, то действительно проблема. И одним облаком ее не решить. Надо чтобы ваш сервис еще был готов к качелям и к тому, что постоянно плавают ресурсы. Как объяснить базе данных, что надо реплицировать сейчас шустрее, а в час дня медленне?
Без проблем можно напихать только фронтендов. С бэкендами постоянная проблема. Запилился бекенд, я добавил новый, акей. А дальше-то что? Надо решить проблему синхронизации и разделяемого контента, обеспечить отсутствие splitbrains когда новый бекенд будет туда-сюда шастать. В итоге когда программисты допилят код для облака, это будет так долго и так дорого. А пока пилят, придется обходиться стандартными и проверенными полуавтоматическими методами.
Дешевле и надежнее все равно держать свой парк машин даже с двукратным запасом. Мы так делаем.
Другой вопрос, что открылся некий стартап. Сегодня на волне и туда толпой прилетел миллион уников, а завтра все разочаровались и никого больше нет. Тут, действительно проблема, как запуститься и как потом слить ненужное железо в случае провала. Я в такие ситуации попадал, ничего хорошего.
Если качает широко, то действительно проблема. И одним облаком ее не решить. Надо чтобы ваш сервис еще был готов к качелям и к тому, что постоянно плавают ресурсы. Как объяснить базе данных, что надо реплицировать сейчас шустрее, а в час дня медленне?
Без проблем можно напихать только фронтендов. С бэкендами постоянная проблема. Запилился бекенд, я добавил новый, акей. А дальше-то что? Надо решить проблему синхронизации и разделяемого контента, обеспечить отсутствие splitbrains когда новый бекенд будет туда-сюда шастать. В итоге когда программисты допилят код для облака, это будет так долго и так дорого. А пока пилят, придется обходиться стандартными и проверенными полуавтоматическими методами.
Дешевле и надежнее все равно держать свой парк машин даже с двукратным запасом. Мы так делаем.
Другой вопрос, что открылся некий стартап. Сегодня на волне и туда толпой прилетел миллион уников, а завтра все разочаровались и никого больше нет. Тут, действительно проблема, как запуститься и как потом слить ненужное железо в случае провала. Я в такие ситуации попадал, ничего хорошего.
Все правильно, Амазон хорошо подходит, чтобы обслуживать фактор роста, и если архитектура проекта учитывает все особенности. Рост — это очень важно. Но в остальных случаях стоит всерьез помучать калькулятор. В том числе и на косвенные расходы.
Например у меня время разработки одного из проектов было порядка 4-5 месяцев. Еще месяц недель уходит на грамотную инфрраструктуру на chef+puppet (вместо недели на грамотный fabric деплой) и еще месяц на то, чтобы сделать проект полностью независимым от инфраструктуры (хочешь кластер, хочешь — вертикалка). Неприятненько.
Всякие тривиальные проблемы вроде приема и индексации 5-8 гб файла с данными превращаются в ад, так как основные группы в целях экономии на спотах, а споты для этого не предназначены. Приходится городить отдельные надежные узлы, которые не сложатся в произвольное время. Упс, еще неделька на ровном месте возникла. Далеко не единственный случай, но характерный.
Например у меня время разработки одного из проектов было порядка 4-5 месяцев. Еще месяц недель уходит на грамотную инфрраструктуру на chef+puppet (вместо недели на грамотный fabric деплой) и еще месяц на то, чтобы сделать проект полностью независимым от инфраструктуры (хочешь кластер, хочешь — вертикалка). Неприятненько.
Всякие тривиальные проблемы вроде приема и индексации 5-8 гб файла с данными превращаются в ад, так как основные группы в целях экономии на спотах, а споты для этого не предназначены. Приходится городить отдельные надежные узлы, которые не сложатся в произвольное время. Упс, еще неделька на ровном месте возникла. Далеко не единственный случай, но характерный.
Например у Joyent SLA хотя-бы что-то гарантирует — joyent.com/company/policies/cloud-hosting-service-level-agreement
Есть понятие как Hybrid Cloud — когда основное железо DS (3 x mirror), а в пиках аллоцируется Public Cloud у провайдера — этот вариант наиболее эффективен по реальным тестам.
Есть понятие как Hybrid Cloud — когда основное железо DS (3 x mirror), а в пиках аллоцируется Public Cloud у провайдера — этот вариант наиболее эффективен по реальным тестам.
Мой опыт работы с облаками в т.ч. Амазоном говорит, что экономически выгодно использовать облака, только если ввиду особенностей вашей архитектуры у вас идут скачкообразные нерегулярные слабопредсказуемые нагрузки.
В случае же если вы можете планировать свои нагрузки Dedicated обходится в 2 и более раз дешевле. При этом вы получаете реальное физическое железо с конкретными параметрами. И единственное в чем вы теряете это время на установку нового сервера.
В проектах нашей компании мы посчитали что нам дешевле взять выделеные сервера в OVH или Hetzner, чем пользоваться облаком. Более того, даже если для резервирования взять в 2 раза больше серверов в разных датацентрах все равно будет дешевле.
В случае же если вы можете планировать свои нагрузки Dedicated обходится в 2 и более раз дешевле. При этом вы получаете реальное физическое железо с конкретными параметрами. И единственное в чем вы теряете это время на установку нового сервера.
В проектах нашей компании мы посчитали что нам дешевле взять выделеные сервера в OVH или Hetzner, чем пользоваться облаком. Более того, даже если для резервирования взять в 2 раза больше серверов в разных датацентрах все равно будет дешевле.
Не только для скачкообразной нагрузки, например, Amazon Simple DB очень хорошо подходит для хранения метаданных. Когда я просчитывал разные варианты, где мне хранить более 10 миллионов записей по 1kb каждая, оказалось, что в Simple DB это будет стоить всего 3 доллара в месяц. Любой более-менее надежный сервер стоил бы в разы дороже, да и еще бы требовал настройки и поддержки. А вот для фронтенда я AWS не стал использовать из-за дороговизны трафика.
> Скорость ввода-вывода на EBS неудовлетворительная
В Provisioned IOPS дисках вроде пофиксили.
В Provisioned IOPS дисках вроде пофиксили.
В Provisioned они как-им-то образом гарантируют уровень IOPS ± 10%, а обычный EBS может быть и лучше и хуже по производительности, зависит от нагруженности, размеров диска, погоды и кто еще знает чего. Насколько я понял из других статей EBS шарится между инстансами, от этого и скорость разная. Если взять диск 1TB то тогда можно будет достичь максимальной скорости в 1Gb, так как он полностью будет ваш.
На Cloud Harmony есть сервис сравнения производитеьлности различных облачных серверов. Так вот я недавно сравнивал EC2 с конкурентами и в соотношении цена/производительность он оказался чуть ли не самым тормознутым и почти самым дорогим.
Я чего не пойму: есть десятки более производительных и дешёвых облачных хостингов, что так всех заклинило на этом AWS?
Я чего не пойму: есть десятки более производительных и дешёвых облачных хостингов, что так всех заклинило на этом AWS?
А кто-нибудь скажет, что сейчас у Амазона с каналом связи до России?
На сколько вообще имеет смысл, если пользователи в основном российские?
p.s. мы проводили тестирование весной и смотрели европейский дата-центр — получали очень грустные цифры в плане скорости :(
На сколько вообще имеет смысл, если пользователи в основном российские?
p.s. мы проводили тестирование весной и смотрели европейский дата-центр — получали очень грустные цифры в плане скорости :(
Мы готовим исследование по производительности сети в пределах Амазона и от Амазона к различным конечным клиентам.
Раз вы тестировали, то значит и сами знаете — как. Оставляет желать лучшего, хотя во многих случаях его скорости будет достаточно. Но вообще, если пользователи российские, то вполне может выручить прокси в России с хорошим каналом на Европу.
3.84 рубля за Гб трафика… Я бы разорился :-D
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
AWS: Хороший, плохой, злой