Comments 11
Железо дёшево, человеческое время нет.
Почему-то в этой формуле забывают про время потраченное пользователями (на то, что приложение звпускается на несколько секунд дольше и аыполняет операции медленнее). Соотношение пользователей к разработчикам обычно не в пользу последних.
На больших системах - нет. В условиях когда есть условные 1000 серверов экономия даже 1% - огромный выигрыш, который не только отобьет работу инженера но и очень быстро принесет прямую прибыль.
Я говорил про конкретную систему в статье - пшш, но приятно. А то что вы говорите очень редко и статьи нет
Про конкретную систему в статье: 200gb памяти в ценах условного амазона это 450-500$ в месяц если пересчитать на r6.large инстансы(при условии что CPU не будет боттленеом). И это при условии резервации на 3 года. Если on demand то можно на два умножать. Если спотовые то наоборот делить на два.
Итого за год это будет примерно зп одного инженера за месяц. Если было потрачено усилий в пределах одного человеко*месяца то это окупится за год. Если сервера были on demand то за полгода. Если все сервера были спотовые то за два года.
А что там дешево а что нет это вот и есть пшш.
AWS тарифицирует не по себестоимости, а по "ценности для клиента". Больше памяти = можешь решать более дорогие задачи хочешь выглядеть крутым = плати больше. И дело не в overcommit (ЦП можно, ОЗУ сложнее)
Кстати, это одна из причин популярности микросервисов - разбить один непропорционально дорогой и "крутой" вертикально масштабированный сервер на несколько дешевых маленьких
Классический трюк облачной экономики. Но вне облаков это не работает
Вместо одного r6i.8xlarge (256 GB) за 3к можно взять 4 r6i.8xlarge (256 GB) за 2к суммарно. AWS специально делает нелинейную цену при вертикальном масштабировании.
Отсюда и архитектурные паттерны:
Шардирование по данным вместо одной большой in-memory БД
Stateless сервисы + внешний кэш (Redis/Memcached)
Horizontal pod autoscaling в K8s вместо вертикального
Вместо одного r6i.8xlarge (256 GB) за 3к можно взять 4 r6i.8xlarge (256 GB) за 2к суммарно.
Можно, хотя тут в этом предложении явно есть ошибка потому что r6i.8xlarge тут с обоих сторон, но 15 r6i.large указанных в моем комментарии будут еще дешевле.
И дело не в overcommit (ЦП можно, ОЗУ сложнее)
Дело в том что реальные сервера стоящие в Амазоне имеют свои физические ограничения. Хз что там сейчас но возьмем за пример 192 ядра(384vcpu пусть будет вместе с оверкоммитом) в одной коробке. Вот эти вцпу можно кроить как нравится, но не нужно забывать что если мы от них откроили 320 vcpu то больше 64 нам уже никак не продать с этого компа. По сути это как заготовка дубового щита, основная деталь и обрезки. Обрезки дешевле а деталь дороже. Поэтому 320 vcpu в одном инстансе будут дороже в пересчете на прайс за 1vcpu чем остальные 64.
Ну инстансы по 4/8/16 vCPU это ходовой товар на рынке spot instances а на 320 vCPU спроса не будет.
Спасибо за статью, было интересно перечитать о механике Swiss Table из других "уст".
У вас задублировалось рассмотрение факта "Если h1 mod 2 == 0 " в разделе "Вставка элемента в Swiss Table"
Как Go 1.24 и Swiss Tables вернули нам 200 гигабайт памяти