System design · практикум
ПРАКТИКУМ
Архитектор
по заявке
Компания присылает описание своего сервиса. По нему нужно собрать схему системы из готовых деталей: клиенты, балансировщик, ограничитель частоты, серверы, базы данных, очереди. Затем компания присылает список своих данных — их нужно разложить по хранилищам. Третьим письмом приходит рост нагрузки или сбой, и схему нужно изменить.
- Дисциплина
- Технология разработки и защиты баз данных, модуль 2
- Время
- 2 пары: схема и данные на первой, изменения и отчёт на второй
- Что нужно знать
- Реляционная и документная модели, что такое кеш и индекс
- Что сдать
- Отчёт
.mdи изображение схемы.png
Конструктор работает в браузере, установка не нужна. Работа сохраняется в этом браузере на этом компьютере; перед уходом из компьютерного класса скачайте отчёт.
§1Три письма компании
В практикуме три заявки: сервис доставки еды «Обед за 30», онлайн-кинотеатр «Полный метр» и сеть поликлиник «Клиника у дома». Компании вымышленные, но их требования взяты из типовых задач: вход по SMS, открытое API для партнёров, медицинские данные по 152‑ФЗ. Заявку для работы указывает преподаватель.
Каждая заявка — три письма. Следующее письмо открывается, когда выполнено предыдущее.
В письме — кто пользуется сервисом, сколько запросов, что уже ломалось у компании или у её конкурентов. По этим фактам собирается схема: какие детали нужны и как они связаны.
Письмо 2 открывается, когда выполнены все обязательные требования.
Компания перечисляет свои сущности: пользователи, заказы, коды из SMS, файлы, события. Для каждой сущности указаны пример полей и объём. Каждую сущность нужно отнести к одному или нескольким хранилищам со схемы.
Письмо 3 открывается, когда распределены все сущности и не меньше 70 % из них распределены верно или допустимо.
Акция, премьера, отказ диска, утечка ключа. Схему нужно изменить так, чтобы она выдержала описанную ситуацию. Требования первого письма при этом продолжают проверяться.
§2Как пользоваться конструктором
Экран конструктора разделён на три части. Слева — письма компании и результаты проверки. В центре — доска со схемой. Справа — детали, из которых собирается схема, и свойства выбранного узла.
Одну деталь можно поставить на схему несколько раз. Например, у сервиса доставки два мобильных приложения — для клиентов и для курьеров. Тогда оба узла подписывают в поле «Подпись на схеме», чтобы их можно было различить.
У части деталей есть настройки, которые проверяются так же, как стрелки: число экземпляров сервера, ключ ограничителя частоты, реплики и шифрование базы, роли Redis. Описание каждой детали — в каталоге деталей и в правой панели конструктора.
§3Что означает стрелка
Стрелка идёт от того, кто обращается, к тому, к кому обращаются. Сайт обращается к балансировщику, балансировщик — к серверу приложения, сервер приложения — к PostgreSQL. Ответ идёт обратно по той же связи, отдельную стрелку для него не рисуют.
Из этого правила следуют три соглашения:
- База данных никого не вызывает, поэтому стрелки от базы нет. Исключение — ClickHouse, который сам забирает события из журнала событий.
- К очереди ведут две стрелки: от сервера, который кладёт задачу, и от фонового обработчика, который её забирает. Обработчик обращается к очереди сам.
- Ограничитель частоты стоит на пути запроса перед тем, что он защищает. Если он хранит счётчики в Redis, от ограничителя к Redis ведёт ещё одна стрелка.
На рисунке ограничитель частоты пропускает к серверу только разрешённые запросы и хранит счётчики в Redis. Сервер обращается к PostgreSQL и к Redis.
§4Как устроена проверка
Кнопка «Проверить схему» сверяет схему с требованиями заявки. Требования бывают двух видов.
| Вид | Что означает | Как показан |
|---|---|---|
| Обязательное | Без этого сервис не выполняет то, что просит компания: падает при отказе сервера, теряет деньги на SMS, раздаёт медицинские снимки по открытой ссылке. | ✗ на красном фоне |
| Рекомендованное | Сервис работает, но хуже: нагружает основную базу лишними записями, не предупреждает дежурного о перегрузке. | ! на жёлтом фоне |
Под невыполненным требованием выводится подсказка: на какие строки письма смотреть. Готового ответа подсказка не содержит. Стрелки и узлы, которые нарушают общие правила (клиент обращается к базе напрямую, узел ни с чем не связан), подсвечиваются на доске красным пунктиром.
Проверка учитывает узлы, их настройки и стрелки. Где стоят узлы на доске, на результат не влияет. Одно требование часто можно выполнить разными способами. Например, ограничитель частоты можно поставить перед отдельным сервисом или перед всем сервером приложения. Проверка примет оба варианта, если ограничитель стоит на каждом пути от клиента к тому, что он защищает.
В письме 2 после проверки у каждой сущности появляется оценка и пояснение:
- верно — выбрано лучшее хранилище;
- допустимо — выбор рабочий, но у него есть недостаток, он назван в пояснении;
- неверно — подходящее хранилище не выбрано или отмечено лишнее.
Некоторые сущности хранятся сразу в двух местах. Карточка фильма лежит в MongoDB, а её копия — в поисковом движке. Поэтому у сущности можно отметить несколько хранилищ.
§5Обоснования
Под каждым письмом есть поле для обоснования. В него записывается, почему выбрано то или иное решение, со ссылкой на факт из письма. За обоснования ставится 3 балла из 10: по ним преподаватель видит, на какие факты письма опирается каждое решение.
Каталог книг хранится в MongoDB, а его копия — в поисковом движке. В письме сказано, что покупатели ищут по фамилии автора и часто ошибаются («Достоевкий»). Фильтр по полю в базе находит только точное совпадение, поисковый движок находит слово с опечаткой и учитывает формы слова.
§6Сдача и оценка
На вкладке «Отчёт» укажите фамилию, имя и группу и скачайте два файла:
arhitektor_<заявка>_<фамилия>.md— отчёт: узлы с настройками, список стрелок, результаты проверок, распределение данных и все обоснования;arhitektor_<заявка>_<фамилия>.png— изображение схемы.
Оба файла сдаются преподавателю тем способом, который принят в группе. Отчёт ссылается на картинку схемы по имени, поэтому файлы должны лежать рядом.
| Критерий | Баллы |
|---|---|
| Письмо 1: выполнены все обязательные требования | 2 |
| Письмо 1: выполнено не меньше половины рекомендованных | 1 |
| Письмо 2: не меньше 90 % сущностей распределены верно или допустимо | 2 |
| Письмо 3: выполнены все обязательные требования | 2 |
| Обоснования: у каждого решения есть ссылка на факт из письма | 3 |
| Итого | 10 |
Перевод в оценку: 9–10 баллов — «отлично», 7–8 — «хорошо», 5–6 — «удовлетворительно».