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

Интересно, что эта ситуация касается меня лично: у нас недавно появился необычный клиент. Он разрабатывает суперкрутого голосового ассистента: долина, раунды на десятки млн $, огромная кодовая база на млн строк, написанная целиком нейросетями, под предводительством одного основателя.

Наша задача — привести все это в порядок, стабилизировать, обеспечить развитие и масштабирование.

На текущий момент мы в основном пользуемся моделями от антропика, но как я могу быть уверен, что свежая модель не решит, что мы конкуренты?

Гитхаб в последнее время сильно сбоит.

В дополнение к инциденту с merge queue, за последние дни успели сломаться поиск и показ пул-реквестов.

Техдир сервиса Владимир Федоров в своем покаянном посте пишет, что причина — во взрывном росте активности на платформе из-за нейросетей (см картинку).

Обещает, что теперь они будут работать над стабильностью, масштабируемость и перестанут гнаться за фичами.

Внешние наблюдатели подозревают две причины: 1) плохой вайбкодинг в Microsoft 2) сложный переезд с собственной инфраструктуры на Azure.

И вот уже знаменитый Митчел Хашимото пишет длинный эмоциональный пост, что уносит репозиторий своего проекта ghostty с гитхаба.

❧

Создать git репозиторий можно без всяких сервисов — это просто файлы на диске. Гитхаб выигрывает за счет удобного контроля доступа, интеграции с ci/cd инструментами, удобного веб-интерфейса для комментирования и тысячи мелочей.

Есть десятки конкурентов, но ни один не дотягивает до качества github. Раньше это был «лучший инструмент, который можно купить за деньги», а теперь он становится одним из многих, со своими плюсами и минусами. Прямо падение гиганта.

Конечно, у таких сервисов огромная инерция, но очень интересно, куда побегут «модные ребята», которые задают тренды. Будет ли это новый классический конкурент со взрывным ростом или что-то распределенное и децентрализованное, соответствующее базовой философии гита?

Ядро чатжпт работает на одном Postgres-сервере с 50 read-only репликами. Это к вопросу о масштабируемости и потребности в сложной инфраструктуре.

PostgreSQL — одна из фундаментальных программ, на которых держится половина интернета и компьютерных систем в целом. Это бесплатная база данных, которой пользуются все — от маленьких интернет-магазинов до банков и крупнейшие сервисы на планете. Именно она гарантирует, что наши данные не потеряются и будут доступны в любой момент.

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

У postgres открытая, по-настоящему распределенная разработка, в которой участвуют сотни инженеров со всего мира.

Многие ИТ-проекты держатся на власти диктатора (Линукс на Линусе), а Postgres вот уже 30 лет управляется меритократией в консенсусной модели.

Свободная BSD-подобная лицензия, которая (в отличие от религиозной GPL) позволяет открыто делать коммерческие продукты на его основе.

Отличная обратная совместимость и близкое соответствие стандартам, и при этом они умудряются первыми реализовывать фичи, которые только позже появляются в платных БД.

PostgreSQL как программа — это настоящее произведение инженерного искусства, а проект в целом — чудо в плане самоорганизации людей. Горжусь, что у нас как у человечества получилось сделать такую красивую штуку.

Я рад, что Postgres постепенно становится самой популярной базой для начинающих, заменяя MySQL.

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

В контексте падения облаков, чем они лучше/хуже собственного железа?

Можно подумать, что я буду сейчас писать про отказоустойчивость. На самом деле, если ваш проект будет лежать, когда лежит весь GCP или AWS, — то для 99% проектов это абсолютно нормально, такие события происходят раз в несколько лет и длятся не больше пары часов. Мы ведь не кислородными масками управляем, верно?

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

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

Главное преимущество облаков в сравнении с «реальными серверами» — возможность быстро масштабироваться, то есть сегодня у тебя один сервер обрабатывает 1000 пользователей, завтра проект завирусился на миллионы, и ты за пару минут запускаешь десятки, сотни серверов.

Минусы? За это удобство и возможность мгновенного масштабирования нужно платить, порой в десятки и сотни раз больше, чем за просто арендованные и уж тем более купленные серверы.

Но есть нюанс: хорошо написанное веб-приложение на одном современном сервере может выдержать нагрузку в сотни тысяч пользователей. Реальных проектов, которым нужно прямо «облачное» масштабирование, — не так много.

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

Тут у облаков есть небольшое преимущество — они предлагают дополнительные, более сложные услуги, чем просто аренда серверов. Например, — настроенная база данных, сервис хранения файлов, предсказательная система как сервис. Можно не отвлекаться на базовые блоки, которые повторяются от проекта к проекту.

Нюанс: многие вещи для удобства программистов, которые облака сделали первыми, теперь можно не дорого воспроизвести самостоятельно, используя опен-сорс решения.

В общем, как обычно, начать стоит с того решения, с которым привык работать технарь, которому вы доверились. Ему ведь пользоваться этими инструментами.

А если вдруг ваши счета за облака станут заметными, — то во-первых, поздравляю, это значит у вас есть пользователи! Во-вторых, переехать на свое железо в эти дни проще, чем когда-либо.

Пример: классно наблюдать, как последние 3 года создатель важного фреймворка Ruby on Rails и культовой системы управления проектами Basecamp Дэвид Хейнемейер Ханссон (DHH) планомерно перевозит свои продукты с миллионами пользователей из облаков на собственные серверы.

Они объявили о планах выхода из Амазоновского облака AWS ещё в октябре 2022. На тот момент, они платили за Амазону 1,5 млн долларов в год! Для начала, они купили себе физических серверов на полмиллиона долларов (всего треть годового чека за облака!)

В июне 2023 объявили об успешном перевозе всех вычислений, а недавно купили специализированное железо для хранения данных и мае наконец перевезли хранилище файлов из AWS S3.

Другой яркий пример, с которым я сталкивался лично, — это стоимость трафика для медиа-проектов. Трафик в облаках для популярного медиа может стоить десятки тысяч долларов, и такой же объем можно обработать десятком арендованных серверов по 40 баксов каждый. Экономия в 100 раз. Но это всё имеет смысл только на масштабе. Так выпьем же за то, чтобы было на чем экономить!

Вышла классная заметка DHH о том, что лучше писать нормальные монолиты, чем пытаться делать модные микросервисы. Дэвид — создатель Basecamp и Ruby on Rails.

Поводом для заметки послужила новая статья команды Amazon Prime Video, где они рассказывают, как отказались от микросервисов, решили проблемы с масштабированием и сократили издержки на 90% (не опечатка).

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

—

Вот Дэвид издевается над Амазоном и микросервисами, а я в традиции постмодернизма поиздеваюсь над ним. Хорошо быть здоровым и богатым — в смысле, что опираясь на многолетний опыт и руководствуясь здравым смыслом, делать минимальное необходимое программирование, не переусложнять систему. Спасибо за совет!

По сути я с ним согласен — в 90% случаев микросервисы не нужны. Но если вы об них ещё не обжигались — то не слушайте старых пердунов вроде нас, делайте свои ошибки, учитесь, по-другому учиться очень сложно.

Тем более, что это интересная задача для нас с Федей — разбирать архитектурные завалы. Если вдруг обнаружили себя в ситуации, что разработка начала тормозить или хотите избежать этого со старта — обращайтесь :)

Почта России у меня ассоциируется с очередями в отделениях и потерянными посылками. В новом эпизоде подкаста разбираемся, насколько это близко к реальности с техническим директором Почтатеха Николаем Кнышем.

А ещё внутри Коля рассказывает, как они обрабатывают полтора миллиона посылок в день и при этом раскатывают софт на 300 тысяч сотрудников в 12 часовых поясах. 🤯

Слушайте и подписывайтесь: Apple, Google, Яндекс, Spotify, Castbox, Overcast, веб-версия.

Давно не писал, две недели решительно не хотел ничего делать. Хочется свалить всё на пневмонию (не коронавирусную), на самом деле просто устал. Продолбал несколько лидов-клиентов. Раньше бы стыдился, но это тема для отдельного поста.

Между тем, происходит куча всего интересного. В мире пандемия (вот классная визуализация и хорошее видео про неё), а у нас в iGooods рекорд за рекордом. Если раньше в пике было по 70 запросов в секунду, то теперь — больше 400. Каждое выступление Путина — +20% посещаемости.

Чтобы выдерживать такие нагрузки, нужно оптимизировать код и увеличивать объем железа. Серверы масштабируются горизонтально и вертикально. Горизонтально — это когда ставишь рядом со старым сервером ещё один, такой же новый, и они делят нагрузку. Это идеальная схема, так мы сейчас регулярно добавляем серверы приложений. К сожалению, базу данных мы горизонтально масштабировать не умеем — для того, чтобы поставить в параллель два сервера БД, нужна специальная магия, запрогать которую мы не успели.

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

Спокойной ночи! 🌛

Вовремя мы взяли iGooods в клиенты. У чуваков столько новых пользователей, что серверы не выдерживают и внешние сервисы бьют лимиты.

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

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

Интереснее сейчас, наверное, только у эпидемиологов, в медиа и в школах, которые пытаются перейти на удаленку. 🚀

Некоторые программисты недавно начали говорить, что у Apple «проблемы с софтом». Мол, во времена Джобса такого не было и вообще, раньше софт был надежнее.

Вот ответ от Стивена Сифонски. Это один из ключевых чуваков в MS: пришел в 1989, уволился в 2012 в должности руководителя разработки Windows https://medium.learningbyshipping.com/apples-software-problem-and-fixing-it-via-twitter-c941a905ba20

Вкратце: последние 15 лет Apple поставляет софт и железо со скоростью и качеством, не виданными в индустрии. При их объемах баг, затрагивающий 0.01% пользователей – это целый стадион недовольных. Кажется, что у Apple есть проблемы роста и это нормальный этап, который решается реорганизацией процессов; ничего драматичного.

Изменение архитектуры проекта при масштабировании. Обратите внимание на отличающуюся конфигурацию палок и брёвен.