Обмен информацией в режиме реального времени — одна из областей, где организации чаще всего в наибольшей степени зависят от внешних поставщиков программного обеспечения как услуги (SaaS). История чатов, вложения файлов, пользовательские каталоги и внутренние беседы могут храниться на инфраструктуре, управляемой Microsoft, Slack, Discord или другой третьей стороной. Для команд, которые хотят больше контролировать место хранения своих коммуникационных данных и работу своей инфраструктуры обмена сообщениями, Matrix предлагает открытую альтернативу.
Synapse — наиболее широко используемая реализация домашнего сервера Matrix. Она предоставляет серверную инфраструктуру для пользователей Matrix, комнат, сообщений, федерации, аутентификации и хранения медиафайлов. Synapse разработан компанией Element и может быть размещен на вашей собственной инфраструктуре. В сочетании с клиентом Matrix, таким как Element, он может предоставить организации полноценную платформу для чата, позволяя при этом общаться с пользователями, размещенными на других серверах Matrix.
Информация о проекте Synapse:
Название: Синапс
URL:
element-hq.github.io/synapse/
Лицензия: AGPLv3 или коммерческая лицензия Element.
Протокол: Матрица
Язык программирования: Python/Twisted с компонентами Rust.
Последняя версия: 1.163.0
База данных: рекомендуется PostgreSQL.
Коммерческое предложение: Synapse Pro/Element Server Suite
Домашний сервер для сети Matrix
Matrix — это протокол федеративной связи. Вместо того чтобы каждый пользователь принадлежал одному центральному провайдеру, организации могут использовать собственные домашние серверы, продолжая при этом взаимодействовать с пользователями на других серверах.
Synapse реализует эту роль домашнего сервера. Когда пользователь создает учетную запись на сервере Synapse, его идентификатор Matrix ID содержит имя сервера (например, @alice:example.com). Комнаты, пользователи, сообщения, информация о членстве и другие события Matrix затем обрабатываются одним или несколькими домашними серверами, участвующими в беседе.
Для пользователей, самостоятельно размещающих свой сервер, выбор server_name является одним из важнейших решений во время установки. Это значение становится частью идентификаторов пользователей и адресов помещений и не может быть просто изменено позже. Таким образом, компания может использовать example.com в качестве своего идентификатора Matrix, в то время как физически Synapse работает по адресу matrix.example.com.
В Synapse обычно не входит сам интерфейс чата для пользователей. Пользователи подключаются через клиент Matrix, например Element, FluffyChat или другое совместимое приложение. Такое разделение между клиентом и сервером является одним из преимуществ Matrix: пользователи не привязаны к конкретному приложению только потому, что организация выбрала Synapse в качестве своего сервера.
Федерация
Федерация — это то, что отличает Matrix от многих систем чата с самостоятельным размещением. Если федерация включена, пользователи вашего сервера Synapse могут присоединяться к комнатам с пользователями, размещенными на других серверах, а удаленные серверы Matrix могут обмениваться событиями напрямую с вашим сервером.
В концептуальном плане Matrix ближе к электронной почте, чем к традиционной корпоративной платформе для чата. Две организации могут использовать собственную инфраструктуру, не имея учетных записей в одном и том же центральном сервисе.
Однако федерация несколько усложняет настройку сети. Другие серверы Matrix должны знать, как связаться с вашим домашним сервером. По умолчанию это определяется на основе настроенного параметра, но Matrix также поддерживает делегирование через файлы. Это позволяет использовать идентификаторы пользователей, например, в то время как сам Synapse работает под другим именем хоста, например, .server_name.well-known@alice:example.commatrix.example.com
Для частных установок федерацию также можно ограничить или отключить. Компании, которая хочет использовать Matrix только в качестве внутренней коммуникационной платформы, не обязательно предоставлять доступ к своему домашнему серверу более широкой федерации Matrix.
Развертывание и база данных
Synapse можно установить из пакетов, сред Python или контейнеров. Для развертывания в производственной среде на собственном сервере типичная архитектура включает Synapse, PostgreSQL, обратный прокси-сервер, постоянное хранилище медиафайлов и, при необходимости, сервер TURN (Traversal Using Relays around NAT) для надежного голосового и видеосоединения.
Synapse поддерживает SQLite для простых установок, но PostgreSQL следует рассматривать как стандартный выбор для производственных систем. PostgreSQL становится особенно важным по мере роста установки и необходим при масштабировании Synapse с использованием нескольких рабочих процессов.
Обычно перед Synapse устанавливается обратный прокси-сервер, такой как NGINX, Caddy, Apache или HAProxy. Он завершает TLS-соединение и предоставляет доступ к клиенту Matrix и конечным точкам федерации через стандартные порты HTTPS, в то время как сам Synapse прослушивает внутренний порт HTTP.
Для работы с медиаконтентом также требуется планирование. Изображения, видео, голосовые сообщения, документы и другой загруженный контент хранятся отдельно от базы данных PostgreSQL. Поэтому администраторам необходимы резервные копии как базы данных, так и хранилища медиафайлов. Резервного копирования только PostgreSQL недостаточно для полного восстановления.
Аутентификация и управление пользователями
Synapse может управлять собственными пользователями и паролями, но организации часто предпочитают интегрировать его с существующим поставщиком идентификационных данных. В зависимости от среды, Synapse может работать с механизмами аутентификации, такими как OpenID Connect и Security Assertion Markup Language (SAML), позволяя пользователям входить в систему через существующую платформу идентификации.
Настройка регистрации должна быть тщательно продумана. Домашний сервер, доступный из интернета, как правило, не должен разрешать неограниченную регистрацию учетных записей, если это не является преднамеренной частью сервиса. Вместо этого администраторы могут создавать учетные записи самостоятельно, использовать механизмы контролируемой регистрации или полагаться на внешнего поставщика идентификационных данных.
Конфигурация сервера также содержит конфиденциальные данные, такие как секретные ключи регистрации и ключи подписи. К ним следует относиться так же, как и к другим учетным данным инфраструктуры, и включать их в стратегию резервного копирования и управления секретами.
Масштабирование с помощью сотрудников
Для небольших или средних установок Matrix Synapse обычно следует запускать как единый процесс. Официального ограничения по количеству пользователей или событий в секунду не существует, поскольку нагрузка на системы Matrix значительно варьируется: 500 в основном простаивающих пользователей в небольших частных комнатах создают совершенно иную нагрузку, чем 500 пользователей, участвующих в больших объединенных комнатах. Как правило, хорошо сбалансированный единый процесс Synapse с PostgreSQL может без проблем обслуживать несколько сотен активных пользователей, а в системах с примерно 1000 зарегистрированными пользователями может и не быть необходимости вводить дополнительные рабочие процессы, если параллельная обработка и трафик объединения невелики.
Масштабирование рабочих процессов стоит рассмотреть, когда основной процесс Synapse регулярно приближается к 100% одного ядра ЦП, запросы /sync заметно замедляются, очереди федерации начинают отставать или задержка доставки сообщений увеличивается при нормальной пиковой нагрузке. Synapse в основном разделен на специализированные рабочие нагрузки, поэтому первым шагом часто является не создание нескольких идентичных экземпляров, а перенос ресурсоемких функций, таких как синхронизация клиентов, обработка федерации, обработка мультимедиа, фоновые задачи или сохранение событий, на выделенные рабочие процессы. В больших масштабах сохранение событий также может быть распределено по идентификатору комнаты между несколькими рабочими процессами.
Поэтому разумная модель планирования заключается в том, чтобы поддерживать более простую монолитную архитектуру в системах с десятками или несколькими сотнями активных пользователей и отслеживать их состояние перед добавлением сложных компонентов. Как только количество одновременно активных пользователей достигает нескольких сотен, частота запросов исчисляется сотнями в секунду или происходит загрузка ЦП основного процесса, использование рабочих процессов становится все более оправданным. Очень крупные развертывания с тысячами одновременно активных пользователей, как правило, следует проектировать с использованием нескольких рабочих процессов с самого начала. Все рабочие процессы по-прежнему используют общую базу данных PostgreSQL и взаимодействуют через механизмы репликации Synapse, обычно с использованием Redis, поэтому горизонтальное масштабирование Synapse не устраняет необходимость в базе данных соответствующего размера.
Для небольшого выделенного сервера Synapse не требуется особенно мощное оборудование. Домашний сервер для небольшой компании, семьи или сообщества может комфортно начать работу с 2-4 современными ядрами ЦП, 4-8 ГБ оперативной памяти и примерно 100-250 ГБ SSD или NVMe-накопителя, при условии умеренного использования федерации и работы с медиафайлами. Для среднего сервера с несколькими сотнями активных пользователей, большими федеративными комнатами или начальными рабочими процессами лучше подойдет около 6-12 ядер, 32-64 ГБ оперативной памяти и 500 ГБ-1 ТБ NVMe-накопителя. Для крупного сервера с тысячами активных пользователей и несколькими рабочими процессами Synapse разумной отправной точкой являются 16-32 ядра, 64-128 ГБ оперативной памяти и 1-4 ТБ быстрого NVMe-накопителя. Однако в таком масштабе разделение PostgreSQL, рабочих процессов Synapse и хранилища медиафайлов между несколькими системами обычно становится более полезным, чем дальнейшее вертикальное масштабирование одного сервера. Во всех случаях быстрое хранилище на SSD-накопителях важнее больших объемов медленных дисковых накопителей, поскольку производительность PostgreSQL оказывает существенное влияние на быстродействие Synapse.
Безопасность и сквозное шифрование
Matrix поддерживает сквозное шифрование для частных разговоров и комнат. В зашифрованной комнате содержимое сообщений шифруется клиентами до того, как они достигнут Synapse, то есть домашний сервер хранит и пересылает зашифрованные события, а не содержимое сообщений в открытом виде.
Это важное различие при самостоятельном размещении. Использование собственного сервера Synapse дает вам контроль над данными учетной записи, метаданными комнаты, медиафайлами, инфраструктурой и хранением данных, но сквозное шифрование по-прежнему в основном зависит от клиентов Matrix и управления ключами.
Сам домашний сервер по-прежнему имеет критически важное значение с точки зрения безопасности. Администраторам следует обновлять Synapse и PostgreSQL, ограничивать доступ к административным API, защищать механизмы регистрации, использовать HTTPS, создавать резервные копии ключей подписи и избегать прямого доступа к внутренним сервисам через Интернет.
Обзор и перспективы
Synapse — наиболее зрелый вариант для организаций, желающих использовать собственный домашний сервер Matrix. Его главные преимущества — совместимость с экосистемой Matrix, федерация, поддержка сквозного шифрования, развитые функции администрирования и возможность масштабирования от небольшой установки на одном сервере до гораздо более крупных развертываний.
Компромисс заключается в сложности. Серьезная установка включает в себя гораздо больше, чем просто запуск контейнера чата: необходимо учитывать PostgreSQL, DNS, TLS, федерацию, хранилище медиафайлов, резервное копирование, управление идентификацией и, при необходимости, инфраструктуру TURN.
В целом, Synapse отлично подходит для команд, которые хотят контролировать свою коммуникационную инфраструктуру, не создавая при этом еще один изолированный «островок» обмена сообщениями. Для тех, кто самостоятельно управляет вспомогательной инфраструктурой, Matrix и Synapse предлагают привлекательную альтернативу централизованным коммуникационным платформам.
