На последнем РИФе я рассказывал об «облаке» как альтернативе традиционному хостингу (на примере Амазона).
С тех пор прошло несколько месяцев. За это время я многократно дискутировал как с ярыми противниками «облака», так и с не менее активными сторонниками.
Последний такой спор случился пару дней назад непосредственно с хостерами. И закончился (с их стороны) примерно таким выводом: «Сейчас облако в хостинге — маркетинговое зло, которое только путает людей».
Тема, как мне кажется, не просто популярная и интересная, но и очень важная. Поэтому я хотел бы обобщить свой собственный опыт (у меня есть несколько личных сайтов на виртуальном shared хостинге, периодически по знакомству присматриваю за одним дедиком, а все рабочие проекты размещены в «облаке» Амазона) и вместе с вами постараться разобраться во всех плюсах и минусах облачного хостинга по сравнению с традиционным.
Говоря в целом о традиционном хостинге, я буду подразумевать любое размещение веб-проектов – чаще VPS, colo или dedicated и чуть в меньшей степени шаред хостинг.
Под «облаком» я в общем случае буду иметь в виду IaaS (Infrastructure as a Service) – «предоставление компьютерной инфраструктуры (как правило в форме виртуализации) как услуги на основе концепции облачных вычислений» (Wikipedia).
(Вообще, обещаю в тексте пореже употреблять разные «...aaS» :) «Облако» — звучит позитивнее, а для конечных пользователей создается хотя бы видимость понятности того, о чем идет речь. Хотя и этот термин уже «замусорен».)
Для потребителя «облако» — это любая вычислительная структура, предоставляемая как сервис по его запросу или автоматически.
С точки зрения провайдера это:
- Аппаратные ресурсы (серверы, сетевое оборудование, системы хранения данных, каналы связи и т.д.)
- Системное ПО (виртуализация)
- Управляющее ПО (биллинг, API и т.д.)
Едва ли не самый частый и самый активно использующийся посыл к переходу на «облака» вообще (и IaaS – в частности) – уменьшение затрат и экономия.
И в этом, как мне кажется, состоит очень большая и серьезная ошибка «облачных» маркетологов.
Давайте попробуем разобраться, есть ли эта самая экономия, и в чем она.
Табличка ниже – сравнение некоторой типовой конфигурации VPS «традиционных» хостеров и виртуальных машин в облаке: приблизительно 800 Mhz CPU, 512 Mb RAM. (Обычный shared хостинг в данном случае не берем в расчет, так как не сможем оценить выделенные ресурсы. Как бы ни лимитировали хостеры те или иные ресурсы, все равно обычный хостинг – это общежитие: кто первый встал – того и тапки.)
Цены — в у.е. (похожие на доллары :)).
Сравнение это не идеально, не следует его использовать как серьезный ориентир при выборе провайдера. Например, у некоторых хостеров нет строго той конфигурации, которую сравниваем мы, поэтому – выбираем ближайшую похожую.
Цель таблички – показать лишь соотношение цен. «Облако» в среднем в полтора-два раза дешевле.
Если же взять для сравнений более «взрослые» конфигурации, например, арендованных физических серверов и аналогичных по мощности виртуальных машин, то мы получим примерно похожее соотношение.
Вроде бы – дешевле, но...
Мы начинаем работать в облаке и сталкиваемся с такими (не самыми очевидными на первый взгляд) сложностями:
- Почти всегда отдельно рассчитывается стоимость траффика.
- Мы (возможно, впервые в жизни) начинаем сталкиваться с таким понятием как «расчеты по потреблению»: если наша виртуальная машина не с жесткой фиксированной ценой, то мы платим за потребленное процессорное время, использованную память; в любом случае – сталкиваемся с таким понятием как IOPS (Input-Output Operations Per Second) – и платим за это.
- При оплате «по потреблению» при резком росте нагрузки (DDoS, «хабраэффект», ошибки в разработке) возможны значительные расходы (в разы больше запланированных).
Где же реальная экономия?
На самом деле, мы не напрямую сокращаем текущие расходы, а оптимизируем несколько иные процессы.
Нет инсталляционных платежей
Для больших проектов – если речь идет о покупке собственного оборудования – больше не нужно выделять значительные средства из бюджета.
Из этого пункта автоматически следует еще одно важное преимущество «облака»:
Минимальные финансовые риски на старте нового проекта
Если вы запускаете новый стартап, то не можете заранее гарантированно знать, взлетит он или нет. «Пошел» проект – отлично, все вложения (в том числе в инфраструктуру) будут окуплены.
А если нет? И вы при этом уже потратились на серверы, софт, заплатили зарплату тем сотрудникам, которые занимались разворачиванием всей инфраструктуры?
В «облаке» вы рискуете только абонентской платой за тот период, в течение которого обслуживалась ваша виртуальная инфраструктура.
Потери в случае неудачи не столько велики (а зачастую – вообще минимальны). И они не отобьют у вас желания реализовывать новые идеи и запускать новые стартапы. :)
Человеческие ресурсы для обслуживания системы
Если речь идет о большом парке машин (десятки-сотни-тысячи), то в виртуальной среде обслуживать их гораздо легче. Компания Microsoft рассказывала о собственном опыте: один системный администратор может обслуживать в «облаке» в десять (и более) раз больше машин, чем реальных физических серверов.
Экономия времени
Любые сервисные работы (добавление дисков в серверы, добавление новых машин и т.п.) в «облаке» будут выполнены быстрее.
* * *
А теперь давайте попробуем разобраться, есть ли у «облака» другие (возможно, даже более очевидные) преимущества?
Must have любого по-настоящему хорошего проекта – регулярные нагрузочные тесты (как перед запуском, так и в процессе работы – на стендах). Нагрузочное тестирование позволяет определить предел работоспособности созданного проекта именно на выбранном оборудовании и дает примерную оценку — когда потребуется масштабирование тех или иных ресурсов.
А иногда масштабирование нужно внезапно! :)
Например, живет себе в сети сайт, посвященный шахматам. И заходит на него 1-2 тыс. человек в день. И тут «внезапно» и непредсказуемо случается шахматный турнир. Посещаемость вырастает в разы, а администратор оказывается не готов к подобной нагрузке.
Оба этих проекта – и «сферический идеальный веб-сайт», и наш шахматный сервер объединяет одно: любое масштабирование потребует времени на выделение новых ресурсов, на перенос проекта на более мощное оборудование и т.п. Во время этих работ (если переезд внезапный) сайт, скорее всего, будет недоступен для посетителей. А это все — деньги владельца проекта.
Следующий момент. Рано или поздно мы упираемся в потолок: мы не можем наращивать мощность сервера неограниченно. К тому же с ростом мощности сервера его стоимость растет не пропорционально. И тут мы переходим к горизонтальному масштабированию (если поддерживает архитектура проекта) – наращиваем не мощности одного сервера, а добавляем новые машины.
И наконец, последний крайне важный момент – обратное масштабирование, чтобы ресурсы не работали вхолостую, и чтобы мы не думали о том, куда деть незадействованные серверы. Шахматный турнир идет не круглый год. Через некоторое время ресурсы, выделенные на пиковую посещаемость оказываются невостребованными (до следующего столь же значимого события).
Масштабирование в «облаке» — простая, понятная и чрезвычайно легкая операция!
- Увеличение ресурсов виртуальной машины доступно моментально.
- Столь же моментально доступно не только вертикальное, но и горизонтальное масштабирование (можно получить практически любое количество виртуальных машин нужной конфигурации).
- После того, как отпадает необходимость в большом количестве ресурсов, мы просто отказываемся от них и перестаем за них платить.
Моментальная доступность любых ресурсов – вообще одно из важнейших преимуществ «облака».
Живой пример, с которым мне как-то довелось столкнуться на практике – срочная необходимость переноса большого «тяжелого» проекта (который жил на отдельном выделенном физическом сервере) в другой датацентр 7-го января.
В нашей стране Новый год отмечают с размахом. И работают в новогодние каникулы лишь те проекты, которым посчастливилось не столкнуться с проблемами в тот период, когда вся страна пьет и гуляет.
Итог обзвона полутора десятков российских хостеров, который предлагают услуги dedicated / colocation: можно разместить свой проект только на типовой стандартной конфигурации, которая уже есть в прайс-листе. И то – только по знакомству. И в лучшем случае — в течение суток. А что-то нестандартное и тем более быстрее – не получится… :(
Итог – проект перенесен в «облако» Амазона.
Напоследок хочу немного поговорить о надежности размещения проектов в «облаке».
Часто слышу такой тезис: облако надежнее.
На мой взгляд, он вводит пользователей в заблуждение и в итоге работает только против.
Не «облако надежнее», а «облако» дает гораздо больше возможностей построить надежную инфраструктуру.
1. Почти все серьезные «облачные» провайдеры владеют несколькими датацентрами, что позволяет им резервировать (на своем уровне) практически все ресурсы. Для конечных пользователей это дает возможность разместить свой веб-проект не на одном виртуальном сервере, а на веб-кластере, состоящем из нескольких резервирующих друг друга серверов, расположенных в разных датацентрах.
Если же нет возможности (например, дорого) постоянно держать полную копию проекта, можно использовать значительно более слабую машину, например, под бэкап данных и базы (например, slave MySQL). В случае аварии проект на резервном сервере быстро переводится в рабочий режим, а сам сервер масштабируется до нужного количества доступных ресурсов (память, CPU и т.д.)
2. Многие «облачные» провайдеры предлагают специализированные облачные хранилища для статического контента (например, Amazon S3).
Они на самом деле надежны, так вся их архитектура такова, что уже непосредственно в ней заложено резервирование на уровне датацентра.
Перенос статического контента в такое хранилище позволяет минимизировать размер и время создания бэкапов. Соответственно – минимизировать и время их разворачивания в случае какой-либо аварии.
3. Те же бэкапы – можно хранить в том же облачном хранилище.
Во-первых, подобные хранилища – дешевые. Это позволяет создавать бэкапы часто и хранить их достаточно долго. Во-вторых, хранилище, которое не зависит от самих виртуальных машин, обеспечивает доступность бэкапов даже в случае самых серьезных аварий и невероятных случаях – даже если в датацентр попадает молния.
Если же проект размещается в одном датацентре на одном или нескольких физических серверах, то в случае аварии (обесточен датацентр):
- У владельца нет доступа к данным. Вообще. Остается только ждать, когда авария будет ликвидирована.
- Если нет возможности ждать (крайне критична доступность сервиса) — нужно брать данные из бэкапа. Из какого? Как и куда его делать? В другой датацентр?
- Отдельный вопрос – в какой другой датацентр переезжать во время аварии. Найти сервер нужной конфигурации (как мы уже разбирали выше) – не самая тривиальная задача. Требующая времени.
- Переехали. Надо менять DNS. Это – опять время. В случае использования «облака», у которого есть несколько датацентров, можно просто «перевесить» прежний IP на новую машину.
* * *
Давайте резюмируем.
Минусы «облака»:
- Не является альтернативой хостингу за 200-300 руб./мес.
- Затраты (время) на обучение сотрудников специфике конкретного сервиса
- Ограничения инфраструктуры (аппаратная часть, специфичное ПО)
- Сложность расчетов «по потреблению»
Плюсы «облака»:
- Экономия за счет возможности планирования ресурсов
- Экономия и отсутствие рисков, связанные с вложениями в инфраструктуру
- Моментальное вертикальное и горизонтальное масштабирование
- Удобство администрирования
- Экономия времени
- Дополнительные сервисы
Кстати, именно дополнительные сервисы зачастую являются одним из факторов, по которым в итоге выбирается «облачный» провайдер.
Возможность размещения в разных датацентрах, множество готовых образов операционных систем, обеспечение доступности в SLA, гибкие конфигурации дисков, «облачные» базы данных, «облачный» кэш данных, конфигурирование файрволла через веб-интерфейс для групп машин, создание копий виртуальных машин и т.д. и т.п.
Масса возможностей для «облачных» провайдеров для конкуренции и привлечения клиентов. :)
* * *
Закончу я свой пост цитатой Брета Тейлора, ныне — технического директора Facebook, а немного ранее — сооснователя FriendFeed: «Когда мы только начинали работу над стартапом (FriendFeed), нам нужно было решить, покупать собственные серверы или же выбрать одного из «облачных» хостинг-провайдеров – таких как Amazon (AWS). Мы выбрали первое – решили приобрести собственные серверы. Оглядываясь назад, я думаю, что это было большой ошибкой.»
