System Design для самых маленьких. Reference к интервью

В статье описан подход к построению высоконагруженных распределенных систем, который может быть полезен как reference при подготовке к интервью в FAANG по system design.

0f92f25ea3e69ded5edb46bfc691b56a.png

Обо мне

Software Engineer с опытом около 7 лет. Успел поработать в стартапах и крупных компаниях. Начинал с разработки прошивок для микроконтроллеров, а сейчас занимаюсь написанием высоконагруженных сервисов. На данный момент работаю в компании Yandex, где мы с командой строим Доставку для вас.

System design. Реальный проект vs Интервью

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

Note: Скоуп — это функциональные и нефункциональные требования; Ограничения — это то, что не будет реализовано в рамках проекта. Функциональные требования описывают поведение приложения, которые ожидает бизнес (expected result). К нефункциональным относятся технические ограничения системы (какую нагрузку оно должно держать, его доступность и прочее.

Обычно в рамках интервью у вас есть 45 минут на то, чтобы продемонстрировать свои навыки (не учитывая времени на знакомство и обсуждения в конце). Когда вы получили задание, не спешите начинать что-то проектировать, т.к нельзя сделать то, не знаю чего.

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

  • Сбор требований (3–4 минуты)

  • Оценка нагрузки (3–4 минуты)

  • Высокоуровневый дизайн (10 минут)

  • Компонентный дизайн (15 минут)

  • Повышение отзывчивости и отказоустойчивости (5 минут)

  • Мониторинг и алертинг (2–3 минуты)

  • Безопасность (1 минута)

Сбор требований

Для начала нужно определиться с тем, что мы собираемся реализовать в рамках проекта (scope):, а именно функциональные и нефункциональные требования; и что оставляем за скобками (out of scope). Выделите пару-тройку основных фичей, которые отличают это приложение от остальных. На их основе стоит накидать черновик API, который поможет во время оценки нагрузки. 

Note: На интервью не стоит тратить много времени на сбор требований. Но на реальном проекте это один из важнейших этапов.

Оценка нагрузки

Определите, чем нагружено ваше приложение: вычислениями (compute intensive), данными (data intensive) или сетью (network intensive). Это и есть bottleneck сервиса, уделите ему наибольшее внимание при вычислениях.

Например, если стоит задача спроектировать сервис вроде Доставки, то можно рассуждать так:

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

  2. Тогда у него будет 4 вида пользователей: отправитель, получатель, курьер и администратор. 

    1. Отправители создают заявки, получатели их трекают, а курьеры в основном принимают и перевозят заказ.

    2. Админы не создают особой нагрузки по сравнению с остальными пользователями, поэтому их можно опустить.

  3. Основная нагрузка идет на storage и network, потому что:

    1. заявки нужно хранить длительный период (storage),

    2. выполнение заказов нужно трекать (network).

  4. Из этого следует, что в перспективе 5 лет стоит подумать о таких параметрах, как:

    1. Daily active users (DAU) && Monthly active users (MAU).

    2. Read/Write баланс.

    3. Network (трафик, connections, rps).

    4. Storage (RAM, ssd/hard disks).

    5. Стоимость создания инфраструктуры и ее поддержки (опционально).

Посчитав все это, вы сможете понять: будет ли приложение держать нагрузку, грубо говоря, на одной машинке, либо же понадобится кластер, распределенный на несколько ДЦ, чтобы удовлетворять требованиям отказоустойчивости (fault tolerance), низкой задержки (low latency) и консистентности данных (обычно eventual consistency).

Высокоуровневый дизайн

После того, как вы определились с требованиями и нагрузкой, пора переходить к высокоуровневому дизайну системы. На данном этапе нужно:

  1. Вспомнить про оговоренные функциональные требования.

  2. На основе их выделить основные сервисы/компоненты системы.

  3. Определиться с основной БД (обычно выбор стоит между SQL и NoSQL).

Note: Представьте, будто вы разрабатываете систему, которая будет жить на одной машинке. Это позволит вам не думать о масштабировании преждевременно. 

Далее в примерах будут использоваться следующие обозначения:

Пример высокоуровнего дизайна

Компонентный дизайн

Дьявол кроется в деталях, поэтому критически важные компоненты системы стоит разбить на более мелкие. Нужно показать, как эти компоненты будут взаимодействовать между собой, какие алгоритмы и структуры данных будут использоваться.

Пример детализации компонента Search UI

Повышение отзывчивости и отказоустойчивости

Теперь настал тот момент, когда стоит задуматься об отзывчивости и отказоустойчивости. Исходя из требований к системе какие-то сервисы (компоненты) будут более высоконагруженными, какие-то менее, поэтому нужно подумать про:

  • масштабирование,

  • балансировку нагрузки,

  • кэширование горячих данных (чаще всего используются),

  • ограничение нагрузки (rate limiters),

  • шардирование и репликацию данных,

  • шину данных (брокеры сообщений).

Пример отказоустойчивого компонента Search UI

Мониторинг и алертинг

Очень часто на собеседованиях забывают упомянуть про мониторинг. Стоит выбирать те метрики, которые нам о чем-то говорят и на которые мы можем повлиять. Их можно разделить на две группы: продуктовые и технические. 

Продуктовые метрики специфичны для каждого продукта. Пример: кол-во созданных заказов, MAU, DAU. 

Из технических метрик часто мониторят тайминги и rps ендпоинтов, ресурсы машинки (cpu wait, кол-во свободных потоков, память), ресурсы БД (время выполнения запросов, кол-во соединений к базе, лаг репликации), network (кол-во открытых соединений, пропускной  канал).

Пример мониторинга в Grafana

Безопасность

Если осталось еще немного времени, то можно коснуться темы безопасности системы. Какие могут осуществляться типы атак/фродов и каким образом мы можем от них защититься. Достаточно упомянуть использование сторонних сервисов (напр. CloudFlare).

Заключение

В данной статье я постарался систематизировать и дать в общем виде подход к решению задач по построению высоконагруженных распределенных систем. Этот план хорошо подходит при прохождении system design интервью.

В следующих статьях разберем конкретные примеры и более детально обсудим их построение. Напишите в комментариях, какие системы Вам хотелось бы рассмотреть. Спасибо!

Полезные ссылки

Пример качественного интервью по system design
Библия для тех, кто хочет научиться разрабатывать высоконагруженные распределенные системы
Книжный клуб Tinkoff
Доклад с Highload про построение Экспресс Доставки в Яндексе
Проходим L6 интервью на system design в FAANG
Архитектурные секции собеседования в Яндексе
Общие принципы прохождения system design интервью

© Habrahabr.ru