Comments 68
С каких это пор собственно масштабируемость — "проблема монолита"?
Неудачно спроектированное будет плохо масштабироваться независимо от "монолитности" или "микросервисности".
Необходимость селективного горизонтального масштабирования, оправдывающего внесение дополнительных межсервисных коммуникаций, не показана.
"Независимые" микросервисы с общей базой данных — это хуже монолита по построению, в такой конфигурации успешно объединены проблемы и устранены достоинства обоих подходов.
Про "автономность" тоже одна реклама. Конечного пользователя (если он голосует) очень мало заботит тот факт, что при аварии с одним микросервисом другие продолжат работу.
Проблема-то в том, что вариант использования с голосованием накроется медным тазом при отказе любого компенента, а значит про "независимость" речь не идет — даже при идеально пришитых пуговицах костюм все равно не айс.
А механизм голосования, в котором пользователь сознательно дезинформируется про "ваш голос учтен" (а счетчики изменятся неизвестно когда) — чистейшая как слеза задняя дверь под произвольные накрутки от организаторов.
Итого: статья вместо грамотной архитектуры демонстрирует недобросовестную рекламу.
С каких это пор собственно масштабируемость — «проблема монолита»?
Горизонтальное масштабирование — это проблема монолита.
Неудачно спроектированное будет плохо масштабироваться независимо от «монолитности» или «микросервисности»
Это точно :)
Необходимость селективного горизонтального масштабирования, оправдывающего внесение дополнительных межсервисных коммуникаций, не показана.
Каждый из трех сервисов масштабируется независимо горизонтально и вертикально. Чтобы увидеть необходимость приведу пример, когда у нас забилась очередь (Якутия активно пошла голосовать, они очень дружные) мы потянули ползунок и докинули сервисов обработки голосов.
«Независимые» микросервисы с общей базой данных — это хуже монолита по построению, в такой конфигурации успешно объединены проблемы и устранены достоинства обоих подходов.
Об общей базе я написал, видимо не достаточно подробно. В данном случае база это не совсем база. Это продажа юнитов к хранилищу. По сути в этом хранилище три «СУБД», но подписка на одну облачную «БАЗУ». Обновление и масштабирование можно сделать независимым, но для этого надо купить три подписки на облачную базу, что в случае этого проекта будет неоправданными расходами. А вообще мы обычно делаем каждому микросервису своё хранилище и DWH для аналитики по всем СУБД.
Про «автономность» тоже одна реклама.
Здесь что-то про эмоции, не понял вопрос.
Проблема-то в том, что вариант использования с голосованием накроется медным тазом
Вы либо не захотели разобраться, либо решили потроллить. В любом случае жду конкретных вопросов, не готов разделять с вами эмоции.
Горизонтальное масштабирование — это проблема монолита.
Вообще-то… нет.
Проблема монолита — селективное горизонтальное масштабирование, когда с одной стороны компоненты нагружены сильно неравномерно, а с другой — приходится платить за масштабирование всей системы.
Соответственно, решение о выделении микросервисов должно иметь в основе именно такие данные — асимметрию загрузки сайта-валидатора-счетчика и дороговизну масштабирования всего этого целиком.
Насколько я вижу, о таком анализе для конкурса "Мисс Россия" в статье ничего нет — только готовое решение.
Каждый из трех сервисов масштабируется независимо горизонтально и вертикально. Чтобы увидеть необходимость приведу пример, когда у нас забилась очередь (Якутия активно пошла голосовать, они очень дружные) мы потянули ползунок и докинули сервисов обработки голосов.
И насколько это дешевле по сравнению с (хорошо спроектированной) монолитной системой?
Здесь что-то про эмоции, не понял вопрос.
Давайте развернуто. Если я пользователь и я хочу проголосовать, то мне необходимо, чтобы все три компонента работали:
- Сайт
- Валидатор
- Счетчик
Неработоспособность чего-то одного лишает меня голоса де-факто. И для меня как пользователю никакого толку, что все остальное работает.
PS: жалко, что не стали отвечать про разрыв обратной связи — вы ее порвали не только и столько для ботоводов, сколько для обычных пользователей. Я голосую онлайн, мне сообщили что мой голос учтен, а счетчик не сдвинулся ни на миллиметр. То, что я подумаю про организаторов, немного предсказуемо.
селективное горизонтальное масштабирование, когда с одной стороны компоненты нагружены сильно неравномерно
Это и имеется ввиду. Просто никто не говорит «селективное горизонтальное...».
о таком анализе для конкурса «Мисс Россия» в статье ничего нет — только готовое решение
Была надежда, что вы разберетесь с тремя простыми ответственностями на схеме, их границами и способами масштабирования. Пояснять подробнее не планировал.
И насколько это дешевле по сравнению с (хорошо спроектированной) монолитной системой?
Покажите мне хорошо спроектированную монолитную систему и я смогу сравнить.
вы ее порвали не только и столько для ботоводов, сколько для обычных пользователей
Видимо вам лучше знать что и зачем мы сделали. Не буду портить монолог.
Была надежда, что вы разберетесь с тремя простыми ответственностями на схеме, их границами и способами масштабирования. Пояснять подробнее не планировал.
Так ваша схема вполне понятна. Непонятно другое — каков мотив реализации именно на микросервисах.
Старая система была неудачно спроектирована для имеющихся нагрузок.
Это вы показали наглядно.
Вы лучше спроектировали новую.
Это вы тоже показали наглядно.
А вот причины выбора именно микросервисной организации вы наглядно показывать не стали.
Хотя это самый важный момент. Микросервисы недешевы и разрабочикам очень полезно знать, что их окупает.
Покажите мне хорошо спроектированную монолитную систему и я смогу сравнить
Ваш же вариант без физического разделения вполне подойдет. Согласитесь, что сравнивать плохо спроектированную монолитную систему с хорошо спроектированной микросервисной — довод в пользу хорошего проектирования, а не микросервисов.
Видимо вам лучше знать что и зачем мы сделали.
Я вполне доверяю вам по обоим пунктам:
- Вы делали это против ботоводоства
- Вы достигли по этому параметру хорошего результата
Но с другой стороны страно так остро реагировать на неизбежное следствие вашего решения — пользователи тоже потеряли обратную связь со всеми вытекающими.
Непонятно другое — каков мотив реализации именно на микросервисах.
Коротко описал в статье, вот выдержка:
Для новой архитектуры мы взяли за основу идеи, которые бы привели к достижению бизнес-целей:
- Разделить приложение на (микро)ответственности.
- Каждая часть будет идеально выполнять свою роль.
- Каждая часть будет сама заботиться о масштабировании.
- Тотальная автоматизация.
Более длинно в другой статье в блоге по более глобальному проекту http://blog.byndyu.ru/2016/11/it.html. Понятно, что конкурс не имеет много бизнес-логики, но три части четко выделялись из монолита, что мы и использовали.
Микросервисы недешевы и разрабочикам очень полезно знать, что их окупает.
Это точно! Одна из причин почему мы выбрали микросервисы — у нас есть достаточный опыт, чтобы силами двух человек за 4 недели переделать весь проект на новую архитектуру. Если мы только читали о микросервисах, то переход на них был бы более рискованный, чем дробление легаси-монолита.
довод в пользу хорошего проектирования, а не микросервисов
Да, именно так. Перед нами стоял выбор: дробить старую систему или написать всё заново. У менять не иллюзий на тему «давайте перепишем всё с нуля!!!111111», подробно на эту тему писал здесь http://blog.byndyu.ru/2014/01/blog-post_8.html. Скажу больше, обычно мы не переписываем всё с нуля, т.к. это рисковано и экономически неоправдано. Но конкретно в этом случае мы посчитали, что надо переписывать всё с нуля. Причин было много: плохая архитектура, очень слабо написан front-end, CMS и, самое главное, не много бизнес-логики.
пользователи тоже потеряли обратную связь со всеми вытекающими
Перед принятием решения мы спросили у программного коммитета, который занимается конкурсом десяток лет, допустимо ли показывать инкремент голосования с задержкой. Заказчики сказали, что да, это приемлемо. Тогда мы приняли решение сделать так, как сделали, иначе искали бы другие пути.
Сообщение неправильное, т.к. в этот момент голос не учтён, а только принят…
Если серьезно, но их голос будет учтен в среднем в течение 15 секунд, а счетчик сайта обновится через час, так что мы их не обманываем. Ну а если это бот пришел накручивать, то ему без разницы какое сообощение.
Выкинуть очередь и обновлять счетчик онлайн не комильфо?
Сравним:
«Ваш голос учтён и появится на сайте в ближайшее время, спасибо за участие в голосовании!»
Их голос будет учтен в среднем в течение 15 секунд, а счетчик сайта обновится через час
Прошедшее время вместо будущего, час как ближайшее время, и совсем непонятно, почему пользователям нельзя показывать информацию из второго сообщения. С комментариями о том, зачем нужна такая схема при необходимости.
Это реальное оправдание для видимого учета голоса пользователя только через час?
С чего вы взяли что меня что-то возмущает?
Александр дал в своих комментариях исчерпывающий ответ: заказчика (оргкомитет) в данном вопросе удобство пользователей не заботило, а по другим критериям принятое решение вполне удачное.
У ютуба подсчет количества просмотров — не основная задача, в отличие от конкурса с голосованием. Если бы ютуб видео по ссылке начинал показывать примерно через час после перехода на страницу — это было бы сравнимо.
Да, основная задача этого сайта — учесть голоса. Не отобразить их сразу, а обеспечить целостность и достоверность. Как уже ниже давались ссылки — есть специальные сайты, которые за деньги обеспечивают победу на этом конкурсе, а значит первоочередная цель — отсеять всех этих нехороших людей, что сами понимаете, достаточно ресурсоёмко.
И удобство для пользователей тут — это уверенность, что кандидат, за которого ты голосовал — победил или проиграл честно.
Не отобразить их сразу, а обеспечить целостность и достоверность.
Это интерес не пользователя, а оргкомитета. А для живого человека самые неприятные интерфейсы — медленные без обратной связи. Именно такой и был сделан.
Иногда число голосов не показывают специально — люди склонны отдавать свой голос одному из лидеров гонки и без знания текущего положения голосование будет точнее. Но к текущему решению это не относится.
Есть еще один вид заинтересованных лиц — сам оргкомитет. И абсолютно непрозрачная для пользователя схема подсчета с неверной информацией об учете голоса по построению — широчайший простор для манипуляций. И даже если считать оргкомитет женой Цезаря (закрыв глаза на комментарии inkvizitor68sl) всегда остаются ложноположительные срабатывания бот-детектора, которые благодаря разрыву обратной связи теперь определить гораздо сложнее.
Если счет не надо обновлять в реальном времени, то можно использовать CQRS, чтобы отдельно обновлять счетчик, отдельно его показывать. Показывать с допустимой задержкой (eventually consistent), зато дешево масштабировать на любую нагрузку.
Правильная реализация позволила бы получить этот же рейтинг с обновлением в режиме реального времени.
Вместо этого накликиваете базу в облаке за копейки, она бэкапит логи транзакций каждые 5 минут, держит нужную нагрузку и реплецируется хоть на весь мир. Периодически делаете проекцию с сырых данных на базу. Веб идет в базу, когда кэш закончился (редко) и в тот момент на фронте рождается новая цифра.
Решение получается железобетонное и дешевое в разработке и поддержке. По сути разрабатывать и настраивать нечего, кроме самого алгоритма отсева.
Еще раз повторю, что подходов может быть много, но в данном случае самые простой и надежный представлен на нашей архитектуре.
И как же переводится на язык пользователя "в ближайшее время"?
А что значит фраза «в ближайшее время»? Кстати, а как это переводится на язык майя? Ну вдруг кто-то из племени будет тоже голосовать.
Почемы вы обычные требования пользователя к системе онлайн-голосования называете придирками?
Учтите, после былинных отказов вроде "Имя Россия" или "Премии рунета" априорного доверия к организаторам любых голосований давно уже нет.
Специфика данного конкретного конкурса только добавляет голосующим скепсиса. А в нюансах микросервисности, очередей и ботоводства обычный пользователь разираться не обязан.
На момент написания комментария Александр еще не дал полного ответа.
Из текста самой статьи никак не следовало, что удобство пользователей на самом деле заказчика не волновало совсем, а исполнителя — только в рамках договора с заказчиком.
В любом случае сообщение, выдаваемое системой пользователю, явно расходится с действительностью.
CMS «Плеск»
А можно поподробнее про этого зверя? Plesk всю жизнь был админ панелью для хостинга и про одноимённую CMS не нашлось никакой информации ни в google, ни на сайте по ссылке.
> Сайт хостился на выделенном сервере. Добавление железа в сервер перестало приносить пользу. Когда заказчик провел нагрузочное тестирование, сайт упал на 150 запросах в секунду.
Ребят, вы вконец охренели со своим пиаром. Миссрашка жила последние 3-4 года на обычной железке с 32G RAM и никто никогда не жаловался на «500 и не работает голосование». И железа туда никто никогда добавлять не пытался — один черт, никогда близкой к 150 RPS цифры там реальной нагрузки не было. И да, если «старую архитектуру» залили бы нормальной железкой — то держала бы она и 300, и 500 RPS (после некоторой настройки), эти цифры покрывают необходимый запас ещё на много лет вперед.
Вот что переписали это дерьмо мамонта — это вы молодцы, правильно сделали, без нового кода там делать нечего было. Но вот утверждать, что ваши соседи по индустрии лаптями едят — это вы зря. Мир тесен.
Самое забавное: сейчас голосование с точки зрения того, что видит пользователь, именно что не работает. Сообщение об учете голоса есть — а результат на сайте будет виден через час.
Будь я пользователем без опыта разработки, остро желающим отдать свой голос за одну из участниц — накатал бы жалобу сразу.
если «старую архитектуру» залили бы нормальной железкой
Добавить железку… :) Именно такого решения и ждали заказчики? Текущая стоимость в 3 раза дешевле, чем тот сервер, который якобы держал нагрузку и проблем не вызывал.
Ребята, ну серьезно, заказчик забрал у вас контракт не потому что всё было круто, быстро и все были довольны. Разве не так?
Но вот утверждать, что ваши соседи по индустрии лаптями едят
Где такое было? Жду цитату из статьи и готов взять свои слова обратно, если там есть оскорбление.
Нет, они ждали новомодных словечек в своём проекте и получили то, что хотели — Ажур при том же количестве ресурсов на бумаге медленнее железа.
> Добавить железку… :)
Не добавить, а заменить. Вы же пишете — «Добавление железа в сервер перестало приносить пользу. ». Никто его туда никогда не добавлял, не планировал, а самое главное — не задумывался об этом, ибо не нужно. Ну а я, в свою очередь, утверждаю, что замена железа на более производительное принесла бы огромную пользу к нафиг никому не нужным цифрам в лице теоретического максимума rps.
> Жду цитату из статьи и готов взять свои слова
Например вот — «Во время конкурса пользователи постоянно жаловались, что страницы медленно открываются, отдают 500-ошибку и не работает голосование».
Или вот — «якобы держал нагрузку».
> Текущая стоимость в 3 раза дешевле,
Хватит врать, серьёзно. В полтора раза дороже ваша S1 в месяц, чем то, что использовалось.
Давайте немного в цифрах. Самый-самый пик запросов в php в 2016м в течении секунды — что-то в районе 80 rps. А вообще нагрузка в день конкурса держалась в промежутке 10-20 rps. Обе цифры выглядят меньше 150, не? Или у меня проблемы с математикой на уровне второго класса?
Пятисоток там тоже в 2016м не было.
> заказчик забрал у вас контракт не потому что всё было круто
Мы можем поговорить про корпоративные за*бы, наверное, но не стоит. А то мы сейчас будем выяснять, у кого из корпов кончились деньги. Переписывать проект нужно было, опять делать это на php было глупым вариантом в 2017м. Так что молодцы, что переписали на современных технологиях и наконец-то задумались об оптимизации фронта.
Но вот утверждать, что оно «плохо работало раньше и падало во время конкурса» — это наглое враньё. Оно работало как работало, во время конкурса и в обычные дни — да, не очень шустро из-за кода и верстки родом из 2008го, но ничуть не медленее, чем обычно. И несмотря на необходимость переписать всё к чертям, старое решение прожило достаточно долго для такого уровня проекта и имело хороший запас по мощности и возможности расти по цифрам дальше.
Могу заверить, что проект сделали хорошо и своей работой я горжусь. Всё, что написано о «прошлом» проекта я знаю со слов организаторов. Видимо так они видели предыдущее сотрудничество.
на обычной железке с 32G RAM
это шутка?
32 гигабайта памяти стоят сейчас 10-12 тысяч. А арендовать сервер с 32G можно на 35 EUR. В ходу сейчас сервера с 256-512G памяти.
Вы используете такого монстра, который явный оверкил для данной задачи и говорите, что нужно ещё добавить железа. 512 GB которые с трудом будут тянуть 150 запросов? Это инженерное решение?
1) Сервер с 32G RAM (и каким-то там процессором из разряда «обычных») стоит дешевле виртуалки в azure с 1.75G RAM. Как в аренду, так и если его купить и поставить в стойку (из расчета, что он будет использоваться 3-4+ года).
2) Железка с 32G ram справлялась с пиковой нагрузкой (в аж целых 80 RPS, да), а виртуалка в azure за бОльшие (или примерно те же) деньги, судя по статье — нет.
3) Сравнивать абсолютные значения RPS старенькой CMS на php и свежего оптимизированного под конкретный проект кода — мягко говоря, некорректно.
4) сервера c 32G сейчас являются игрушкой для стажеров, а не «монстром» в IT-компаниях. Возможно, в мире махрового ынтерпрайза это не так. Повторюсь, RAM сама по себе не стоит ничего. Каких-то денег стоят серьёзные процессоры, но его там нет и не было (e5540, что ли или похожий).
5) в действительно высоконагруженных проектах на данный момент закупаются/арендуются сервера с 256G+ RAM (при условии наличия соответствующих процессоров в ноде). Сервера со 128G отправляются в девелопмент или вроде того, а сервера с 32G уже года 3 как распродаются такими проектами за бесценок (потому что утилизация стоит приличных денег).
6) что добавлять железо нужно было в MR — я как раз не говорил. Про это почему-то в статье говорят (почему — думаю, юристы разбираться будут, кто и что кому сообщил. Сами владельцы проекта не в курсе, что у них, оказывается, что-то раньше падало).
7) Даже если и добавлять железо — то менять процессор, а не память.
Впрочем, посыл «Это инженерное решение?» вы зря так саркастично употребили. Многие проблемы забрасываются железом ровно потому, что так дешевле. За зарплату хорошего разработчика можно амортизировать/арендовать 20-30 хороших железок. А за удивившие вас 32G памяти в сервере можно разве что один раз в паб вдвоём-втроём хороший сходить.
За зарплату хорошего разработчика можно амортизировать/арендовать 20-30 хороших железок.
Чтобы железки превратить в нечто полезное, нужны те самые дорогие инженеры. Вместо этого можно взять PaaS (любой, не обязательно Azure) и заниматься только бизнес-задачами, что мы и сделали.
с 2016 цифры. Вряд ли в этом году больше.
Бывает так, что люди, которые поддерживают девушек устраивают флешмобы. Или популярные девушки (по 40К подписчиков) просят за них голосовать. Или любители покупки голосов размещают объявления о накрутках (мы отсеяли 500К бото-голосов из 750К общих). Тогда начинает нагружаться голосование. А нам надо в конце дня предоставлять отчет по накруткам и показывать сколько откручивали. Алгоритмы и хитрости отсева не rocket-science, но требуют ресурсов.
При этом проходят пресс-релизы, девушки ездят на мероприятия и т.п. В этот момент много народу (2К rps) приходят смотреть фоточки, новости и т.п. на сайте.
В итоге, из-за того что сайт постоянно качает между двумя активностями мы решили их разделить и масштабировать отдельно. Даже если бы боты завалили API для голосования, то сайт бы продолжал работать в обычном режиме, а он является «витриной» для продажи конкурса.
Несколько моментов, которые я не очень понял.
«Выбирали очередь между Service Bus и Storage Queues» по требованиям вроде бы и 2е подходит, или я чего-то не знаю?
У вас и для api и для сайта я так понимаю был .net core. Kestrel использовали в обоих случаях с iis в качестве прокси или чистый?
«Выбирали очередь между Service Bus и Storage Queues» по требованиям вроде бы и 2е подходит, или я чего-то не знаю?
Модель работы Service Bus Queues выглядит надежнее, чем у Storage queues, а именно больше гарантий при доставки сообщений (At-Least-Once и At-Most-Once), более надежная блокировка (Peek & Lock или Receive & Delete). Также нет ограничений на время хранения сообщений. Ограничение на сообщение в Storage queues — 64 KB, а в Service Bus Queues — 256 KB or 1 MB.
Сам по себе Service Bus больше похож на очереди, а Storage Queues это скорее некое расширение обычного хранилища. Более подробно https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted.
У вас и для api и для сайта я так понимаю был .net core. Kestrel использовали в обоих случаях с iis в качестве прокси или чистый?
В WebApp использовали Kestrel, IIS руками не трогали. Видимо он где-то есть глубоко в Azure, чтобы балансировать, если кол-во инстансов увеличивается.
Было бы интересно почитать о том, как вы боролись с накруткой.
Могу рассказать только о том, что видно на сайте, но не о внутренних алгоритмах отсева, иначе этим воспользуются люди, которые продают накрутки. Попробуйте поискать «накрутка голосов мисс россия», например, есть вот такие ребята http://jet-s.ru/blog/konkurs-miss-rossija-pomozhem-vyigrat. Кроме них мы видели с десяток видео, как формировать POST-запросы к предыдущим формам голосования.
О видимых способах отсева:
- Убрали обратную связь при голосовании. Это лишает тех, кто тыкает в сайт понимания работает их способ или нет. Они посылают запросы и мы всегда отвечаем, причем мгновенно, что их голос будет учтен. Если бы счетчик обновлялся сразу, то подобрать способ обхода защиты было бы проще.
- Проверка по IP. Это, конечно, очень простое ограничение, но не бесполезное.
- Recaptcha. Да, мы все знаем о сервисах ручного «взлома» любой капчи :)
- Аутентификация через аккаунт в соц. сети. Да, мы в курсе, что аккаут в соц. сети стоит 3-5 рублей за штуку.
- «Магия» анализа на клиенте и на сервере, здесь подробностей не будет
Единственная неприятная проблема возникла с Kestrel, который под нагрузкой начинал отвечать кодом 502.3. При этом приложение падало и не оживало до перезапуска.
Проблема была в версии Kestrel версии 1.1.0. Описание в Issue323 и Issue311. Нам повезло, что за две недели до начала конкурса вышел пакет Microsoft.AspNetCore.Server.Kestrel версии 1.1.1 и проблема ушла..
По мне так очередной показатель того что AspNet Core сырой. А если бы не вышел апдэйт, чем бы ваше решение было бы лучше предыдущего в том плане что страницы
отдают 500-ошибку
Вы надолго останетесь в истории, как человек не сумевший обосновать свой профессионализм Умпутуну ;-).
Вам остались часы для адекватных ответов.
Как мы «Мисс Россию» на руках переносили