Обычный виртуальный хостинг хорош именно тем, что о нем почти не приходится думать. Купили тариф, добавили домен, установили CMS, создали базу данных — сайт работает. Не нужно самостоятельно обновлять операционную систему, следить за веб-сервером или решать, сколько памяти выделить базе.
Для блога, корпоративного сайта, небольшого интернет-магазина и многих других проектов этого хватает надолго. Иногда — на весь срок жизни сайта.
Но по мере роста появляется неприятная ситуация. Тариф вроде бы еще подходит, дискового пространства достаточно, а сайт периодически начинает тормозить. Во время рекламной кампании страницы открываются медленнее. Импорт каталога приходится запускать ночью. Появляются ограничения на процессорное время, память или количество одновременно выполняемых процессов.
Первая мысль обычно проста — нужен тариф помощнее.
Иногда этого действительно достаточно. Но бывает момент, когда дальнейшее увеличение обычного хостинга уже не решает главную проблему. Проекту становится нужна инфраструктура, ресурсы которой можно менять значительно свободнее.
И здесь появляется облако.
Важно только не воспринимать облачный хостинг как автоматическую следующую ступень после виртуального. Маленькому сайту облако может вообще ничего полезного не дать. А для другого проекта возможность быстро получить дополнительные вычислительные ресурсы окажется важнее разницы в стоимости услуг.
Разберемся, где проходит эта граница.
Виртуальный хостинг ограничивает не только место на диске
Когда владельцу сайта говорят об ограничениях тарифа, первым обычно вспоминают гигабайты.
На практике дисковое пространство далеко не всегда становится первым узким местом.
На одном физическом сервере виртуального хостинга находятся сайты разных клиентов. Провайдер должен распределять ресурсы так, чтобы один проект не мог забрать процессор и оперативную память всей машины.
Поэтому у тарифов появляются ограничения CPU, RAM, процессов, времени выполнения скриптов, подключений к базе и других ресурсов.
Это нормальное устройство услуги.
Проблема начинается тогда, когда сайт регулярно приближается к этим границам. Причем свободные гигабайты на диске никак не помогают, если PHP-процессы упираются в лимит памяти или приложение создает слишком большую нагрузку на процессор.
Перед переездом стоит сначала посмотреть, какое именно ограничение мешает проекту.
Один медленный сайт еще не означает что вам нужно облако
Это очень важный момент.
Если WordPress открывает страницу пять секунд, перенос в облако не должен быть первым способом лечения.
Причиной может оказаться тяжелый плагин, неоптимизированная тема, огромные изображения, медленные запросы к базе, внешний сервис, ошибка кэширования или вредоносный код.
Более мощная инфраструктура способна временно скрыть проблему. Плохой запрос к базе начнет выполняться быстрее на более производительном сервере, но хорошим от этого не станет.
Поэтому сначала полезно определить причину замедления.
Если сайт тормозит даже при небольшой нагрузке, стоит проверить само приложение. Если в спокойные часы он работает быстро, а проблемы появляются именно при росте числа одновременных посетителей, вопрос инфраструктуры становится намного интереснее.
Облако имеет смысл использовать для масштабирования нормального приложения, а не как дорогой способ не заниматься его оптимизацией.
Первый хороший сигнал для облака — нагрузка стала непредсказуемой
Представим обычный интернет-магазин.
Большую часть недели его посещаемость относительно стабильна. Затем запускается рекламная кампания, приходит рассылка или начинается сезонный спрос. За короткое время количество посетителей увеличивается в несколько раз.
Через несколько часов нагрузка снова становится обычной.
Для виртуального хостинга такие скачки неудобны. Тариф выбирается заранее, а доступные ресурсы ограничены его условиями.
Можно постоянно оплачивать более мощный тариф с большим запасом. Но значительная часть ресурсов тогда нужна только несколько часов или дней.
Облачная инфраструктура интересна тем, что вычислительные ресурсы можно изменять под текущую потребность. В более сложной архитектуре нагрузку можно распределять между несколькими экземплярами приложения.
Именно переменная нагрузка является одним из самых понятных аргументов в пользу облака.
Но возможность масштабирования не означает что оно произойдет само
В рекламе облачных платформ иногда создается ощущение, что сайт просто переносится «в облако», после чего инфраструктура автоматически становится бесконечной.
Так это не работает.
Если приложение находится на одной виртуальной машине, увеличение ресурсов этой машины остается вертикальным масштабированием. Ей можно добавить CPU или RAM, если платформа и выбранная конфигурация это позволяют.
Автоматическое горизонтальное масштабирование сложнее. Для него приложение должно уметь работать одновременно на нескольких машинах.
Нужно решить, где хранятся пользовательские файлы, сессии и база данных. Понадобится распределение запросов между экземплярами. Состояние приложения нельзя бездумно хранить на локальном диске одной машины.
То есть настоящее облачное масштабирование — это не только функция хостинга, но и свойство архитектуры проекта.
Для обычного сайта такая сложность может быть совершенно лишней.
Интернет-магазин часто становится кандидатом на переход раньше блога
У информационного сайта значительную часть нагрузки можно снять кэшированием.
Если статья одинакова для всех посетителей, готовая страница может отдаваться без повторного выполнения тяжелой серверной логики.
У интернет-магазина больше динамики.
Корзина, авторизация, оформление заказа, остатки, персональные данные, фильтры, поиск, импорт товаров и синхронизация с внешними системами создают работу, которую нельзя целиком заменить статическим кэшем.
Кроме посетителей существуют фоновые процессы.
Ночью магазин может импортировать каталог, обновлять цены и создавать резервную копию. Утром начинается синхронизация остатков. Днем приходит трафик из рекламы.
В какой-то момент владельцу становится неудобно размещать все это в рамках одного обычного тарифа.
Облако позволяет разделять компоненты и масштабировать их независимо, но делать это нужно тогда, когда такая архитектура действительно решает существующую проблему.
Иногда сайту нужен не облачный хостинг а обычный VPS
Между виртуальным хостингом и сложной облачной инфраструктурой существует очень удобный промежуточный вариант — VPS.
На виртуальном сервере пользователь получает собственную операционную систему и выделенную конфигурацию виртуальной машины. Можно самостоятельно настроить веб-сервер, PHP, базу, Redis, Docker и другие компоненты.
Для многих выросших сайтов этого более чем достаточно.
Если нагрузка относительно стабильна, а проблема обычного хостинга заключается в ограничениях или невозможности установить нужное программное обеспечение, VPS часто оказывается проще облака.
Особенно если весь проект нормально помещается на одной машине.
Поэтому правильный вопрос после виртуального хостинга звучит не «какое облако выбрать», а «что именно мне стало невозможно делать на текущем хостинге».
Ответ часто сразу показывает, нужен VPS или уже действительно стоит смотреть на облачную архитектуру.
Облако интересно когда компоненты сайта хочется разделить
На обычном хостинге пользователь редко задумывается, где физически находится MySQL относительно PHP. Провайдер предоставляет готовую среду.
На собственном сервере приложение и база тоже часто устанавливаются вместе.
По мере роста это перестает быть единственным вариантом.
Веб-приложение может работать на одних виртуальных машинах, база — на другой инфраструктуре, файлы храниться отдельно, а статический контент раздаваться через CDN.
Так каждый компонент можно развивать независимо.
Если база требует больше памяти, не обязательно увеличивать ресурсы всех веб-серверов. Если вырос трафик приложения, можно добавить вычислительные экземпляры, не перенося базу.
Для маленького сайта это выглядит как ненужное усложнение. Для крупного сервиса — как возможность перестать масштабировать всю систему одним большим сервером.
Объектное хранилище может снять с сервера огромный объем файлов
Сайты постепенно накапливают изображения, документы, архивы, видео и другие пользовательские файлы.
Хранить их на диске веб-сервера удобно, пока сервер один.
Когда экземпляров приложения становится несколько, появляется вопрос: какой из них содержит правильную версию файла?
Объектное хранилище решает эту задачу иначе. Файлы существуют отдельно от вычислительных машин, а приложение обращается к ним как к самостоятельному сервису.
Это упрощает замену и масштабирование веб-серверов.
Но переносить медиатеку небольшого корпоративного сайта в отдельное объектное хранилище только ради слова «облако» необязательно. Польза появляется вместе с реальной потребностью в независимом хранении данных.
CDN и облако решают разные задачи
Эти технологии иногда смешивают.
CDN хранит копии статического контента в распределенной сети и отдает их пользователям с подходящих узлов. Это уменьшает нагрузку на основной сервер и может ускорить доставку изображений, стилей, скриптов и других файлов.
Облако предоставляет вычислительные и другие инфраструктурные ресурсы.
Одно не заменяет другое.
Более того, обычный сайт на виртуальном хостинге вполне может использовать CDN, не переезжая в облако. Иногда этого уже достаточно, чтобы заметно снизить нагрузку и ускорить отдачу тяжелой статики.
Поэтому сначала стоит понять, что именно стало узким местом.
Отказоустойчивость не появляется от одного слова cloud
Еще один распространенный миф — считать любой облачный сервер автоматически отказоустойчивым.
Одна виртуальная машина остается одной виртуальной машиной.
Если приложение работает только на ней и по какой-либо причине экземпляр недоступен, сайт тоже может перестать работать.
Облачная платформа дает инструменты, из которых можно построить более устойчивую систему: несколько экземпляров, балансировку, репликацию, резервирование и распределенное хранение.
Но архитектуру все равно нужно спроектировать.
Это принципиальное отличие между «сервер находится в облаке» и «сервис построен с учетом отказов отдельных компонентов».
Для проекта, которому действительно критична доступность, смотреть нужно на всю схему, а не только на название услуги.
Резервные копии нужны и в облаке
Переезд с обычного хостинга иногда создает ложное ощущение, что теперь данные защищены инфраструктурой облачного провайдера.
Отказоустойчивое хранилище защищает от одних сценариев, но не от всех.
Пользователь может удалить данные. Приложение может повредить базу. Ошибочная миграция способна изменить тысячи записей. Скомпрометированная учетная запись может дать злоумышленнику доступ к рабочей инфраструктуре.
Поэтому резервное копирование остается отдельной задачей.
Копии желательно хранить так, чтобы проблема рабочего окружения не уничтожила их вместе с основными данными.
И периодически проверять восстановление. Сам факт наличия файла с названием backup еще не гарантирует, что из него получится вернуть сайт.
Облако особенно полезно проектам которые быстро меняются
Есть сайты, нагрузку которых довольно легко прогнозировать.
Корпоративный ресурс годами получает примерно одинаковое количество посетителей. Иногда публикуется новая страница, меняются фотографии, но инфраструктура остается прежней.
Есть другой тип проектов.
Запускаются новые сервисы, появляются мобильные приложения, API, фоновые обработчики, очереди, аналитика, новые базы и интеграции. Сегодня требуется одна машина, через месяц — несколько разных компонентов.
Для таких проектов ценность облака заключается не только в производительности.
Главное преимущество — возможность сравнительно быстро создавать и изменять инфраструктуру.
Новый сервер не обязательно заказывать как отдельную физическую машину. Его можно создать программно. Инфраструктуру можно описывать конфигурацией, автоматизировать развертывание и повторять окружение.
Чем активнее развивается техническая часть проекта, тем важнее становится такая гибкость.
Для небольшого сайта облако может оказаться сложнее чем нужно
Технологически интересное решение не всегда является хорошим решением для конкретного бизнеса.
Если на сайте несколько десятков страниц, одна база и стабильная посещаемость, обычный качественный хостинг может выполнять задачу прекрасно.
Владельцу не нужно думать о виртуальных сетях, балансировщиках, политиках доступа, образах серверов и стоимости отдельных компонентов.
Провайдер уже собрал все в одну услугу.
Переезд в облако в таком случае способен увеличить не столько производительность, сколько количество вещей, за которыми нужно следить.
Именно поэтому простота виртуального хостинга является его преимуществом, а не недостатком.
Облачный счет сложнее обычного тарифа
На виртуальном хостинге обычно понятно, за что платит пользователь. Есть тариф с набором возможностей и период оплаты.
В облачной инфраструктуре стоимость может складываться из нескольких частей.
Вычислительные ресурсы, диски, снимки, резервные копии, публичные IP, исходящий трафик, балансировщики, базы данных и объектное хранилище могут учитываться отдельно.
Это дает гибкость, но требует контроля.
Особенно важно следить за ресурсами, которые больше не используются. Тестовая виртуальная машина забыта, старый диск остался подключенным, снимки продолжают храниться — каждый отдельный элемент может казаться мелочью, но вместе они влияют на итоговые расходы.
Поэтому облако требует не только технического, но и финансового мониторинга.
Перед переездом полезно неделю посмотреть на текущий хостинг
Необязательно гадать, чего не хватает сайту.
Если хостинг предоставляет статистику ресурсов, посмотрите на нее в течение обычной недели и во время пиков.
Интересны загрузка процессора, потребление памяти, дисковые операции, количество процессов, обращения к базе, сетевой трафик и срабатывания ограничений тарифа.
Отдельно запишите моменты, когда пользователи замечали замедление.
Если проблема появляется каждый день в одно и то же время, возможно, виноват cron или резервное копирование. Если она совпадает с рекламными всплесками, вероятнее влияние посетителей.
Такая статистика поможет подобрать новую инфраструктуру значительно точнее, чем совет «берите облако с запасом».
Не переносите сайт пока не понимаете куда он переезжает
Облако — слишком широкое понятие.
Можно создать одну облачную виртуальную машину и фактически получить аналог VPS. Можно построить несколько серверов за балансировщиком. Можно использовать управляемую базу и объектное хранилище. Можно вынести только один компонент существующего проекта.
Поэтому перед миграцией нужна хотя бы простая схема.
Где работает приложение? Где находится база? Где хранятся файлы? Как создаются резервные копии? Что произойдет при отказе одного компонента? Как сайт будет масштабироваться?
Если ответы пока отсутствуют, переезд лучше не начинать.
Иначе можно перенести старую архитектуру в более сложную среду и получить те же проблемы вместе с новыми расходами.
Сам переезд лучше делать без резкого отключения старого хостинга
Рабочий сайт не стоит переносить по принципу «удалили здесь, загрузили туда».
Сначала создается новое окружение. На нем устанавливается приложение, переносится база и проверяются необходимые сервисы.
Сайт тестируется до переключения домена.
Для динамического проекта отдельно продумывается финальная синхронизация данных. Пока старая версия доступна посетителям, в базе продолжают появляться заказы, комментарии или другие изменения.
После проверки DNS направляется на новую инфраструктуру.
Старый хостинг полезно некоторое время не удалять, пока вы не убедились, что новая площадка работает стабильно и все необходимые данные действительно перенесены.
Как понять что время перехода действительно пришло
Самый хороший признак — вы можете сформулировать проблему, которую облако должно решить.
- Нагрузка регулярно меняется в несколько раз.
- Проект упирается в ограничения виртуального хостинга.
- Приложению нужны собственные системные компоненты.
- Необходимо независимо масштабировать приложение и базу.
- Требуется несколько экземпляров сервиса.
- Файлы нужно отделить от вычислительных машин.
- Проект быстро развивается и инфраструктура постоянно меняется.
- Требования к доступности уже не помещаются в архитектуру одного сервера.
Если вместо этого причина звучит как «облако современнее», переезд можно отложить.
Иногда правильным следующим шагом остается более мощный хостинг
Не каждый выход за ограничения тарифа означает конец виртуального хостинга.
У провайдера может быть более производительная линейка с увеличенными лимитами. Если сайт остается обычным сайтом и владельцу не нужны собственные системные настройки, переход на такой тариф может быть самым простым решением.
Это особенно удобно, если хостер самостоятельно переносит аккаунт и практически ничего не меняется для владельца.
Следующий вариант — VPS.
Он подходит, если требуется больше контроля и ресурсов, но нет необходимости строить распределенную систему.
И только после этого имеет смысл оценивать, дает ли облачная архитектура преимущества, которыми проект действительно воспользуется.
Облако стоит выбирать не за модное название а за гибкость
Обычный хостинг, VPS и облако нельзя выстроить в линейку от плохого к хорошему.
Это разные инструменты.
Виртуальный хостинг выигрывает простотой. VPS дает контроль над собственной серверной средой. Облако позволяет собирать инфраструктуру из отдельных ресурсов и менять ее по мере необходимости.
Для небольшого сайта первый вариант часто оказывается лучшим. Для стабильного растущего проекта может прекрасно работать VPS. Облако начинает особенно хорошо раскрывать себя там, где нагрузка меняется, компоненты нужно масштабировать независимо или инфраструктура уже перестала помещаться в одну машину.
Поэтому переезжать стоит не тогда, когда сайт достиг определенного количества посетителей, а когда ограничения текущей площадки начали мешать развитию проекта.
Сначала найдите это ограничение. Затем сравните способы его устранить. И если именно облако дает нужную гибкость без неоправданного усложнения, переход становится техническим решением, а не следованием моде.
