Реальное время коммуникации — это одна из сфер, где организации часто сильнее всего зависят от внешних поставщиков услуг по модели «Безопасность как услуга» (Security as a Service, SaaS). История чатов, вложенные файлы, каталоги пользователей и внутренние разговоры могут храниться на инфраструктуре, управляемой Microsoft, Slack, Discord или другой третьей стороной. Для команд, которые хотят иметь больше контроля над тем, где хранятся их коммуникационные данные и как работает их инфраструктура обмена сообщениями, Matrix предлагает открытую альтернативу.

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

Информация о проекте Synapse:

Название: Synapse

URL: https://element-hq.github.io/synapse/

Лицензия: AGPLv3 или коммерческая лицензия Element

Протокол: Matrix

Язык: Python/Twisted с компонентами на Rust

Последний релиз: 1.163.0

База данных: Рекомендуется PostgreSQL

Коммерческое предложение: Synapse Pro/Element Server Suite

Домашний сервер для сети Matrix

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

Synapse реализует эту роль домашнего сервера. Когда пользователь создает учетную запись на сервере Synapse, его идентификатор Matrix (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 нужно знать, как связаться с вашим домашним сервером. По умолчанию это определяется на основе настроенного server_name, но Matrix также поддерживает делегирование через файлы .well-known. Это позволяет использовать идентификаторы пользователей, такие как @alice:example.com, в то время как сам Synapse работает под другим именем хоста, например matrix.example.com.

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

Развертывание и база данных

Synapse можно установить из пакетов, окружений Python или контейнеров. Для производственного саморазмещаемого развертывания типичная архитектура состоит из Synapse, PostgreSQL, обратного прокси-сервера, постоянного хранилища медиаданных и, опционально, сервера TURN (Traversal Using Relays around NAT) для надежной передачи голоса и видео.

Synapse поддерживает SQLite для простых установок, но PostgreSQL следует рассматривать как стандартный выбор для производственных систем. PostgreSQL становится особенно важен по мере роста инсталляции и требуется, когда Synapse масштабируется с использованием нескольких рабочих процессов (воркеров).

Обратный прокси-сервер, такой как NGINX, Caddy, Apache или HAProxy, обычно размещается перед Synapse. Он завершает TLS-соединение и предоставляет клиентские конечные точки Matrix и конечные точки федерации через стандартные порты HTTPS, в то время как сам Synapse прослушивает внутренний порт HTTP.

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

Аутентификация и управление пользователями

Synapse может поддерживать собственных пользователей и пароли, но организации часто хотят интегрировать его с существующим поставщиком учетных записей (identity provider). В зависимости от окружения, Synapse может работать с такими механизмами аутентификации, как OpenID Connect и Security Assertion Markup Language (SAML), позволяя пользователям входить в систему через существующую платформу идентификации.

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

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

Масштабирование с помощью воркеров

Для небольшой или средней инсталляции Matrix Synapse обычно должен запускаться как единый процесс. Официального ограничения по производительности, выраженного в конкретном числе пользователей или событий в секунду, не существует, поскольку рабочие нагрузки Matrix существенно различаются: 500 в основном бездействующих пользователей в небольших приватных комнатах создают совсем другую нагрузку, чем 500 пользователей, участвующих в крупных федеративных комнатах. В качестве практического правила хорошего тона: один процесс Synapse подходящего размера с PostgreSQL может с комфортом обслуживать несколько сотен активных пользователей, а инсталляции с примерно 1 000 зарегистрированных пользователей могут по-прежнему не нуждаться в воркерах, если уровень параллелизма и трафик федерации невелики.

Масштабирование с помощью воркеров стоит рассмотреть, когда основной процесс Synapse регулярно приближается к 100 процентам загрузки одного ядра процессора, запросы /sync начинают заметно замедляться, очереди федерации начинают отставать или задержка доставки сообщений увеличивается при обычной пиковой нагрузке. Synapse в значительной степени разделен на специализированные рабочие нагрузки, поэтому первым шагом часто является не создание нескольких идентичных экземпляров, а перенос ресурсоемких функций, таких как синхронизация клиентов, обработка федерации, обработка медиаданных, фоновые задачи или сохранение событий, в выделенные воркеры. При больших масштабах средства сохранения событий (event persisters) также могут быть разделены (шардированы) по идентификатору комнаты между несколькими воркерами.

Разумная модель планирования заключается в том, чтобы оставлять инсталляции с десятками или несколькими сотнями активных пользователей на более простой монолитной архитектуре и вести мониторинг, прежде чем добавлять сложность. Как только инсталляция достигает нескольких сотен одновременно активных пользователей, стабильной частоты запросов в несколько сотен в секунду или насыщения ЦП на главном процессе, воркеры становятся все более полезными. Очень крупные развертывания с тысячами одновременно активных пользователей, как правило, с самого начала должны проектироваться с расчетом на несколько воркеров. Все воркеры по-прежнему разделяют 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 предлагают убедительную альтернативу централизованным коммуникационным платформам.