Все мы любим красивые логи, которые нам дают ребята из Платформы, где все понятно и хорошо видно. Но что делать со своими pet-проектами? Когда они уже в мини-продакшине, как посмотреть что творится в контейнере?

Раньше я ходил через ssh, подключался интерактивно к контейнеру, смотрел в реальном времени логи, пока не обнаружил шикарный Dozzle!

Всего одна команда и один конфигурационный файл, и вот у вас почти что свой Docker Desktop со всеми контейнерами и всеми логами в реальном времени!

docker run --restart always -d -v  /var/run/docker.sock:/var/run/docker.sock -v /data:/data -p 8080:8080 amir20/dozzle --auth-provider simple

и создать перед этим файл в /data/users.yml

users:
  # "admin" here is username
  admin:
    email: me@email.net
    name: Admin
    # Generate with docker run amir20/dozzle generate --name Admin --email me@email.net --password secret admin
    password: $2a$11$9ho4vY2LdJ/WBopFcsAS0uORC0x2vuFHQgT/yBqZyzclhHsoaIkzK
    filter:

Вот что получаем в итоге:

Доступ к любому контейнеру и его логам. Все это можно через Caddy Server повесить на удобный вам поддомен и в реальном времени смотреть на то как работает ваш сайт. Или не работает, и узнать почему.

Для проведения интервью можно использовать следующий шаблон — позволяет структурировать ответ и не забыть спросить основные моменты, необходимые для проектирования:

Скачать шаблон для https://excalidraw.com/

Фреймворк	Язык	RPS	Удобство	Экосистема	Сообщество	Документация	Масштабируемость	Безопасность	Интеграция
Actix	Rust	100000	7	7	8	8	9	9	7
Warp	Rust	90000	7	6	7	7	9	9	7
ASP.NET Core	C#	60000	9	9	9	9	9	9	9
Fiber	Go	60000	8	7	8	8	8	8	8
Gin	Go	55000	8	8	9	8	8	8	8
Fastify	JS	60000	9	8	8	9	8	8	9
NestJS	JS	50000	9	9	9	9	9	9	9
Spring Boot	Java	40000	8	10	10	9	10	9	10
Micronaut	Java	35000	8	8	7	8	9	9	8
FastAPI	Python	30000	9	8	8	9	8	8	8
Django	Python	2000	9	10	10	10	8	9	9
Hanami	Ruby	2000	7	7	7	7	7	8	7
Rails	Ruby	1900	10	10	10	9	8	8	9
Laravel	PHP	1000	9	9	10	10	8	8	9
Symfony	PHP	900	8	9	9	9	9	9	9

1. Удобство: Насколько легко начать работу и разрабатывать с использованием фреймворка.
2. Экосистема: Разнообразие и качество доступных библиотек и инструментов.
3. Сообщество: Активность и размер сообщества разработчиков.
4. Документация: Качество и полнота официальной документации.
5. Масштабируемость: Способность фреймворка справляться с ростом нагрузки и размера приложения.
6. Безопасность: Встроенные механизмы безопасности и легкость их реализации.
7. Интеграция: Простота интеграции с другими технологиями и сервисами.

При выборе фреймворка следует учитывать все эти факторы в контексте конкретного проекта. Например:

• Для быстрой разработки прототипов могут подойти Ruby on Rails или Django.
• Для высоконагруженных систем стоит обратить внимание на Actix, ASP.NET Core или Spring Boot.
• Если важна гибкость и легковесность, то Fastify или Gin могут быть хорошим выбором.
• Для корпоративных приложений с сложной бизнес-логикой Spring Boot или ASP.NET Core предоставляют широкие возможности.

Сколько серверов надо?

MAU (10^n)	DAU	RPS	Серверы (Fiber)	Серверы (Django)
10000 (10^4)	3 500	0.61	1	1
100000 (10^5)	35 000	6.08	1	1
1000000 (10^6)	350 000	60.76	1	1
10000000 (10^7)	3 500 000	607.64	1	1
100000000 (10^8)	35 000 000	6076.39	1	4
1000000000 (10^9)	350 000 000	60763.89	2	31

Согласованное хеширование (Consistent hashing) — это специальная техника хеширования в компьютерных науках, которая обладает важным свойством: при изменении размера хеш-таблицы требуется перераспределить в среднем только n/m ключей, где n — количество ключей, а m — количество слотов.

Основные особенности

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

Применение

Согласованное хеширование широко используется в распределенных системах, особенно в:

• Распределенных кэшах
• Системах хранения данных (например, Amazon Dynamo)
• Сетях доставки контента (CDN)
• Балансировке нагрузки

Принцип работы

1. Ключи и серверы отображаются на виртуальную окружность (обычно от 0 до 2π).
2. Каждый ключ назначается ближайшему серверу по часовой стрелке.
3. При добавлении или удалении сервера перераспределяются только ключи, попадающие в его сегмент.

Преимущества

• Минимизация перераспределения данных при изменении количества серверов.
• Улучшение масштабируемости и отказоустойчивости распределенных систем.

Согласованное хеширование стало ключевой технологией для многих современных распределенных систем, обеспечивая эффективное распределение данных и нагрузки

---

Рандеву-хеширование (Rendezvous hashing) или хеширование с наибольшим случайным весом (HRW) — это алгоритм, позволяющий клиентам достичь распределенного соглашения о выборе k вариантов из n возможных. Этот метод часто применяется в распределенных системах для назначения объектов серверам или прокси.

Основные особенности

• Простота: Алгоритм концептуально прост и легок в реализации.
• Минимальное нарушение: При добавлении или удалении узла перераспределяются только объекты, связанные с этим узлом.
• Равномерное распределение: Обеспечивает равномерное распределение объектов по узлам.
• Поддержка взвешивания: Позволяет учитывать разную мощность узлов.

Принцип работы

1. Для каждого объекта и каждого узла вычисляется хеш-значение.
2. Объект назначается узлу с наибольшим хеш-значением.
3. При изменении набора узлов пересчитываются только затронутые объекты.

Применение

Рандеву-хеширование используется во многих реальных системах, включая:

• Балансировщик нагрузки GitHub
• Распределенная база данных Apache Ignite
• Файловое хранилище Tahoe-LAFS
• Pub/sub платформа Twitter EventBus

Преимущества перед согласованным хешированием

• Более простая концепция и реализация
• Не требует предварительных вычислений или хранения токенов
• Обеспечивает простое решение для распределенного k-соглашения

Рандеву-хеширование становится все более популярным в современных распределенных системах благодаря своей простоте, эффективности и гибкости

Характеристика	Согласованное хеширование	Рандеву-хеширование
Год изобретения	1997	1996
Сложность	Более сложный	Проще
Метод отображения	Отображает узлы и ключи на кольцо хеширования	Вычисляет хеш-значения для каждой пары ключ-узел
Размещение объектов	По часовой стрелке на хеш-кольце	Выбирает узел с наибольшим хеш-значением
Балансировка нагрузки	Хорошая, но могут быть горячие точки	В целом лучше, более равномерная
Масштабируемость	Хорошо масштабируется при инкрементных изменениях	Менее масштабируемо, пересчитывает все хеши
Предварительные вычисления токенов	Требует предварительного вычисления и хранения токенов	Не требует предварительных вычислений токенов
Сложность добавления/удаления узлов	O(K/N + log N)	O(n) для базовой реализации
Перераспределение ключей	Минимальное перемещение ключей	Объекты перераспределяются на оставшиеся узлы
Реальное использование	Cassandra, Couchbase	GitHub Load Balancer, Apache Ignite, Twitter EventBus

База данных	CAP	QPS	Масштабирование	Оптимизация	In memory/Disk based	Область применения
Apache Cassandra	AP	До 1 000 000	Горизонтальное	Write	Disk based	Большие данные, IoT
Memcached	CP	До 1 000 000	Горизонтальное	Read	In memory	Кэширование, веб-приложения
Redis	CP	До 500 000+	Горизонтальное	Read/Write	In memory	Кэширование, сессии
Amazon DynamoDB	AP	До 500 000	Автоматическое горизонтальное	Read/Write	Disk based	Веб-приложения, мобильные приложения
ClickHouse	CP	До 300 000	Горизонтальное	Read/Write	Disk based	Аналитика, большие данные
Couchbase	AP	До 200 000	Горизонтальное	Read/Write	Hybrid	Веб-приложения, мобильные приложения
PostgreSQL	CA	До 150 000	Вертикальное, репликация	Read	Disk based	Транзакционные системы, ГИС
Oracle Database	CA	До 120 000	Вертикальное, RAC кластеры	Read/Write	Disk based	Корпоративные приложения, финансы
MongoDB	CP	До 100 000	Горизонтальное и вертикальное	Read/Write	Disk based	Веб-приложения, IoT
MySQL	CA	До 100 000	Вертикальное, репликация	Read	Disk based	Веб-сайты, CMS
Etcd	CP	До 80 000	Горизонтальное	Read	Disk based	Распределенные системы, конфигурации
Apache HBase	CP	До 30 000	Горизонтальное	Write	Disk based	Большие данные, аналитика
Microsoft Azure Cosmos DB	AP	Варьируется	Горизонтальное	Read/Write	Disk based	Глобально распределенные приложения
InfluxDB	CP	Варьируется	Горизонтальное	Read/Write	Disk based	IoT, мониторинг
PostGIS	CA	Варьируется	Вертикальное, репликация	Read	Disk based	ГИС, картография
Apache Spark SQL	CP	Варьируется	Горизонтальное	Read/Write	In memory	Аналитика больших данных
OpenSearch	AP	Варьируется	Горизонтальное	Read	Disk based	Поиск, логи
CouchDB	AP	Варьируется	Горизонтальное	Read/Write	Disk based	Веб-приложения, мобильные приложения
Firebird	CA	Варьируется	Вертикальное, репликация	Read/Write	Disk based	Встраиваемые системы, локальные приложения

Примечания:

1. «In memory» означает, что база данных хранит данные преимущественно в оперативной памяти для быстрого доступа.
2. «Disk based» означает, что база данных в основном хранит данные на диске.
3. «Hybrid» (как в случае с Couchbase) означает, что база данных использует как память, так и диск для оптимальной производительности.
4. Значения QPS являются приблизительными и могут варьироваться в зависимости от конфигурации и нагрузки.