База Hotels.ru за год увеличивается примерно на 50 % вместе с числом уникальных пользователей. А значит, приходится регулярно наращивать производительность, что непросто с административной точки зрения. Раз уж мы выбирали сервису новый «дом», логично было сделать основным критерием отбора гибкость масштабирования.

Полевые испытания показали, что для достижения комфортной пользователю скорости выборки и пересчета вариантов необходимо 1,5k IOPS по дисковой системе. К тому же показатель должен быть гарантированным, чтобы обеспечивать стабильный отклик сайта. На этом этапе отсеялась едва ли не половина предложений, так как конкретных гарантий по операциям ввода-вывода провайдеры старались избегать.

Список потенциальных облаков сузился и по географическому признаку. Мы не готовы были жертвовать скоростью ради перспективы хостинга за рубежом (как показали последние тенденции — правильно сделали). По части надежности расчеты возможных потерь показали, что оптимальным SLA для нашего сервиса будет 99,5 % и выше.

Как строился сервис

Мы создавали Hotels.ru для российского пользователя, поэтому приоритет по времени отклика и доступности был у России. Чем дальше веб-серверы от конечного пользователя, тем дольше ему придется ждать загрузки. Поэтому мы выбирали российскую площадку для размещения, с доступом к магистральным каналам региона. В результате выбор пал на один из облачных дата-центров с прямым подключением к точке обмена трафиком M9. Так влияние сетевых издержек на User Experience было минимизировано.

При построении высоконагруженной системы логично выбирать простую конфигурацию, без лишних довесков и сложностей. Сервис состоит из двух больших частей: веб-приложения и базы данных. Мы остановились на платформе Linux и PHP-приложении с базой MySQL.

Конечно, сотни тысяч одновременных подключений со всей страны генерируют серьезную нагрузку. Поэтому приложение развернуто на виртуальной ферме веб-серверов, нагрузка на которые балансируется средствами vSphere. Под базу выделена отдельная большая виртуальная машина, которая страхуется от сбоев с помощью vSphere High Availability. Вопрос надежности ИТ-ландшафта целиком отдан на откуп облачному провайдеру с соответствующим SLA.

Долго думали над катастрофоустойчивостью решения — это вообще сейчас популярная тема. Решили не «делать как все», а подойти к вопросу с умом и калькулятором. После расчетов объема потерь при гипотетической катастрофе мы пришли к выводу, что для компании потери становятся ощутимы спустя сутки недоступности. А при RTO в размере суток нет надобности в системах репликации или чем-то подобном, поэтому мы ограничились бэкапом и резервной площадкой.

Тут надо немного пояснить схему. Бэкапы делаются несколько раз в день, а резервная площадка присутствует в качестве договоренности с другим ЦОД о переносе туда данных в разумные сроки. Что касается сетевой целостности, то мы полагаемся на BGP, и потому проблема несоответствия имени и IP при переезде нас не коснется. За пять лет работы сервиса реальной масштабной аварии не случилось (тьфу-тьфу-тьфу), но при испытаниях схема показала себя вполне надежной. Во время очередной такой репетиции весь процесс занял менее 16 часов.

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

Зато вся прелесть облака осознается, когда перед праздниками трафик по сайту увеличивается в десяток раз и нужно срочно поднять мощность. На заре сервиса это вызывало натуральную панику и аврал, а сейчас вопрос решается добавлением виртуальных процессоров и IOPS для дисковой системы. Как только пик спал и, по прогнозам, повторений не предвидится — отключаем временно выделенные мощности, чтобы не платить лишнего.

Немного лирики и ИТ-философии

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

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

Мы тратим много времени и сломанных копий на обсуждение новой идеи или пожеланий пользователей. Любопытная идея одного из тестировщиков вполне способна породить долгое обсуждение и желание попробовать. Благо A/B-тестирование придумали умные люди, и мы часто добавляем новую фишку для половины наших пользователей. А потом разглядываем графики статистики и делаем выводы.

О нездоровой конкуренции

В век технологий и правового общества методы теневой борьбы с конкурентами не потеряли своей актуальности — вы наверняка регулярно встречаете сообщения о DdoS-атаках в СМИ. Рост популярности Hotels.ru привлек внимание недобросовестных лиц, и на нас, что недавно привело к масштабной атаке.

DDoS в нашем случае была направлена на перегрузку системы огромным числом запросов, хотя сам трафик при этом был небольшим. Вы же помните, что Hotels проводит анализ конкурентных цен и выводит сводные данные пользователям? Вот этим и решили воспользоваться злоумышленники чтобы «положить» нашу базу. Запросы сыпались из охватывающей четыре страны ботнет-сети, и сервису практически сразу стало нехорошо.

Выручил мониторинг облака, оповестивший о проблемах уже в первые 10 минут атаки. Наши серверы находятся под наблюдением провайдерского ZABBIX, который заодно приглядывает за сетью. Так что своевременное обнаружение проблем избавило и от потери репутации, и от более масштабных последствий. Реагировать на угрозу пришлось быстро, и было принято решение временно блокировать входящий трафик из атакующих стран, благо действительно крупных среди них не было. Параллельно увеличили число соединений и вздохнули спокойно.

Как раз после этого случая задумались о какой-то специальной системе борьбы с DDoS, потому как руками с этим справляться непросто и небыстро. Всегда ведь есть что улучшить, верно? Но пока вопрос в разработке, уж больно много нюансов.

Планы на будущее

Развитие Hotels.ru идет своим чередом, и регулярный прирост числа пользователей подтверждает, что мы двигаемся в верном направлении. Отсутствие сколь-нибудь заметных сложностей с серверной инфраструктурой позволяет думать не о покупке железа и найме новых администраторов, а о развитии. Например, сейчас вся команда увлеченно работает над большим обновлением: серьезно поменяется интерфейс и появятся новые возможности. Тут я не буду особенно раскрывать подробности, оставим место сюрпризу. Скажу лишь, что изменения будут еще и в «мозгах» сервиса: перейдем на HTML5, CSS3 и прочие новомодные штуки.

Параллельно занимаемся дополнительной сертификацией по стандарту PCI DSS, регламентирующего безопасность карточных платежей. Раньше мы просто пользовались услугами PCI DSS хостинга на уровне размещения оборудования, а остальные требования выполняли самостоятельно, что создавало чрезмерную нагрузку. Теперь собираемся передать эту работу провайдеру, для чего требуется несколько иной уровень сертификации PCI DSS.

Для этого мы собрали отдельную группу специалистов и работаем в сотрудничестве с «[ИТ-ГРАД]]». Дело в том, что большую часть требований стандарта может выполнять поставщик облачных сервисов, для этого у него должна быть сертификация PCI DSS с границами применимости, включающими не только сдачу оборудования в аренду, но и его администрирование.

В нашем случае мы планируем передать в зону ответственности IaaS-провайдера такие задачи, как:

управление конфигурацией сетевого оборудования (межсетевые экраны, маршрутизаторы);
контроль сроков действия паролей к серверным системам и виртуализации;
разработка стандартов конфигурации системных компонентов, управление изменениями;
шифрование канала при административном доступе к оборудованию и системам виртуализации;
контроль использования системных учетных записей;
поиск и выявление системных уязвимостей в оборудовании и ПО виртуализации;
и другие.

Сертификация эта непростая и довольно длительная. Спросите, зачем это нам вообще? Чтобы иметь возможность хранить информацию о карточках клиентов и не заставлять их каждый раз при бронировании вводить одну и ту же платежную информацию. Ранее мы уже реализовали оплату брони через собственный сайт, без перенаправления на посредника. Удобство такой схемы пользователи оценили сразу (все действия на одном сайте, со знакомым интерфейсом), да и для имиджа компании было полезно (сомнительная компания не будет заниматься подобными сложностями). Теперь мы решили шагнуть дальше и хранить в пользовательском профиле всю необходимую информацию.

Сегодня в России IaaS-операторов с сертификатом PCI DSS, который по области действия охватывает администрирование, а не только размещение оборудования, можно сосчитать по пальцам одной руки. На наш взгляд, бизнес рано или поздно добавит этот пункт к обширному списку «облачных требований».

Источник — «https://zdrav.expert/index.php/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82:Hotels.ru_(IT-Grad_Cloud)»