Это гостевой пост нашего партнера - компании ИТ-ГРАД. Давно прошли времена, когда бронирование отеля за рубежом было чем-то невероятным и отдавалось на откуп турагентствам. Никого не удивить и специализированными сервис-каталогами, где можно в разумные сроки выбрать себе временное пристанище на чужбине, почитать отзывы и оформить резерв. Сейчас таких агрегаторов достаточно, но не все они предлагают поддержку туристов на русском языке и полную прозрачность в отношении цен. Пять лет назад мы решили исправить эти недочеты и сделать свой сервис бронирования. Так появился Hotels.ru.
Как все начиналось
Конечно же, мы хотели стать не просто еще одним каталогом отелей, а лидером российского рынка бронирования. Благо национальные особенности нам близки и есть четкое понимание, в каком направлении развиваться.
Решено было сфокусироваться на открытости и возможности выбора. Мы считаем, что добиться этого просто — достаточно не пытаться замыкать клиента на себя. То есть не создавать ощущения, что либо он купит здесь, либо отправится на поиски куда-то еще. Поэтому мы решили сразу показывать все доступные цены и способы бронирования (в том числе с сайтов наших конкурентов). Вокруг этой идеи и происходило развитие всего сервиса.
На этом этапе появились и первые сложности технического плана. Дело в том, что обработка огромных массивов информации из множества источников потребовала от нас серьезных вычислительных мощностей. Как вы понимаете, начинался стартап явно не с мощного дата-центра и сотен серверов. Когда собственного железа стало не хватать, мы начали искать некое гибкое решение с разумной ценой. Тогда идея облачных вычислений активно набирала обороты, и мы решили попробовать.
Выбор облачного будущего
Наша база за год увеличивается примерно на 50 % вместе с числом уникальных пользователей. А значит, приходится регулярно наращивать производительность, что непросто с административной точки зрения. Раз уж мы выбирали сервису новый «дом», логично было сделать основным критерием отбора гибкость масштабирования.
Полевые испытания показали, что для достижения комфортной пользователю скорости выборки и пересчета вариантов необходимо 1,5k IOPS по дисковой системе. К тому же показатель должен быть гарантированным, чтобы обеспечивать стабильный отклик сайта. На этом этапе отсеялась едва ли не половина предложений, так как конкретных гарантий по операциям ввода-вывода провайдеры старались избегать.
Список потенциальных облаков сузился и по географическому признаку. Мы не готовы были жертвовать скоростью ради перспективы хостинга за рубежом (как показали последние тенденции — правильно сделали). По части надежности расчеты возможных потерь показали, что оптимальным SLA для нашего сервиса будет 99,5 % и выше.
Основным игроком отечественного рынка корпоративного IaaS в 2010 году была компания «ИТ-ГРАД», и наши требования не вызвали проблем с их стороны. Договор подписан, сервис перевезен в новое облако.
Как строился сервис
Мы создавали 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, который по области действия охватывает администрирование, а не только размещение оборудования, можно сосчитать по пальцам одной руки. На наш взгляд, бизнес рано или поздно добавит этот пункт к обширному списку «облачных требований».
RSS
