А что, если современные технологии для большинства вещей избыточны? В проекте «ЭХО» я решил проверить это на практике, создав цифровую капсулу времени для потомков. Цель — позволить людям оставить память о себе (фото и мысли) в максимально простом и «вечном» формате.

Технически это эксперимент по созданию системы на 250 млн анкет без баз данных, фреймворков и лишних слоев — только чистый Go и минималистичный Linux. В этой статье я поделюсь опытом, как заставить обычный ПК работать с такой нагрузкой, используя лишь стандартную библиотеку и файловую систему.

Забегая вперед. Анализ и моделирование показали, что базовый узел Проекта «ЭХО» способен вместить около 250 млн единиц информации. Под единицей информации подразумеваем графический файл (фото) объемом 24000 байт и простой текстовый файл объемом 240-300 байт. Т.е. где-то 25000 байт максимум. Это в нашем проекте Анкета. Сам узел это пусть Ryzen7700 и на нем 2x32Gb ОЗУ, ну и парочка SSD/NVMe. То есть далеко не корпоративный сервер, а средний такой пользовательский компьютер. Пропускная способность в этом случае даже на среднем канале составит 2500 читаемых анкет в секунду. И то все будет очень долго упираться скорее в канал, чем в мощность сервера.

Заточка на минимум стека (количества и уровня) технологии, максимум совместимости

Как обычно?

Обычно любой проект начинается с выбора базы данных: MySQL, PostgreSQL, MongoDB… Затем веб-сервер, интерпретатор, фреймворки — все это слои, без которых он просто даже не включится. Понятное дело, что каждый слой такого сервера требует внимания: обновления безопасности, миграции схем, совместимости версий. Сменилась версия БД, стала лучше? Правда пропали некоторые функции, которые «устарели», но забиты в вашем коде. В сопроводиловке написано – deprecated или to be coverted.

Они все протестировали у себя, у пользователей. У них заработало с небольшими изменениями. Ты поверил… нанял программиста, он исправил как в документации. Не заработало. Знакомо? А еще бывают ситуации, когда ошибка в одном месте может порушить целостность всех данных (да пусть даже одной единицы хранения). А если через 10 (100) лет технология устареет?

И ладно бы небольшой код самого ПО можно поднапрячься и переписать, но когда потребуется миграция? А миграция с конвертацией? Ох, блин, это конечно как молния которая может ударит, может нет… Но с точки зрения Вечности — просто еще одна точка отказа. И это мы рассматриваем бесплатное ПО, а уж когда речь зайдет о закрытых проприетарных решениях… Там ведь и под капот-то не заглянешь. Да еще и баснословные суммы заплати и за обновление и за поддержку. Конечно, бесплатное тоже бывает становится платным… или как-нибудь условно-платным. А еще оно перестает поддерживаться или дорабатываться… Но даже тут масштабы дополнительных финансовых вливаний несоразмерны.

Как реализовано в Проекте ЭХО?

Всего два пункта:

1. ОС Linux в минималках, настроенная и «замороженная».

2. Cкомипилированный бинарник Go

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

Принципиально отказались от сторонних HTTP-фреймворков и роутеров - весь сервис написан на чистой как слеза младенца стандартной библиотеке (net/http). Это не только минимизирует зависимости и исключает сюрпризы при обновлениях, но и дает полную прозрачность: даже middleware для gzip-сжатия реализовано вручную. Стандартная библиотека Go в этом проекте и подозреваю что во многих будущих, уже из коробки дает всё необходимое для высокой нагрузки и предсказуемости кода.

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

Я уже упоминал, что вместо БД мы используем файловую систему, что по факту-то тоже БД, но усеченное и все равно входит в минимальный набор ПО. Конечно, можно и тут пойти еще глубже — уйти на уровень ниже, но не будем усложнять.

Чтобы избежать проблем с производительностью файловых систем - жесткая иерархию. Количество вложенных директорий на одном уровне не превышает 100 000, а на нижнем уровне хранятся лишь единичные файлы. В связке с NVMe это снимает вопросы и фрагментации, и задержек поиска, делая работу с данными почти такой же быстрой, как в специализированных БД.

Структура папок вполне ожидаемая — Верхний уровень группировка, кластеры/.../Нижний уровень, единица хранения. И в каждой из них набор файлов.
В нашем случае, например так:
data\galaxies\galaxy_167fp0s0thfju\filled\токен

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

Чтобы избежать лишний восклицаний, сразу уточню — да, предусмотрены и мьютексы и индексы в ОЗУ которые лежат в соответствующих служебных файлах. Совсем разгуляться с индексами не получилось, и идеальным балансом стал сводный индекс в ОЗУ, а уточняющие уже по мере необходимости читаются в память. Это позволило сразу сэкономить 24Gb ценной оперативы и при этом не сказалось на скорости ответа клиенту.

В итоге, Глобальный индекс токенов (token → galaxyID + starID) хранится в памяти и собирается при старте из index.json каждой галактики. Запросы к нему защищены мьютексами. Каждая галактика имеет свой отдельный мьютекс для атомарных операций с файлами. Это позволяет избежать состояния гонки при одновременных записях, благодаря мьютексам и атомарным операциям (сначала пишем stars.json, потом index.json, с возможностью отката) мы гарантируем целостность данных даже при сбоях. А при перезапуске отдельная процедура проверяет и восстанавливает индексы.

Масштабирование заложено в архитектуру скорее заодно, для порядка: двухбуквенные префиксы галактик позволят распределять нагрузку по серверам если вдруг жители Земли поверят в этот проект (до 676 узлов и астрономическое число анкет).

Вполне себе устойчивое решение. Опять-таки, без слоя БД.

Вопросы безопасности

Мы не собираем персональные данные для рекламы. Наша цель — дать возможность человеку зафиксировать свой образ и мысли «своими словами». Чтобы сквозь время на нас смотрели не ID в базе данных, а живые люди. Именно поэтому архитектура проекта "ЭХО" стремится к Вечности через минимализм.

Вот тут пришлось проявить немало смекалки и вкатать в современные понятия и принципы простые, но действенные. Поскольку сервис наш не предназначен для сбора, классификации, перепродажи персональных данных и не содержит их вовсе, то можно было бы и совсем не заморачиваться. В данном проекте воровать нечего и тратить на это ресурсы бессмысленно. Тем не менее мы, все же отработали, как положено по чеклисту все необходимые моменты. Авторизацию мы заменили на невосстанавливаемый токен и переложили полностью ответственность за сохранность своих данных на пользователя. Система задумывалась как не содержащая ПД и просто чтобы не заморачиваться с GDPR и прочими локальными актами в этой области. Поэтому у нас просто нет никаких данных по которым пользователь мог бы подтвердить свою личность и право на содержимое папки. Токен мы усилили PIN, но большей частью лишь для того чтобы разделить функцию токена на две роли — полное редактирование и проставление одной отметки. Но схема получилась интересная, честная и правильная.

Добавили обязательную защиту паузой для ряда операций (пользователю пофиг, а ботам уже неприятно — скорость падает), добавили детекцию подозрительной активности и блокировку по IP и прочие мелочи.

Резервное копирование, кластеризация

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

В итоге, лишний раз имеет смысл подумать, а стоит ли все усложнять, планируя какую-то систему?

Про фронт в этой статье я не планирую писать, это отдельная история и ей отдельная статья. Но его можно вообще просто зайти и посмотреть в любой момент. Его ламповость - производная от требования ко всей системе.

PS. Такую тему одному конечно было бы крайне сложно реализовать. Роль архитектора, дирижера и частично программиста, конечно же была на мне. Но были и люди, которые кто советом, кто кусочком или кусищем кода помогал, рефакторил. В коде встречались и совсем человеческие кусочки и… нечеловеческие. Они и сейчас встречаются. В любом случае, механические и рутинные вопросы каждому помогал решать ИИ. А вот конечное сведение, причесывание, разбиение модулей и функций я бы без ИИ делал год (особенно front). И это действительно удобно! Насколько возможно полностью программирование отдать ИИ, пока не скажу — любит он и пофантазировать и забыть да так, что потом пока найдешь понимаешь что было проще эту процедуру написать ручками.

На этом я закончу свой первый в жизни пост на Хабре, всем благодарен. Если есть вопросы — спрашивайте, есть предложения — предлагайте, если чем-то поможет в работе - я рад. Ну и не забудьте зажечь свою звезду. Теперь вы знаете, что это может оказаться надежнее в плане Вечности :-) Ссылка вот: Проект ЭХО - оставь миру послание