ScyllaDB спонсировала этот пост.
«Нет более увлекательной игры, чем масштабная технологическая игра. Но если вы в нее сыграете, некоторые люди возненавидят вас за это. Это нормально… это игра, в которую вы решили играть». — Адам Джейкоб
На саммите Monster Scale 2025 Рэйчел Стивенс, директор по исследованиям RedMonk, поговорила с Адамом Джейкобом, соучредителем Chef и генеральным директором System Initiative, о том, что на самом деле означает создание и эксплуатация программного обеспечения в больших масштабах.
Monster SCALE Summit 2026 пройдет 11–12 марта, в нем примут участие Antirez, создатель Redis; Камиль Фурнье, автор книг «Путь менеджера» и «Инжиниринг платформ»; Мартин Клеппманн, автор книги «Проектирование приложений с интенсивным использованием данных» и более 50 других. Мероприятие бесплатное и виртуальное. Зарегистрируйтесь и присоединяйтесь к сообществу для оживленного общения.
Экзистенциальный вопрос масштаба
Стивенс начал с экзистенциального вопроса: «Существует ли ваше программное обеспечение, если ваши пользователи не могут его запустить?» Да, ваш код все еще существует в GitHub, даже если us-east-1 выйдет из строя. Но что, если:
- Ваша система ползает под нагрузкой.
- Критические интеграции постоянно ломаются.
- Вы не можете позволить себе расходы на инфраструктуру.
«Масштабное программное обеспечение — это не только пропускная способность», — сказал Стивенс. «Речь идет о том, чтобы ваш код сохранялся, адаптировался и оставался доступным независимо от нагрузки и местоположения, где вы работаете. Потому что, если ваши пользователи не смогут его использовать, ваше программное обеспечение может просто не существовать».
В этом контексте Стивенс привлек человека, который всю свою карьеру имел дело с масштабированием непосредственно: Адама Джейкоба.
Масштабируйтесь только тогда, когда больно
Стивенс спросил Джейкоба, как команды могут сбалансировать качество, скорость и масштаб в условиях неопределенности. Как избежать срезания углов и преждевременной оптимизации?
Джейкоб утверждает, что на ранних этапах можно не сильно беспокоиться о масштабе. Большинство продуктов терпят неудачу по другим причинам еще до того, как масштабируемость становится проблемой.
Он объяснил: «Я думаю об этом через призму необязательности. Когда вы начинаете создавать что-то новое, приятно не слишком беспокоиться о масштабе, потому что вы можете никогда его не достичь. Большинство продуктов не терпят неудачу, потому что они не поддаются масштабированию. Подумайте о том, как сильно Twitter не смог масштабироваться… и все же мы здесь».
Первым приоритетом является создание надежного продукта. Как только масштаб станет реальной проблемой, тогда имеет смысл провести рефакторинг и устранить узкие места. Но если вы немного побывали в этом квартале, ваш опыт поможет вам сделать ранний выбор, который окупится позже.
Джейкоб отметил: «Преждевременная оптимизация реальна. Но по мере того, как вы приобретаете опыт, некоторые решения вы принимаете заранее, потому что знаете, что, если все получится, вы будете счастливее позже — например, факторизация вашего кода, чтобы его можно было со временем разбить на части по границам сети, если вам это нужно».
Страшные истории масштабируемости Chef
Затем Стивенс спросил Джейкоба, поделится ли он ужасной историей о масштабировании из тех времен, когда он работал шеф-поваром. Джейкоб согласился и подарил два памятных подарка.
«Лучшее было, когда мы запустили первую версию Hosted Chef. За день до запуска мы обнаружили, что создание нового пользователя занимает около полутора минут. Когда мы запускали его на ноутбуке, это не занимало столько времени, но это заняло позже… и мы никогда его не тестировали. Поэтому в последние часы перед запуском мы изменили его с системы «любой может зарегистрироваться» на систему очередей с маленьким космическим роботом, говорящим: «Спрос настолько высок, мы свяжемся с вами». Мы просто скрыли проблему масштабируемости».
«Другой пример: тот же самый сервер Chef (тот, который не мог быстро создавать учетные записи) в конечном итоге должен был работать в Facebook. Первоначальная версия была написана на Rails, с которым было приятно работать, но недостаточно параллельно. В масштабе Facebook на один сервер Chef может быть направлено 40 000 или 50 000 объектов. Поэтому мы перестроили его в Erlang, что отлично подходит для такого рода проблем. Я буквально перенес версию Erlang в Facebook на USB-накопителе. Когда мы его установили, и запустили центр обработки данных, мы подумали, что он сломан, потому что он использовал меньше вычислительных ресурсов, и завершился почти мгновенно».
Джейкоб объяснил, что если бы они с самого начала попытались создать сервер Chef на Erlang, проект, вероятно, не получил бы успеха. Начало работы с Rails позволило вывести Chef в мир и узнать, что на самом деле должна делать система. Только позже, когда они поняли, как на самом деле ведет себя система, они смогли перестроить ее с правильной архитектурой и временем выполнения для масштабирования.
Рост или эффективность: знайте, в какую игру вы играете
В конечном итоге в Chef масштабирование потребовалось для привлечения таких клиентов, как Facebook и JPMorgan Chase, которые работают в огромных масштабах.
Джейкоб посоветовал: «Для масштабирования потребовались крупные инвестиции, но это сработало. Вы не можете купить свое ядро. Если это важно для клиентов, вам придется создавать его самостоятельно. Люди часто ждут слишком долго, чтобы осознать, что у них есть глубокая архитектурная проблема, которая также является проблемой бизнеса. Перестройка масштаба занимает месяцы, поэтому вам придется начинать раньше».
Ваш собственный подход к масштабированию должен в конечном итоге зависеть от того, в какую игру вы играете:
- В игре венчурного капитала рост и развитие стоят на первом месте. Вы можете тратить деньги на более быстрое масштабирование, потому что у вас есть финансирование.
- В борьбе за прибыльность эффективность стоит на первом месте. Перерасход средств на вычисления или плохая архитектура сильно сказывается на прибыли.
Почему масштабирование — самая веселая игра
Стивенс отметил, что «когда программное обеспечение добивается успеха, оно перестает быть вашим — оно становится общим». Затем она спросила Джейкоба, каково это, когда ваша технология масштабируется до такой степени, что у людей возникает очень твердое мнение о ней. Его ответ:
«Трудно создавать вещи, которые будут интересны людям. Если вам посчастливилось создать что-то, что вам нравится, и поделиться этим с миром, и люди полюбят это в ответ, это невероятно полезно. Даже если они этого не делают, это все равно подарок.
«Однажды кто-то постучал по мне в кафе и сказал: «Ты написал «Шеф»? Я ненавижу «Шефа». Я сказал: «Мне очень жаль; Я написал это не для того, чтобы обидеть тебя. Но в масштабе это означает, что он использовал это. Это имело значение в его жизни. И это то, чего вы хотите: чтобы люди испытали на себе то, что вы создали.
«Мне нравятся технологии, проблемы, трудности. Масштабирование добавляет больше уровней сложности, больше уровней удовольствия. Нет игры веселее, чем масштабная технологическая игра. Но если вы в нее играете, некоторые люди будут вас за это ненавидеть. Это нормально… это игра, в которую вы решили играть».
Полную версию выступления вы можете увидеть ниже.
ScyllaDB спроектирована для обеспечения предсказуемой производительности в любом масштабе. Его используют организации, которым требуется сверхнизкая задержка, даже при рабочих нагрузках, превышающих 1 млн операций в секунду. Наша уникальная архитектура использует возможности современной инфраструктуры, что приводит к меньшему количеству узлов, меньшему администрированию и меньшим затратам. Узнайте больше Последние новости от ScyllaDB ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одного эпизода. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Синтия Данлоп пишет о разработке и тестировании программного обеспечения гораздо дольше, чем ей хотелось бы признать. В настоящее время она является старшим директором по контент-стратегии в ScyllaDB. Узнайте больше от Синтии Данлоп
