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

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



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



    Pandorama

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



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



    image

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



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



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

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



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


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



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



    Рисунок 2. Схематичное изображение инфраструктуры 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 x 1Gb Ethernet NIC (помимо KVM Over IP), внутри инфраструктуры было решено организовать 2 сети. Внешняя сеть через инфраструктуру хостинг провайдера подключена к интернету по гигабитному каналу, а внутренняя изолирована. При этом в каждой из сетей объединено 2 x 1Gb c помощью LACP в одно логическое соединение. Разделение на внутреннюю и внешнюю сеть позволило удобно и просто исключить влияние внутреннего служебного трафика на внешний «клиентский» трафик. А LACP одновременно повышает как производительность (за счет балансировки TCP-соединений между интерфейсами), так и отказоустойчивость за счет резервирования каналов.



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



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

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



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



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



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

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



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



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



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



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

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



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



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

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



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


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



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



    Рисунок 5. Принципы резервирования данных в 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: копии данных хранятся минимум в трех экземплярах (исходные данные, локальная реплика, и одна копия в облаке), в двух разных физических средах (локально на дисках и в облаке), и одна копия вынесена на внеофисное хранение.



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


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



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



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

    Заключение


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



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




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

    Veeam Software
    203,00
    Продукты для резервного копирования информации
    Поделиться публикацией

    Комментарии 25

      +1
      Отключение одной ВМ или физического сервера. Команда эмулировала разные события, например, отключая ВМ одну за другой или целый хост, и смотрела, как это повлияет на всю систему. В то же время происходила имитация пользовательской нагрузки. Тестирование выявило определенные проблемы, которые позже были устранены.

      Какие проблемы? И как устраняли? Можно подробности?
        0
        проблемы были разные, начиная от некорректных условий переключения на резервный SQL до проблемы, что CDN, что он продолжал стягивать картинки с отключенного сервера статики. про какую часть проблем подробнее рассказать?
          +1
          Желательно обо всех.
            +3
            в процессе подготовки к релизу, был составлен список что может упасть:
            -picture store — мы планировали использовать DFS, но после не тестов выяснилось, что там иногда начинает тупить репликация — не справляться. было решено вынести сохранение картинок на уровень приложения(краулер пытается сохранить картинку на диск на оба сервера), не очень красивое решение, но оно оправдано тем, что у нас нет файлового хранилища

            -haproxy — если пользователь был залогинен, прокси могла выставить куку на рандомный сервер, решили выносом логики выставления куки на фронтэнд

            -CDN первый наш CDN падал, в итоге перешли на cloudfare но там была проблема, что брался один из из списка, в итоге на picture store навешали NLB что бы внешний IP был общий

            — Была проблема с логикой старта ВМ, в некоторых случаях(теоретических), у нас могла пропасть внутреняя сеть, но остаться внешняя сеть, в данном случае ВМ стартовали и поулчалось, например что раббита у нас было 2 на одном адресе после восстановления сети… что есть плохо

            — с SQL была проблема, рассматривали вначале автоматическое переключение между серверами, при помощи 3 стороны witness, но т.к. у нас база в асинхронном режиме, то решили использовать скрипт, который переключает в одном направление primary сервер, а восстаналивать потом ручками, вдруг конфликты будут.

            во время тестирования, параллельно смотрели как себя ведет система для конечного пользователя. Самое страшное для нас это падение SQL основного, тогда даунтайм будет до 15-30 минут, остальное для пользователя проходит не заметно. SQL кластер, было бы лучше равернуть, но он упирается в отсутствие файлового хранилища
        0
        При этом, чтобы сам экземпляр HAProxy не стал точкой отказа, их развернуто несколько штук с настроенным DNS Round Robin. Это старая добрая ламповая технология, которая просто работает, когда пользователь выбирает случайный IP-адрес из списка.

        Т.е. если один из HAProxy упадет, то каждый N-ый запрос пользователя не будет обрабатываться, т.к. DNS севрер не будет знать какой из HAProxy упал? А если и будет знать, то пройдёт какое-то время перед тем как DNS обновится на стороне пользователя?
          +1
          в статье небольшая неточность есть, а именно: haproxy еще установлен heartbeat, который контролирует, что все IP, на которых весит сайт находятся на живой ноде. т.е. в случае падение одной из проксей, внешний упавшей IP будет авотматически поднят на другой проксе
            0
            Используется ли в вашем случае conntrackd (или аналоги), чтобы восстанавливать сессии?
              0
              фактически пользователь попадает всегда на один и тот же фронтэнд, если он находится в работоспособном состояние, а прокси направляет его на нужный, в зависимости от куки. Если фронтэнд упадет, то пользовательская сессия пропадает, в случае падения прокси переключение составляет в пределах 1-5с, Пользователь должен попадать на тот же сервер т.к. генерация индивидуальной ленты на лету требует ресурсов и у нас их нет лишних. При логине, мы, конечно, проверяем на каком сервере уже залогинен пользователь.
                0
                Для парсинга кук HAProxy работает в режиме HTTP? Если кук много, то откуда HAProxy понимает в какой backend отправлять пользователя? Используется какое-то хранилище?
                  0
                  да, конечно в режиме HTTP работает.https трафик тоже на прокси разбирается и по http идет на frontend

                  про много кук не понял, можно пояснить?
                  смотрится значение куки, и в зависимости от значения, направляется на нужный сервер, если не валидное значение, то на случайный север отправляется, и frintend выставит нужное значение

                  P.S. у нас на проекте сложилась, такая терминология: backend — 40 сервисов, которые обеспечивают поставку и прочее, frontend — сайт, который генерирует пользовательскую ленту, прокси — балансирует нагрузку между серверами frontend.
                    0
                    Я полагал, что данные о сервере в куке зашифрованы. Теперь увидел, что они задаются в явном виде. Т.е. задав неправильную куку SERVERID=BZG-FE-02; я могу увеличить нагрузку на backend, который не обслуживал мою сессию изначально?
                      0
                      до того, как пользователь начнет грузится в кэш, будет проверено, не залогинен ли пользователь уже, если да, то кука будет изменена, и пользователь попадет на нужный сервер.
                        0
                        Спасибо за ответы, интересно. В любом случае скрытие названий backend'ов в куках не повредит.
                          0
                          Спасибо! Подумаем над этим.
          0
          Немного не по теме, но на стартовой странице кнопки и speech-bubble вроде бы низкого разрешения, особенно текст. Или только у меня?
            0
            Возможно у Вас retina-дисплей. Мы еще не оптимизировали для них картинки.
              0
              Вроде бы нет, обычный дисплей, 1920x1200, 17 дюймов, 131ppi
                0
                Возможно что-то с версткой, мы посмотрим. Если Вас не затруднит, пришлите скриншот на kp(ат)deepdox.ru. Плюс, если возможно, дайте знать какое окружение (платформа, браузер и т.п.)
                  0
                  Написал.
            0
            Пытался зарегистрироваться, линк активации попал в gmail spam
              0
              Да, действительно. Пока не удается нам понять почему так про нас gmail думает. DKIM — используем. В письмах рассылки, как и положено, внизу есть unsubscribe-ссылка. Unsubscribe Rate примерно 0.10%, SPAM SCORE у писем активации 1.259 almost perfect.
                0
                может из-за использование majljet?
                  0
                  Возможно, мы рассматривали в качестве кандидатов MailJet и SendGrid. Майлджет нам понравился удобной статистикой и мы остановились на нем. Сейчас пытаемся с их поддержкой по этому вопросу найти общий язык. Если не получится, то попробуем перейти на SendGrid или поискать кого-нибудь еще.
              0
              Если не секрет, то какая именно SQL база использовалась?
              Та же PostgreSQL не уступает MongoDB/
                0
                Использовалась MongoDB (NOSQL) и MSSQL Server в качестве реляционного транзакционного хранилища.

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

              Самое читаемое