Комментарии
58
Да, впечатляет. Может быть, они теперь хотят сделать задел на будущее с большим запасом?
А разве не масштабирование одна из киллер-фич облаков. Ну про то что платишь ровно за ту мощность которую используешь в данный момент.
Железо стоит дёшево, а программисты дорого (с), а также удобное и и не бьющее по капексу масштабирование в облаке, особенно когда тебя финансируют миллиардеры, умудрилось вылиться в то, что для обработки 70ТБ данных нужно 116ТБ памяти.
Железо стоит дёшево, а программисты дорого (с), а также удобное и и не бьющее по капексу масштабирование в облаке, особенно когда тебя финансируют миллиардеры, умудрилось вылиться в то, что для обработки 70ТБ данных нужно 116ТБ памяти.
Если архитектура неэффективна то стоимость железа для её реализации может легко превысить стоимость программистов, а стоимость облачного "железа" и так довольно высока.
Зато железо можно нарастить сразу и практически мгновенно. А вот вбухивать в программистов надо какое-то время что бы увидеть результат. Да и тут могут быть «сюрпризы».
Такой вот менеджмент.
Такой вот менеджмент.
Я правильно понимаю, что Parler не только не умеют в приватность, но и в инфраструктуру, зато хорошо умеют в маркетинг, раз на это им выделяется столько денег?
Мне кажется, что они даже не в курсе про такую штуку, как индексы в базе данных…
P/S Пару раз с таким сталкивался)
P/S Пару раз с таким сталкивался)
Мне только AliCloud на ум приходит по таким мощностям.
Два предположения:
- Они публикуют требования, которые ни один из мелких провайдеров(крупные отказались) не может выполнить, чтоб потом иметь возможность сказать инвесторам / пользователям: "это не мы не смогли набрать юзербазу, а нас деплатформнули. Дайте больше денег, что-нибудь придумаем."
- Менеджеры/разработчики почесали голову и решили, что управлять проектом, который помещается на 2 сервера(как stackoverflow, например) — недостаточно круто. Частая проблема, на самом деле.
Менеджеры/разработчики почесали голову и решили, что управлять проектом, который помещается на 2 сервера(как stackoverflow, например)
Однако ж, 10, нет, 11 лет назад у stackoverflow была такая конфигурация:
А здесь — текущая: stackexchange.com/performance
23 сервера в сумме, уже выглядит реалистично.
Однако ж, 10, нет, 11 лет назад у stackoverflow была такая конфигурация:
Это их полная инфраструктура, я имел ввиду их реальные потребности в железе. Например, в 2016-м у них было 11 веб-серверов, но реально необходим всего один. Они писали про прогон прода на двух серверах(как тест минимальной конфигурации на случай проблем), но сейчас не могу найти.
Жесть кто таким вообще пользуется когда есть вк?
Конечно блин в сети раскритиковали. В сети в принципе все вечно критикуют
Ага. Наконец-то я нашел проект про который нельзя сказать «Главное сделать как-нибудь, а оптимизировать будем потом. Ты что, не слышал про „преждевременную оптимизацию“?
Интересно, Парлер «создадут» с нуля или он вернётся с того, что было? Я так понимаю сотни терабайт данных уже утеряны.
Маловероятно, что всё утеряно у них. Откуда такая информация?
У них ведь перед выселением с AWS случился data breach unintended offsite backup, так что им не стоит волноваться о сохранности их данных.
Я правильно понимаю что в Parler помимо обмена сообщениями и постинга картинок был ещё и стриминг видео от пользователей и судя по всему именно для его работы и нужна была большая часть ресурсов?
для стриминга без транскодинга особо ресурсов не надо, можно сотню Mbps c ядра получать
Я так понимаю, официального комментария от самой компании нет, только вот это фото экрана, где невозможно сказать, не является ли это просто фото документа, которое опубликовавший набрал самостоятельно в редакторе?
Тогда можно хоть заобсуждаться, а я могу сделать такое же фото и там указать, что Parler нужно 500 машин с тремя эксибайтами RAM каждая.
Какие именно метаданные позволяют говорить, что этому заявлению в твиттере стоит верить?
Кстати а может кто прикинуть сколько они в aws за такую конфигурацию платили?
116 тб озу под пг? это шутка такая чтоле? Смотрю на всю эту хрень и думаю как же я жил в 2004 с миллионом пользователей на жалких 8 гб озу а…
Del
Надо не забывать, что в 2004 году были и пользователи меньше с более простыми запросами и требованиями.
пользователи меньше
Ну да, сейчас еда более доступна, средний рост пользователя стал больше…
давайте навскидку:
— всевозмжные теги (вон у SO целых 3 сервера под это)
— соц сети (куда надо пушить какую-то инфу)
— нотификации (нужно регулярно что-то проверять и отправлять пользователю нотификацию, а когда откроет — показывать по ней нужную инфу)
— опять же, теперь и «авторизация уже не та, что по http», недостаточно проверить пароль в plain text
— всевозмжные теги (вон у SO целых 3 сервера под это)
— соц сети (куда надо пушить какую-то инфу)
— нотификации (нужно регулярно что-то проверять и отправлять пользователю нотификацию, а когда откроет — показывать по ней нужную инфу)
— опять же, теперь и «авторизация уже не та, что по http», недостаточно проверить пароль в plain text
нуда, на 6 порядков, ага… Может коллеги наши стали меньше думать?
Там выше вон про утечку данных и что у них данных то 70 тб, то есть 1.5 раза можно в оперативку сложить.
Там выше вон про утечку данных и что у них данных то 70 тб, то есть 1.5 раза можно в оперативку сложить.
— прикинули, что если их взломают и начнут выкачивать контент — то сервера могут прилечь
— решили обезопасить себя и положили всё в оперативку
…
— PROFIT!
— решили обезопасить себя и положили всё в оперативку
…
— PROFIT!
клауд приучает новое поколение г*внокодеров (особенно в США, где за расходы платят деньгами венчурных капиталистов) не думать об оптимизации, а просто шлеп-шлеп и в продакшен да побыстрее.
какая там архитектура, безопасность, эффективность всем пофигу
их некомпетентность не сильно видна, если у сайта посещаемость дохлая, а как только нагрузка вырастает так сразу все и летит к чертям
какая там архитектура, безопасность, эффективность всем пофигу
их некомпетентность не сильно видна, если у сайта посещаемость дохлая, а как только нагрузка вырастает так сразу все и летит к чертям
это не клауд приучает, а реалии жизни: запусти стартап как можно быстрее, если взлетит — потом будешь переписывать/оптимизировать, а если нет — начнешь другой.
никому сегодня не нужен проект, который разрабатывался 3 года, для которого идеальное окно для запуска было 2 года назад.
никому сегодня не нужен проект, который разрабатывался 3 года, для которого идеальное окно для запуска было 2 года назад.
AWS с такими характеристиками стоит пару миллионов в месяц при этом не давая никакой надежности и защиты. Сломаться может что угодно в том числе авс и масштабные сервисы все равно по умолчанию должны строиться с учетом того что пару серверов может просто сгореть. Поэтому нет никакой разницы это дешевый сервер за 30 евро или супер пупер делл за 10к евро в месяц.
Для сравнения дедик от хетзнера
AMD EPYC 7502P 32 Cores 512GB 4x 4TB NVMe
Один 450 евро в месяц + безлим трафик и защита от атак
200 штук 90к евро и 12800 гарантированных мощных ядер, 102TB DDR4, 1600TB NVMe (raid 10).
Не говоря про selectel, ovh, аукцион хетзнера.
AWS похоже дают больше откаты или я не знаю зачем там вообще что либо покупать эти оверселнутые виртуалочки по х40 цене.
Ещё я думаю aws просто перекладывает затраты на содержание всего амазона на aws.
Для сравнения дедик от хетзнера
AMD EPYC 7502P 32 Cores 512GB 4x 4TB NVMe
Один 450 евро в месяц + безлим трафик и защита от атак
200 штук 90к евро и 12800 гарантированных мощных ядер, 102TB DDR4, 1600TB NVMe (raid 10).
Не говоря про selectel, ovh, аукцион хетзнера.
AWS похоже дают больше откаты или я не знаю зачем там вообще что либо покупать эти оверселнутые виртуалочки по х40 цене.
Ещё я думаю aws просто перекладывает затраты на содержание всего амазона на aws.
Сравнивать Hetzner и AWS некорректно. В Хетцнере вы получаете голое железо и сами должны делать все с нуля, включая систему автопровиженинга, автоскейлинга, балансировку, мониторинг, сами должны заботиться о своевременной замене дисков. Помимо этого в Хетцнере конфигурации серверов достаточно ограниченны, например можно ли там на ходу добавить диск к серверу? Или быстро пересоздать сервер в другой сети? Не говоря о доброй сотне дополнительных сервисов, которые предоставляют AWS.
Я вовсе не оправдываю AWS, цены у них действительно конские, но согласитесь, что удобно не сидеть и самому все это настраивать, а просто заказать нужные сервисы в нужном количестве и продолжать разработку. В случае Hetzner вы сами все настраиваете и платите своим временем и страданиями, в AWS вы просто платите большими деньгами.
Я вовсе не оправдываю AWS, цены у них действительно конские, но согласитесь, что удобно не сидеть и самому все это настраивать, а просто заказать нужные сервисы в нужном количестве и продолжать разработку. В случае Hetzner вы сами все настраиваете и платите своим временем и страданиями, в AWS вы просто платите большими деньгами.
всё верно, либо нанимаешь своих devops и платишь им, либо покупаешь у амазону и платишь devops амазона, за то что всё работает.
Балансировку завезли уже
Сравнивать впски и полноценный дедик некорректно. Это совсем разное качество. Мониторить нужно все, в том числе и впс. Просто на дедике добавляется мониторинг смарт и температур. Замена дисков это максимум час времени и это делают инженеры ДЦ по запросу. Добавлять на ходу диск можно но не нужно. Экономя пару сотен тыс. евро можно нанять одного человека который будет следить за статусами и если что пинать ДЦ. Платить за красивую кнопочку для этого не нужно.
Тем подозрительнее желание Амазона и других провайдеров отказаться от клиента который несет 2млн$ ежемесячно, тем более что если хостить ресурсы через субподрядчика-прокладку (на амазоне/диджитал океане и тд), а фронты вынести в Румынию или Китай — то никто и не узнает где хостится Парлер.
Вообще если Парлер внезапно заработает сразу после инаугурации можно будет запросто скатиться в конспирологию, привет ZOG.
Вообще если Парлер внезапно заработает сразу после инаугурации можно будет запросто скатиться в конспирологию, привет ZOG.
Если у вас два раза в месяц есть пики трафика, десятикратные и двадцатикратные от нормы, то как поможет хетзнер? Там гранулярность оплаты — помесячно и Once-off Setup ценой в месячную аренду. Уже не так все радужно?
Для пиков трафика сетевики давно придумали бёрст-тарификацию.
Тут вот товарищ расписал как это работает.
Если там действительно вопрос стоял в паре лямов в месяц — уверяю, о тарифе бы договорились, там и 100х пики от 2Гбит можно было в подарок к аренде серверов дать.
Тут вот товарищ расписал как это работает.
Если там действительно вопрос стоял в паре лямов в месяц — уверяю, о тарифе бы договорились, там и 100х пики от 2Гбит можно было в подарок к аренде серверов дать.
а причем тут канал? Если у вас спайк в 10х запросов то и серверов нужно в 10 раз больше что бы их обслужить.
Упс. Видимо это сетевая профдеформация =(
Ваша правда
Ваша правда
- Сервера же не на 100% загружены по умолчанию в on-premise конфигурации. 10К ядер для БД, 2.5К для приложения и 2.5-6.5 для прочего — огромный оверкилл. Когда я работал в одном тематическом поисковике(кстати, примерно те же 2M MAU), у нас весь бэкенд поиска c 1.5k RPS хостился на ~150 ядрах суммарно и 500gb ram, раскиданных по трём десяткам мелких машин при 50% загрузки в пиковые часы.
- Parler — соцсеть, а не банк. Они могут позволить себе деградацию производительности / отсекать часть запросов в крайнем случае / отключать самые тяжёлые фичи.
- Так не важно на сколько они загружены, суть в том что нагрузка вырастет, в лучшем случае линейно. Если у вас 100 серверов с 5% утилизацией, значит вы уже переплачиваете за сервера. Абсолютные цифры вообще не важны.
- Речь то не о Parler а о разнице cloud vs dedicated. Решать проблему регулярных спайков через отключение функциональности мягко говоря странно, даже для социалочки.
У хетцнера проблемы со стабильностью несколько больше чем у амазона.
Но… Вы по деньгам уложитесь в 10—кратные спайки в сравнении с амазоном.
Да, да — переплачивать в 10 раз всегда — на хетцнере дешевле, чем платить за нормальную нагрузку на амазоне. Во всяком случае именно так было по рекомендованным поддержкой амазона конфигурациям, когда их попросили "вот такое, но в облаке".
А спайки. Ну, спайки вам в амазоне посчитают отдельно сверху плюсом.
Да, да — переплачивать в 10 раз всегда — на хетцнере дешевле, чем платить за нормальную нагрузку на амазоне. Во всяком случае именно так было по рекомендованным поддержкой амазона конфигурациям, когда их попросили «вот такое, но в облаке».
Эм, ну давайте с вами посчитаем. Возьмем указанный выше конфиг AMD EPYC 7502P 32 Cores 512GB 4x 4TB NVMe и рассчитаем сколько это выйдет за год.
Hetzner
www.hetzner.com/dedicated-rootserver/ax161/configurator
В евро 551.25 x 12 + 148.75 = 6736.75. Доверимся гуглу — 8,186.09 долларов.
AWS
calculator.aws/#/addService выбираем EC2.
Наиболее близким аналогом будет i3.metal 64vCPU 512mb 8 x 1900 NVMe. No upfront payment. 12 x 3,663 = 43 956$.
43 956 / 8,186 = 5.3
Итого: Вы можете купить в hetzner в 5.3 раза больше железа, если разбежка между стандартной нагрузкой сервером и пиком меньше х6 то вам выгоднее использовать hetzner если же выше то выгоднее использовать инстансы которые вы в любой момент можете слить. Как видно x10 тут и не пахнет.
А спайки. Ну, спайки вам в амазоне посчитают отдельно сверху плюсом.
Не понял о чем вы говорите. Я имел в виду что если вам несколько раз в месяц нужно x10 серверной мощности то в случае дедикейтед у вас только один вариант — иметь мощности способные обслужить эти спайки. Если же у вас облако то вы упрощенно говоря вы просто создаете кластер с min, max количеством серверов и типом этих серверов. Как только нагрузка упадет ваш кластер просто вернет машины обратно амазону и вы будете дальше платить за x1. Да, этот x1 вам обойдется в 5 раз дороже но не в 10 как если бы вы просто выкупили x10 мощности у хетцнера.
Я уже не говорю что если урезать осетра и иметь в виду сервера попроще (8-16 ядер и 32-64 гб) то вы можете сэкономить до 70% используя спотовые инстансы если вы умеете их готовить.
TLDR: нельзя просто взять и оценить сумму всех затрат на вашу инфраструктуру сопоставив ценник из хетцнера и из aws.
Как видно x10 тут и не пахнет.
Hint: если поставить страну, например, Украину, то получите цены на 19% ниже и ваши 8186$ превратятся в 6600$
К тому же ваш расчет это если брать голые инстансы.
Но по факту в Amazon вам предложат (и надо заметить справедливо и правильно предложат) использовать соответствующие технологии в облаке — всякие там ELB, RDS и иже с ними.
На это навесятся соответствующие прайсы за iops, трафик, еще что-то.
Не понял о чем вы говорите.
Говорю о том, что на резервирование для спайков в авс мы заплатим дополнительно. А тут у нас мы его заложили исходно.
Хуже всего то, что масштабирование там только на бумаге моментальное, если мне не наврали девопсы, то dns propagation работает к сожалению не мгновенно и бывали случаи, когда новый инстанс включался работу аж через пару часов (что уже сопоставимо со скоростью развертывания hetzner или ovh).
reserved и spot instances спасут только некоторых отцов русской демократии.
Первые, если я правильно понял, уже учтены в вашей калькуляции. А spot требуют отдельного обвеса для контроля и стабильности работы уже вашего сервиса плюс их или нужно будет брать в избыточном количестве в виду возможного отключения, или же брать их с гарантированной длительностью (2е емнип дороже, насколько именно — не помню). Это все время и человеческий труд, который зачастую стоит дороже железа.
Hint: если поставить страну, например, Украину, то получите цены на 19% ниже и ваши 8186$ превратятся в 6600$
Любопытненько. Возможно иногда будет выгодно открыть юрлицо на Украине специально для таких оплат.
К тому же ваш расчет это если брать голые инстансы.
Но по факту в Amazon вам предложат (и надо заметить справедливо и правильно предложат) использовать соответствующие технологии в облаке — всякие там ELB, RDS и иже с ними.
Да, именно что предложат а не заставят. Вы же можете задеплоить haproxy на один из инстансов? С другой стороны ведь это тоже время и человеческий труд. Для dedicated у вас роскоши выбора нету.
На это навесятся соответствующие прайсы за iops, трафик, еще что-то.
Иопсы учитываются если вы используете блочные девайсы(виртуальные ssd) и то наверное не всегда. Тут же согласно условиям задачи чистый металл, nvme. В любом случае не уверен что это составит ощутимую часть платежа.
Говорю о том, что на резервирование для спайков в авс мы заплатим дополнительно. А тут у нас мы его заложили исходно.
Ну вы же заплатите когда оно понадобится, если не понадобится то не заплатите. А с дедикейтед придется заплатить сразу.
Хуже всего то, что масштабирование там только на бумаге моментальное, если мне не наврали девопсы, то dns propagation работает к сожалению не мгновенно и бывали случаи, когда новый инстанс включался работу аж через пару часов (что уже сопоставимо со скоростью развертывания hetzner или ovh).
Может инстансов не оказаться в наличии в нужном регионе. Но из моего опыта масштабирование 1-300+ c5 занимало в районе получаса. Хочется мгновенного масштабирования и ноль работы девопса — сейчас есть серверлесс концепция. Все уже будет включено в стоимость.
Первые, если я правильно понял, уже учтены в вашей калькуляции.
Нет не учтены, я сравнивал без оплаты вперед, иначе какой смысл от облачного масштабирования.
А spot требуют отдельного обвеса для контроля и стабильности работы уже вашего сервиса
Это верно, опция не для всех но тем не менее она есть. Либо экономить на железе либо на персонале.
Почитал требования, подумал, индусы что ли строили? Полез искать сотрудников, американцы, кто то испаноговорящий, китайцы, даже русские есть. Спрашивается почему не смогли сделать более качественно, и менее потребительски к ресурсам?
А зачем? Это ж преждевременная оптимизация, корень всех зол. А потом хоп, и оптимизация уже не преждевременная, но поздно.
Уже неделю никто в мире официально не может предоставить Parler необходимые мощности
Да ладно? Прям у все все занято? И у китайцев (Alibaba Cloud, в Китае вообще 75% всех cloud-мощностей в мире) тоже?
а давно вы проверяли пинг до китайского клауда? сколько выйдет выполнить 5 запросов в базу на 1 страницу?
Запросы внутри облака будут (т.е. грубо говоря в пределах одного ДЦ), а пинг до фронта ну будет на сотню мс больше от силы.
Т.е. странички будут загружаться на 0.1 сек медленнее и все.
Т.е. странички будут загружаться на 0.1 сек медленнее и все.
Это если фронт норм написан. А если он дёргает кучу последовательных запросов?
Будет тормозить, да. Но это уже и на ходу переписать можно. «Работает и тормозит» это все равно лучше чем «не работает»
Для 2Гб/с внешнего траффика нужно столько железа? Они там что, геном человека считают? Имхо даже если перекодировать каждое залитое изображение и видео на лету в несколько разрешений все равно столько ресурсов не потребуется…
Тут либо фейк, либо требования на нехилый такой вырост, типа решили заложить в 10 раз больше, авось кто-нибудь пожалеет жертв демократии и сделает скидку.
Тут либо фейк, либо требования на нехилый такой вырост, типа решили заложить в 10 раз больше, авось кто-нибудь пожалеет жертв демократии и сделает скидку.
По количеству серверов интересно сравнить с Одноклассники.
2018
Спустя 12 лет Одноклассники превратились в гигантский сервис с более 70 миллионами пользователей. У нас больше 7 000 машин в 4 дата-центрах
Здесь
У Parler пользователей: 15 million (total) 2.3 million (active)
Как это часто бывает, прямое сопоставление невозможно. Придется сделать допущение, что 70 миллионов пользователей для Одноклассники это total для Parler.
Тогда:
- Одноклассники, пользователей на сервер: 70E6/7000 = 10000
- Parler, пользователей на сервер: 15E6/550 ~= 27000
Понятно, что тут не учтены параметры серверов, что, безусловно, весьма важно.
Придется сделать допущение, что 70 миллионов пользователей для Одноклассники это total для Parler.
Нет. ОК были по активным пользователям чуть меньше ВК, а у ВК как раз 80 MAU, т.е. Parler имеет по 4К активных пользователей в месяц на сервер.
Очень любопытно, почему Скотт Хансельман упомянут как пользователь, а Джон Кармак, как культовый разработчик. Скотт Хансельман мягко говоря не последний человек в .Net сообществе и в этой конкретной теме, думаю, понимает побольше Кармака, который занимается игровыми движками.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
В сети раскритиковали затратность технической архитектуры Parler