Comments 59
Да, впечатляет. Может быть, они теперь хотят сделать задел на будущее с большим запасом?
А разве не масштабирование одна из киллер-фич облаков. Ну про то что платишь ровно за ту мощность которую используешь в данный момент.
Железо стоит дёшево, а программисты дорого (с), а также удобное и и не бьющее по капексу масштабирование в облаке, особенно когда тебя финансируют миллиардеры, умудрилось вылиться в то, что для обработки 70ТБ данных нужно 116ТБ памяти.
Железо стоит дёшево, а программисты дорого (с), а также удобное и и не бьющее по капексу масштабирование в облаке, особенно когда тебя финансируют миллиардеры, умудрилось вылиться в то, что для обработки 70ТБ данных нужно 116ТБ памяти.
Я правильно понимаю, что Parler не только не умеют в приватность, но и в инфраструктуру, зато хорошо умеют в маркетинг, раз на это им выделяется столько денег?
Мне только AliCloud на ум приходит по таким мощностям.
Два предположения:
- Они публикуют требования, которые ни один из мелких провайдеров(крупные отказались) не может выполнить, чтоб потом иметь возможность сказать инвесторам / пользователям: "это не мы не смогли набрать юзербазу, а нас деплатформнули. Дайте больше денег, что-нибудь придумаем."
- Менеджеры/разработчики почесали голову и решили, что управлять проектом, который помещается на 2 сервера(как stackoverflow, например) — недостаточно круто. Частая проблема, на самом деле.
Менеджеры/разработчики почесали голову и решили, что управлять проектом, который помещается на 2 сервера(как stackoverflow, например)
Однако ж, 10, нет, 11 лет назад у stackoverflow была такая конфигурация:
А здесь — текущая: stackexchange.com/performance
Однако ж, 10, нет, 11 лет назад у stackoverflow была такая конфигурация:
Это их полная инфраструктура, я имел ввиду их реальные потребности в железе. Например, в 2016-м у них было 11 веб-серверов, но реально необходим всего один. Они писали про прогон прода на двух серверах(как тест минимальной конфигурации на случай проблем), но сейчас не могу найти.
Жесть кто таким вообще пользуется когда есть вк?
Конечно блин в сети раскритиковали. В сети в принципе все вечно критикуют
Ага. Наконец-то я нашел проект про который нельзя сказать «Главное сделать как-нибудь, а оптимизировать будем потом. Ты что, не слышал про „преждевременную оптимизацию“?
Интересно, Парлер «создадут» с нуля или он вернётся с того, что было? Я так понимаю сотни терабайт данных уже утеряны.
Я правильно понимаю что в Parler помимо обмена сообщениями и постинга картинок был ещё и стриминг видео от пользователей и судя по всему именно для его работы и нужна была большая часть ресурсов?
Я так понимаю, официального комментария от самой компании нет, только вот это фото экрана, где невозможно сказать, не является ли это просто фото документа, которое опубликовавший набрал самостоятельно в редакторе?
Тогда можно хоть заобсуждаться, а я могу сделать такое же фото и там указать, что Parler нужно 500 машин с тремя эксибайтами RAM каждая.
Какие именно метаданные позволяют говорить, что этому заявлению в твиттере стоит верить?
UFO just landed and posted this here
116 тб озу под пг? это шутка такая чтоле? Смотрю на всю эту хрень и думаю как же я жил в 2004 с миллионом пользователей на жалких 8 гб озу а…
Del
Надо не забывать, что в 2004 году были и пользователи меньше с более простыми запросами и требованиями.
UFO just landed and posted this here
давайте навскидку:
— всевозмжные теги (вон у SO целых 3 сервера под это)
— соц сети (куда надо пушить какую-то инфу)
— нотификации (нужно регулярно что-то проверять и отправлять пользователю нотификацию, а когда откроет — показывать по ней нужную инфу)
— опять же, теперь и «авторизация уже не та, что по http», недостаточно проверить пароль в plain text
— всевозмжные теги (вон у SO целых 3 сервера под это)
— соц сети (куда надо пушить какую-то инфу)
— нотификации (нужно регулярно что-то проверять и отправлять пользователю нотификацию, а когда откроет — показывать по ней нужную инфу)
— опять же, теперь и «авторизация уже не та, что по http», недостаточно проверить пароль в plain text
нуда, на 6 порядков, ага… Может коллеги наши стали меньше думать?
Там выше вон про утечку данных и что у них данных то 70 тб, то есть 1.5 раза можно в оперативку сложить.
Там выше вон про утечку данных и что у них данных то 70 тб, то есть 1.5 раза можно в оперативку сложить.
клауд приучает новое поколение г*внокодеров (особенно в США, где за расходы платят деньгами венчурных капиталистов) не думать об оптимизации, а просто шлеп-шлеп и в продакшен да побыстрее.
какая там архитектура, безопасность, эффективность всем пофигу
их некомпетентность не сильно видна, если у сайта посещаемость дохлая, а как только нагрузка вырастает так сразу все и летит к чертям
какая там архитектура, безопасность, эффективность всем пофигу
их некомпетентность не сильно видна, если у сайта посещаемость дохлая, а как только нагрузка вырастает так сразу все и летит к чертям
UFO just landed and posted this here
Сравнивать Hetzner и AWS некорректно. В Хетцнере вы получаете голое железо и сами должны делать все с нуля, включая систему автопровиженинга, автоскейлинга, балансировку, мониторинг, сами должны заботиться о своевременной замене дисков. Помимо этого в Хетцнере конфигурации серверов достаточно ограниченны, например можно ли там на ходу добавить диск к серверу? Или быстро пересоздать сервер в другой сети? Не говоря о доброй сотне дополнительных сервисов, которые предоставляют AWS.
Я вовсе не оправдываю AWS, цены у них действительно конские, но согласитесь, что удобно не сидеть и самому все это настраивать, а просто заказать нужные сервисы в нужном количестве и продолжать разработку. В случае Hetzner вы сами все настраиваете и платите своим временем и страданиями, в AWS вы просто платите большими деньгами.
Я вовсе не оправдываю AWS, цены у них действительно конские, но согласитесь, что удобно не сидеть и самому все это настраивать, а просто заказать нужные сервисы в нужном количестве и продолжать разработку. В случае Hetzner вы сами все настраиваете и платите своим временем и страданиями, в AWS вы просто платите большими деньгами.
всё верно, либо нанимаешь своих devops и платишь им, либо покупаешь у амазону и платишь devops амазона, за то что всё работает.
Балансировку завезли уже
UFO just landed and posted this here
Тем подозрительнее желание Амазона и других провайдеров отказаться от клиента который несет 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-мощностей в мире) тоже?
Для 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
Понятно, что тут не учтены параметры серверов, что, безусловно, весьма важно.
Очень любопытно, почему Скотт Хансельман упомянут как пользователь, а Джон Кармак, как культовый разработчик. Скотт Хансельман мягко говоря не последний человек в .Net сообществе и в этой конкретной теме, думаю, понимает побольше Кармака, который занимается игровыми движками.
Sign up to leave a comment.
В сети раскритиковали затратность технической архитектуры Parler