Как и обещали, мы начали переводить некоторые посты из англоязычного Техноблога 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, локальное хранилище и т. д.) вместо того, чтобы применить новейшие рецепты?
Мы постараемся поподробнее ответить на эти вопросы в ближайшие несколько месяцев.
