Архитектура BigData-инфраструктуры сервиса Pandorama и защита ее данных от сбоев

Если мантра Google звучит как “поиск всей информации в мире одним кликом”, то мантра молодого российского проекта Pandorama ^[1] идет дальше: “найдем без клика всю интересную вам информацию”.

Приложение Pandorama предлагает своим пользователям “бесконечную” персонализированную ленту новостей, составленную на основе их личных информационных предпочтений, не требуя при этом от читателя работы с “тегами”, “категориями” или “лайками” друзей. Сначала нужно ответить на пару вопросов про несколько забавных панд, а потом нужно просто… читать предлагаемую ленту. Те новости, которые вы прочитали, будут автоматически анализироваться и обрабатываться системой, с тем, чтобы в дальнейшем такого рода новостей в ленте становилось все больше, а тех новостей, которые не вызвали у вас интереса – все меньше.

Pandorama уже объединяет более 40 тыс. пользователей по всему миру, и это число постоянно растет. В данной статье рассматривается BigData-инфраструктура этого проекта, функционирующая в режиме 24x7, механизмы обеспечения ее отказоустойчивости, и защита ее данных от сбоев, построенная с использованием Veeam Backup & Replication Cloud Edition ^[2].

Итак, как работает веб-сервис Pandorama? Каждый день его робот постоянно ищет новую информацию, обходя множество страниц в сети (ежедневно анализируются около 35 тысяч источников). Каждая найденная статья обрабатывается с помощью собственных лингвистических алгоритмов, после чего ей автоматически присваивается один или несколько тегов вроде «iPhone 5s» в зависимости от содержания. Конечный пользователь получает персонализированную ленту статей, собранную на основе его личных интересов, выявленных системой Pandorama. Проект Pandoramа изначально планировался основателями как международный, нацеливался на массовый рынок, поэтому в качестве языка новостной ленты был выбран английский.

Рисунок 1. Окно регистрации в Pandorama

Сейчас Pandorama арендует четыре выделенных физических сервера, на которых развернуто более 30 виртуальных машин (ВМ). Для обеспечения масштабируемости и отказоустойчивости применяется следующий набор технологий:

• Объединение сетевых каналов Ethernet (LACP)
• Баллансировка веб-нагрузки (HAProxy)
• Баллансировка сетевых соединений (DNS Round Robin и NLB)
• Географически распределенное кеширование картинок и статических ресурсов (CDN)
• NoSQL, включая шардинг и зеркалирование (MongoDB)
• Зеркалирование SQL
• Репликация ВМ и резервное копирование ВМ локально и в облако с помощью Veeam Backup & Replication Cloud Edition ^[2]

Подробнее об этом будет рассказано ниже.

Инфраструктура Pandorama

Как любой стартап, бюджет Pandorama сильно ограничен, поэтому команда старается максимально эффективно инвестировать деньги во все, включая инфраструктуру. Изначально рассматривалось несколько вариантов хостинга ^[3]. В первую очередь подумали об Amazon, однако предварительные подсчеты показали, что этот вариант слишком дорог. Вообще во многих случаях Amazon – хорошая точка для старта, если архитектура построена на небольших хорошо тиражируемых модулях. Однако в случае Pandorama эта схема не сработала, — инфраструктура проекта включает несколько «тяжелых» серверов, занимающихся лингвистическим анализом. Здесь важны большие объемы памяти и быстрые диски, и аренда таких виртуальных машин (с учетом дополнительных мер отказоустойчивости) для Pandorama оказалась слишком дорогой. Другой вариант хостинга ^[3] — это аренда физических серверов с установкой на них своих ВМ. Этот путь оказался более подходящим по цене.

На данный момент, сейчас на физическом уровне Pandorama представляет собой следующую инфраструктуру.

Рисунок 2. Схематичное изображение инфраструктуры Pandorama – физические сервера и подключение к сети

Вся система сбалансирована с точки зрения нагрузки и обладает некоторой избыточностью по объему хранимых данных для отказоустойчивости. Например, если одна из ВМ выйдет из строя, данные не потеряются, а другие ВМ возьмут на нагрузку себя. Где-то это достигается за счет репликации ВМ, где-то за счет репликации данных приложением внутри ВМ (например, в случае MongoDB). Как вы отметили, в инфраструктуре Pandorama нет единого хранилища (дорого), зато все ВМ сбалансированно распределены по физическим серверам.

На каждом из четырех хостов по 128 GB RAM и 2 процессора Xeon E5-2670. С учетом Hyper-Threading получается 32 vCPU. Массив RAID-10 из SATA-дисков для размещения ВМ и данных, которые не требуют быстрого доступа. Для ВМ с активным I/O массив SSD-дисков. Для увеличения срока службы SSD архитекторы Pandorama убедились, что файловые системы гостевых ОС работают с TRIM ^[4] через гипервизор. Конечно, нужно также регулярно проверять состояние самих дисков.

Поскольку каждый из серверов имеет 4 x 1Gb Ethernet NIC (помимо KVM Over IP), внутри инфраструктуры было решено организовать 2 сети. Внешняя сеть через инфраструктуру хостинг ^[3] провайдера подключена к интернету по гигабитному каналу, а внутренняя изолирована. При этом в каждой из сетей объединено 2 x 1Gb c помощью LACP ^[5] в одно логическое соединение. Разделение на внутреннюю и внешнюю сеть позволило удобно и просто исключить влияние внутреннего служебного трафика на внешний «клиентский» трафик. А LACP одновременно повышает как производительность (за счет балансировки TCP-соединений между интерфейсами), так и отказоустойчивость за счет резервирования каналов.

Логически инфраструктуру Pandorama можно разделить на 3 отдельных блока.

Рисунок 3. Схематичное изображение инфраструктуры Pandorama «по модулям»

Ядро поставки контента. Загруженность этого блока зависит от количества источников, которые нужно обойти (сейчас около 35 тыс. в день), и количества статей и текстов, которые нужно обработать. Этот блок не должен страдать от пользовательской нагрузки на сайт. И наоборот, Front End, взаимодействующий с пользователем, не должен ощущать проблемы поставки. Эти части разделены. Третий блок, связующий, передает и сохраняет данные.

В Pandorama используется много различных механизмов сбора и обработки текстов и графики, например:

• Краулинг статей с отсеиванием нерелевантного содержимого (подобно тому, как это делается у getpocket.com ^[6] или readability.com ^[7])
• Автоматическое тегирования статей: это про «тортики», а это про «фотоаппараты»
• Нахождение похожих статей или дублей картинок

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

Немного о ядре данных. Промежуточные данные, которые не требуют сохранения, передаются через шину RabbitMQ. Эта шина легкая и неприхотливая. В RabbitMQ есть несколько возможностей по защите от отказов. Можно сделать очереди сообщений транзакционными, т.е. каждое из них принудительно будет сохраняться на диск. Можно установить кластер с зеркалированием очередей. Для Pandorama эти механизмы оказались избыточными, поэтому просто создана холодная копия, реплика ВМ с RabbitMQ на соседнем хосте, которая запуститься, если основная ВМ перестанет работать.

Другое дело базы данных. Основной БД является MongoDB. Для повышения производительности и надежности используются шардинг ^[8], зеркальные реплики ^[9] и резервное копирование, о котором речь пойдет ниже. Одной из проблемных точек является плохо масштабируемая БД SQL. Дело в том, что в Pandorama много кода, который пока не успели перевести на работу с MongoDB. Поэтому SQL в отдельных случаях используется, а его отказоустойчивости удалось добиться за счет горячего резерва — зеркалирования.

А теперь о том, с чем взаимодействуют пользователи — Front-end.

Рисунок 4. Пример персонифицированной ленты Pandorama.

Здесь применяется целый букет технологий повышения надежности и производительности. Есть 2 кластера веб-серверов:

• Первый кластер обслуживает пользователя и генерирует ему персональную ленту контента. Защита от сбоев и балансировка нагрузки выполняется с помощью HAProxy. При этом, чтобы сам экземпляр HAProxy не стал точкой отказа, их развернуто несколько штук с настроенным DNS Round Robin. Это старая добрая ламповая технология, которая просто работает, когда пользователь выбирает случайный IP-адрес из списка. Это позволяет распределять нагрузку без выделенного балансировщика, но как быть с сессией пользователя? Эту проблему решает HAProxy, который знает, на каком из веб-серверов кластера обслуживается текущий пользователь.
• Второй кластер предназначен для отдачи статического контента, где нет понятия сессии пользователя. Тут как раз бы и пригодился DNS Round Robin, однако, к сожалению, CDN ^[10], который используется в Pandorama, эту технологию пока не поддерживает, поэтому в Pandorama настроен NLB ^[11].

Немного слов о CDN. Трафик загрузки картинок во много раз превышает весь остальной трафик с Pandorama. В качестве CDN на Pandorama используется CloudFlare. За исключением нескольких замечаний этот сервис полностью устраивает и позволяет экономить более 85% трафика.

Защита данных от сбоев Pandorama

Вопрос о защите данных и отказоустойчивости возник еще на этапе проектирования инфраструктуры сервиса. В части отказоустойчивости сейчас система настроена таким образом, что при выходе из строя одного физического сервера, оставшиеся три примут нагрузку на себя. В части защиты данных от сбоев Veeam Backup & Replication Cloud Edition ^[2] защищает виртуальную часть инфраструктуры через резервные копии и репликацию ключевых работающих виртуальных машин на соседние хосты.

Как налажена защита данных в Pandorama?

Рисунок 5. Принципы резервирования данных в Pandorama

1. Если приложение внутри ВМ позволяет делать репликацию встроенным способом, то этот функционал и используется. Например, так зеркалируется MongoDB и SQL и синхронизируется кеш картинок в веб-кластере.
2. Если такой возможности нет, то реплицируется вся ВМ, например, RabbitMQ ВМ – раз в 4 часа.
3. Помимо репликации должны быть еще полные и дифференциальные резервные копии… Если приложение позволяет сделать резервную копию с помощью встроенного функционала, то можно пользоваться им, как, например, в случае SQL или сохранения логов web-серверов как отдельных файлов.
4. В противном случае, делается резервная копия всей ВМ. Так, например, команда Pandorama поступает с MongoDB при отсутствии приемлемого backup-решения.
5. Раз в неделю резервные копии ВМ загружаются в облако Amazon Glacier. Причем дедупликация и компрессия в Veeam Backup уменьшают размер резервной копии с 140GB (размер оригинальной ВМ) до 10GB.
6. Прочие резервные копии также отправляются в облако. Тут важно отметить, что, Veeam помогает не только делать резервные копии в виртуальной среде,, но также используется в Pandorama для загрузки в облако других файлов.

По сути, в части защиты данных в Pandorama успешно реализовано правило резервного копирования 3-2-1 ^[12]: копии данных хранятся минимум в трех экземплярах (исходные данные, локальная реплика, и одна копия в облаке), в двух разных физических средах (локально на дисках и в облаке), и одна копия вынесена на внеофисное хранение.

Тестирование восстановления

Об актуальности тестирования восстановления из резервных копий было рассказано ранее в этом посте ^[13]. Команда Pandorama проводит тестирование на восстанавливаемость системы после разного рода «аварий».

Рассматриваются следующие возможные сценарии:

• Отключение одной ВМ или физического сервера. Команда эмулировала разные события, например, отключая ВМ одну за другой или целый хост, и смотрела, как это повлияет на всю систему. В то же время происходила имитация пользовательской нагрузки. Тестирование выявило определенные проблемы, которые позже были устранены.
• Сгорел весь датацентр. Защита данных в случае такого развития событий – это простое резервное копирование в Amazon Glacier. Это худший сценарий, и для Pandorama приемлемо, что восстановление системы будет происходить в течение пары дней. Почему так? Потому что защита с более низким RTO от такой аварии стоит больше, чем стартап может себе позволить, да и в этом нет необходимости.

Заключение

Пример проекта Pandorama еще раз доказывает: что хранение большого объема неструктурированных данных (BigData) и их защита, отказоустойчивость системы, и решения по обеспечению одновременного доступа множества пользователей к Интернет-сервису – все может быть настроено сравнительно просто, функционально, и не дорого по стоимости.

Полезные ссылки:

• Pandorama ^[14] (на англ. языке)
• Правило резервного копирования 3-2-1 ^[12]
• Whiteboard Russia! Виртуализация с нуля ^[15] (видео, длительность 1:27)
• 10 принципов защищенной виртуальной среды ^[16] (видео, длительность 1:20)
• Сотни виртуальных машин: рекомендации по защите данных ^[17]
• 10 рекомендаций по мониторингу среды VMware ^[18]
• С чего начать миллиардную компанию ^[19]

Авторы: Мария Левкина (Veeam) [vMaria ^[20]], Константин Пичугов (Pandorama), Александр Ширманов (Veeam) [sysmetic ^[21]]

Автор: vMaria

Источник ^[22]