OneTwoTrip: нам подходит не любое облако

Основной бизнес OneTwoTrip – онлайн-бронирование путешествий (авиабилетов и отелей). Последние четыре года мы быстро растем, открываем офисы в других странах, ведем масштабную внутреннюю разработку своих ключевых сервисов как для сайта OneTwoTrip.com, так и для одноименных мобильных приложений. 90% нашей инфраструктуры является облачной. По нашим оценкам, это значительно снижает наши затраты на обслуживание «физической» составляющей ИТ.

Мы работали со многими российскими и международными провайдерами. Выбирая, мы всегда интересуемся надёжностью облака, его историей и технологичностью решения. Также критичным при работе с виртуальными машинами является возможность автоматизировать процесс управления, что предполагает доступ к облаку через API. Оптимально, чтоб API был открытым и поддерживался сторонними разработчиками. Это позволяет выделять ресурсы «по требованию», без расхода человеко-часов.

Помимо этого, мы обращаем внимание на следующие параметры:

● время создания/удаления виртуальной машины (норма – не более минуты до входа на сервер по сети);

● минимальный квант биллинга (общим стандартом сейчас является час, но есть и более точные решения);

● возможность изменения размеров одной виртуальной машины (оптимально, если это реализуемо без её перезагрузки, но пересоздание хоста с нуля неприемлемо).

При этом иногда довольно критично иметь возможность не получить больше ресурсов, а уменьшить выделяемый объём. Например, был реальный кейс: общее число поисковых запросов на сервисе на время снизилось – и за 30 минут мы урезали поисковый кластер на треть. А бывало и наоборот: в течение часа нужно было на треть увеличить общее число серверов причем в автоматическом режиме. Провайдер, который такого не позволяет, нам не нужен.

Вдобавок к этому мы рассматриваем облако не только как виртуальные сервера, но и как сеть. Таким образом, приятным дополнением будет возможность выделения изолированных сегментов и управление разрешениями на уровне SDN, а не на каждой ноде индивидуально.

Также стоит обратить внимание на поведение провайдера в случае каких-либо проблем, на скорость реакции поддержки и их действия. Некоторые подрядчики могут просто оставить вас с уничтоженным диском и пропавшими данными, а иные наоборот: предупредят о проблеме и предложат пути решения, например, перенесут информацию и процессы на другой физический сервер. Да и в целом, общее отношение провайдера к безопасности играет значительную роль: это и своевременные обновления хост-систем, и возможности разделения доступа между сотрудниками, и учёт действий.

Тем не менее, когда речь идёт об облаках, нужно учитывать, что проблемы случаются у всех и быть к этому готовым. Поэтому не стоит полагаться целиком на одно облако: разумнее вынести часть инфраструктуры в другие, а резервные копии критичных данных хранить в независимых местах. Тогда при должном уровне автоматизации можно будет полностью восстановиться в другом облаке. Из этого вытекает и такой позитивный момент: при необходимости можно отказаться от услуг провайдера и с минимальными затратами переехать к другому. В случае с физическими серверами это более болезненный и длительный процесс.

Мы используем облака для боевых серверов, для создания тестовых и демонстрационных сред, однако хранение больших объёмов информации всё ещё оказывается выгоднее на физических серверах. В остальных случаях нам выгоднее использовать облачные решения: помимо выгоды от отказа владеть и обслуживать «железо», мы получаем гибкость общих затрат на инфраструктуру в зависимости от текущих потребностей бизнеса.