Конечно с таким уровнем детализации, как в докладе, все распределенные системы сборки будут похожи. Нет, мы не используем Bazel, у нас собственная система сборки, отличающаяся, как минимум, двумя аспектами — наши сборочные файлы значительно более лаконичные, и сборочный граф, которым оперирует система сборки, может быть сериализован и использован не только для трассировки зависимостей, но и для многих других целей, таких как определение diff'а (разницы по сборочных артефактам, в том числе и промежуточным) между двумя ревизиями, анализа критического пути, инициации системы CI по изменениями в зависимостях проекта, получение и инъекция статистических данных.
Не совсем верное утверждение – распределенность сложная, дорогой с т.з. потребителя она становится при упрощении системы, в нашем случае, например, при отказе от data affinity.
Вы пробовали убрать распределённость и запустить тот же процесс на условном толстом сервере (100+ ядер, 500+Гб памяти)?
Из не имеющих под собой никаких оснований предположений) предположу, что вы получите примерно 10х экономию ресурсов и несколько кратное ускорение джоб из-за экстремальной локальности данных, полного переиспользования кеша и надёжных интерфейсов (IPC на localhost дешевле и проще, чем сетевое взаимодействие).
Конечно пробовали. И для сборок, которые затрагивают значительную часть репозитория, мы получили времена, примерно в 5 раз превышающие время выполнения такой же сборки на умеренно загруженном кластере. Но основная проблема в том, что в каждый момент времени мы выполняем больше 2х сотен сборок одновременно, и все эти сборки имеют значительное пересечение по промежуточным артефактам сборочного графа. Интенсивное использование data affinity (запуск сборочных нод на тех хостах, которые имеют большее количество входных данных для ноды) и распределенного кеша (воркеры могут обмениваться сборочными артефактами) позволяет нам превосходить по скорости локальную сборку. В целом, как я говорил в докладе, эффективное управление сборочным кэшом позволяет нам экономить значительные объемы вычислительных ресурсов.
Парой комментариев выше я уже написал что ошибиться даже в несколько раз не будет проблемой с т.з. дизайна системы и ее последующей эксплуатации, особенно на таком, достаточно высоком уровне абстракции. Т.е. мы же говорим не о скорости доступа к памяти, а производительности достаточно сложного компонента. Но понимать порядок предела производительности подсистем и из чего он складывается, конечно, нужно.
Ну, у нас в компании есть некоторый опыт работы с трафиком, в том числе с обработкой SSL handshake'ов. Это цифры взяты по усредненным показателям производительности наших серверов. А в комментарии выше есть ссылка на бенчмарк от ngnix.
По-большому счету на таком интервью мы не можем оценивать кандидатов бинарно — в ходе беседы мы получаем информацию о том, насколько хорошо человек разбирается в тех областях, что были перечислены в статье, из чего уже можно делать выводы, решение какой сложности задач можно ему доверять.
Пользоваться поисковиком во время интервью не запрещается, но я бы не рекомендовал — в самой статье и в далее в комментариях я пытаюсь показать что не так важно знание конкретного фреймворка/сервиса и точные показатели производительности на определенной модели железа, как понимание порядка предела этой производительности и факторов, из которых эти пределы сказываются.
И вновь встречается формулировка "готовьтесь к собеседованию, прочитайте книжки, статьи, послушайте доклады и т.д.". Только вот одни лишь эти знания не дадут опыта, который будет более ценным на реальном рабочем месте с реальными рабочими задачами.
Одни эти знания действительно не дадут опыта. А вот опыт, полученный без этих знаний будет значительно менее ценным.
Стало интересно - действительно ли собеседования у вас на этом этапе проходят так подробно, с детализацией до таблиц в БД и чуть ли не конфигов сервисов? Сколько же оно длится по времени? Действительно это те вещи, которые хочется услышать от кандидата?
На собеседование отводится час, и за это время мы действительно ожидаем услышать от кандидата рассуждения по тем пунктам, которые я указал в статье. Некоторые части прорабатываются максимально детально вплоть до описания полей используемых структур данных. Возможно, некоторые моменты, где интервьюер чувствует уверенные знания кандидата, проговариваются менее подробно, но в целом нужно проработать все.
Мне, как сотруднику отдела технологий разработки, ближе всего история про монорепозиторий — большинство кодовой базы Яндекса хранится в нем. От каждого проекта, заехавшего в монорепозиторий требуется строгое соблюдение правил жизни в нем — думаю, тут более чем достаточно историй о преодолений внутреннего сопротивления.
Или, например, здесь описывается история о том, как мы переезжали из Oracle в PostgreSQL — там нет описания того, насколько жаркие были дискуссии на старте проекта, о его целесообразности в целом, но в качестве основных аргументов за переезд приводился успешный опыт коллег.
В целом мне кажется что отношение к тестированию в компании отражает уровень ее зрелости — чем дальше от уровня стартапа, тем больше вниманию уделяется качеству производимого ПО.
Мне всегда было интересно, какого опыта надо набираться, чтобы брать цифры максимальной нагрузки для таких расчетов? То есть, например:
То есть мы можем рассчитывать максимум на обслуживание ~20 тысяч запросов на сервер. Это значительно ниже предела обслуживания запросов в KV store, который составляет порядка 100 тысяч RPS
Вот почему именно 20 тысяч, и разве это не должно зависеть от мощности сервера? С KV store не сталкивался, но откуда цифра для него — из документации или тоже из практики?
Я вел расчеты под среднестатистический сервер, сейчас это порядка 64 вычислительных потоков, ≈2Gb RAM на ядро — похожие конфигурации используются для проведения бенчмарков, вот например бенчмарк от ngnix, в нем используется 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30 GHz, 36 real (or 72 HT) cores
Или вот там дальше — «40 серверов, с учетом мощности СУБД 43 сервера» — то есть добавляем 3 сервера на базу. Почему именно три, и какими конкретно должны быть все эти 43 сервера (CPU, RAM)?
Это минимальная конфигурация для обеспечения консенсуса. В целом рассуждения по этому поводу есть в статье:
Для самой базы потребуется достаточно много дискового места и порядка десяти CPU на обслуживание запросов — здесь доминантным ресурсом будет дисковое пространство, такой инстанс скорее всего займет полноценный сервер. Считаем, что выбранное нами managed-решение для СУБД имеет встроенные механизмы по автоматическому переключению primary-инстанса на основе алгоритмов распределенного консенсуса. Поэтому нам потребуется три таких сервера для отказоустойчивости.
Далее,
Но самое интересное — что происходит, если уже при старте проекта выяснится, что конфигурация все же не выдерживает по той или иной причине (хотя ожидаемое число RPS не превышено) и начинает падать? Это иногда может быть равносильно полному провалу проекта, и уж точно является полным провалом ответственного лица.
все так. Поэтому человек, отвечающий за дизайн системы должен быть достаточно опытным специалистом, чтобы минимизировать вероятность ошибки в оценке необходимых вычислительных ресурсов. Очевидно что невозможно рассчитать требования с точностью до вычислительного ядра. Если мы ошиблись в несколько раз, теоретически дефицит можно компенсировать за счет имеющихся ресурсов других проектов, кроме этого можно вспомнить сценарии выживания системы при превышении уровня штатной нагрузки, которые мы должны были проработать еще на этапе проектирования. Более точные оценки можно будет получить уже на этапе моделирования и прототипирования будущей системы, нагрузочных тестов полученных прототипов.
Просто мне видится какой-то замкнутый круг — для реализации хайлоад-проектов нужен опыт, набраться его, не создавая такие самому, невозможно, а для пет-проекта даже несколько штук серверов выглядит как перебор, не говоря уже о десятках…
Не обязательно получать опыт только на основе собственных ошибок — извлекайте его из докладов на профильных конференциях и тематических ресурсах. Для этого и существует Хабр в том числе )
Конкретные решения ни когда не создаются с нуля. Всегда есть ограничения в виде внутренних традиций, организационной структуры и бюджетов.
Ну, когда-то же они были кем-то созданы ) Я бы хотел чтобы в проектах периодически появлялись люди, способные критически оценить существующую систему, и, если она требует модернизации, могли ее предложить, в том числе аргументируя в терминах бюджетов и затрат на эксплуатацию.
Интересно, в какой мере инженеры Яндекса осведомлены о подходах к разработке в других компаниях?
Не требуется никакого промышленного шпионажа для того, чтобы узнать как устроена инфраструктура разработки в Facebook или система доставки контента в Netflix — большие компании регулярно выпускают различные статьи и доклады на тематических конференциях. Обмен знаниями и опытом выгоден всем участникам рынка.
В первую очередь хочется сказать спасибо за подробный анализ и развернутый комментарий.
Из популярного я бы добавил Cassandra, Scylla, FoundationDB, Tarantool. Последний так вообще, судя по публикациям, создан для таких задач.
Я не ставил перед собой целью составить тут список наиболее популярных key-value-хранилищ, хотя, без сомнения, перечисленные выше решения — отличные кандидаты для него. Просто список получился бы слишком длинным ) В целом, я хотел показать, что название конкретного решения не так важно, как понимание того, на каких принципах оно реализовано и для решения какого класса задач разрабатывается.
каковые являются Non-functional requirements.
Hitachi Solutions высказывает даже такое мнение, что: "The Architect focuses on non-functional requirements".
Хорошее замечание. Функциональные требования (какие задачи решает система) конечно, важны, но основная задача дизайна системы заключается в определении баланса ее качества и ограничений, т.е. нефункциональных требований.
"Четыре девятки" относятся к доступности (availability). Отказоустойчивость (fault tolerance) — это про способность системы свойство технической системы сохранять свою работоспособность после отказа одной или нескольких её составных частей.
Все так, исправлюсь.
Если взять шесть серверов по 10 процессоров в каждом можно попытаться напрямую взять планочку 500.000 RPS на БД типа Scylla или Tarantool. Тут многое еще зависит от того, сколько RAM можно использовать.
Можно взять 12 серверов по 10 процессоров, тогда планочка точно возьмется. При этом вся система существенно упростится.
Согласен, это один из вариантов решения, хотя мне, все-таки, больше нравится мой вариант, так как он лучше утилизирует доступный нам объем RAM, так как дефицитным ресурсом в системе оказался CPU, при сохранении разумных затрат на эксплуатацию. В принципе, в дизайне систем нет единственно правильного решения задачи — их всегда множество. Этой статьей я хочу дать повод людям задуматься и порассуждать над тем, как и почему мы выбираем тот или иной подход в дизайне конкретной системы. Если разработчик способен увидеть различные варианты реализации и обсудить их преимущества и недостатки, это отличный специалист.
Звучит сурово, с учетом того, что серверов в KV store: 9 * 4 ДЦ = 36. Непонятно, как будет высокая согласованность достигаться в таком случае. Читаем из KV — там запись уже есть, но вся операция записи еще не завершилась.
Ооо, а вот это вот вообще отличное замечание. Я даже хотел вынести свои размышления по поводу решения проблемы согласованности записи в 3 десятка реплик в секцию дополнительных вопросов, но у меня и так уже получился огромный текст, решил не переутяжелять.
В целом нас тут спасает то, что идентификаторы ссылок генерируются случайным образом, не подтвержденные записи не могут быть запрошены у системы, соответственно и востребованы из KVS — согласованность не нарушается с точки зрения интерфейса системы.
Как я говорил в презентации, планировщик (диспетчер очереди), решает две основные задачи: максимизация утилизации оборудования и минимизация времени простоя задач в очереди. На синтетических тестах с условно бесконечным свободным местом на дисках он показывает очень высокий уровень утилизации агентов, в production-системе есть дополнительный фактор вытеснения ресурсов из кэша агента и освобождении дискового пространства — настройками агента можно регулировать скорость вытеснения — в таком случае утилизация кластера повышается, но понижается cache hit. Сейчас это статически настроенный параметр по результатам моделирования; есть идея добавить учет фактора голодания пользовательского пула из-за недостатка агентов с достаточным свободным местом для выполнения задач непосредственно в планировщик, но в целом по предварительным оценкам такая оптимизация значительно снижает время ожидания менее 1% задач.
В нашем случае речь идет про установку нового соединения + SSL handshake на каждый запрос — то, что в тесте названо CPS (Connections per Second).
Конечно с таким уровнем детализации, как в докладе, все распределенные системы сборки будут похожи. Нет, мы не используем Bazel, у нас собственная система сборки, отличающаяся, как минимум, двумя аспектами — наши сборочные файлы значительно более лаконичные, и сборочный граф, которым оперирует система сборки, может быть сериализован и использован не только для трассировки зависимостей, но и для многих других целей, таких как определение diff'а (разницы по сборочных артефактам, в том числе и промежуточным) между двумя ревизиями, анализа критического пути, инициации системы CI по изменениями в зависимостях проекта, получение и инъекция статистических данных.
Не совсем верное утверждение – распределенность сложная, дорогой с т.з. потребителя она становится при упрощении системы, в нашем случае, например, при отказе от data affinity.
Конечно пробовали. И для сборок, которые затрагивают значительную часть репозитория, мы получили времена, примерно в 5 раз превышающие время выполнения такой же сборки на умеренно загруженном кластере. Но основная проблема в том, что в каждый момент времени мы выполняем больше 2х сотен сборок одновременно, и все эти сборки имеют значительное пересечение по промежуточным артефактам сборочного графа. Интенсивное использование data affinity (запуск сборочных нод на тех хостах, которые имеют большее количество входных данных для ноды) и распределенного кеша (воркеры могут обмениваться сборочными артефактами) позволяет нам превосходить по скорости локальную сборку. В целом, как я говорил в докладе, эффективное управление сборочным кэшом позволяет нам экономить значительные объемы вычислительных ресурсов.
Парой комментариев выше я уже написал что ошибиться даже в несколько раз не будет проблемой с т.з. дизайна системы и ее последующей эксплуатации, особенно на таком, достаточно высоком уровне абстракции. Т.е. мы же говорим не о скорости доступа к памяти, а производительности достаточно сложного компонента. Но понимать порядок предела производительности подсистем и из чего он складывается, конечно, нужно.
Ну, у нас в компании есть некоторый опыт работы с трафиком, в том числе с обработкой SSL handshake'ов. Это цифры взяты по усредненным показателям производительности наших серверов. А в комментарии выше есть ссылка на бенчмарк от ngnix.
По-большому счету на таком интервью мы не можем оценивать кандидатов бинарно — в ходе беседы мы получаем информацию о том, насколько хорошо человек разбирается в тех областях, что были перечислены в статье, из чего уже можно делать выводы, решение какой сложности задач можно ему доверять.
Пользоваться поисковиком во время интервью не запрещается, но я бы не рекомендовал — в самой статье и в далее в комментариях я пытаюсь показать что не так важно знание конкретного фреймворка/сервиса и точные показатели производительности на определенной модели железа, как понимание порядка предела этой производительности и факторов, из которых эти пределы сказываются.
Одни эти знания действительно не дадут опыта. А вот опыт, полученный без этих знаний будет значительно менее ценным.
На собеседование отводится час, и за это время мы действительно ожидаем услышать от кандидата рассуждения по тем пунктам, которые я указал в статье. Некоторые части прорабатываются максимально детально вплоть до описания полей используемых структур данных. Возможно, некоторые моменты, где интервьюер чувствует уверенные знания кандидата, проговариваются менее подробно, но в целом нужно проработать все.
Мне, как сотруднику отдела технологий разработки, ближе всего история про монорепозиторий — большинство кодовой базы Яндекса хранится в нем. От каждого проекта, заехавшего в монорепозиторий требуется строгое соблюдение правил жизни в нем — думаю, тут более чем достаточно историй о преодолений внутреннего сопротивления.
Или, например, здесь описывается история о том, как мы переезжали из Oracle в PostgreSQL — там нет описания того, насколько жаркие были дискуссии на старте проекта, о его целесообразности в целом, но в качестве основных аргументов за переезд приводился успешный опыт коллег.
Полностью поддерживаю здесь ответ @funca
В целом мне кажется что отношение к тестированию в компании отражает уровень ее зрелости — чем дальше от уровня стартапа, тем больше вниманию уделяется качеству производимого ПО.
То есть мы можем рассчитывать максимум на обслуживание ~20 тысяч запросов на сервер. Это значительно ниже предела обслуживания запросов в KV store, который составляет порядка 100 тысяч RPS
Я вел расчеты под среднестатистический сервер, сейчас это порядка 64 вычислительных потоков, ≈2Gb RAM на ядро — похожие конфигурации используются для проведения бенчмарков, вот например бенчмарк от ngnix, в нем используется
2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30 GHz, 36 real (or 72 HT) coresЭто минимальная конфигурация для обеспечения консенсуса. В целом рассуждения по этому поводу есть в статье:
Далее,
все так. Поэтому человек, отвечающий за дизайн системы должен быть достаточно опытным специалистом, чтобы минимизировать вероятность ошибки в оценке необходимых вычислительных ресурсов. Очевидно что невозможно рассчитать требования с точностью до вычислительного ядра. Если мы ошиблись в несколько раз, теоретически дефицит можно компенсировать за счет имеющихся ресурсов других проектов, кроме этого можно вспомнить сценарии выживания системы при превышении уровня штатной нагрузки, которые мы должны были проработать еще на этапе проектирования. Более точные оценки можно будет получить уже на этапе моделирования и прототипирования будущей системы, нагрузочных тестов полученных прототипов.
Не обязательно получать опыт только на основе собственных ошибок — извлекайте его из докладов на профильных конференциях и тематических ресурсах. Для этого и существует Хабр в том числе )
Ну, когда-то же они были кем-то созданы ) Я бы хотел чтобы в проектах периодически появлялись люди, способные критически оценить существующую систему, и, если она требует модернизации, могли ее предложить, в том числе аргументируя в терминах бюджетов и затрат на эксплуатацию.
Не требуется никакого промышленного шпионажа для того, чтобы узнать как устроена инфраструктура разработки в Facebook или система доставки контента в Netflix — большие компании регулярно выпускают различные статьи и доклады на тематических конференциях. Обмен знаниями и опытом выгоден всем участникам рынка.
В первую очередь хочется сказать спасибо за подробный анализ и развернутый комментарий.
Я не ставил перед собой целью составить тут список наиболее популярных key-value-хранилищ, хотя, без сомнения, перечисленные выше решения — отличные кандидаты для него. Просто список получился бы слишком длинным ) В целом, я хотел показать, что название конкретного решения не так важно, как понимание того, на каких принципах оно реализовано и для решения какого класса задач разрабатывается.
Хорошее замечание. Функциональные требования (какие задачи решает система) конечно, важны, но основная задача дизайна системы заключается в определении баланса ее качества и ограничений, т.е. нефункциональных требований.
Все так, исправлюсь.
Согласен, это один из вариантов решения, хотя мне, все-таки, больше нравится мой вариант, так как он лучше утилизирует доступный нам объем RAM, так как дефицитным ресурсом в системе оказался CPU, при сохранении разумных затрат на эксплуатацию. В принципе, в дизайне систем нет единственно правильного решения задачи — их всегда множество. Этой статьей я хочу дать повод людям задуматься и порассуждать над тем, как и почему мы выбираем тот или иной подход в дизайне конкретной системы. Если разработчик способен увидеть различные варианты реализации и обсудить их преимущества и недостатки, это отличный специалист.
Ооо, а вот это вот вообще отличное замечание. Я даже хотел вынести свои размышления по поводу решения проблемы согласованности записи в 3 десятка реплик в секцию дополнительных вопросов, но у меня и так уже получился огромный текст, решил не переутяжелять.
В целом нас тут спасает то, что идентификаторы ссылок генерируются случайным образом, не подтвержденные записи не могут быть запрошены у системы, соответственно и востребованы из KVS — согласованность не нарушается с точки зрения интерфейса системы.
:) Тут я хотел сказать что в данной подсистеме нет ничего необычного — про устройство систем такого класса уже есть 100500 статей.