Есть много сообщений о том, как выглядит типичное собеседование в Google. Но, хотя это и не так широко описывается и обсуждается, довольно часто проводится собеседование по проектированию системы. Для позиции SRE это NALSD: неабстрактный дизайн большой системы. Ключевое различие между интервью SWE и SRE состоит в этих двух буквах: NA.

Итак, в чем разница? Как подготовиться к этому интервью? Давайте не будем абстрактными и воспользуемся примером. Чтобы быть более не абстрактным, возьмем что-нибудь из материального мира, чтобы на настоящем собеседовании (по крайней мере, не на собеседовании в Google) вас не спросили об одном и том же :)

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

Интервью с NALSD: разработка системы публичных библиотек.

Прежде всего, мы собираем характеристики нагрузки, задавая интервьюеру вопросы или делая разумные предположения (не забывая сформулировать их вслух). Поскольку интервью касается масштабируемых систем, мы ожидаем города с большим населением (скажем, 1 млн +). У нас есть несколько вариантов: одно огромное здание или местные библиотеки плюс хранилище. Я думаю, что последнее более разумно, так как оно также позволяет нам расширить систему на несколько городов.

Теперь давайте сосредоточимся на системе для отдельного города; мы должны иметь возможность снова применить тот же дизайн (с небольшими исправлениями), чтобы расширить его до странового уровня. Итак, у нас есть город с населением более 1 миллиона человек. Чтобы упростить вычисления, округлим число до 1 миллиона возможных читателей. Каждый читатель хочет читать что-то независимо друг от друга, в произвольные моменты времени. Таким образом, мы можем смоделировать поток читателей как процесс Пуассона. Во время собеседования делать правильные вычисления немного сложно, поэтому давайте еще раз упростим и скажем, что около 1% возможных читателей будут приходить брать книгу каждый день. Итак, предположим, что 10 000 запросов на книги в день.

Итак, наша задача теперь стала: предоставить возможность раздавать 10000 книг в день (это также означает, что мы должны иметь возможность забрать эти 10000 книг когда-нибудь позже) в более чем миллионном городе. Эта оценка показывает, что решение с одним зданием не выдержит испытания (чтобы обеспечить книгами более 1 миллиона человек, наша библиотека должна быть доступна в течение разумного периода времени, иначе их желание взять книгу прекратится в пробке). Итак, давайте попробуем угадать разумный размер локальных библиотек, которые мы должны создать. Абсолютно правильная оценка будет включать плотность населения, задержки доступности и т. Д., Но поскольку это не повлияет на общий дизайн, мы снова можем упростить его, рассмотрев равномерное распределение похожих единиц. Мы до сих пор не знаем, насколько большими должны быть блоки; например, мы могли бы распределить 10000 библиотек с одной книгой по всему городу, но это явно не сработает. Спускаемся на уровень ниже.

Единая местная библиотека. Чтобы книга была полезной, большинство посетителей должны иметь возможность найти нужную книгу. Это означает, что нам нужно отслеживать использование и прогнозировать спрос на самые популярные запросы, чтобы быть готовыми их обслуживать. Вдобавок у нас должен быть широкий ассортимент менее популярных товаров. По моим приблизительным подсчетам, в библиотеке меньше 1000 наименований книг, десятки экземпляров наиболее популярных из них и отдельные пьесы для хвостов. Среднее время чтения книги в нашей библиотеке составляет от 3 дней до 2 недель (разумеется, реальное время зависит от самой книги, что в реальном случае потребует дополнительного анализа); Давайте оценим как 1 неделю на книгу. Это означает, что розданная книга вернется через 1 неделю, поэтому у нас должен быть запас лучших книг на 1 неделю (через неделю они пополняются за счет возвратов).

Предположим, что средний коэффициент раздува равен 6, что позволит нам получить единицу хранения 6000 книг. Меньший объем хранилища будет означать нехватку наиболее популярных наименований (ну, меньшие единицы все еще могут быть полезны - например, небольшой киоск в торговом центре с надписью «Сумерки», но давайте сейчас оставим это за пределами нашего дизайна).

В стабильном состоянии доходность и заимствования каждый день почти одинаковы (с некоторым разбросом), но мы также должны планировать пиковые доходы (которые могут быть событиями внешней синхронизации: праздники, тенденции и т. Д.). Правильный способ - создать и запустить статистическую модель. Но пока давайте оставим ⅓ в качестве буфера. Это означает, что у нас должно быть 6000 книг для раздачи плюс место на 2000.

Подводя итог: нам нужен библиотечный блок на 8000 книг. Ежедневное пополнение запасов будет дорогостоящим, поэтому нам следует ожидать, что этого хватит на неделю или две. Две недели, 6000 книг, с возможной перекосом возвратов, это около 300 книг в день. В день открытия мы можем заполнить все хранилище (8000 книг), чтобы заполнить начальные 2000 книг в обороте. 2000 за 3 дня = 600 книг в день, с перекосом буфера = 800 книг в день.

Оценим пропускную способность и ограничения нашего хранилища. Одна книга занимает около 2 погонных сантиметров, 8000 книг = 160 метров. Мы можем сложить его по вертикали 4 раза, то есть 40 погонных метров. Если разбить его на стойки по ~ 5 метров, то получится 8 стеллажей с 4 полками по 5 метров каждая. Один библиотекарь (или робот-библиотекарь) должен уметь работать с двумя стойками; извлечение одной книги займет: 5 секунд, чтобы дойти до полок, 5 секунд, чтобы взять / поставить книгу на место, 5 секунд, чтобы вернуться назад (всего 15 секунд). 4 библиотекаря обеспечат нам максимальную пропускную способность 15 книг в минуту. Таким образом, обработка не более 900 книг в час.

Если мы также учтем время обработки запроса (10 с), время поиска (5 с) и время отслеживания в системе (2 с), мы получим пиковое значение 400 книг в час. Таким образом, мы должны справиться с нашей оценкой в ​​800 книг в день за 2 часа.

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

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

Вот и все, пора двигаться дальше. По нашим оценкам, потребность в общей библиотечной сети составляет 10 000 книг в день. Одна единица составляет 800 книг в день, поэтому нам нужно 12,5 единиц. Если мы сделаем равномерное географическое распределение, каждый читатель должен находиться в пределах 1-2 единиц (на границе города) и 3–4 (внутри города). Это дало бы возможность немного сгладить пики и / или покрыть нехватку лучших книг.

Мы также знаем, что любую библиотеку можно закрыть в любой момент (пожар, осмотр, перекраска дверных ручек холодильника и т. Д.), И что чем больше у нас единиц, тем выше вероятность совпадения этих событий. Таким образом, нам нужен 1 резервный блок на каждые 5–6 блоков. Итак, всего нам нужно 15 единиц для удовлетворения потребностей нашего города, если мы будем поддерживать необходимое снабжение в каждой единице.

Как мы уже думали ранее, нам нужно пополнять хранилище каждую неделю или две (ранее мы догадались, что две) - примерно половину хранилища нужно заменять, чтобы следовать тенденциям и т. Д. Итак, 4000 книг новой доставки и 4000 книг удалено из нее. . При каждом пополнении запасов нам нужно извлечь 4000 книг и вставить обратно 4000 новых записей. С нашей производительностью 400 книг в час на одно пополнение запасов уйдет 10 очень напряженных часов. Что ж, кажется, все в порядке, тем более что оптовые операции обычно дешевле; Но в любом случае - надо иметь в виду, что операция по пополнению запасов обходится в 5 раз дороже, чем просто обслуживание.

Средняя книга (2 см * 20 см * 30 см) составляет 1,5 литра объема, поэтому 4000 книг = 6 кубических метров. Он должен уместиться в одном среднем легком грузовом автомобиле. 1 кубометр бумаги весит 600 кг, 6 м³ = 3,6 тонны. В среднем легковой грузовой автомобиль может выдержать ~ 1,5 тонны, поэтому нам нужно 3 тонны. Плюс один для резервирования. У нас есть 15 библиотечных единиц, которые обновляются раз в две недели, а это значит, что это будет жестко по графику, поэтому нам нужна еще одна машина.

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

Время вышло. Итак, что же такого особенного в вопросе NALSD? Масштабируемость ожидается от любой крупной системы. Но на собеседовании NALSD нужно быть конкретным.

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

Я до сих пор помню, как во время собеседования с NALSD я застрял с IOPS одного жесткого диска, равным 600, просто потому, что я недавно работал над оптимизацией некоторого рейд-массива, где у всего массива было 600 IOPS ... Интервьюер был слегка удивлен: 600 операций ввода-вывода в секунду на диск? : D

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

Если для исправления предположения требуется полная переработка системы, это либо ошибка проекта, либо неправильное исправление, либо новое предположение выводит нас за пределы применимости проекта (а это не так уж редко в реальной жизни). Важно не упустить этот факт: вам следует проверять полученные цифры, чтобы убедиться, что они реалистичны как во время разработки, так и после любых исправлений.

Как SRE, мы должны думать о масштабируемости реальных систем в рамках ограничений реального оборудования. Мог бы существовать красивый алгоритм, который заменяет гигантскую временную сложность на некоторый объем ОЗУ… Но все же 1 ПиБ ОЗУ на 1 ЦП - это не то, что мы можем построить сегодня. Итак, если у нас есть 1 ПиБ ОЗУ, у нас также будет около 10 КБ процессоров. Или 20к. Или даже 30к. Это означает, что мы должны сосредоточиться на реальном (локальном) оптимуме, достижимом сегодня в реальности, а не на глобальном оптимуме, достижимом в идеальных условиях.

Вы не должны запоминать точные числа, но вы должны уметь применять эмпирические правила, чтобы получить порядки величины. Например, количество операций ввода-вывода в секунду: HDD - около 100, SSD - около 100 тысяч. Но эти сотни тысяч идут с разницей в цене между HDD и SSD, такой как 1: 3 или 1: 4. Он также игнорирует все, что есть вокруг: пространство в стойке, блейд-серверы для дисков, сетевые порты и другие вещи, которые перестают быть дешевыми, если вы работаете в пета- и экзадарах.

Теперь удобно устроиться в кресле, расслабиться и попробовать разработать систему выращивания и доставки свежих куриных яиц по подписке.