Insight IT

Архитектура Одноклассников

Иван Блинков — Tue, 22 Mar 2011 00:17:00 +0300

Сегодня представители Одноклассников рассказали о накопленном за 5 лет опыте по поддержанию высоконагруженного проекта. Была опубликована довольно детальная информация о том, как устроена эта социальная сеть для аудитории "постарше". Далее можно прочитать мою версию материала, либо перейти на оригинал по сссылке.

Платформа

Windows и openSUSE - основные операционные системы
Java - основной язык программирования
С/С++ - для некоторых модулей
GWT - реализация динамического веб-интерфейса
Apache Tomcat - сервера приложений
JBoss 4 - сервера бизнес-логики
LVS и IPVS - балансировка нагрузки
MS SQL 2005 и 2008 - основная СУБД
BerkleyDB - дополнительная СУБД
Apache Lucene - индексация и поиск текстовой информации

Статистика

До 2.8 млн. пользователей онлайн в часы пик
7,5 миллиардов запросов в день (150 000 запросов в секунду в часы пик)
2 400 серверов и систем хранения данных, из которых 150 являются веб-серверами
Сетевой трафик в час пик: 32 Gb/s

Оборудование

Сервера используются двухпроцессорные с 4 ядрами, объемом памяти от 4 до 48 Гб. В зависимости от роли сервера данные хранятся либо в памяти, либо на дисках, либо на внешних системах хранения данных.

Все оборудование размещено в 3 датацентрах, объединенных в оптическое кольцо. На данный момент на каждом из маршрутов пропускная способность составляет 30Гбит/с. Каждый из маршрутов состоит из физически независимых друг от друга оптоволоконных пар, которые агрегируются в общую “трубу” на корневых маршрутизаторах.

Сеть физически разделена на внутреннюю и внешнюю, разные интерфейсы серверов подключены в разные коммутаторы и работают в разных сетях. По внешней сети HTTP сервера, общаются с Интернетом, по внутренней сети все сервера общаются между собой. Топология внутренней сети – звезда. Сервера подключены в L2 коммутаторы (access switches), которые, в свою очередь, подключены как минимум двумя гигабитными линками к aggregation стеку маршрутизаторов. Каждый линк идет к отдельному коммутатору в стеке. Для того, чтобы эта схема работала, используется протокол RSTP. При необходимости, подключения access коммутаторов к agregation стеку осуществляются более чем двумя линками с использованием link aggregation портов. Aggregation коммутаторы подключены 10Гб линками в корневые маршрутизаторы, которые обеспечивают как связь между датацентрами, так и связь с внешним миром. Используются коммутаторы и маршрутизаторы от компании Cisco.

Для связи с внешним миром используются прямые подключения с несколькими крупнейшими операторами связи, общий сетевой трафик в часы пик доходит до 32Гбит/с.

Архитектура

Архитектура проекта имеет традиционную многоуровневую структуру:

презентационный уровень;
уровень бизнес-логики;
уровень кэширования;
уровень баз данных;
уровень инфраструктуры (логирование, конфигурация и мониторинг).

Код проекта в целом написан на Java, но есть исключения в виде модулей для кэширования на C и C++. Java был выбран так как он является удобным языком для разработки, доступно множество наработок в различных сферах, библиотек и opensource проектов.

Презентационный уровень

Используем собственный фреймворк, позволяющий строить композицию страниц на языке Jаvа, с использованием собственные GUI фабрик (для оформления текста, списков, таблиц и портлетов).
Страницы состоят из независимых блоков (обычно портлетов), что позволяет обновлять информацию на них частями с помощью AJAX запросов.
При данном подходе одновременно обеспечивается минимум перезагрузок страниц для пользователей с включенным JavaScript, так и полная работоспособность сайта для пользователей, у которых он отключен.
Google Web Toolkit используется для реализации функциональные компонент, таких как Сообщения, Обсуждения и Оповещения, а также все динамических элементов (меню шорткатов, метки на фотографиях, сортировка фотографий, ротация подарков и.т.д.). В GWT используются UIBinder и HTMLPanel для создания интерфейсов.
Кешируются все внешние ресурсы (Expires и Cache-Control заголовки). CSS и JavaScript файлы минимизируются и сжимаются (gzip).
Для уменьшения количества HTTP запросов с браузера, все JavaScript и CSS файлы объединяются в один. Маленькие графические изображения объединяются в спрайты.
При загрузке страницы скачиваются только те ресурсы, которые на самом деле необходимы для начала работы.
Никаких универсальных CSS селекторов. Стараются не использовать типовые селекторы (по имени тэга), что повышает скорость отрисовки страниц внутри браузера.
Если необходимы CSS expressions, то пишутся «одноразовые». По возможности избегаются фильтры.
Кешируется обращения к DOM дереву, а так же свойства элементов, приводящие к reflow. Обновляется DOM дерево в «оффлайне».

Уровень бизнес-логики

На уровне бизнес логики располагаются около 25 типов серверов и компонентов, общающихся между собой через удаленные интерфейсы. Каждую секунду происходит около 3 миллионов удаленных запросов между этими модулями. Сервера на уровне бизнес логики разбиты на группы. Каждая группа обрабатывает различные события. Есть механизм маршрутизации событий, то есть любое событие или группу событий можно выделить и направить на обработку на определенную группу серверов. При общении серверов между собой используется свое решение, основанное на JBoss Remoting.

Уровень кэширования

Для кэширования данных используется самописный модуль odnoklassniki-cache. Он предоставляет возможность хранения данных в памяти средствами Java Unsafe. Кэшируются все данные, к которым происходит частое обращение, например: профили пользователей, списки участников сообществ, информация о самих сообществах, граф связей пользователей и групп, праздники, мета информация о фотографиях и многое другое.Для хранения больших объемов данных в памяти используется память Java off heap memory для снятия ненужной нагрузки с сборщика мусора. Кеши могут использовать локальный диск для хранения данных, что превращает их в высокопроизводительный сервер БД. Кеш сервера, кроме обычных операций ключ-значение, могут выполнять запросы по данным, хранящимся в памяти, минимизируют таким образом передачу данных по сети. Используется map-reduce для выполнения запросов и операций на кластере. В особо сложных случаях, например для реализации запросов по социальному графу, используется язык C. Это помогает повысить производительность.

Данные распределяются между кластерами кеш серверов, а также используется репликация партиций для обеспечения надежности. Иногда требования к быстродействию настолько велики, что используются локальные короткоживущие кеши данных полученных с кеш серверов, расположенные непосредственно в памяти серверов бизнес логики.

Для примера, один сервер, кэширующий граф связей пользователей, в час пик может обработать около 16 600 запросов в секунду. Процессоры при этом заняты до 7%, максимальный load average за 5 минут — 1.2. Количество вершин графа - более 85 миллионов, связей 2.5 миллиарда. В памяти граф занимает 30 GB.

Уровень баз данных

Суммарный объем данных без резервирования составляет 160Тб. Используются два решения для хранения данных: MS SQL и BerkeleyDB. Данные хранятся в нескольких копиях, в зависимости от их типа от двух до четырех. Полное резервное копирование всех данных осуществляется раз в сутки, плюс каждые 15 минут делаются резервные копии новых данных. В результате максимально возможная потеря данных составляет 15 минут.

Сервера с MS SQL объединены в failover кластера, при выходе из строя одного из серверов, находящийся в режиме ожидания сервер берет на себя его функции. Общение с MS SQL происходит посредством JDBC драйверов.

Используются как вертикальное, так и горизонтальное разбиение данных, т.е. разные группы таблиц располагаются на разных серверах (вертикальное партиционирование), а данные больших таблицы дополнительно распределяются между серверами (горизонтальное партиционирование). Встроенный в СУБД аппарат партиционирования не используется — весь процесс реализован на уровне бизнес-логики. Распределенные транзакции не используются — всё только в пределах одного сервера. Для обеспечения целостности, связанные данные помещаются на один сервер или, если это невозможно, дополнительно разрабатывается логика обеспечения целостности данных. В запросах к БД не используются JOIN даже среди локальных таблиц для минимизации нагрузки на CPU. Вместо этого используется денормализация данных или JOIN происходят на уровне бизнес сервисов, что позволяет осуществлять JOIN как с данными из баз данных, так и с данными из кэша. При проектировании структуры данных не используются внешние ключи, хранимые процедуры и триггеры. Опять же для снижения потребления вычислительных ресурсов на серверах баз данных. SQL операторы DELETE также используются с осторожностью — это самая тяжелая операция. Данные удаляются чаще всего через маркер: запись сначала отмечается как удаленная, а потом удаляется окончательно с помощью фонового процесса. Широко используются индексы, как обычные, так и кластерные. Последние для оптимизации наиболее высокочастотных запросов в таблицу.

Используется C реализация BerkleyDB версии 4.5. Для работы с BerkleydDB используется своя библиотека, позволяющая организовывать двухнодовые master-slave кластера с использованием родной BDB репликация. Запись происходит только в master, чтение происходит с обеих нод. Данные хранятся в tmpfs, transaction логи сохраняются на дисках. Резервная копия логов делается каждые 15 минут. Сервера одного кластера размещены на разных лучах питания дабы не потерять обе копии одновременно. Помимо прочего, BerkleyDB используется и в роли очереди заданий.

Внутри системы используется взвешенный round robin, а также вертикальное и горизонтальное разбиение данных как на уровне СУБД, так и на уровне кэширования.

В разработке новое решение для хранения данных, так как необходим еще более быстрый и надежный доступ к данным.

Уровень инфраструктуры

Для агрегации статистики используется собственная библиотека, основанная на log4j. Сохраняется такая информация, как количество вызовов, среднее, максимальное и минимальное время выполнения, количество ошибок. Данные сохраняются во временные базы, но раз в минуту данные переносятся из них в общий склад данных (data warehouse), а временные базы очищаются. Сам склад реализован на базе решений от Microsoft: MS SQL 2008 и сиситема генерации отчетов Reporting Services. Он расположен на 13 серверах, находящихся в отдельной от production среде. Некоторые из них отвечают за статистику в реальном времени, а некоторые за ведение и предоставление доступа к архиву. Общий объем статистических данных составляет 13Тб. Планируется внедрение многомерного анализа статистики на основе OLAP.

Управление сервисами происходит через самописную централизованную систему конфигурации. Через веб-интерфейс доступно изменение расположения портлетов, конфигурации кластеров, изменение логики сервисов и прочее. Вся конфигурация сохраняется в базе данных. Каждый из серверов периодически проверяет, есть ли обновления для приложений, которые на нем запущены, и, если есть, применяет их.

Мониторинг логически разделен на две части:

Мониторинг сервисов и компонентов
Мониторинг ресурсов, оборудования и сети

Система мониторинга сервисов также самописная и основывается на оперативных данных с упомянутого выше склада. Мониторинг ресурсов и здоровья оборудования же онован на Zabbix, а статистика по использованию ресурсов серверов и сети накапливаетя в Cacti. Для предпринятия мер по устранению чрезвычайных ситуаций работают дежурные, которые следят за всеми основными параметрами. Оповещения о наиболее критичных аномалиях приходят по смс, остальные оповещения отсылаются по емейлу.

Команда

Над проектом работают около 70 технических специалистов:

40 разработчиков;
20 системных администраторов и инженеров;
8 тестеров.

Все разработчики разделены на небольшие команды до 3х человек. Каждая из команд работает автономно и разрабатывает либо какой-то новый сервис, либо работает над улучшением существующих. В каждой команде есть технический лидер или архитектор, который ответственен за архитектуру сервиса, выбор технологий и подходов. На разных этапах к команде могут примыкать дизайнеры, тестеры и системные администраторы.

Разработка ведется итерациями в несколько недель. Как пример жизненного цикла разработки можно привести 3х недельный цикл:

определение архитектуры;
разработка, тестирование на компьютерах разработчиков;
тестирование на pre-production среде, релиз на production среду.

Практически весь новый функционал делается «отключаемым», типичный процесс запуска новой функциональной возможности:

Функционал разрабатывается и попадает в production релиз;
Через централизованную систему конфигурации функционал включается для небольшой части пользователей;
Анализируется статистика активности пользователей, нагрузка на инфраструктуру;
Если предыдущий этап прошел успешно, функционал включается постепенно для все большей аудитории;
Если в процессе запуска собранная статистика выглядет неудовлетворительно, либо непозволительно вырастает нагрузка на инфраструктуру, то функционал отключается, анализируются причины, исправляются ошибки, происходит оптимизация и все повторяется с начала.

Подводим итоги

В отличии от остальных популярных социальных сетей в Одноклассниках используются технологии, рассчитанные в первую очередь на корпоративный рынок, начиная от обоих СУБД и заканчивая операционными системами.
Во многом этот факт обуславливает комплексный подход к генерации пользовательского интерфейса, не слишком высокую производительность и многие другие особенности этой социальной сети.
Использование "тяжелых" технологий с самого начала оставило Одноклассники с большим количеством доставшегося по наследству от ранних версий устаревшего кода и купленных давно лицензий на проприетарный софт, которые выступают в роли оков, от которых довольно сложно избавиться.
Возможно эти факторы и являются одними из основных препятствий на пути к завоеванию большей доли рынка и быстрому развитию платформы как в функциональном, так и техническом плане.

Архитектура LinkedIn

Иван Блинков — Thu, 11 Sep 2008 04:00:00 +0400

LinkedIn является крупнейшей в мире социальной сетью для профессионалов. Популярность этого проекта может быть далека, от более общетематических социальных сетей, таких как, скажем Facebook, но, тем не менее, нагрузка на серверную часть проекта создается пользователями серьезная. О том как этот проект с ней справляется и пойдет речь далее.

Предисловие

Сообщение о публикации двух презентаций c JavaOne 2008 о LinkedIn и их обобщении от Overn Hurvitz пронеслось по русскоязычным новостным ресурсам уже достаточно давно, но время черкнуть пару строк обо всем этом нашлось у меня только сейчас.

Статистика

22 миллиона пользователей;
4+ миллиона уникальных посетителей в день;
40 миллионов просмотров страниц в день;
2 миллиона поисковых запросов в день;
ежедневно отправляются 250 тысяч приглашений;
1 миллион ответов в день;
2 миллиона электронных сообщений ежедневно.

Платформа

Solaris (как x86, так и SPARC)
Tomcat и Jetty
Oracle и MySQL
Никакого ORM
ActiveMQ для JMS
Lucene в качестве основы для поиска
Spring в роли "клея"

Серверная архитектура

2003-2005

одно монолитное веб-приложение;
одна общая база данных;
сетевой граф кэшируется в памяти в "Облаке";
поиск пользователей реализован с помощью Lucene, он работал на той же машине, что и "Облако", так как поиск был отфильтрован в соответствии с сетью пользователя, таким образом было удобно совмещать эти две функции на одной машине;
веб-приложение напрямую обновляет базу данных, а она, в свою очередь, обновляет "Облако".

2006

Добавлена репликация для уменьшения нагрузки на основную базу данных. Реплики предоставляют данные в режиме "только для чтения", а репликация ведется в асинхронном режиме с помощью дополнительного компонента под названием Databus, с его появлением обновление данных стало выглядеть следующим образом:
- сначала какие-либо изменения происходят в веб-приложении;
- веб-приложение обновляет основную базу данных;
- она, в свою очередь, отправляет обновления на Databus;
- далее уже Databus обновляет: реплики, Облако и поисковый индекс.
Поиск был вынесен на отдельный сервер.

2008

веб-приложение само по себе практически ничего не делает: бизнес логика распределена по отдельным сервисам;
веб-приложение все так же предоставляет пользователям графический интерфейс, но для его генерации она теперь вызывает сервисы;
каждый сервис имеет свою специфическую базу данных (т.е. вертикальное сегментирование);
такой подход позволяет другим приложениям (помимо основного) получать доступ к LinkedIn, такие приложения были созданы для работодателей, рекламных служб, и так далее.

Облако

"Облаком" в LinkedIn называют сервер, который кэширует весь граф социальной сети в памяти;
его размеры: 22 миллиона вершин и 120 миллионов ребер;
занимает 12GB оперативной памяти;
одновременно держится в памяти в 40 экземплярах;
построение Облака из данных, в дисковой системе, занимает 8 часов;
обновления происходят в режиме реального времени с помощью Databus;
во время остановки данные записываются на диск;
кэш реализован с помощью C++, а доступ предоставляется по JNI;
они выбрали именно C++ так как требовалось использовать минимум оперативной памяти, а также, задержки, связанные с Garbage Collection, были неприемлемыми.
размещение всех данных в памяти является ограничением, но, как удалось выяснить в LinkedIn, разбиение графов на части - не самая тривиальная задача.

Облако кэширует целиком весь граф социальной сети LinkedIn, но на практике же пользователям требуется видеть его со своей точки зрения. Данная задача является вычислительно сложной, по-этому она выполняется лишь один раз при создании новой сессии, а затем система поддерживает результат в кэше. Такой подход требует 2 MB оперативной памяти на каждого активного пользователя. В течении сессии такой кэш обновляется только если сам пользователь сделал какие-либо изменения в нем, если же изменение вызвано другими пользователями - владелец сессии не заметит изменений.

Помимо этого используется кэширование профилей пользователей средствами EHcache. Одновременно в памяти хранится до 2 миллионов профилей (из 22 миллионов). Изначально планировалось использовать алгоритм LFU, но оказалось, что иногда EHcache зависал секунд на 30 во время перерасчета LFU, таким образом было принято решение о использовании вместо него алгоритма LRU.

Архитектура коммуникации

Как известно, пользователи практически любой социальной сети генерируют огромное количество сообщений в единицу времени, причем каждый тип сообщений обычно требует индивидуального подхода, но в целом их можно разделить на две категории: постоянные и временные. В LinkedIn разработчики построили по отдельному сервису, для обработки каждой из этих категорий. Каждый из них определенно заслуживает отдельного внимания, так как общего в них мало.

Сервис постоянных сообщений

Этот коммуникационный сервис выполняет все операции, связанные с постоянными сообщениями: приватными сообщениями и электронной почтой. Перед ним ставится вполне тривиальный ряд задач: доставлять сообщения получателям и сохранять их на постоянной основе, но на самом деле этим все не ограничивается: должны также поддерживаться, скажем, доставка сообщений с задержкой, массовые рассылки, отмена отправки сообщения, возможность добавления в сообщения какого-либо интерактивного контента. Реализован он был примерно следующим образом:

вся система работает асинхронно и активно использует JMS;
клиенты отправляют сообщения так же через JMS;
далее сообщения перенаправляются с помощью сервиса маршрутизации в соответствующий почтовый ящик или напрямую в обработку электронной почты;
доставка сообщений происходит как с помощью Pull (клиенты запрашивают свои сообщения), так и с использованием Push (т.е. отправки сообщений);
помимо этого используется Spring с их собственными закрытыми расширениями, использующими HTTP-RPC.

Приемы, способствующие масштабируемости

Функциональное сегментирование: отправленные, полученные, архивные сообщения. (т.е. вертикальное сегментирование)
Классовое сегментирование: пользовательские, гостевые, корпоративные почтовые ящики.
Сегментирование по диапазонам: по идентификаторам пользователей или по лексикографическим диапазонам самих сообщений. (т.е. горизонтальное сегментирование)
Асинхронное выполнение операций.

Сервис сетевых обновлений

Этот сервис обеспечивает работу любых временных уведомлений, например, вызванных изменением статуса пользователей в контакт-листах. Такие сообщения должны с течением времени удаляться из-за быстрой потери актуальности, а также должна поддерживаться группировка и приоритезация сообщений. Функционирование этого сервиса оказалось не настолько очевидно, по сравнению с предыдущим, так что до итогового варианта было перепробовано масса менее удачных решений, но обо всем по порядку.

Изначальная архитектура (до 2007 года)

используется много серверов, которые могут содержать обновления;
клиенты отправляют запросы на каждый сервис отдельно: вопросы, обновления профилей и т.д.
на сбор всех данных требовалось относительно много времени.

В 2008 году вся эта система поэтапно эволюционировала собственно в сам сервис сетевых обновлений:

Первая итерация

клиент отправляет единственный запрос сервису сетевых обновлений;
этот сервис в свою очередь параллельно отправляет всем остальным сервисам соответствующие запросы.
результаты агрегируются и все вместе возвращаются клиенту;
весь процесс основывается на Pull.

Вторая итерация

стал использоваться метод Push: каждый раз, когда происходит какое-либо событие, они помещаются в пользовательский "почтовый ящик", в момент запроса пользователя ему возвращается просто содержимое, уже ожидающее своего звездного часа в специально том самом "ящике";
такой подход сильно ускоряет процесс чтения, так как на тот момент данные уже готовы;
с другой стороны, какая-то часть данных может так никогда и не понадобиться, что приводит к бесполезным передвижениям данных и лишнему используемому дисковому пространству;
небольшая часть обработки данных все же производится уже в момент запроса пользователя (например, объединение нескольких обновлений от определенного пользователя в одно);
обновления хранятся в CLOB'ах: по одному CLOB'у на каждый тип обновления для каждого пользователя (то есть в сумму около 15 CLOB'ов на каждого пользователя);
сначала использовался размер CLOB'ов равный 8 KB, что было явно больше требуемого и приводило к существенному количеству неиспользуемого дискового пространства.
вместо CLOB'ов можно было бы использовать дополнительные таблици по одной на каждый тип обновлений, но в этом случае пришлось бы постоянно удалять из них устаревшие записи, что было бы чрезвычайно неэффективно.
в дополнение к этому использовался JMX для мониторинга и изменения конфигурации в реальном времени, что оказалось очень удобным и полезным.

Третья итерация

Цель: повысить производительность путем сокращения количества обновлений CLOB'ов, так как они требуют много вычислительных ресурсов.
Был добавлен буфер: колонки в таблицах типа varchar(4000), в которых данные помещались изначально. При полном заполнении ячейки данные перемещаются в CLOB; это позволило на порядок сократить количество их обновлений.
Уменьшен размер самих сообщений об обновлениях.

И напоследок пару советов от LinkedIn

нельзя бесконечно долго ограничиваться одной базой данных: используйте много баз данных как с вертикальным, так и с горизонтальным сегментированием данных;
забудьте о ссылочной целостности и кросс-серверных JOIN'ах;
забудьте о 100% целостности данных;
при большом масштабе издержки могут стать проблемой: оборудование, базы данных, лицензии, системы хранения данных, электроэнергия и так далее;
как только вы станете достаточно крупны и популярны, спаммеры и прочие злые люди не заставят себя долго ждать;
не забывайте про кэширование!!!
используйте асинхронные потоки данных;
аналитика и построение отчетов может стать непростой задачей, постарайтесь задуматься о них заранее в процессе планирования системы;
имейте всегда ввиду, что Ваша система может упасть в любой момент;
не стоит недооценивать траекторию своего роста.

P.S.

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

Кстати если Вы еще не успели подписаться на RSS - сейчас самое время!

Архитектура Mailinator

Иван Блинков — Tue, 24 Jun 2008 18:17:00 +0400

Ваш пьяный друг когда-либо вдохновлял Вас на создание первого в своем роде интернет-сервиса, который пришелся бы по вкусу миллионам пользователей и при этом неприхотливо обрабатывал миллиарды электронных писем ежегодно? Именно так Paul Tyma и создал Mailinator.

Mailinator представляет собой бесплатный, не требующий инсталляции, сервис для разрушения планов злобных спаммеров путем предоставления регистрации "одноразовых" почтовых адресов. Если Вы не не будете публиковать в Сети свой настоящий интернет-адрес - спаммеру не будут слать вам письма, вместо этого они будут спамить Mailinator :-)

Как же Mailinator справляется со своей ролью анти-спам супергероя?

Источники информация

Да-да, это снова перевод статьи от Todd'а (цифры правда не первой свежести, но все же). На что-то более глобальное я в ближайшее время способен не буду, в основном благодаря незаметно подкравшейся сессии и, отчасти, работе.

Платформа

Статистика

Сервис обработал: 1.29 миллиардов электронных писем за 2007 год. 450.74 миллионов за 2006. 280.68 миллионов за 2005.
В период пиковых нагрузок обрабатывается 6.5 миллионов электронных писем в сутки или 4513 сообщений в минуту или 75 в секунду.
Mailinator работает на всего одном весьма средненьком компьютере с AMD Athlon 2GHz процессором, 1 GB оперативной памяти (которая используется не целиком) и низкопроизводительным IDE жестким диском объемом 80 GB. И она в общем-то загружена далеко не полностью.
Mailinator работает месяцами без присмотра и теряется очень небольшое количество сообщений, даже при постоянных спам-атаках и высоких пиковых нагрузках.

Архитектура

Так как система бесплатна, она не должна быть идеальной. Таким образом основные цели:
- Создание системы, которая ценит выживание превыше всего, даже пользователей. Основным ключом является именно выживание, так как Mailinator вынужден ежедневно отражать спам-атаки.
- Предоставить пользователям 99,99% доступность и точность данных. Более высокие гарантии будут существенно менее практичными и приведут к большим затратам. И так как сервис бесплатен, этот небольшой риск для пользователей становится просто частью правил игры.
- Поддержка следующей модели сервиса: пользователь регистрируется где-то, заходит в Mailinator, жмет на пришедшую ссылку и забывает об этом. Это означает, что письма не должны храниться постоянно. Они могут размещаться в оперативной памяти, так как являются временными (живут три-четыре часа). Если Вам нужен обычный настоящий почтовый ящик - воспользуйтесь любым другим соответствующим сервисом.
Изначально письма обрабатывались следующим образом:
- Sendmail получал письмо в общий ящик на диске.
- Java-приложение доставало сообщение используя IMAP и/или POP (с течением времени это менялось) и удаляло их.
- Система загружала все письма в память и оставляла их там.
- Наиболее старые сообщения вытеснялись как только накапливался лимит в 20000 сообщений.
Данный принцип работал вполне неплохо:
- Он стабилен и работал месяцами без каких-либо проблем.
- Использовался практически весь гигабайт оперативной памяти.
- Проблемы начались, когда количество сообщений в сутки начало превышать 800000. Система начала давать сбои из-за использования жесткого диска между Mailinator и email подсистемой.
- Наиболее старые сообщения вытеснялись как только накапливался лимит в 20000 сообщений.
Новая архитектура:
- Идея заключалась в отказе от временного хранения данных на жестком диске путем полного переписывания всей системы с нуля.
- Веб-приложение, почтовый сервер и все хранилище писем функционируют в рамках одной JVM.
- Sendmail был заменен на специально написанный для этого проекта SMTP сервер. Так как природа Mailinator не требовала полноценного SMTP сервера. Mailinator не отправляет писем, основная цель - принимать или отвергать входящие письма. Это является недостатком многоуровневой архитектуры. Она часто является залогом успеха в процессе масштабирования веб-приложения, но порой она может и наоборот полностью убить всю производительность благодаря неверному принятию ответственных решений. Решение о создании собственного SMTP сервера было достаточно интересным и смелым, многие другие руководители проектов вместо этого просто добавили бы дополнительное оборудование в систему. Это не было бы ошибкой, но, согласитесь, создание своего собственного решения задачи - намного более интересный подход.
- Сейчас Mailinator получает почту напрямую, обрабатывает ее и хранит в оперативной памяти. Жесткие диски полностью обходятся и практически не используются.
- Основное их применение - хранение сообщений в случае остановки сервиса для того, чтобы они могли быть восстановлены при запуске.
- Ведение логов было отключено.
- Система использует менее 300 потоков. Это оказалось вполне достаточно.
- При принятии сообщения, система пропускает его через набор фильтров и хранит его в памяти только в том случае, если все фильтры были успешно пройдены.
- Каждый почтовый адрес ограничен только 10 письмами, так что популярные адреса вроде joe@mailinator.com не могут "взорвать" систему.
- Письма не могут превышать 100 kb, а все приложения автоматически уничтожаются. Это позволяет существенно сэкономить в плане используемой оперативной памяти..
Электронные письма сжимаются в оперативной памяти:
- 99% писем никто даже не открывает, компрессия позволяет сэкономить место в оперативной памяти. Письмо разжимается в исходное состояние только если кто-то решает его открыть.
- Mailinator может хранить около 80000 писем в оперативной памяти, используя лишь 300 MB памяти, по сравнению с 20000 писем, занимающих 1 GB без использования компрессии.
- С таким подходом к хранению писем, они живут в среднем 3-4 часа.
- В память поместится и 200000 писем, но на практике это и не требуется.
- Оперативная память ценна, а процессорное время - вовсе нет. Именно из-за этого используется компрессия для экономии памяти и использования излишков вычислительных мощностей.
Mailinator не гарантирует анонимность или приватность:
- Любой пользователь может получить доступ к любому почтовому ящику.
- Отказ от ограничений доступа делает схему работы системы намного более простой.
- Со стороны пользователя такой подход очень прост, так как не требуется абсолютно никакой регистрации. Когда сайт требует ввести почтовый адрес достаточно лишь просто ввести любой адрес Mailinator. Вам не нужно создавать отдельный аккаунт. Банальный ввод адреса создает почтовый ящик. Все просто.
- На практике же, не смотря на вышесказанное, пользователи все же получают изрядную степень приватности.
Стремление к выживанию требует агрессивной борьбы со спамом:
- Mailinator не имеет ничего против спама, но так как спама приходит нереально много, когда он подвергает риску работоспособность сервиса приходится его фильтровать.
- Этот факт привел к правилу: если Вы делаете что-то (получаете спам или что-то еще), что мешает работе системы - Ваши письма не будут приниматься и Вы можете быть временно заблокированы.
Для успешного приема письмо должно пройти следующую цепочку фильтров:
- Все письма, которые не смогли быть доставлены, отклоняются.
- При слишком большом количестве писем с одного IP они перестают приниматься.
- Слишком много писем с одинаковой темой не принимаются.
- Письма, содержащие в заголовках запрещенные сервисом слова, также не попадают в почтовые ящики.
Выживание в условиях наплыва писем с одного IP адреса:
- Для этого типа фильтрации используется AgingHashMap. Когда сервис получает очередное письмо, IP помещается в массив и счетчик, соответствующий этому ключу, увеличивается на единицу в момент получения каждого последующего письма с этого IP.
- Спустя определенное время без получения писем с IP, соответствующие ему счетчик обнуляется.
- Когда счетчик достигает определенного порога, IP блокируется, предотвращая поток сообщений.
- Этим простым методом пользуются многие интернет-ресурсы для защиты различных своих компонентов, например комментариев. В роли хранилища для такого массива при распределенном функционировании системы часто используют memcached.
Защита от "зомби" атак:
- Спам может приходить и с больших координированных сетей с разными IP адресами, как раз участников таких сетей и называют "зомби". Одинаковые письма приходят со множества разных адресов, так что защита по IP адресам становится бессильна.
- Этот фильтр несколько более сложный, чем блокировка по IP, так как требуется достать из письма строку с заголовком, да и их сравнение - несколько ресурсоемкая задача.
- Когда около 20 писем с одинаковыми темами приходят в течении 2 минут, этот заголовок блокируется на час.
- Что интересно, Mailinator не хранит заблокированные темы вечно, так как это значило бы, что этот список неуклонно рос и приходилось бы вечно отслеживать соответствия с ним. Это никак не приемлемо для мимолетной природы Mailinator. Более комплексные алгоритмы защиты от спама нужны лишь только если ставятся цели с более жесткой борьбой со спама, для Mailinator же данный вариант - наиболее эффективный.
- Этим фильтром блокируется около 9% писем.
- Mailinator фильтрует сообщения только по теме и IP, так что системе не приходится прочитывать и анализировать все письмо целиком. Это позволяет неплохо сэкономить на вычислительных ресурсах при достаточно эффективной итоговой фильтрации.
Для уменьшения угрозы DDoS атак:
- Все соединения, неактивные какое-то время обрываются.
- Mailinator отвечает отправителям писем очень медленно, 10, 20 или даже 30 секунд, даже для небольших объемов данных. Это замедляет работу спаммеров, пытающихся отправлять спам как можно быстрее, и заставляет их лишний раз задуматься о целесообразности отправки снова спама на этот адрес. Период ожидания уменьшается во время повышенных нагрузок на сервис, так что письма не теряются из-за этого.

Подводим итоги

Идеальность - всего лишь ловушка. Как много систем были кардинально усложнены лишь для того, чтобы достичь 100%-го результата во всех аспектах. Если Вы участвовали в подобных совещаниях, Вы понимаете о чем идет речь. О нет, мы не можем сделать этого, так как есть 0,01% шанс, что что-то пойдет не так. Лучше спросите себя: насколько неидеальными можно позволить себе быть, чтобы все равно оставаться достаточно неплохим сервисом?
То, что Вы отвергаете, ничуть не менее важно, чем то, что Вы оставляете в системе. Существует масса концепций по построению архитектуры системы. Нужно не только выбрать подходящие, но и отказаться от тех, которые излишни.
Знайте предназначение своей системы и разрабатывайте ее в соответствии с этим. Быть всем для всех значит быть ничем для никого. Временное хранение электронных писем, позволяя небольшой части спама пробиться через фильтры, в совокупности с не 100% временем работы системы производят достаточно хорошее впечатление на пользователей. Построение собственного SMTP-сервера необходимо лишь в случае, если у Вас есть весомые аргументы в пользу того, что он Вам необходим. Далеко не факт, что такая идея придет в голову, возможно выбор пал бы и на более тривиальное решение, связанное просто с добавлением дополнительного оборудования.
Постарайтесь как можно быстрее свести механизм работы системы к наиболее общему случаю. Очень большой процент писем отвергается, так что это оправданно сделать это как можно раньше, чтобы минимизировать ресурсы, требуемые для их обработки. Найдите способ сделать это как можно быстрее в отношении наиболее частых случаев. то очень часто становится важным компонентом стратегии масштабирования.
Эффективность часто означает "постройте это самостоятельно". Готовые решения обычно решают большой спектр задач, но на практике часто нужна лишь небольшая часть функционала, в таких случаях можно написать небольшой компонент с нуля самостоятельно, чтобы он мог выполнять только нужные функции, но более эффективно.
Небольшое количество сбоев - вполне допустимо. Все заблокированные адреса не должны быть запомнены навечно. Позвольте этим спискам генерироваться на основе локальных данных, а не глобального состояния. Это очень простая и эффективная архитектура.
Java совсем не обязательно должна быть медленной. На эту тему сказано уже достаточно.
Избегайте работы с жесткими дисками. Многие приложения требуют работы с дисковой системой, но очень часто именно она оказывается узким местом в системе. Можете ли Вы обойтись без него, используя более креативные подходы к архитектуре системы?
Ограничте использование ресурсов. Задайте рамки для размеров почтовых ящиков и других подобных элементов системы, это позволит избежать неконтролируемых скачков нагрузок. Неограниченное использование ресурсов недопустимо при ограниченности ресурсов.
Сжимайте данные. Компрессия данных может стать неплохим достижением в попытках сэкономить оперативную память. Можно сократить использование памяти вдвое с лишь небольшой дополнительной нагрузкой, связанной с компрессией и декомпрессией информации. Если обмен данными происходит локально, достаточно лишь закодировать данные и предоставить API для доступа к данным без полной декомпрессии.
Используйте фиксированные объемы ресурсов для обработки запросов. Многие приложения не могут контролировать используемые ресурсы, в частности - оперативную память, таким образом они могут порой давать сбой при использовании излишне больших ее объемов. Для более стабильной работы стоит ограничить используемые ресурсы и откладывать выполнение новых задач пока они используются полностью. Для управление доступом к ресурсам можно использовать определенную логику в зависимости от ситуации: по времени, по приоритету, "честный" доступ, но так как ресурсы ограничены, система несколько ослабнет под серьезной нагрузкой.
Если данные не хранятся длительное время, они не могут стать причиной возбуждения судебного дела о нарушении чьих-либо прав.
Пользуйтесь тем, что знаете лучше всего. Этот урок не раз оправдывал себя. Paul знал Java лучше, чем что-либо еще, именно по-этому он заставил приложение на этом языке работать и выполнить все поставленные задачи.
Найдите свои собственные Mailinator'ы. Конечно, Mailinator является очень небольшой системой. В более крупной системе этот проект был бы лишь небольшой дополнительной возможностью, но такие системы обычно состоят просто из нескольких подпроектов размером с Mailinator. А что если подойти к разработке некоторых из них так же как и к Mailinator?
KISS работает, правда довольно редко. Простота систем часто обсуждается, но практические примеры появляются достаточно редко. Чаще всего разговор остается на уровне: твоя система сложная, а моя - простая, просто так как она моя. Mailinator является хорошим примером простой архитектуры системы.
Надежность является функцией архитектуры системы. Для построения системы, эффективно использующей память и выживающей серьезные атаки спаммеров, потребовалось серьезно подойти к каждому уровню ее архитектуры.