ПРОИЗВОДИТЕЛЬНАЯ МОДЕЛЬ ОБМЕНА СООБЩЕНИЯМИ ДЛЯ КРУПНОМАСШТАБНЫХ МЕССЕНДЖЕРОВ

A PRODUCTIVE MESSAGING MODEL FOR LARGE-SCALE MESSENGERS

Victor Rozhkov

Master's student, Transbaikal State University,

Russia, Chita

Dmitry Semiguzov

Scientific supervisor, Associate Professor, Transbaikal State University,

Russia, Chita

АННОТАЦИЯ

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

ABSTRACT

Ensuring effective communication between millions of users requires building a computing system capable of working with ever-increasing loads while maintaining the quality of service.

Ключевые слова: мессенджер; высокие нагрузки; интенсивная передача данных; вычислительная архитектура; масштабируемость; надёжность.

Keywords: messenger; high load; data intensive; computing architecture; scalability; reliability.

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

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

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

До популяризации высоконагруженных систем, в мессенджерах использовались другие распространённые вычислительные архитектуры: «клиент-сервер», пиринговая и федеративная [6]. Каждая из данных архитектур обладает своими достоинствами и недостатками.

В архитектуре «клиент-сервер» есть множество клиентов, обслуживаемых одним сервером. При старте разработки нового приложения чаще всего придерживаются именно такой архитектуры, т.е. сервер занят всем – обработкой запросов, чтением и записью в базу данных и бизнес-логикой. Это экономит время и ресурсы на запуск приложения, но дальнейший рост системы затруднён из-за невозможности масштабирования. Единая точка отказа в виде сервера не способствует росту отказоустойчивости, дополнительно возникают сложности при добавлении новых бизнес-функций. Такие приложения наиболее уязвимы к атакам распределённого отказа в обслуживании.

В противовес клиент-серверной архитектуре существует пиринговая (одноранговая) архитектура. Здесь главную роль играют пиры – отдельные узлы, выполняющие функции клиента и сервера одновременно. Мессенджеры на основе пиринговой архитектуры позволяют обмениваться сообщениями и файлами напрямую, без посредников. Это значительно повышает уровень конфиденциальности и безопасности общения. Отсутствие единой точки отказа делает систему отказоустойчивой и позволяет ей неограниченно масштабироваться, но при этом гарантия, что все устройства следуют заранее установленным правилам, может находится под сомнением. Устройствам, участвующим в пиринговой сети необходимо постоянно поддерживать активное соединение с другими, что не всегда возможно ввиду прерывающегося соединения и исчерпывания переносной батареи, если речь идёт о мобильных устройствах. Для одноранговых сетей также характерна высокая сложность разработки пирингового протокола и приложения.

Федеративная архитектура стремится вобрать в себя положительные стороны клиент-серверной и пиринговой архитектур. В федеративной архитектуре существует множество серверов, каждый из которых обслуживает только зарегистрированных у себя клиентов. Клиент сохраняет право подключаться и отключаться тогда, когда он посчитает это нужным. Каждый сервер сохраняет свою автономность, но также может передавать сообщения клиентам, присоединённым к другим серверам. Клиенты сами выбирают, какому серверу они доверят свои данные. Это закономерно приводит к повышению безопасности общения. В любой момент пользователь может создать свой собственный сервер и установить на нём свой набор правил и ограничений. Масштабируемость и отказоустойчивость такой сети обеспечивается путём создания новых серверов. Как правило, протокол федеративной сети достаточно гибкий, чтобы им могли пользоваться как можно большее количество устройств, но грамотно реализовать такой протокол весьма сложно. При работе с данной архитектурой пользователям придётся столкнуться с возросшей сложностью работы с приложением – появляется необходимость самостоятельной навигации в федеративной сети. Грамотное использование федеративного мессенджера требует некоторой технической подкованности.

С ростом популярности и возросшей нагрузкой на веб-приложения у разработчиков появились потребности в новых инструментах и техниках. Высокие нагрузки – это ситуация, при которой вычислительная система перестаёт справляться с текущей нагрузкой [2]. Создание высоконагруженного приложения подразумевает разработку системы на основе архитектуры, способной эффективно работать с огромными объёмами трафика, данных и большим количеством пользовательских запросов. Основные цели, стоящие перед высоконагруженной архитектурой – надёжность, масштабируемость и удобство сопровождения.

Каждое крупномасштабное приложение уникально в своих потребностях и возможностях, т.е. в этой сфере нет шаблонных решений проектирования, но есть вполне определённый набор инструментов: API-шлюзы (единые точки входа), балансировщики нагрузки (равномерно распределяют запросы к отдельным узлам системы), очереди сообщений (быстрые проводники данных между частями системы), кэши (хранят часто используемые данные), базы данных (постоянное хранение данных), сервисы (обработка бизнес-логики), «толстый» клиент (от англ. rich client – автономный клиент, которому делегирована некоторая часть бизнес-логики) и система мониторинга (отслеживает состояние различных частей приложения в реальном времени).

Построение высоконагруженной системы можно представить в виде следующей последовательности действий: описание бизнес-логики, выяснение числовых показателей системы, выявление максимального влияния нагрузки на время отклика (допустимая степень деградации системы), описание схемы движения данных, проектирование системы и тестирование системы до тех пор, пока не будут удовлетворены требования к доступности, надёжности и удобству сопровождения [7].

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

На первом шаге выделяются компоненты бизнес-логики – сервисы для работы с учётными записями, для работы с профилем, работы со списком контактов, для обмена сообщениями в чатах и группах, для обозначения статуса в сети, работы с файлами и изображениями.

После этого выявляются основные числовые показатели [3]. Предположим, что у системы будет 100 млн активных пользователей в сутки, при этом каждый пользователь получает и отправляет в среднем 50 сообщений в личных чатах, по 100 сообщений из 5 групповых чатов, 10 картинок средним размером 1 МБ и 5 файлов, каждый из которых занимает в среднем 5 МБ дискового пространства. Получается, что среднестатистический пользователь в сутки будет генерировать 35.055 МБ информации, а аудитория в 100 миллионов пользователей будет ежедневно создавать трафик в 5727 Пбайт – 476.8 Тбайт текста из личных сообщений, 4.76 Пбайт текста из групповых сообщений, 953.6 Пбайт картинок и 2384 Пбайт файлов.

Следующий шаг проектирования – выяснение максимальной степени деградации системы. Для сервиса регистрации и аутентификации максимальное время отклика должно составлять не больше 2 секунд (при максимальном времени в 5 секунд). Допустимое время работы для сервиса отправки сообщений должно быть минимальным – отправка сообщения между двумя пользователями и в группах должна осуществляться практически в реальном времени (с максимальной задержкой в 3 секунды). Ожидается, что сервис индикации о присутствии в сети будет один из самых загруженных из-за огромного количества клиентов, имеющих постоянное соединение с ним, поэтому максимальное время отклика должно составлять не больше 10 секунд (при допустимом времени в 15 секунд). Такие операции как загрузка и скачивание изображений, документов и других файлов не требуют мгновенного отклика, поэтому обработка этих операций может быть начата и завершена в асинхронном режиме с некоторой задержкой.

При разработке мессенджера имеет смысл использование паттерна «rich client». Это обусловлено тем, что от клиентской части приложения требуется быстродействие, интерактивность и возможность иметь доступ к данным в оффлайн-режиме, т.е. сохранение данных на устройстве клиента. Серверная часть мессенджера будет построена вокруг «толстого» клиента, представляя собой хранилище для разных типов данных с поддержкой постоянного соединения с клиентом для обмена данными в режиме реального времени.

В типичном мессенджере существует четыре типа данных:

1. Общие данные – профиль пользователя, список контактов, настройки;

2. Изображения;

3. Файлы (документы и др.);

4. Истории переписок.

Первый тип данных без проблем хранится в традиционных реляционных базах данных.

Изображения, как и файлы, нужно хранить в специальном объектном хранилище. Такое хранилище предназначено специально для хранения огромного количества файлов и их метаданных. Оно обладает плоским адресным пространством, в отличие от файловых систем с иерархичным пространством. Эта особенность позволяет объектному хранилищу беспрепятственно масштабироваться и реплицироваться. Масштабирование же файловых хранилищ ограничено максимальным размером тома (8 петабайт для NTFS, 128 петабайт для exFAT). Для кэширования изображений следует использовать географически распределённую сеть доставки контента (CDN, от англ. content delivery network), заточенную для работы с картинками.

Четвёртый тип данных является уникальным для мессенджера. Для хранения переписок лучше всего подходит хранилище «ключ-значение», поскольку реляционные базы данных плохо работают с длинными последовательностями данных [1]. Произвольный доступ к таким данным начинает работать медленно, когда индексы достигают больших значений. Помимо этого, хранилище «ключ-значение» обеспечивает горизонтальное масштабирование базы данных и работает с низким временем отклика.

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

Существует два основных типа масштабирования – вертикальное (наращивание ресурсов на одном узле системы) и горизонтальное (использование ряда однородных узлов и равномерное распределение нагрузки между ними при помощи балансировщика нагрузки). Горизонтальное масштабирование способно распределить нагрузку и рабочие риски между множеством узлов. Для бесшовной работы такой системы сервисы, запущенные на узлах распределённой системы, не должны хранить в себе состояние между клиентскими запросами [5]. Такой подход принято обозначать словом «stateless» (от англ. «Без состояния»). Это означает, что любой запрос клиента может быть передан любому из экземпляров сервиса, что защищает клиента от сбоев отдельных машин и позволяет системе эффективно масштабироваться.

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

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

Сервис может быть снабжён устройством кэширования для запоминания часто запрашиваемой информации. Использование кэша в подсистемах, где нет чётко выраженных «популярных» данных почти не даст никакого выигрыша в производительности, т.к. данные в кэше будут попросту постоянно перезаписываться или «вымываться» по мере заполнения пространства памяти устройства кэша.

Для получения запросов извне в веб-приложениях и распределённых системах используется паттерн коммуникации «API-шлюз» (от англ. API, application programming interface, «Интерфейс прикладного программирования») [4]. Этот элемент находится между внешним миром и системой, обеспечивая единую точку входа для клиента. Может существовать несколько таких точек входа, т.е. здесь имеется возможность горизонтального масштабирования.

Полученный от пользователя запрос отправляется на балансировщик нагрузки – это узел, осуществляющий равномерное распределение сетевого трафика по множеству однородных экземпляров сервисов приложения. Балансировщик нагрузки находится между клиентом и приложением, оставаясь невидимым для клиента. Именно он играет основную роль в масштабируемости и отказоустойчивости системы. Этот элемент также поддаётся горизонтальному масштабированию точно так же, как и API-шлюз.

Для аутентификации и авторизации в системе следует использовать JSON Web-токены (JWT). Такие токены будут создаваться сервисом учётных записей, подписываться секретным ключом и передаваться клиенту, который в дальнейшем будет использовать данный токен для подтверждения подлинности своего аккаунта при обращении к сервисам системы.

На основе полученных во время написания статьи данных была составлена первоначальная архитектура мессенджера, способная обеспечить аудиторию в 100 млн пользователей коммуникацией с приемлемым уровнем сервиса (на рис. 1). Она является масштабируемой, надёжной и удобной для сопровождения. Разработанная архитектура является достаточно общей и схематичной, т.е. для конкретной реализации системы могут потребоваться различного рода доработки в виде новых функций и других изменений.

Рисунок 1. Предлагаемая архитектура приложения

Список литературы:

1. Сюй А. System Design. Подготовка к сложному интервью. СПб.: Питер, 2022. 304 с.;
2. Клеппман М. Высоконагруженные приложения. Программирование, масштабирование, поддержка. СПб.: Питер, 2018. 640 с.;
3. Оллспоу Дж. Искусство планирования мощностей. СПб.: Питер, 2011. 208 с.;
4. Бёрнс Б. Распределенные системы. Паттерны проектирования. СПб.: Питер, 2019. 224 с.;
5. Стин ван М., Таненбаум Э. С. Распределенные системы. М.: ДМК Пресс, 2021. 584 с.;
6. Ньюмен С. Создание микросервисов. СПб.: Питер, 2016. 304 c.;
7. Бунин О. В., Лапшин М. К., Осипов К. В., Машуков К. С. Учебник по высоким нагрузкам. Издательство Олега Бунина, 2019. 52 с.