Ретейл, онлайн и авиаперевозки
Каждый путешествующий по России и миру человек наверняка слышал об S7 Airlines — по крайней мере вы наверняка видели их яркие, позитивно раскрашенные самолеты. Авиакомпания входит в S7 Group. Это холдинг из нескольких компаний, каждая из которых занимается какой-то своей частью бизнеса, связанного с организацией авиаперевозок.
Есть сервисная «наземная» служба, служба, занимающаяся обслуживанием пассажиров в аэропортах, компания, отвечающая за перевозки грузов, подразделение для продажи билетов… В общем, продолжать можно долго, но вас наверняка больше интересует «самая IT» из всех служб — S7 t-Retail. Подразделение занимается всей онлайн-составляющей, включая обслуживание системы продажи билетов онлайн. Сюда же относится кол-центр, но сегодня разговор не о нем. Дальнейшее повествование будет посвящено именно этой «дочке». Вся ИТ-инфраструктура S7 t-Retail условно делится на две части:
- Статичные сервисы — портал Sru и семейство информационных сайтов, через которые можно получить доступ ко всем сервисам компании и почерпнуть необходимую информацию.
- Динамичные сервисы — все остальные сайты и приложения, предполагающие некий интерактив. Сюда входит система бронирования и покупки билетов, информирование о рейсах и пр.
Как вы уже догадались, вся «соль» заключается именно в динамичной составляющей, так как потребности этих сервисов напрямую зависят от рыночных тенденций и пользовательских предпочтений. Значит, и основное внимание в части ИТ уделяется именно таким системам.
Первые билеты онлайн
Весь онлайн начался в уже далеком 2006 году, когда компания решила внедрить систему онлайн-продажи билетов. Тогда билеты были еще бумажными, хотя и продаваемыми через Интернет, но общая идея сохранилась до сих пор. Вся сопутствующая онлайн-продажам серверная инфраструктура изначально размещалась в ЦОД собственной сервисной компании S7 IT (вариант колокейшена), так как этот вариант был наиболее целесообразным в плане денег и будущих апгрейдов. По крайней мере за «железную» составляющую отвечали другие люди, они же и занимались апгрейдом.
Сайт по продаже билетов работает на платформе OJT (OpenJaw Technology), которая специализирована под авиацию. С архитектурной точки зрения там все классически: ферма серверов приложений на Red Hat Enterprise Linux (каждый отвечает за свой «участок») и бэкэнд в лице PostgreSQL. В S7 вообще любят мир *nix и опенсорс, даже когда эти понятия не были столь модными, как в наши дни.
Термин Open Jaw не является эксклюзивной выдумкой одноименной компании. На авиационном жаргоне «открытой пастью» (в переводе с английского) называют такой незамкнутый маршрут «туда и обратно», при котором пассажир вылетает обратно из другого аэропорта. Например: туда Москва — Берлин, обратно Мюнхен — Москва.
Как это часто бывает с развивающимся направлением, S7 t-Retail через некоторое время переросла заложенные изначально мощности. Билетов продавалось все больше, многие пользователи с энтузиазмом перешли на бронирование в режиме онлайн, и на S7 IT обрушилась целая лавина запросов на апгрейд и расширение. Разумеется, все были только за, но сроки закупки и установки железа вы все знаете. В результате каждое серьезное обновление требовало нескольких недель задержки, что неприемлемо для развивающегося бизнеса. А поскольку подобные изменения стали происходить все чаще, S7 t-Retail решили пойти другим путем.
Когда мощностей начинает потихоньку не хватать
Фактически долгое ожидание при наращивании мощностей складывалось из двух этапов:
- Закупка и ожидание железа.
- Установка и настройка железа с ПО.
Чтобы исключить первый и оптимизировать второй, в 2012 году S7 t-Retail решили перейти на виртуальную инфраструктуру. Тогда виртуализация активно набирала популярность и представлялась решением всех проблем. Так, в общем-то, и вышло: развертывание нового виртуального сервера теперь происходило за 2–3 часа вместо нескольких недель и большую часть времени занимала банальная установка обновлений.
Для виртуализации была выбрана лучшая на рынке платформа — конечно же, VMware — и аппаратная база подразделения S7 IT. Так как утилизация оборудования существенно выросла за счет возросшей плотности размещения (плюсы виртуализации вы и так знаете, не буду повторяться), обошлись даже без серьезных вложений в новое железо. Кстати, темпы виртуализации в масштабах инфраструктуры S7 t-Retail не могут не удивлять: за 6 месяцев было виртуализовано 99 % систем! В некоторых крупных компаниях процесс виртуализации тянется годами и под него открывают целые отделы. Но ничто не вечно под луной, и в какой-то момент эффективной утилизации железа стало недостаточно.
Лирическое отступление
При разговоре с Егором мы обсудили такое любопытное явление, как смещение стоимости облачных ресурсов в сторону оперативной памяти. Дело в том, что при анализе статистики потребления ресурсов S7 t-Retail выяснилось, что дороже всего обходятся изменения именно по объему ОЗУ. Это выглядит тем более любопытно, что память считается постоянно дешевеющим ресурсом. В общем, ожидали увидеть в «дорогих» позициях дисковое пространство, а никак не память. Но обо всем по порядку — передаю слово Егору.
Мы экспериментировали с обеими доступными моделями оплаты облака: с полным резервированием (когда оплачиваешь потребление определенного объема, которым и ограничен) и Pay-as-you-go. Вторая модель предполагает оплату постфактум по реально использованным ресурсам. Это выглядело интересно с учетом слабой прогнозируемости пиковых нагрузок. В результате нескольких месяцев работы по схеме Pay-as-you-go было установлено следующее:
- В месяце, когда вся платформа работала на Pay-as-you-go, память составила 91 % от всего счета! 2 % пришлось на CPU и 7 % — на диски.
- По схеме reserved память занимала 60 % счета. Процессор, правда, стоил уже дороже — 27 %.
Но цифры явно не без погрешности, так как в этих периодах использовался разный объем хранилища: во втором месяце на модели reserved хранилище выросло в объеме до 240 %. И тем не менее пример любопытный. Хотя, конечно, все зависит от специфики и объемов конкретного проекта.
Не знаю, как читателю, но мне в крупных проектах интереснее всего смотреть на этап выбора оборудования/поставщика/ПО и последующее внедрение. Обычно возникает довольно много нюансов и особенностей, которые вылезают как раз на масштабе. В случае с S7 я поинтересовался, как происходил выбор поставщика и на что делался упор.
Егор, а как выбирали провайдера, какие были требования? Сейчас поставщиков на рынке довольно много…
Это точно, но у нас к моменту формирования желания попробовать облако уже набрался некий набор необходимых опций. В частности, рассматривали только ЦОД с «тремя девятками» доступности (99,9 % доступность сервисов в год), такие дата-центры как раз и были представлены в основной массе на рынке. Сложности возникли, когда мы озвучили свое видение этих девяток.
«У специалистов подрядчика должны гореть глаза, им должно быть интересно обсуждать и реализовывать проект потенциального заказчика. Причем этот подход оправдывает себя не только с облачными провайдерами, но и с любыми другими поставщиками технологичных услуг». Егор Баяндин, директор по технической поддержке и сопровождению S7
Дело в том, что по классической схеме Uptime Institute доступность «три девятки» предполагает чуть более 8 часов простоев ежегодно. Теоретически эти часы могут быть и подряд за один день. Для нас такое развитие событий выглядит неприемлемым, поэтому вопрос сразу оговаривался с потенциальным облачным провайдером.
Как выяснилось, почему-то не все ЦОД с заявленной доступностью 99,9 % готовы были подписаться под нашими условиями. Таким образом, большинство предложений было отсеяно уже на этом этапе. Плюс у меня есть свое видение хорошего подрядчика — у специалистов такого поставщика должны «гореть глаза» и ощущаться заинтересованность в своем деле. Как показала практика, работа с компаниями, специалисты которой демонстрируют безразличие к проекту, ни к чему хорошему не приведет. Так мы и пришли к «ИТ-ГРАД» после нескольких встреч и общения с вашими техническими специалистами.
Тот же ЦОД, но виртуальный
Итак, на дворе 2014 год. Очередной всплеск продаж билетов в летний сезон поднял нагрузку на оборудование на 10–15 %, что серьезно просадило отклик сайтов. Казалось бы, процент небольшой. Но вы ведь помните, что для эффективного использования и обозримого ROI (возврата инвестиций) необходимо загружать оборудование до 80 %, сохраняя оставшиеся как раз на случай кратковременных всплесков. Однако особенности архитектуры x86 не позволяют процессорам работать со штатной эффективностью при загрузке, близкой к 100 %. И заход в «красную зону» чреват заметной потерей производительности. Именно это и начало происходить.
Хороший пользовательский сервис строится так, чтобы демонстрировать максимальную скорость и плавность, не раздражая потенциального покупателя «лагами» и рывками анимации. Ведь даже один эпизод заказа билетов через тормозящий интерфейс способен отнять у вас определенный процент пользователей в пользу сервисов-агрегаторов или других каналов продаж. Поэтому было жизненно необходимо поддерживать определенную планку по части скорости. И это вдвойне непросто, когда при пиковой нагрузке необходимо добавить несколько десятков процессорных ядер и пару десятков терабайт памяти.
Все это привело к запуску нового проекта миграции на более гибкую платформу, желательно без закладывания сумасшедших бюджетов «на всякий случай». Решено было попробовать облака, которые как раз избавились от «детских болезней» и стали походить на нормальное промышленное решение. К тому же изначально работающие с виртуализацией провайдеры должны явно лучше разбираться в «тонкой настройке» таких систем, что позволит исключить многие шероховатости перехода. В процессе виртуализации специалисты S7 сделали одно небольшое, но важное дело — перешли на тотальное использование FQDN при обращении одних сервисов к другим (вместо привычных IP-адресов). Да-да, мы все знаем, что это основы и вообще логично. Но кто без греха — хоть пара сервисов, да настроены на обращение к ресурсам по IP. И вскрывается это при какой-нибудь масштабной миграции, когда адресация для подобных сервисов внезапно оказывается другой. В общем, это небольшое дело сыграло значимую роль в гладком переходе на облачные «рельсы» — достаточно было просто мигрировать VM и настроить новую сетевую инфраструктуру.
Пространство для маневров
Мы решили немного заглянуть в будущее и обсудить с Егором проектные планы компании S7 в части облачных и прочих технологий.
Егор, так что все-таки больше всего «цепляет» в облачной архитектуре, какие возможности были недоступны в вашем дата-центре?
Больше всего нравится ощущение полного контроля над виртуальными машинами: мы можем распределять доступные ресурсы как угодно, в зависимости от любых всплесков нагрузки или пожеланий наших разработчиков. Раньше любое подобное распределение мощностей выливалось в приобретение комплектующих и долгую перенастройку оборудования. С виртуализацией, конечно, стало полегче, но в конечном счете все равно упирались в ресурсы железа. А с виртуальным ЦОД об оборудовании даже думать особенно не приходится.
Сейчас уже полностью перенесли клиентский трафик в IaaS или все же облако работает в тандеме с собственным ЦОД?
Сейчас в облачной среде работает около 1 % продакшен-нагрузок. Остальное отдано для разработок и тестирования новых сервисов или изменений. Да, доля 1 % не кажется большой, но не стоит забывать и про размер всей инфраструктуры, на ее фоне это не так уж и мало. Кроме того, такое распределение с успехом решает обработку пиковых нагрузок в сезон продаж и позволяет экспериментировать с системами без нагрузки на рабочие экземпляры приложений. Что касается работы «в тандеме», то ничего такого делать не пришлось — мы просто разделили свой ЦОД и облако на уровне конкретных информационных систем. То есть сервис либо целиком перемещен в облако, либо работает в ЦОД S7 IT.
А есть планы по полному переезду в IaaS?
Планы, безусловно, есть, но не все сразу. В перспективе видится смещенная в облако инфраструктура, которая все же связана с собственным ЦОД. Клиентский трафик при таком раскладе думаем разделять внешним балансировщиком. Вообще, сейчас активно прорабатываются другие проекты, вроде катастрофоустойчивости. Но говорить пока рано, так как все находится на стадии «начали обсуждать».
А если подытожить, что бы вы отметили как безусловные плюсы (или минусы) при работе с облачными системами?
Ну, минусы тут в принципе найти сложно. Разве только то, что мы пока не подобрали для себя наиболее подходящую схему работы с моделью Pay-as-you-go. То есть видны безусловные выгоды от использования схемы оплаты по факту, но технические особенности работы VMware с памятью не всегда позволяют эти преимущества извлечь. В нашем случае получилось иногда даже выгоднее зарезервировать ресурсы под 100 %. Плюсов, конечно же, много, перечислю только основные:
- Гибкость в части распределения ресурсов. Если у вас есть 100 vCPU и пара десятков терабайт памяти, вы можете использовать их как угодно и на любых виртуальных машинах. Не нужно подбирать память под конкретное железо или перераспределять его между виртуальными хостами.
- Заметно быстрее происходит развертывание VM. От запуска процесса до стадии «все готово и апдейты установлены» теперь проходит лишь 2–3 часа, вместо нескольких дней.
- Нет необходимости решать вопросы закупки и модернизации оборудования. Для нас это важный момент, ввиду обилия согласований в процессе заказа.
- Возможность обойти большинство ошибок при настройке инфраструктуры. Так как у облачного провайдера обычно работают специалисты по конкретному продукту (VMware), то многие нюансы и особенности «тюнинга» виртуальных систем решены по умолчанию и давно.
В общем и целом, у нас сложилось вполне положительное впечатление от работы в облачной среде. Безусловно, будем развивать этот проект и дальше.
На этом я поблагодарил Егора за уделенное время и любопытную информацию — далеко не все пользователи облачных систем скрупулезно изучают их работу и оценивают выгоду от перехода. Надеюсь, читателю было так же интересно, как и мне.
*Источник материала: КОМПЬЮТЕРРА.
