Обзор архитектуры сервиса Evernote

    image
    Как и обещали, мы начали переводить некоторые посты из англоязычного Техноблога Evernote, в котором наши инженеры и разработчики рассказывают о некоторых подробностях технической реализации сервиса, делятся историями и просто интересными фактами из своей работы.

    Сегодня мы хотели бы начать обзор архитектуры Evernote с общего представления о структуре сервиса. Сейчас мы не будем вдаваться в детали относительно каждого компонента, оставив это для будущих постов.

    Начнем со схемы, представленной выше. Вся указанная там статистика приведена на 17 мая 2011 года.

    Сеть: Практически весь трафик в/из Evernote идет на www.evernote.com через HTTPS-порт 443. Он включает, как всю «веб-активность», так и синхронизацию со всеми программными клиентами через наш API на базе Thrift. В общей сложности, генерируется порядка 150 млн. HTTPS-запросов в сутки с пиковым трафиком около 250 Мбит/с. Особенно «рада» этому обстоятельству наша ночная смена администраторов, поскольку ежедевный пик приходится примерно на 6:30 утра по тихоокеанскому времени.

    Мы используем BGP, чтобы отправлять трафик напрямую через полностью независимую сеть каналов, обеспечиваемую нашим основным (NTT) и дополнительным (Level 3) провайдерами. Он фильтруется через Vyatta на пути к балансировщикам нагрузки A10, которые мы установили в январе, когда достигли предела производительности SSL для наших старых балансировщиков. Нам пока вполне удобно обрабатывать существующий трафик, используя один AX 2500 плюс отказоустойчивый сервер, но мы готовимся протестировать их конфигурацию N+1 при создании нашего кластера, чтобы быть готовыми к будущему росту.

    Шарды: Ядром сервиса Evernote является ферма серверов, которые мы называем шардами (shards). Каждый шард обрабатывает все данные и весь трафик (веб и API) для когорты из 100 000 пользователей Evernote. Поскольку у нас уже более 9 млн. пользователей, получается около 90 шардов.

    Каждый шард — это пара серверов SuperMicro с двухъядерными процессорами Intel, огромным объемом оперативной памяти и полностью забитыми промышленными дисками Seagate, сконфигурированными в зеркальные RAID-массивы. Во главе каждого сервера у нас работает хост Debian, которые управляет парой виртуальных машин Xen. В основной виртуальной машине запущено ядро из следующего набора приложений: Debian + Java 6 + Tomcat +Hibernate + Ehcache + Stripes + GWT + MySQL (для метаданных) + иерархические локальные файловые системы (для файловых данных).

    Все пользовательские данные в основной виртуальной машине на одном сервере синхронно дублируются в дополнительной машине на другом сервере с помощью DRBD. Это означает, что каждый байт пользовательских данных хранится, как минимум, на четырех различных промышленных дисках, физически расположенных на двух разных серверах. И добавьте к этому ночное резервное копирование. Если у нас возникает какая-либо проблема с сервером, мы можем перебросить работу с основной виртуальной машины на дополнительную, расположенную на другом сервере, с минимальным временем простоя, с помощью Heartbeat.

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

    Львиная доля работы по направлению пользователей на их шарды приходится на балансировщики нагрузки, у которых есть набор инструкций по поиску шарда с помощью URL и/или cookies.

    UserStore: Хотя подавляющее большинство всех данных хранится на логически независимых шардах (“NoteStore”), все они связаны с единой базой аккаунтов “UserStore” (также работает на MySQL) с небольшим количеством информации о каждом аккаунте, такой как имя пользователя, MD5-функция от пароля и идентификатор шарда пользователя. Эта база данных достаточно мала, чтобы помещаться в оперативной памяти, но мы при этом обеспечиваем такое же надежное ее резервирование с помощью аналогичной комбинации зеркальных RAID и репликаций через DRBD для вторичного и ночного резервного копирования.

    Ферма распознавания изображений: Для того чтобы обеспечить поиск слов внутри изображений в ваших заметках, мы выделили пул из 28 серверов, которые ежедневно используют свои 8-ядерные процессоры для обработки новых изображений. В напряженные дни поток может достигать 1,3 или 1,4 млн. отдельных изображений. В настоящее время там используется сочетание Linux и Windows, но уже на днях мы планируем завершить миграцию на Debian, чтобы избавиться от лишних зависимостей.

    Эти сервера обеспечивают работу процесса распознавания, который мы называем AIR (“Advanced Imaging and Recognition”). Софт для него был разработан нашей R&D-командой. Это ПО обрабатывает каждое изображение, идентифицирует области, содержащие текст и затем пытается составить взвешенный список возможных совпадений для каждого слова с использованием “распознавательных движков”, которые генерируют наборы предположений. В работе используются как механизмы, разработанные нашей командой, которая специализируется на AIR (например, распознавание рукописного текста), так и лицензированные технологии от коммерческих партнеров, имеющих лучшие в своей отрасли разработки.

    Другие службы: Все вышеупомянутые серверы парами установлены в стойках нашего дата-центра в городе Санта-Клара, Калифорния. В дополнение к аппаратному обеспечению, которое обеспечивает базовую работу сервиса, у нас также есть небольшие группы серверов для более простых задач, которые требуют один или два сервера или виртуальных машин Xen. Например, работу нашего SMTP-шлюза для входящей почты обеспечивает пара серверов на Debian с Postfix и специальным обработчиком почты, написанным на Java, установленным поверх Dwarf. Наш Twitter-шлюз для возможности отправки заметок в свой аккаунт с помощью @myen — это просто небольшой скрипт, использующий twitter4j.

    Наш корпоративный сайт работает на Apache, блоги — на WordPress. Большую часть нашей внутренней топологии резервирования обеспечивает продукция HP. Для управления конфигурированием мы используем Puppet, а для мониторинга — Zabbix, Opsview и AlertSite. Ночное резервное копирование обеспечивается комбинацией разного ПО, которое передает данные по выделенному гигабитному каналу на резервный дата-центр.

    Постойте, а зачем? Мы понимаем, что этот пост рождает много очевидных вопросов о том, почему мы выбрали X, а не Y в самых разных ситуациях. Почему мы выбрали собственные сервера вместо использования услуг «облачного» провайдера? Почему мы предпочли старое ПО (Java, SQL, локальное хранилище и т. д.) вместо того, чтобы применить новейшие рецепты?

    Мы постараемся поподробнее ответить на эти вопросы в ближайшие несколько месяцев.
    Evernote
    0,00
    Evernote
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +1
      Сейчас у вас распознаванием голоса в заметках занимается партнёр.
      Планируете ли реализовать подобный функционал своими силами?
      Или, например, купить этого партнёра, и включить его наработки в базовую поставку?
        0
        Пока покупать голосовые сервисы мы не намерены (и строить свои пока тоже): дело в том, что 100%-софтверных и приемлемых по качеству (хотя бы на уровне нашего распознавания изображений) технологий распознавания голоса пока в природе нет (нам о них не известно). Если появятся такие решения, которые можно приобрести/интегрировать, тогда будем смотреть. Разумеется, встроенное распознавание речи в Evernote было бы очень кстати.
        +8
        Спасибо, что поделились, я очень люблю подобные статьи. Живой, конкретный пример реализации.
          0
          По кешированию.
          Насколько я понял по картинке, отдельной фермы кеширующих серверов нет, т.е. используются in-memory EhCache инстансы на серверах-шардах. Таким образом, кеши существуют в рамках отдельных шард и помещаются в память отдельной машины (не потому ли там столько памяти?).
          Используете ли вы EhCache как кеш второго уровня Hibernate, или у вас собственный слой перед DAO-уровнем, где вы программно работаете с EhCache, или кеш включен как-то иначе?

          В целом и короче говоря, было бы интересно узнать о деталях принятой у вас стратегии кеширования, а также верны ли мои предположения выше.
            0
            Мы попросим поподробнее рассказать о кешировании в одном из будущих постов нашего системного архитектора, Дейва Энгберга (Dave Engberg), который и ведет оригинальный блог на английском.

            Либо, что еще лучше, можно задать ему вопрос напрямую в комментариях к англоязычному посту — он старается подробно отвечать на все вопросы.
              +1
              Задал вопросы там. Если будет что-то неочевидное — перепишу ответы сюда.

              Кстати, какого плана вопросы имеет смысл писать сюда, на хабр?
                0
                Мы тут больше по продуктам, клиентам, фичам и API / Site Memory. Что касается низкоуровневой архитектуры и вопросов по конфигурации серверного ПО, упомянутого в этой обзорной статье, то это лучше обращаться к непосредственному автору (Дейву).
            0
            а что значит на картинке 28+?
            20+ еще понятно, что круглое число + хвостик (1, 2, 3, ...), а вот с точным числом 28 не совсем ясно.
              0
              Могу предположить, что это означает, что число таких серверов непрерывно растет (как и «90+» в случае с шардами). Т.е. на момент подготовки материала публикации было 90 шардов и 28 AIR-серверов соответственно, но спустя всего несколько дней их количество уже могло увеличиться.
              0
              Спасибо за интересный материал!

              Скажите, происходит ли перераспределение пользователей по шардам, чтобы нагрузка на них была равномерной?
                +2
                При таком количестве пользователей (100 тыс. на шард) сильных перекосов по нагрузке быть не должно (это как средняя температура по палате). Скорее могу предположить, что при необходимости шарды будут периодически переезжать на физически другие ноды (более быстрые, современные, с большего размера накопителями), но при этом все пользователи так и будут идти когортами, без «расселения» по соседним шардам.

                К тому же наша архитектура такова, что ссылки на заметки, например (новая функция, которую мы будем скоро запускать) содержат только GUID заметки, но и ID шарда (что-то типа evernote://shard/guid/), так что просто перенеся пользователя на другой шард мы тем самым побьем эти ссылки. Поэтому перенос пользователей на другие шарды маловероятен.
                  0
                  Очепятка: "… содержат *не* только GUID заметки ..."
                0
                Если ли планы создания клиента под WP7 и BlackBerry (Tablet)
                  0
                  Разработка клиента для WP7 в процессе, планшетов Blackberry пока в плане нет
                  0
                  Напомните пожалуйста, в чем схему сети рисовали.

                  Помню что там-же рисовал, но где именно не помню :(
                    0
                    Может и визио, со своим набором фигур.
                      0
                      Нет, это не visio. Это браузерная такая штуковина на флеше написанная.
                  –1
                  Спасибо, очень увлекательно. Но у меня возникает один вопрос: Вы открыли всю вашу «внутреннюю кухню», рассказали что у Вас как и где храниться. Правильно ли это с точки зрения безопасности? (Потому что знаем, что и в Хабре есть очень «любопытные» люди)
                    0
                    Где вы тут видите угрозу безопасности?
                      0
                      «Security through obscurity» или «безопасность путем сокрытия» — не самый лучший способ достижения той самой безопасности. То, что мы не боимся рассказывать о внутренностях, означает, что мы уверены в правильности применения этих технологий, что настоящей безопасности уделяем достаточно внимания, и что знание внутренней кухни третьими лицами на фактическую нашу безопасность не влияет.
                        0
                        Тогда, будучи активным пользователем вашего прекрасного сервиса, что могу сказать? Молодцы!
                      0
                      А почему Java и SQL это старое ПО? А что тогда новое? NoSQL и node.js что-ли? Мне кажется если почитать фундаментальные книжки по SQL(например Дейта) или по языкам и компиляторам, то возникает вопрос какое ПО ещё старое. Правильнее было бы сказать «классическое ПО».

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

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