Предыдущая запись | Следующая запись
Мы решили работать с Amazon Elastic Compute Cloud (EC2). Это удивительный "хостинг", позволяющий арендовать некоторое число компьютеров из вычислительной сети с почасовой оплатой за использование самих машин и оплатой сетевого трафика "по факту".
Машины можно заказывать в том числе програмно - можно написать программу, которая будет самостоятельно подключать к работе новые компьютеры и что-то на них запускать или останавливать их, если они уже не нужны.
Новые машины оказываются в вашем распоряжении в считанные минуты - при том что для традиционных видов хостинга добавление новой машины как правило занимает несколько дней (лучший результат о котором я слышал - 4 часа). Ну и конечно оплата в традиционном варианте будет не почасовая, скорее вам предложат оплатить как минимум месяц.
EC2, как и другие веб-сервисы компании Amazon, меня весьма впечатлил. Amazon оказалась компанией, у которой есть чему поучиться даже таким крутым ребятам как Google. В то время как Google только начинает пытаться продавать свои вычислительные мощности (взгляните на Google App Engine), Amazon давно и успешно это делает.
Что нам дает Elastic Cloud:
- Отличный тестовый стенд - где еще нам дадут запустить десяток-другой машин на несколько часов для тестирования?
- Готовая к росту, легко расширяемая инфраструктура - минимум головной боли по части администрирования
- Естественный доступ к другим интересным сервисам, таким как Simple Storage (S3), Simple Queue Service (SQS) и еще не доступного для общего использования, но уже вовсю тестируемого SimpleDB
Резюмирую: EC2 дает возможность не париться о куче вещей, быстро действовать, пробовать, развиваться.
Однако, если у вас не безумный стартап на стадии взрывного роста (а даже если и он), рекомендую подходить к вопросу об использовании EC2 осторожно и взвешенно. Жизнь в облаке не только дает много удивительных возможностей, но и влечет за собой появление непростых аспектов, которых вне облака попросту бы не было. Вот лишь некоторые из них:
- Как только одна из ваших машин останавливается (специально или в результате сбоя) вы теряете все что на ней было. Учитывая, что потенциально любая машина может дать сбой, это очень серьезное заявление.
- Облако предоставляет ограниченный выбор типов машин по составу железа, добавить что-то своей особой конфигурации невозможно. Поставить какую-нибудь свою железку невозможно. Выкручивайтесь тем что есть.
- Все машины работают в едином сетевом пространстве. Гоняете важные данные с машины на машину? - Шифруйте!
Список можно продолжить. :-)
В общем, использовать EC2 для небольшого сайта - скорее всего перебор. Но если вы строите масштабируемую систему, которой предстоит расти до гигантских размеров, то специфика облака это как раз то, что ждет вас в будущем - более или менее отдаленном. Так что в нашем случае эти особенности помогают с самого начала строить систему правильно, не расчитывать на полностью контролируемое и вроде как "долгоживущее" железо, а опираться на облако. :-)
Машины можно заказывать в том числе програмно - можно написать программу, которая будет самостоятельно подключать к работе новые компьютеры и что-то на них запускать или останавливать их, если они уже не нужны.
Новые машины оказываются в вашем распоряжении в считанные минуты - при том что для традиционных видов хостинга добавление новой машины как правило занимает несколько дней (лучший результат о котором я слышал - 4 часа). Ну и конечно оплата в традиционном варианте будет не почасовая, скорее вам предложат оплатить как минимум месяц.
EC2, как и другие веб-сервисы компании Amazon, меня весьма впечатлил. Amazon оказалась компанией, у которой есть чему поучиться даже таким крутым ребятам как Google. В то время как Google только начинает пытаться продавать свои вычислительные мощности (взгляните на Google App Engine), Amazon давно и успешно это делает.
Что нам дает Elastic Cloud:
- Отличный тестовый стенд - где еще нам дадут запустить десяток-другой машин на несколько часов для тестирования?
- Готовая к росту, легко расширяемая инфраструктура - минимум головной боли по части администрирования
- Естественный доступ к другим интересным сервисам, таким как Simple Storage (S3), Simple Queue Service (SQS) и еще не доступного для общего использования, но уже вовсю тестируемого SimpleDB
Резюмирую: EC2 дает возможность не париться о куче вещей, быстро действовать, пробовать, развиваться.
Однако, если у вас не безумный стартап на стадии взрывного роста (а даже если и он), рекомендую подходить к вопросу об использовании EC2 осторожно и взвешенно. Жизнь в облаке не только дает много удивительных возможностей, но и влечет за собой появление непростых аспектов, которых вне облака попросту бы не было. Вот лишь некоторые из них:
- Как только одна из ваших машин останавливается (специально или в результате сбоя) вы теряете все что на ней было. Учитывая, что потенциально любая машина может дать сбой, это очень серьезное заявление.
- Облако предоставляет ограниченный выбор типов машин по составу железа, добавить что-то своей особой конфигурации невозможно. Поставить какую-нибудь свою железку невозможно. Выкручивайтесь тем что есть.
- Все машины работают в едином сетевом пространстве. Гоняете важные данные с машины на машину? - Шифруйте!
Список можно продолжить. :-)
В общем, использовать EC2 для небольшого сайта - скорее всего перебор. Но если вы строите масштабируемую систему, которой предстоит расти до гигантских размеров, то специфика облака это как раз то, что ждет вас в будущем - более или менее отдаленном. Так что в нашем случае эти особенности помогают с самого начала строить систему правильно, не расчитывать на полностью контролируемое и вроде как "долгоживущее" железо, а опираться на облако. :-)
- Где:дома
- Настроение:
calm


Comments
Респект!
Спасибо! :-)
Чем может быть полезна SQS пока не вижу. Если появятся задачи, куда она хороша ляжет - конечно будем использовать. :-)
Ну а SQS - отличный механизм коммуникации. Именно то, чего обычно не хватает для построения распределенных систем и что каждый разработчик сам заново изобретает. А по поводу задач, то SQS будет полезна для:
- балансировки нагрузки (распределения пользователей\задач)
- общения с инфраструктурными службами (бекап, подсчет какой-нить статистики)
- извещения серверов об изменени состояния системы (упала\появилась новая БД, пофикшен баг - обновить бинарники)
Сам жду как limited beta закончится. Если б не limited beta то перевел бы свой сервис на EC2. Пока только систему бекапов перевел.
Ждем вместе? :-)
Просто те задачи, которые мы решаем прямо сейчас (до которых успели добраться) пока этой штуки не требуют. Как потребуют - прикрутим. :-)
Кстати, для извещения о событиях, которые возникают не очень часто, а реагировать надо быстро (типа падения БД) SQS не очень подходит, т.к. либо придется слишком часто ее опрашивать, либо узнаем о событии слишком поздно. Разве что использовать SQS как временное хранилище, а само извещение как-то отдельно.
Окончания limited beta мы не ждем. В первом варианте используем mnesia (распределенная БД Эрланга), а там посмотрим. Может перейдем на SimpleDB, а может прикрутим mnesia к S3... Впрочем, об этом напишу отдельный пост. :-)
Кстати, а что у тебя за сервис?
Да, про БД может не самый лучший пример. На днях выложили документ http://developer.amazonwebservices.c
Тоже на ерланг в последнее время смотрю. Пока не использую.
Сервис - http://who.hasfiles.com
Спасибо за ссылочку на документ с примерами :-)
Сервис у вас прикольный. :-)
Я и не подозревал что современные операционки могут работать с WebDav без установки дополнительного софта.
Современные ОС много что могут если напильником обработать :-)
- Таймаут должен быть в несколько раз (а лучше на порядок-другой) выше средней длительности обработки
- Таймаут должен быть не слишком большим, чтобы пользователь устал ждать и ушел
Как правило, это легко достижимо, т.к. секунды, которые готов ждать пользователь - это довольно много для большого круга задач. А там где задачи подлиннее, пользователь будет готов ждать и дольше.
Если не успел обработать - тупо обрабатывать повторно. Тут скорее вопрос в том чтобы обработчики не подрались за ресурсы + учесть вероятность появления "мусорных" данных.
Надо учитывать, что отваливание по таймауту - очень редкое событие, а ложное отваливание по таймауту (когда старый обработчик продолжает работать) - еще более редкое. Кстати, можно научить его помирать, если не уложился - тогда уходит проблема конфликта.
В идеале можно пытаться расчитывать таймауты на базе ран-тайм статистики, но для большинства задач это будет перебор. :-)