Bluesky — это перспективный проект, разрабатывающий децентрализованную социальную сеть на основе протокола Atproto. Одной из ключевых задач в этой системе является работа реле, которые обеспечивают непрерывную синхронизацию контента и поддержку активности пользователей по всей сети. В июле 2024 года были опубликованы серьезные заметки от инженеров Bluesky, описывающие процесс развертывания полноценного сетевого Atproto Relay с использованием программного обеспечения bigsky. Эти рекомендации особенно полезны для инженеров, системных администраторов и заинтересованных энтузиастов, желающих построить инфраструктуру, аналогичную той, которая поддерживает официальный сервис Bluesky. Основной акцент в докладе сделан на вычислительных ресурсах и конфигурациях, необходимых для полноценного реле, способного одновременно обрабатывать всю сеть.
Такой сервер должен не только собирать и републиковать весь поток событий сети (firehose), но и иметь возможность справляться с пиковыми нагрузками, ростом количества аккаунтов, увеличением числа инстансов Personal Data Servers (PDS) и большим числом потребителей данных. Для работы реле используется open-source софт bigsky, который Bluesky развивает и поддерживает. Этот софт обеспечивает:• Сбор информации с каждого PDS;• Постоянную синхронизацию репозиториев с изменениями;• Хранение и индексацию сотен тысяч взаимодействий в сети. На практике было обнаружено, что стандартная конфигурация bigsky при попытках «заполнить» все исторические данные сети (backfill) приводит к ошибкам переполнения памяти (OOM). В результате команда разработчиков внесла несколько изменений и улучшений в основной репозиторий, а также дополнила документацию, чтобы облегчить настройку производительного реле.
Ограничения и масштабируемость — серьезный вопрос при работе с full-network relay. Автор заметок предполагает, что современный сервер может обрабатывать в 10 раз больше событий, чем требуется на сегодня. Тем не менее, ограничением скорее всего станет не процессор или память, а именно дисковое пространство, которое может исчерпаться в течение года из-за быстрого роста сети и объёма хранимых данных. Для решения подобных проблем рассматриваются различные варианты оптимизации, включая использование альтернативных движков баз данных, изменение способа хранения данных (отказ от миллионов мелких файлов в пользу объединённых форматов), шардирование нагрузки между несколькими машинами и упрощение реле, не требующих полного зеркалирования всей сети. Что касается выбора оборудования, ключевым параметром является большой и быстрый диск.
В реальном продакшене Bluesky используют по 1 ТБ на базу PostgreSQL и 1 ТБ для хранилища CAR-файлов (Content Addressable Archive) на локальном диске, при этом рекомендуется файловая система XFS, способная эффективно работать с большим количеством мелких файлов. Для обеспечения запаса роста и резервов берётся обычно в два раза больше дискового пространства — 2 ТБ для базы данных и 2 ТБ для CAR-хранилища. Всё это может размещаться либо на одном диске, либо на двух отдельных. Важным также является использование SSD или, ещё лучше, NVMe накопителей для ускорения операций ввода-вывода, особенно при процессах backfill. По ресурсам CPU для реле не требуется большое количество циклов — процесс интенсивно параллелен, но сильно зависит от ввода-вывода, поэтому процессор с 12 виртуальными ядрами и 32 ГБ оперативной памяти считается достаточно сбалансированным решением.
Также необходимо обеспечить хороший месячный трафик, поскольку обмен данными идёт постоянно и в больших объёмах. Автор заметок описывает опыт выбора сервера у провайдера OVH, где за сумму около 150 долларов в месяц была приобретена машина с 12 виртуальными ядрами, 32 ГБ ОЗУ и парой NVMe-дисков по 1,92 ТБ каждый, с гарантированной пропускной способностью сети в 1 Гбит/с без ограничений по трафику. Такая конфигурация отвечает большинству требований для полноценного реле Bluesky. Процесс развертывания операционной системы и конфигурации сервера включает установку Ubuntu 24.04, настройку XFS-разметки для второго диска, конфигурирование PostgreSQL с необходимыми базами данных и пользователями, установку зависимостей и утилит, а также сборку и запуск самого bigsky relay из исходников.
Очень важной является правильная настройка конфигурационных параметров реле в файле .env, где задаются параметры подключения к базам, расположение директорий для хранения данных, а также лимиты по параллелизму, соединениям и очередям. Для работы вэб-интерфейса управления используется сервер Caddy с обратным проксированием, где производится настройка DNS и SSL сертификатов. Интерфейс предоставляет удобные инструменты для мониторинга, контроля лимитов, управления списком PDS и отдельных репозиториев. В примерах приведена методика поэтапного запуска первоначального сканирования сети — backfill — с помощью скриптов, запускаемых из командной строки на машине или удалённо.
Backfill занимает несколько дней, при этом непрерывно открываются новые PDS, которые выявляются в процессе обхода и синхронизации идентификаторов DID (Decentralized Identifiers). Рекомендуется не перегружать систему одновременными запросами к крупным PDS, а равномерно разделять нагрузку. Автор отмечает, что нет централизованного общедоступного реестра PDS. Для получения списка инстансов рекомендуется использовать сторонние публичные каталоги или сканировать директорию DID PLC, которая является публичным и перечислимым реестром. Наличие специального API для реле, выдающего список известных PDS и их текущий статус, было бы полезным дополнением для облегчения администрирования.
При мониторинге производительности во время backfill нагрузка на диск и сеть достигает сотен мегабайт в секунду, высокая активность по записям в базу данных и значительная нагрузка на процессор, обусловленная обработкой большого числа операций ввода-вывода и индексации. В спокойном режиме работы, когда реле просто подписано на поток данных, потребление ресурсов значительно уменьшается, а количество операций чтения и записи сбалансировано. Важным параметром для реле является параметр автоматического сжатия данных (компактификации), который по умолчанию отключён, чтобы уменьшить нагрузку во время интенсивного backfill. В последующем его можно активировать для освобождения дискового пространства и оптимизации производительности. В итоге, запуск полноценного сетевого Atproto Relay — задача технически сложная, требующая серьёзных аппаратных ресурсов и тонкой настройки сервисов и базы данных.
Тем не менее, доступность open-source инструментария, а также подробные рекомендации специалистов Bluesky делают этот процесс реализуемым и позволяют энтузиастам и профессионалам вывести собственные реле на уровень, сравнимый с официальными инстансами. Такой опыт необходим для развития децентрализованных социальных сетей, где устойчивое функционирование и прозрачность инфраструктуры имеют первостепенное значение. Запуск и поддержка полного реле на базе bigsky — это одновременно вызов и возможность изучить архитектуру перспективной сети Bluesky изнутри, внести свой вклад и обеспечить надежную работу децентрализованной социальной платформы будущего.
