В начинающем бизнесе всё сосредоточено на завоевании рынка. Любые усилия должны быть направлены на то, что нужно здесь и сейчас. Это касается и серверной инфраструктуры. Множество резервирующих серверов в географически удаленных друг от друга дата-центрах — это, конечно, круто и надежно. Но когда у вас несколько десятков клиентов, какой в этом смысл?
Мы исходили из того же подхода, когда начали разрабатывать облачный сервис Okdesk. Продукт увидел свет на «минимально жизнеспособной инфраструктуре»: виртуальная машина в западном дата-центре, на которой было установлено приложение и СУБД (со временем поисковый движок переехал на соседнюю «виртуалку»). Вокруг этого хозяйства был настроен минимальный мониторинг через ping-admin и регулярные бекапы в облако другого провайдера.
В статье: о причинах переезда, выборе способа переключений дата-центров, выборе дата центра и первых результатах.
С такой инфраструктурой мы продержались “без падений” и показали доступность сервиса в 99,97% (2 часа простоя в год, включая плановые), при этом за всё время мы ни разу не получали жалоб со стороны клиентов на “тормоза” или “простои”.
Но с ростом клиентской базы росли не только выручка и мощность виртуальной машины. Росло и нервное напряжение. Сон становился все более беспокойным, а на прогулке с ребенком внутренний дежурный ожидал сигнала на телефон об инфраструктурной проблеме. Когда количество активных клиентов Okdesk приблизилось к сотне, стало понятно, что дальше так жить нельзя. “Минимально жизнеспособная инфраструктура” себя исчерпала: при серьезной инфраструктурной проблеме простой сервиса мог составить 2 и более часа. И одно дело — когда сервер «лежит» 2 часа для десяти клиентов, и совсем другое — когда доступа нет у сотен. Первое как-то можно пережить, а после второго восстановить репутацию будет куда сложнее, чем работоспособность сервиса.
Итак, мы решили внедрять более надежную инфраструктуру для Okdesk. И вот что из этого получилось…
С чего начать проектирование инфраструктуры облачного сервиса? Нет, не с изучения современных подходов и технологий :) Начать нужно с определения бизнес-требований.
Okdesk — это SaaS для управления клиентскими заявками в сервисных бизнесах. А значит — бизнес-критичная система для потребителей. Исходя из этого мы сформулировали следующие требования:
Два написанных выше требования стали направляющими при проектировании инфраструктуры и выборе конечного решения.
Мы не стали изобретать велосипед и на первом шаге применили следующий подход. В основном дата-центре на двух физических серверах установлено приложение и СУБД. В резервном дата-центре установлен один физический сервер с СУБД и приложением. Между СУБД в резервном дата-центре и СУБД в основном дата-центре настроена репликация данных. В случае аварии в основном дата-центре мы будем перенаправлять трафик в резервный дата центр (см. следующий раздел), время на переключение трафика по плану не должно превышать 5 минут (решение о переключении трафика принимает человек, поэтому в эти 5 минут не включено время реакции на инцидент).
Следующим шагом, когда нагрузка на приложение потребует более мощных серверов (примерно через 4-6 месяцев по нашим расчетам), мы планируем перейти к кластерной модели (балансировщик + ноды с приложением). Можно было бы использовать один мощный сервер, это дешевле. Но при отказе одного большого сервера придется переключать трафик в резервный дата-центр (несколько минут недоступности сервиса), тогда как в случае отказа одной небольшой ноды, максимум что могут почувствовать клиенты — это временная и не критичная деградация производительности. А вот в резервном дата-центре все с точностью до наоборот. По мере роста планируем увеличивать мощности резервного сервера: риск одновременного “падения” основного дата-центра и резервного минимальный, поэтому допустимо немного сэкономить.
Как мы выяснили, есть 3 самых распространенных способа организации быстрого переключения IP адреса, закрепленного за доменным именем:
Остановимся подробнее на плюсах и минусах каждого из способов.
Плюсы:
— быстрое переключение;
— низкая стоимость.
Минусы:
— предоставляется не всеми дата-центрами;
— настраивается дата-центром, в случае необходимости изменений процесс может затянуться;
— не понятно насколько хорошо дела обстоят с резервированием.
Плюсы:
— полный контроль над логикой работы;
— невысокая стоимость;
— несколько ДНС серверов, куда делегирована зона: можно говорить о резервировании.
Минусы:
— некоторые DNS серверы игнорируют TTL переданный от держателя зоны. По нашей информации, число таких упорных серверов очень мало. Но они есть (т.е. не для всех пользователей переключение между IP может сработать оперативно).
Плюсы:
— простая настройка;
— практически мгновенное переключение между IP адресами.
Минусы:
— появляется ещё одна теоретическая точка отказа. С нашей точки зрения в этом плане условный cloudflare с большей вероятностью даст сбой, чем днс амазона или vrrp;
— т.к. все запросы к сервису будут проходить через cloudflare, а наши пользователи в основном находятся на территории СНГ, то это приведёт к увеличению времени ответа от сервера.
В результате мы приняли решение остановиться на route 53 от Amazon. Решение не идеальное, но всегда приходится чем-то жертвовать. При этом мы продолжим изучать другие возможные варианты.
По историческим причинам наш мониторинг состоит из следующих компонент:
Некоторые функции наших мониторингов дублируются, но это, пожалуй, тот случай, когда лучше больше, чем меньше.
При выборе дата-центра исходили из следующих требований:
Исходя из этих требований выбирали между Selectel и Servers.
У каждого из провайдеров свои плюсы и минусы.
Плюсы:
— широкая линейка dedicated серверов;
— приемлемые цены;
— много лет на рынке, много доп. сервисов (например, vrrp, которого нет в Servers.ru);
— среди клиентов есть Вконтакте — можно ожидать, что это мотивирует провайдера быть на переднем крае технологий.
Минусы:
— в последнее время наблюдаем много сообщений от знакомых и коллег по цеху о проблемах со стабильностью.
Плюсы:
— дата-центры в нескольких странах, серверы в разных ДЦ можно объединить в одну сеть “из коробки” (т.е. это не дополнительная услуга). Пока наш основной бизнес в СНГ и наличие зарубежных ДЦ не имеет большого значения. Но в обозримом будущем мы планируем выходить на другие рынки, поэтому использование инфраструктуры одно провайдера – хорошее подспорье;
— новые брендовые серверы Dell;
— гибкость и клиентоориентированность как в саппорте (ответы прилетают быстро), так и в продажах (например, без проблем можно договориться об изменении стандартной конфигурации: добавить дисков или памяти).
Минусы:
— есть большой разрыв между конфигурациями серверов. Так, например, самая простая конфигурация включает 1 процессор с 4 ядрами, а следующая 2 процессора по 16 ядер (с разницей в цене 2 раза);
— при прочих равных, цены выше.
В итоге мы выбрали Servers, так как разница цены за хостинг в абсолютном значении оказалась несущественной по сравнению с рисками нестабильной работы.
По итогам переезда мы не только стали спать спокойнее, мы значительно улучшили показатели. Например, среднее время отклика уменьшилось в 4 раза
Ну а клиенты Okdesk могут продолжать не беспокоиться о сохранности и доступности данных.
p.s. в рамках статьи мы не погружались в технические аспекты инфраструктуры. Мы хотели сделать акцент на том, что выбор технических решений должен основываться на базе бизнес-требований. На вопросы по техническим аспектам по мере возможности ответим в комментариях.
Мы исходили из того же подхода, когда начали разрабатывать облачный сервис Okdesk. Продукт увидел свет на «минимально жизнеспособной инфраструктуре»: виртуальная машина в западном дата-центре, на которой было установлено приложение и СУБД (со временем поисковый движок переехал на соседнюю «виртуалку»). Вокруг этого хозяйства был настроен минимальный мониторинг через ping-admin и регулярные бекапы в облако другого провайдера.
В статье: о причинах переезда, выборе способа переключений дата-центров, выборе дата центра и первых результатах.
С такой инфраструктурой мы продержались “без падений” и показали доступность сервиса в 99,97% (2 часа простоя в год, включая плановые), при этом за всё время мы ни разу не получали жалоб со стороны клиентов на “тормоза” или “простои”.
Но с ростом клиентской базы росли не только выручка и мощность виртуальной машины. Росло и нервное напряжение. Сон становился все более беспокойным, а на прогулке с ребенком внутренний дежурный ожидал сигнала на телефон об инфраструктурной проблеме. Когда количество активных клиентов Okdesk приблизилось к сотне, стало понятно, что дальше так жить нельзя. “Минимально жизнеспособная инфраструктура” себя исчерпала: при серьезной инфраструктурной проблеме простой сервиса мог составить 2 и более часа. И одно дело — когда сервер «лежит» 2 часа для десяти клиентов, и совсем другое — когда доступа нет у сотен. Первое как-то можно пережить, а после второго восстановить репутацию будет куда сложнее, чем работоспособность сервиса.
Итак, мы решили внедрять более надежную инфраструктуру для Okdesk. И вот что из этого получилось…
В первую очередь бизнес-требования
С чего начать проектирование инфраструктуры облачного сервиса? Нет, не с изучения современных подходов и технологий :) Начать нужно с определения бизнес-требований.
Okdesk — это SaaS для управления клиентскими заявками в сервисных бизнесах. А значит — бизнес-критичная система для потребителей. Исходя из этого мы сформулировали следующие требования:
- в случае проблем в дата-центре (как локальных — когда выходит из строя конкретный сервер, так и глобальных — когда пропадает или деградирует доступ ко всему дата-центру) время неработоспособности с точки зрения клиента не должно превышать 15 минут. Допускается незначительная деградация производительности на время решения проблем в основном дата-центре;
- в случае аварий, в результате которых безвозвратно теряется продакшн-СУБД, не допускается потеря клиентских данных более чем за несколько секунд до аварии.
Два написанных выше требования стали направляющими при проектировании инфраструктуры и выборе конечного решения.
От требований к реализации
Общий подход
Мы не стали изобретать велосипед и на первом шаге применили следующий подход. В основном дата-центре на двух физических серверах установлено приложение и СУБД. В резервном дата-центре установлен один физический сервер с СУБД и приложением. Между СУБД в резервном дата-центре и СУБД в основном дата-центре настроена репликация данных. В случае аварии в основном дата-центре мы будем перенаправлять трафик в резервный дата центр (см. следующий раздел), время на переключение трафика по плану не должно превышать 5 минут (решение о переключении трафика принимает человек, поэтому в эти 5 минут не включено время реакции на инцидент).
Следующим шагом, когда нагрузка на приложение потребует более мощных серверов (примерно через 4-6 месяцев по нашим расчетам), мы планируем перейти к кластерной модели (балансировщик + ноды с приложением). Можно было бы использовать один мощный сервер, это дешевле. Но при отказе одного большого сервера придется переключать трафик в резервный дата-центр (несколько минут недоступности сервиса), тогда как в случае отказа одной небольшой ноды, максимум что могут почувствовать клиенты — это временная и не критичная деградация производительности. А вот в резервном дата-центре все с точностью до наоборот. По мере роста планируем увеличивать мощности резервного сервера: риск одновременного “падения” основного дата-центра и резервного минимальный, поэтому допустимо немного сэкономить.
Как переключаться между дата-центрами?
Как мы выяснили, есть 3 самых распространенных способа организации быстрого переключения IP адреса, закрепленного за доменным именем:
- VRRP;
- DNS хостеры с коротким TTL
- Веб-сервисы (по типу cloudflare).
Остановимся подробнее на плюсах и минусах каждого из способов.
VRRP
Плюсы:
— быстрое переключение;
— низкая стоимость.
Минусы:
— предоставляется не всеми дата-центрами;
— настраивается дата-центром, в случае необходимости изменений процесс может затянуться;
— не понятно насколько хорошо дела обстоят с резервированием.
DNS хостеры с коротким TTL (на примере route53 от Amazon)
Плюсы:
— полный контроль над логикой работы;
— невысокая стоимость;
— несколько ДНС серверов, куда делегирована зона: можно говорить о резервировании.
Минусы:
— некоторые DNS серверы игнорируют TTL переданный от держателя зоны. По нашей информации, число таких упорных серверов очень мало. Но они есть (т.е. не для всех пользователей переключение между IP может сработать оперативно).
Веб-сервисы (на примере Cloudflare)
Плюсы:
— простая настройка;
— практически мгновенное переключение между IP адресами.
Минусы:
— появляется ещё одна теоретическая точка отказа. С нашей точки зрения в этом плане условный cloudflare с большей вероятностью даст сбой, чем днс амазона или vrrp;
— т.к. все запросы к сервису будут проходить через cloudflare, а наши пользователи в основном находятся на территории СНГ, то это приведёт к увеличению времени ответа от сервера.
В результате мы приняли решение остановиться на route 53 от Amazon. Решение не идеальное, но всегда приходится чем-то жертвовать. При этом мы продолжим изучать другие возможные варианты.
Мониторинг
По историческим причинам наш мониторинг состоит из следующих компонент:
- Ping-admin — умеет делать http запросы по заданным адресам и, если в ответе что-то не так, отправляет смс и звонит на заданные номера. Стоит недорого и прост в настройке. Неплох как стартовый минимальный мониторинг, можем его посоветовать тем, кто только запускается и хочет всегда знать работает его сервис или нет;
- Monit — установлен на сервере и мониторит базовые метрики: количество свободного места, загруженность CPU и размер свободной оперативной памяти. Бесплатен, но требует минимальных познаний в unix системах и способности читать мануалы
- Scoutapp — профилирование приложения в части производительности и узких мест в программном коде. Позволяет анализировать данные в различных временных срезах и разбирать отдельные запросы.
- Клиент-серверная утилита (появилась после monit’a), контролирует большое число характеристик сервера, может контролировать изменение бизнес параметров (например количество новых объектов в БД за отрезок времени), умеет рисовать красивые графики и слать уведомления.
Некоторые функции наших мониторингов дублируются, но это, пожалуй, тот случай, когда лучше больше, чем меньше.
Выбор дата-центра
При выборе дата-центра исходили из следующих требований:
- наличие площадки в России (для соответствия закону о защите перс. данных);
- наличие не менее 2 площадок в целом.
Исходя из этих требований выбирали между Selectel и Servers.
У каждого из провайдеров свои плюсы и минусы.
Selectel:
Плюсы:
— широкая линейка dedicated серверов;
— приемлемые цены;
— много лет на рынке, много доп. сервисов (например, vrrp, которого нет в Servers.ru);
— среди клиентов есть Вконтакте — можно ожидать, что это мотивирует провайдера быть на переднем крае технологий.
Минусы:
— в последнее время наблюдаем много сообщений от знакомых и коллег по цеху о проблемах со стабильностью.
Servers:
Плюсы:
— дата-центры в нескольких странах, серверы в разных ДЦ можно объединить в одну сеть “из коробки” (т.е. это не дополнительная услуга). Пока наш основной бизнес в СНГ и наличие зарубежных ДЦ не имеет большого значения. Но в обозримом будущем мы планируем выходить на другие рынки, поэтому использование инфраструктуры одно провайдера – хорошее подспорье;
— новые брендовые серверы Dell;
— гибкость и клиентоориентированность как в саппорте (ответы прилетают быстро), так и в продажах (например, без проблем можно договориться об изменении стандартной конфигурации: добавить дисков или памяти).
Минусы:
— есть большой разрыв между конфигурациями серверов. Так, например, самая простая конфигурация включает 1 процессор с 4 ядрами, а следующая 2 процессора по 16 ядер (с разницей в цене 2 раза);
— при прочих равных, цены выше.
В итоге мы выбрали Servers, так как разница цены за хостинг в абсолютном значении оказалась несущественной по сравнению с рисками нестабильной работы.
Промежуточные результаты
По итогам переезда мы не только стали спать спокойнее, мы значительно улучшили показатели. Например, среднее время отклика уменьшилось в 4 раза
Ну а клиенты Okdesk могут продолжать не беспокоиться о сохранности и доступности данных.
p.s. в рамках статьи мы не погружались в технические аспекты инфраструктуры. Мы хотели сделать акцент на том, что выбор технических решений должен основываться на базе бизнес-требований. На вопросы по техническим аспектам по мере возможности ответим в комментариях.
