Оффлайн
- Регистрация
- 21.07.20
- Сообщения
- 40.408
- Реакции
- 1
- Репутация
- 0
Архитектурные секции у многих вызывают чувство неопределенности и тревоги: формулировки не изобилуют деталями, как проверить ответ — непонятно. При этом способность пройти архитектурную секцию отличает вчерашнего выпускника от человека, которому можно доверить строить нечто большее, чем обход бинарных деревьев. В определенный момент я решил как следует подготовиться секции по дизайну, потратил на это около пары недель и выработал системный подход, которым хочу с вами поделиться.
План
Очень важно его иметь. Даже если вы где-то ошибетесь и свернете не туда в своих рассуждениях, общая структурированность подхода сыграет вам на руку. В самом начале можно умеренно тупить и расспрашивать собеседующего о подробностях, но начиная с некоторого момента (который в моем плане ниже соответствует пункту 3) инициатива должна быть полностью у вас и лучшее ее не отпускать до самого конца. Мой план был примерно таким:
1. Собрать список ключевых фич и выписать их в углу доски. Этот простой трюк поможет вам не забыть важное ограничение или допущение.
2. Понять, какими техническими характеристиками должна обладать система: ожидаемый RPS, диапазон допустимых времен ответа, ожидания в плане консистентности и надежности.
3. Собрать простейшее решение, рассчитанное на одну машину, которое будет хоть как-то работать. Начинать с 20 датацентров по всему миру не нужно, гораздо лучше к этому постепенно прийти.
4. Найти единую точку отказа или узкое место в плане производительности.
5. Предложить один или больше вариантов решения проблемы, внятно объяснить плюсы и минусы каждого из них
6. Выбрать один из вариантов и перейти к пункту 4, если время еще есть, а если оно заканчивается — перейти к следующему пункту
7. Прикинуть размеры стораджей, количество серверов, пропускную способность сети, аккуратно это все выписать
8. Бонус: поговорить про дополнительные фичи, внедрение ML, метрики продукта, эксперименты
Очень важно контролировать время. Я старался минут 5-10 тратить на два первых пункта и минут 5 на два последних.
Трейдофы
Их нужно проговаривать, даже если они кажутся очевидными. После внедрения любой новой детали важно сказать что-нибудь в духе «мы добавили новый элемент, это решит такую-то проблему, но за это мы заплатим тем-то». Трейдофы могут быть какими-то например такими:
1. Любые новые компоненты системы или рост количества уже существующих запчастей решают проблему нагрузки/скорости ответа, но добавляют головной боли с поддержкой и деплоем.
2. Шардирование решает проблему нагрузки и нехватки места, но добавляет проблем с перешардированием в будущем.
3. Реплицированное хранилище решает проблему нагрузки и надежности, но в случае наличия read и write реплик заставляет думать о протухших значениях и противостоянии доступности и консистентности
4. Кэш решает проблему с нагрузкой, но заставляет думать о протухших значениях и cache coherency.
5. Собственное решение можно легко менять и оптимизировать для своих нужд, но его придется сперва написать.
6. Существующее решение хорошо тем, что оно уже существующее, но в нем придется разбираться.
Числа
Все знают про
В конечном итоге важно следующее:
1. Знать временные расходы на чтение данных из разного уровня процессорных кэшей, памяти, SSD, HDD и сети.
2. Помнить время round trip'ов внутри датацентра и вокруг земного шара, а также минимальную задержку, которую человек ощущает как лаг (~100ms).
3. Уметь быстро конвертировать байты в гигабайты, наносекунды в секунды и т.д., этот скилл у меня выработался сам собой в процессе практики.
Практика
Я купил маркерную доску, брал уже существующие сервисы и пытался придумать, как бы я их сделал с нуля. Рисовал на доске схемы, прикидывал нагрузку и необходимые ресурсы, искал в своем дизайне слабые места. Еще у меня есть классные друзья, с которыми мы устраивали псевдосекции и тренировались друг на друге — это был суперполезный опыт. После практики можно лезть в интернет и искать, как это на самом деле сделано, а потом пробовать еще раз. После 10-20 раундов с разными сервисами наступает просветление и отдельные повторяющиеся запчасти в существующих системах начинают быть отчетливо видны. Запчасти могут быть например такими:
1. Поиск (желательно с возможностью в реальном времени обновлять индекс)
2. Файловое хранилище (gfs, haystack)
3. Распределенное kv-хранилище (cassandra, dynamo)
4. Message queue и pub-sub системы в целом (kafka)
4. Лента новостей (twitter, instagram, facebook)
5. Чат, мессенджер, сервер для онлайн-игры (whatsapp, telegram, battle.net)
6. Стриминг, видео и аудио-чат (skype, twitch, youtube)
Ресурсы
1.
2.
3. Видео с конференций на тему как это устроено (тысячи их). После пары десятков видосов начинаешь видеть слабые места решений из первых двух пунктов. Реальные системы иногда устроены проще, чем их дизайнят в обучающих материалах, а иногда наоборот.
4. Cайт
5. Ну и самый важный ресурс — это ваши друзья и знакомые, которые знают, как устроены их системы и могут вам про них рассказать.
Несколько хороших видео и каналов
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Если жестких временных рамок у вас нет, но перспектива собеседования уже маячит на горизонте, самой правильной тактикой будет постоянно в фоне что-то читать/смотреть на тему устройства больших систем. С алгоритмическими задачками то же самое: лучше их периодически решать и быть всегда в тонусе, чем на выходных перед интервью пытаться осилить весь литкод. Тем не менее, интенсивная подготовка к архитектурной секции за короткий срок сделала меня значительно более лучшим специалистом.
План
Очень важно его иметь. Даже если вы где-то ошибетесь и свернете не туда в своих рассуждениях, общая структурированность подхода сыграет вам на руку. В самом начале можно умеренно тупить и расспрашивать собеседующего о подробностях, но начиная с некоторого момента (который в моем плане ниже соответствует пункту 3) инициатива должна быть полностью у вас и лучшее ее не отпускать до самого конца. Мой план был примерно таким:
1. Собрать список ключевых фич и выписать их в углу доски. Этот простой трюк поможет вам не забыть важное ограничение или допущение.
2. Понять, какими техническими характеристиками должна обладать система: ожидаемый RPS, диапазон допустимых времен ответа, ожидания в плане консистентности и надежности.
3. Собрать простейшее решение, рассчитанное на одну машину, которое будет хоть как-то работать. Начинать с 20 датацентров по всему миру не нужно, гораздо лучше к этому постепенно прийти.
4. Найти единую точку отказа или узкое место в плане производительности.
5. Предложить один или больше вариантов решения проблемы, внятно объяснить плюсы и минусы каждого из них
6. Выбрать один из вариантов и перейти к пункту 4, если время еще есть, а если оно заканчивается — перейти к следующему пункту
7. Прикинуть размеры стораджей, количество серверов, пропускную способность сети, аккуратно это все выписать
8. Бонус: поговорить про дополнительные фичи, внедрение ML, метрики продукта, эксперименты
Очень важно контролировать время. Я старался минут 5-10 тратить на два первых пункта и минут 5 на два последних.
Трейдофы
Их нужно проговаривать, даже если они кажутся очевидными. После внедрения любой новой детали важно сказать что-нибудь в духе «мы добавили новый элемент, это решит такую-то проблему, но за это мы заплатим тем-то». Трейдофы могут быть какими-то например такими:
1. Любые новые компоненты системы или рост количества уже существующих запчастей решают проблему нагрузки/скорости ответа, но добавляют головной боли с поддержкой и деплоем.
2. Шардирование решает проблему нагрузки и нехватки места, но добавляет проблем с перешардированием в будущем.
3. Реплицированное хранилище решает проблему нагрузки и надежности, но в случае наличия read и write реплик заставляет думать о протухших значениях и противостоянии доступности и консистентности
4. Кэш решает проблему с нагрузкой, но заставляет думать о протухших значениях и cache coherency.
5. Собственное решение можно легко менять и оптимизировать для своих нужд, но его придется сперва написать.
6. Существующее решение хорошо тем, что оно уже существующее, но в нем придется разбираться.
Числа
Все знают про
You must be registered for see links
, но числа по ссылке на мой взгляд структурированы не самым удобным образом и я их в процессе подготовки переформатировал для удобства запоминания.В конечном итоге важно следующее:
1. Знать временные расходы на чтение данных из разного уровня процессорных кэшей, памяти, SSD, HDD и сети.
2. Помнить время round trip'ов внутри датацентра и вокруг земного шара, а также минимальную задержку, которую человек ощущает как лаг (~100ms).
3. Уметь быстро конвертировать байты в гигабайты, наносекунды в секунды и т.д., этот скилл у меня выработался сам собой в процессе практики.
Практика
Я купил маркерную доску, брал уже существующие сервисы и пытался придумать, как бы я их сделал с нуля. Рисовал на доске схемы, прикидывал нагрузку и необходимые ресурсы, искал в своем дизайне слабые места. Еще у меня есть классные друзья, с которыми мы устраивали псевдосекции и тренировались друг на друге — это был суперполезный опыт. После практики можно лезть в интернет и искать, как это на самом деле сделано, а потом пробовать еще раз. После 10-20 раундов с разными сервисами наступает просветление и отдельные повторяющиеся запчасти в существующих системах начинают быть отчетливо видны. Запчасти могут быть например такими:
1. Поиск (желательно с возможностью в реальном времени обновлять индекс)
2. Файловое хранилище (gfs, haystack)
3. Распределенное kv-хранилище (cassandra, dynamo)
4. Message queue и pub-sub системы в целом (kafka)
4. Лента новостей (twitter, instagram, facebook)
5. Чат, мессенджер, сервер для онлайн-игры (whatsapp, telegram, battle.net)
6. Стриминг, видео и аудио-чат (skype, twitch, youtube)
Ресурсы
1.
You must be registered for see links
. Не все решения оттуда оптимальны, некоторые откровенно слабы, но материал хорошо структурирован и служит неплохой стартовой точкой.2.
You must be registered for see links
. По этой ссылке много полезного материала, но в нем легко запутаться.3. Видео с конференций на тему как это устроено (тысячи их). После пары десятков видосов начинаешь видеть слабые места решений из первых двух пунктов. Реальные системы иногда устроены проще, чем их дизайнят в обучающих материалах, а иногда наоборот.
4. Cайт
You must be registered for see links
5. Ну и самый важный ресурс — это ваши друзья и знакомые, которые знают, как устроены их системы и могут вам про них рассказать.
Несколько хороших видео и каналов
1.
You must be registered for see links
2.
You must be registered for see links
3.
You must be registered for see links
4.
You must be registered for see links
5.
You must be registered for see links
6.
You must be registered for see links
7.
You must be registered for see links
8.
You must be registered for see links
9.
You must be registered for see links
10.
You must be registered for see links
11.
You must be registered for see links
12.
You must be registered for see links
Если жестких временных рамок у вас нет, но перспектива собеседования уже маячит на горизонте, самой правильной тактикой будет постоянно в фоне что-то читать/смотреть на тему устройства больших систем. С алгоритмическими задачками то же самое: лучше их периодически решать и быть всегда в тонусе, чем на выходных перед интервью пытаться осилить весь литкод. Тем не менее, интенсивная подготовка к архитектурной секции за короткий срок сделала меня значительно более лучшим специалистом.