Comments 23
UFO just landed and posted this here
Есть, мы об этом пишем в разделе «Yandex Message Queue API» — так как YMQ поддерживает AWS SQS API, то для работы можно использовать широкий набор AWS SDK, предлагаемых для самых разных языков.
А также YMQ можно использовать в фреймворках и библиотеках, которые поддерживают SQS как транспорт — например, в Celery, Laravel и т.п.
А также YMQ можно использовать в фреймворках и библиотеках, которые поддерживают SQS как транспорт — например, в Celery, Laravel и т.п.
UFO just landed and posted this here
Там же интерфейс такой же как у AWS SQS, к которому клиентов — дофига
Как правильно отмечает librarian, так как интерфейс такой же, как у AWS SQS, можно использовать готовые AWS SDK для всех языков. Чуть позже мы и в нашу документацию добавим сэмплы кода для разных языков.
Вообще API YMQ настолько тривиален, что можно и так сразу пользоваться. :) Настраивать ничего не нужно, очередь создал и вперёд.
Что касается мимикрирования под другие сервисы — это интересная и правильная мысль, но тут зачастую просто реализацией клиента не обойдёшься, у других очередей другой набор функций, просто так не полетит. Либо надо на недостающие функции бросать исключения — и тогда далеко не все приложения протестируешь, либо доделывать недостающее в самом сервисе — а это уже дополнительное время на разработку. Но мы думаем в этом направлении.
Вообще API YMQ настолько тривиален, что можно и так сразу пользоваться. :) Настраивать ничего не нужно, очередь создал и вперёд.
Что касается мимикрирования под другие сервисы — это интересная и правильная мысль, но тут зачастую просто реализацией клиента не обойдёшься, у других очередей другой набор функций, просто так не полетит. Либо надо на недостающие функции бросать исключения — и тогда далеко не все приложения протестируешь, либо доделывать недостающее в самом сервисе — а это уже дополнительное время на разработку. Но мы думаем в этом направлении.
Прикольно, респект разработчикам! Наверно, предполагается, что в будущем очередью можно будет управлять не только с помощью утилиты «aws», но и с помощью «yc»? А то сейчас как-то не логично, YCC управляется с yc, а YMQ с aws.
Спасибо за статью.
Интересно, а какие Вы приведёте аргументы, чтобы сподвигнуть пользоваться YandexMQ вместо того же RabbitMQ или других облачных очередей?
На стороне RabbitMQ, что он open source, кроссплатформенный, бесплатный, проверенный годами, горизонтально масштабируемый, с плагинами для мониторинга, имеющий готовые библиотеки для множества языков, отлично работает на хостах в разных частях мира и т.д.
Например Яндекс.Облака — не бесплатные, поэтому стоит указать, что стоимость 30-38 р/млн. сообщений. Наверняка стоимость ниже чем у AWS или Azure. Посмотрел, что Azure даже 0.4$/mln без VAT, но как обычно в облачках дьявол кроется в деталях. )
Честно хочется узнать, может ещё кому будет интересно.
Интересно, а какие Вы приведёте аргументы, чтобы сподвигнуть пользоваться YandexMQ вместо того же RabbitMQ или других облачных очередей?
На стороне RabbitMQ, что он open source, кроссплатформенный, бесплатный, проверенный годами, горизонтально масштабируемый, с плагинами для мониторинга, имеющий готовые библиотеки для множества языков, отлично работает на хостах в разных частях мира и т.д.
Например Яндекс.Облака — не бесплатные, поэтому стоит указать, что стоимость 30-38 р/млн. сообщений. Наверняка стоимость ниже чем у AWS или Azure. Посмотрел, что Azure даже 0.4$/mln без VAT, но как обычно в облачках дьявол кроется в деталях. )
Честно хочется узнать, может ещё кому будет интересно.
Отличный вопрос.
RabbitMQ — это действительно один из самых популярных и известных сервисов опенсорсных очередей. Поэтому и внутри Яндекса разные сервисы в своё время стали его использовать. Однако опыт реальной промышленной эксплуатации RabbitMQ нашими сервисами показывает, что не так всё хорошо:
— разворачивать и поддерживать кролика команде каждого сервиса нужно самостоятельно;
— он не всегда стабильно работает;
— если ломается, то надо чинить, иногда руками и это не всегда легко;
— в режиме high availability не обеспечивается надёжность сообщений — при отказах серверов кластера и переезде мастера очереди возможна потеря сообщений.
Из-за необходимости ручной работы бесплатность RabbitMQ достаточно условна, да и за серверы тоже нужно заплатить.
А у YMQ:
— сервис полностью управляемый (managed), то есть Облако всю поддержку осуществляет самостоятельно. Пришёл в UI/API, создал очередь — дальше работаешь с endpoint'ом, про поддержку сервиса не думаешь;
— вся архитектура как YMQ, так и Yandex Database построена таким образом, чтобы не терять данные даже при значительных сбоях — потерях дисков, серверов целиком, стоек серверов или даже датацентров. Если вы сделали SendMessage, и сервер ответил HTTP 200 OK, значит, сообщение надёжно записано и будет доступно для прочтения (мы не рассматриваем мегакатастрофы вроде метеоритов, уничтожающих одновременно все ДЦ Яндекса — если вы что-то знаете и планируете быть к такому готовыми, напишите в нам в техподдержку и мне в личку, желательно как можно скорее);
— YMQ гораздо более отказоустойчив, чем кролик, сообщение при записи синхронно пишется в три реплики в три датацентра (у кролика же репликация по WAN не рекомендуется). YMQ спокойно, без каких-либо потерь сообщений переживает не то что выход из строя сервера — датацентр целиком может выйти из строя и YMQ продолжит работать;
— графиков больше и они более информативные — очень часто, если проблема на стороне пользователя, то её причину можно установить прямо по графикам на дашборде, не нужно лезть в логи. Некоторые крайне полезные графики есть вообще только у нас — например, количество вычиток сообщений (сразу видно, если клиентское приложение сбоит и не с первого раза обрабатывает сообщения);
— с библиотеками тоже всё хорошо вследствие поддержки SQS API — можно брать AWS SDK для любого языка и пользоваться;
— в будущем Яндекс.Мониторинг обязательно позволит навешивать алерты на очереди YMQ.
И всё это всего лишь за 30,48 руб. за миллион (!) запросов.
Конечно, у RabbitMQ функциональность побогаче, и поддерживается больше протоколов, но мы обнаружили, что существующих в YMQ функций уже сейчас достаточно для реализации подавляющего большинства пользовательских сценариев. Если у вас есть сценарий, который не получается реализовать на нашем сервисе — напишите, это будет очень ценно.
RabbitMQ — это действительно один из самых популярных и известных сервисов опенсорсных очередей. Поэтому и внутри Яндекса разные сервисы в своё время стали его использовать. Однако опыт реальной промышленной эксплуатации RabbitMQ нашими сервисами показывает, что не так всё хорошо:
— разворачивать и поддерживать кролика команде каждого сервиса нужно самостоятельно;
— он не всегда стабильно работает;
— если ломается, то надо чинить, иногда руками и это не всегда легко;
— в режиме high availability не обеспечивается надёжность сообщений — при отказах серверов кластера и переезде мастера очереди возможна потеря сообщений.
Из-за необходимости ручной работы бесплатность RabbitMQ достаточно условна, да и за серверы тоже нужно заплатить.
А у YMQ:
— сервис полностью управляемый (managed), то есть Облако всю поддержку осуществляет самостоятельно. Пришёл в UI/API, создал очередь — дальше работаешь с endpoint'ом, про поддержку сервиса не думаешь;
— вся архитектура как YMQ, так и Yandex Database построена таким образом, чтобы не терять данные даже при значительных сбоях — потерях дисков, серверов целиком, стоек серверов или даже датацентров. Если вы сделали SendMessage, и сервер ответил HTTP 200 OK, значит, сообщение надёжно записано и будет доступно для прочтения (мы не рассматриваем мегакатастрофы вроде метеоритов, уничтожающих одновременно все ДЦ Яндекса — если вы что-то знаете и планируете быть к такому готовыми, напишите в нам в техподдержку и мне в личку, желательно как можно скорее);
— YMQ гораздо более отказоустойчив, чем кролик, сообщение при записи синхронно пишется в три реплики в три датацентра (у кролика же репликация по WAN не рекомендуется). YMQ спокойно, без каких-либо потерь сообщений переживает не то что выход из строя сервера — датацентр целиком может выйти из строя и YMQ продолжит работать;
— графиков больше и они более информативные — очень часто, если проблема на стороне пользователя, то её причину можно установить прямо по графикам на дашборде, не нужно лезть в логи. Некоторые крайне полезные графики есть вообще только у нас — например, количество вычиток сообщений (сразу видно, если клиентское приложение сбоит и не с первого раза обрабатывает сообщения);
— с библиотеками тоже всё хорошо вследствие поддержки SQS API — можно брать AWS SDK для любого языка и пользоваться;
— в будущем Яндекс.Мониторинг обязательно позволит навешивать алерты на очереди YMQ.
И всё это всего лишь за 30,48 руб. за миллион (!) запросов.
Конечно, у RabbitMQ функциональность побогаче, и поддерживается больше протоколов, но мы обнаружили, что существующих в YMQ функций уже сейчас достаточно для реализации подавляющего большинства пользовательских сценариев. Если у вас есть сценарий, который не получается реализовать на нашем сервисе — напишите, это будет очень ценно.
Прошу прощения, мне показалось что ваше решение чем-то очень напоминает Apache Kafka. Вполне возможно, я многое путаю. Не могли бы рассказать, чем ваше решение принципиально отличается от той же самой кафки? Спасибо!
Ну, и то, и другое — очереди сообщений :)
В остальном есть куча различий. Kafka больше про упорядоченные потоки данных (per partition) и exactly-once семантику (при определённых усилиях со стороны потребителя, конечно). Она хорошо масштабируется и позволяет прокачивать огромные объёмы данных. Но в то же время её API становится неудобным, если порядок неважен, а хочется обрабатывать сообщения в очереди независимо. С Kafka не получится так же легко построить очередь задач, как на основе YMQ. Например, в Celery она не поддерживается по этой причине — зато есть RabbitMQ, AWS SQS (а значит и YMQ) и другие.
В остальном есть куча различий. Kafka больше про упорядоченные потоки данных (per partition) и exactly-once семантику (при определённых усилиях со стороны потребителя, конечно). Она хорошо масштабируется и позволяет прокачивать огромные объёмы данных. Но в то же время её API становится неудобным, если порядок неважен, а хочется обрабатывать сообщения в очереди независимо. С Kafka не получится так же легко построить очередь задач, как на основе YMQ. Например, в Celery она не поддерживается по этой причине — зато есть RabbitMQ, AWS SQS (а значит и YMQ) и другие.
Производительность FIFO-очереди ограничена 30 запросами в секундуКак-то все очень грустно по сравнению с той же Kafka которая дает примерно те же гарантии (fifo, exactly-once)
Всё верно, Kafka для сценария FIFO является одной из самых производительных очередей, но, как правильно пишет ya-radix в соседнем комментарии, FIFO в некоторых сценариях использования только мешает — если порядок не важен. Поэтому YMQ — это, в первую очередь, стандартные очереди c at least once и отсутствием порядка, а FIFO — дополнительная, нишевая функциональность для тех случаев, когда нужен FIFO, не нужна высокая нагрузка и не хочется использовать две разных системы.
В любом случае, это место мы тоже будем оптимизировать, если будет спрос на это. 30 RPS только выглядит скромно — это достаточно много, зачастую сервису нужно хорошо постараться, чтобы генерировать такой RPS, в большинстве случаев сервисам хватает единиц RPS.
В любом случае, это место мы тоже будем оптимизировать, если будет спрос на это. 30 RPS только выглядит скромно — это достаточно много, зачастую сервису нужно хорошо постараться, чтобы генерировать такой RPS, в большинстве случаев сервисам хватает единиц RPS.
FIFO в некоторых сценариях использования только мешает — если порядок не важен
Что-то мне сложно представить случаи когда он именно мешает. Не нужен — да, много случаев, но чтобы мешал…
30 RPS только выглядит скромно — это достаточно много, зачастую сервису нужно хорошо постараться, чтобы генерировать такой RPS, в большинстве случаев сервисам хватает единиц RPS.
Эээ… ну я даже не знаю что сказать. Наверное типовым клиентам Я и хватает 30 RPS, но городить очереди и прочее ради 30 RPS как-то смысла не вижу. Наверное проще очередь в табличке в MySQL держать :) Шутка, конечно, но в каждой шутке…
Я всё к тому что есть продукт №1 — Кафка. Она предоставляет fifo+exactly once с производительностью в десятки-сотни тысяч RPS на одной ноде в зависимости от.
И есть сабж, который с теми же гарантиями дает 30… или тысячу-другую без гарантий. Я всё понимаю, но разница уж очень большая.
В любом случае, начинание хорошее. Особенно в свете того что тот же Амазон часто берет какой-нибудь опенсурс продукт и начинает продавать его как сервис, что многим очень не нравится. Тут хотя бы своё :)
Что-то мне сложно представить случаи когда он именно мешает. Не нужен — да, много случаев, но чтобы мешал…
Например, если передаются сообщения, разброс времени обработки которых очень большой и сама обработка дорогая. Воркер обрабатывает «тяжёлое» сообщение минуту, за это время обрабатывается большое количество других сообщений. Если на обработке «тяжёлого» воркер падает, то все остальные успешно сообщения тоже надо заново переобрабатывать — прочтённые сообщения в партиции коммитятся по порядку, если какое-то ранее не закоммитили и упали, незакоммиченными будут и все следующие за ним.
Или другой пример — есть 100 партиций и 80 воркеров. Поровну не поделить, некоторые воркеры получат по две партиции. Если партиции «тяжёлые», воркеры с двумя партициями могут и не справляться. Нужно либо подгонять количество воркеров к количеству партиций — что может быть дорого и/или неудобно, либо количество партиций к воркерам — что та ещё задача, особенно если число воркеров меняется динамически. Здесь мешает не столько FIFO, сколько partition level parallelism, но это вещи связанные — порядок появляется как раз на потоке сообщений. Если бы был message level parallelism (и, соответственно, не было бы порядка), количество воркеров и партиций никак не были бы связаны.
Эээ… ну я даже не знаю что сказать. Наверное типовым клиентам Я и хватает 30 RPS, но городить очереди и прочее ради 30 RPS как-то смысла не вижу. Наверное проще очередь в табличке в MySQL держать :) Шутка, конечно, но в каждой шутке…
В БД в любом случае держать не надо, при росте нагрузки там неминуемо будут проблемы и придётся куда-то мигрировать. Поэтому даже при небольших RPS в тех местах, где нужна очередь, лучше сразу использовать очередь — это асинхронные взаимодействия, постановка задач, пересылка сообщений без необходимости получения ответа и т.п. Жить и развиваться будет сильно проще. Тем более что очередь использовать очень просто, это как раз таблички в БД нужно «городить» — придумывать схему, как-то её поддерживать и развивать, мигрировать, делать какую-то библиотеку для работы с этими табличками, наступать примерно на все грабли разработчиков очередей (в статье как раз раскрываются некоторые примеры таких граблей), потом упереться в то, как это всё добро на MySQL тормозит, полгода оптимизировать и понять, что написали своё подобие сервиса очередей. Кому всё это нужно в 2019 году — непонятно.
А в YMQ три основных вызова — SendMessage, ReceiveMessage и DeleteMessage. Предельно просто и понятно, подставляешь endpoint и реквизиты для доступа и вперёд.
Я всё к тому что есть продукт №1 — Кафка. Она предоставляет fifo+exactly once с производительностью в десятки-сотни тысяч RPS на одной ноде в зависимости от.
И есть сабж, который с теми же гарантиями дает 30… или тысячу-другую без гарантий. Я всё понимаю, но разница уж очень большая.
Сравнивать FIFO-очередь и Kafka бессмысленно, FIFO-очереди YMQ не ставят себе задачу заменить Kafka, в сценариях, где нужно передавать эти десятки тысяч RPS упорядоченных данных, нужно использовать заточенные под это инструменты — так, внутри Яндекса мы для передачи упорядоченных потоков тоже не используем FIFO-очереди YMQ, а используем Logbroker — наша собственная разработка система передачи данных, тоже поверх Yandex Database, и горизонтально масштабируется на огромные значения RPS и MB/s.
Даже стандартные очереди YMQ (которые уже сейчас при необходимости поддерживают те же десятки тысяч RPS в одну очередь, и это не предел оптимизаций) не стоит сравнивать с Kafka — функции и задачи у этих систем немного разные.
В простых сценариях, где сообщения не упорядочены и не требуется поддержка exactly once, нужно просто брать YMQ и не морочиться с нумерацией сообщений, количеством партиций и т.п.
В будущем, возможно, мы как раз будем предоставлять Logbroker в Яндекс.Облаке в том или ином виде, вот тогда можно будет вернуться к сравнению с Kafka.
Сравнивать FIFO-очередь и Kafka бессмысленно, FIFO-очереди YMQ не ставят себе задачу заменить Kafka
Сравнивать имеет смысл, т.к. решается одна и та же задача. А то, что у команды не было задачи конкурировать с Kafka — это вопросы, относящиеся к политической области, а не технической.
На мой взгляд, сравнение более, чем уместное: при одинаковых гарантиях Kafka выдает на многие порядки большую производительность. Тут возникает масса вопросов про эффективность.
Даже стандартные очереди YMQ (которые уже сейчас при необходимости поддерживают те же десятки тысяч RPS в одну очередь, и это не предел оптимизаций) не стоит сравнивать с Kafka — функции и задачи у этих систем немного разные.
Можно тут прояснить, в чем разница задач для очередей? Какие задачи выполняют распределенные очереди кроме той, чтобы хранить последовательность сообщений, добавлять и извлекать?
Kafka передаёт данные с сохранением порядка, а стандартные очереди YMQ — без. Как я показал выше, есть сценарии, на которых это различие принципиально.
Тут я не очень понял. Можно сказать, что то, что Kafka сохраняет порядок — приятный бонус. Можно им не пользоваться, и тогда задачи становятся одинаковыми. А значит можно снова сравнивать, верно?
Получается, что у Kafka производительность выше во всех сценариях работы. Более того, Kafka предоставляет больше гарантий и возможностей. Думаю, вот в таком аспекте и можно сравнить.
Я, наверное, имею слишком узкое понимание, но так и не смог усвоить как очередью может называться то, что, вообще говоря, не гарантирует сохранение порядка сообщений. На самом деле, когда вы говорите что ваши варианты понимания «очереди» отличаются от кафки хотя бы чем-нибудь, видно, что вы как бы специально не выходите на функционал кафки, оставляя для него маленькое слепое пятно, чтобы не выглядеть плохо при сравнении.
Вообще, если какой-то сервис в ваккуме не требователен к нагрузке и хочет каких-то удобных прибамбасов: изменения количества консьюмеров на лету, приоритетные очереди и т.п., то этот сервис не спроектирован под большую нагрузку в будущем. Именно стандартные квадратно-гнездовые требования кафки и определяют то, как сервис, если он хочет расти, должен работать с очередями. И потому, когда вы говорите про сервисы, которым кафка не подходит, вы говорите не про highload промышленные машины, а про игрушки в песочнице. К сожалению, как следствие, ваш сервис, несмотря на всю красоту, выглядит как красивый грибочек именно в этой песочнице. Все ключевые слова вроде бы есть, но кроме одновременно скорости и сохранения порядка.
Вообще, если какой-то сервис в ваккуме не требователен к нагрузке и хочет каких-то удобных прибамбасов: изменения количества консьюмеров на лету, приоритетные очереди и т.п., то этот сервис не спроектирован под большую нагрузку в будущем. Именно стандартные квадратно-гнездовые требования кафки и определяют то, как сервис, если он хочет расти, должен работать с очередями. И потому, когда вы говорите про сервисы, которым кафка не подходит, вы говорите не про highload промышленные машины, а про игрушки в песочнице. К сожалению, как следствие, ваш сервис, несмотря на всю красоту, выглядит как красивый грибочек именно в этой песочнице. Все ключевые слова вроде бы есть, но кроме одновременно скорости и сохранения порядка.
pubsub в pull режиме и SQS в дефолтном режиме так же не сохраняют порядок. Это тоже «игрушки в песочнице»? Вообще, с большой вероятностью, если вам важен в порядок в тех областях где используют SQS, Pubsub, а теперь и YMQ, вы что-то делаете не так: cloud.google.com/pubsub/docs/ordering
Sign up to leave a comment.
Архитектура сервиса распределённых очередей сообщений в Яндекс.Облаке