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

Перевод репозитория https://leetcode.com/discuss/career/229177/My-System-Design-Template

1. Ожидания от функционала [5 мин]

• Варианты использования
• Сценарии, которые не будут охвачены
• Кто будет использовать
• Сколько пользователей будет
• Шаблоны использования

2. Оценки [5 мин]

• Пропускная способность (QPS для запросов на чтение и запись)
• Ожидаемая латентность системы (для запросов на чтение и запись)
• Соотношение чтения/записи
• Оценки трафика
• Запись (QPS, объем данных)
• Чтение (QPS, объем данных)
• Оценки хранилища
• Оценки памяти
• Какие данные мы хотим хранить в кэше, если используем его
• Сколько RAM и машин нам нужно для достижения этого
• Объем данных для хранения на диске/SSD

3. Цели проектирования [5 мин]

• Требования к латентности и пропускной способности
• Согласованность vs Доступность [Слабая/сильная/итоговая => согласованность | Отказоустойчивость/репликация => доступность]

4. Высокоуровневый дизайн [5-10 мин]

• API для сценариев чтения/записи критических компонентов
• Схема базы данных
• Базовый алгоритм
• Высокоуровневый дизайн для сценариев чтения/записи

5. Глубокое погружение [15-20 мин]

Масштабирование алгоритма

Масштабирование отдельных компонентов:

• Доступность, согласованность и масштабируемость для каждого компонента
• Паттерны согласованности и доступности

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

a) DNS

b) CDN [Push vs Pull]

c) Балансировщики нагрузки [Активный-Пассивный, Активный-Активный, Уровень 4, Уровень 7]

d) Обратный прокси

e) Масштабирование уровня приложений [Микросервисы, Обнаружение сервисов]

f) БД [RDBMS, NoSQL]

• RDBMS
• Мастер-слейв, Мастер-мастер, Федерация, Шардинг, Денормализация, Оптимизация SQL
• NoSQL
• Ключ-Значение, Широкая колонка, Граф, Документ
• Быстрый поиск:
  • RAM [Ограниченный размер] => Redis, Memcached
  • AP [Неограниченный размер] => Cassandra, RIAK, Voldemort
  • CP [Неограниченный размер] => HBase, MongoDB, Couchbase, DynamoDB

g) Кэши

• Клиентское кэширование, CDN кэширование, Кэширование веб-сервера, Кэширование базы данных, Кэширование приложений, Кэш на уровне запросов, Кэш на уровне объектов
• Политики вытеснения:
• Cache aside
• Write through
• Write behind
• Refresh ahead

h) Асинхронность

• Очереди сообщений
• Очереди задач
• Обратное давление

i) Коммуникация

• TCP
• UDP
• REST
• RPC

6. Обоснование [5 мин]

• Пропускная способность каждого уровня
• Латентность между каждым уровнем
• Обоснование общей латентности

Времена доступа к памяти и хранилищам

• Обращение к кэшу L1: 0.5 нс
• Обращение к кэшу L2: 7 нс
• Обращение к основной памяти: 100 нс
• Чтение 1 МБ последовательно из основной памяти: 250,000 нс
• Произвольный доступ к жесткому диску: 10,000,000 нс
• Чтение 1 МБ последовательно с жесткого диска: 20,000,000 нс[3]

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

Сетевые задержки

• Пересылка 2 КБ по сети со скоростью 1 Гбит/с: 20,000 нс
• Передача сообщения туда/обратно в одном дата-центре: 500,000 нс
• Передача пакета из Калифорнии в Нидерланды и обратно: 150,000,000 нс[3]

Понимание сетевых задержек важно при разработке распределенных систем.

Другие важные числа

• Ошибка при предсказании условного перехода: 5 нс
• Открытие/закрытие мьютекса: 25 нс
• Сжатие 1 КБ быстрым алгоритмом: 3,000 нс[3]

Эти цифры помогают оценивать эффективность различных операций в коде.

Степени двойки

Разработчикам также полезно помнить степени двойки: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024[31]. Они часто встречаются при работе с памятью, файловыми системами и другими аспектами разработки.

Коды ошибок HTTP

• 403: доступ запрещен
• 404: страница не найдена
• 500: внутренняя ошибка сервера
• 503: сервис недоступен[31]

Перевод и адаптация этого репозитория https://github.com/jguamie/system-design/blob/master/notes/system-design-outline.md

Это рекомендуемый подход к решению задач проектирования систем. Не все эти темы будут актуальны для конкретной задачи.

1. Функциональные требования / Уточнения / Предположения (Functional Requirements / Clarifications / Assumptions)
2. Нефункциональные требования (Non-Functional Requirements)
   1. Согласованность vs Доступность (Consistency vs Availability)
   2. Задержка (Latency)
      1. Насколько быстрой должна быть эта система?
      2. Задержка, воспринимаемая пользователем (User-perceived latency)
      3. Задержка обработки данных (Data processing latency)
   3. Безопасность (Security)
      1. Потенциальные атаки? Как их следует смягчать?
   4. Конфиденциальность (Privacy)
      1. PII (Personally Identifiable Information — Персональные данные, позволяющие идентифицировать личность), PCI (Payment Card Industry — Индустрия платежных карт) или другие пользовательские данные
   5. Целостность данных (Data Integrity)
      1. Как восстановиться после повреждения или потери данных?
   6. Соотношение чтения:записи (Read:Write Ratio)
3. API (Application Programming Interface — Интерфейс программирования приложений)
   1. Публичные и/или внутренние API?
   2. Просты ли API для понимания?
   3. Как идентифицируются сущности?
4. Схемы хранения (Storage Schemas)
   1. SQL (Structured Query Language — Язык структурированных запросов) vs NoSQL (Not Only SQL — Не только SQL, обозначает нереляционные базы данных)
   2. Очереди сообщений (Message Queues)
5. Проектирование системы (System Design)
6. Масштабируемость (Scalability)
   1. Как масштабируется система? Учитывайте увеличение как объема данных, так и трафика.
   2. Каковы узкие места? Как их следует устранять?
   3. Каковы граничные случаи? Что может пойти не так? Предполагая, что они произойдут, как их следует решать?
   4. Как мы будем проводить стресс-тестирование этой системы?
   5. Балансировка нагрузки (Load Balancing)
   6. Автомасштабирование / Репликация (Auto-scaling / Replication)
   7. Кэширование (Caching)
   8. Партиционирование (Partitioning)
   9. Репликация (Replication)
   10. Непрерывность бизнеса и аварийное восстановление (BCDR — Business Continuity and Disaster Recovery)
   11. Интернационализация / Локализация (Internationalization / Localization)
       1. Как масштабироваться на несколько стран и языков? Не предполагайте, что в США используется только английский язык.