Punt используют в контексте «перенести на попозже». Punt a ticket to the next sprint, punt our meeting to next week.
В моей эпсилон-окрестности это используется достаточно часто, за всю отрасль не берусь говорить.
Согласен с тем, что его не стоит использовать, но скорее по причине того, что его всегда приходится объяснять. В этом, в общем-то, и есть посыл статьи.
Отказов в явной форме я не видел, но, думаю, что конечно они бывают. Сейчас рынок к целом очень плохой для соискателя – предложений мало, компенсации ползут вниз, к сожалению, так что надо быть готовым к тяжелой работе по поиску.
Визы оформляют, но есть затруднения. Британскую визу оформляют месяц-два, экспресс не работает. В Ирландию визу русских и белорусам дают только на однократный въезд.
Это хороший вопрос. Я думаю, что если язык правда позволяет, то стоит его качать с носителями, общаясь на темы вне работы. Я познакомился с парой южноафриканцев на почве детей, общаемся – там, конечно, уже совсем другие законы.
Ещё хочу попробовать зайти к Toastmasters, в нашем офисе есть группа. Слышал отзывы о том, что это неплохой способ попрактиковаться, но своего мнения пока нет.
Не, тут же нет посыла «делайте только так и никак иначе». Всё перечисленное — это только чтобы забутстрапиться и сдвинуться с мёртвой точки. Should an individual possess the ardent desire to refine the sophistication of their vernacular, let no impediment hinder their noble pursuit. Yeah?
Не знаю, за что минусуют – мысль-то верная. Я действительно в Яндексе научился многому сильно проще и быстрее. И в Амазоне сейчас выстраивание отношений с русскоязычными выходит на порядок-другой быстрее. И сейчас у меня группа почти целиком русскоязычная, что даёт серьёзное преимущество в скорости общения.
С другой стороны, таких масштабов и зрелости практик на локальных рынках не найти, думаю, нигде. Всё-таки работать на реальном острие прогресса (каким бы тупым это остриё не было иногда) дорогого стоит.
Думаю, что единственного правильного ответа нет, в конечном итоге всё зависит от желаний и целей конкретного человека, а они редко ограничиваются только работой. Эта статья для тех, кто определился с целью, но побаивается языка.
Всё так. Более того, нет ничего зазорного в том, чтобы на собес со шпаргалками приходить – просто спросите, можно ли их использовать, если у интервьюера вдруг другое мнение.
Kafka передаёт данные с сохранением порядка, а стандартные очереди YMQ — без. Как я показал выше, есть сценарии, на которых это различие принципиально.
Что-то мне сложно представить случаи когда он именно мешает. Не нужен — да, много случаев, но чтобы мешал…
Например, если передаются сообщения, разброс времени обработки которых очень большой и сама обработка дорогая. Воркер обрабатывает «тяжёлое» сообщение минуту, за это время обрабатывается большое количество других сообщений. Если на обработке «тяжёлого» воркер падает, то все остальные успешно сообщения тоже надо заново переобрабатывать — прочтённые сообщения в партиции коммитятся по порядку, если какое-то ранее не закоммитили и упали, незакоммиченными будут и все следующие за ним.
Или другой пример — есть 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.
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 функций уже сейчас достаточно для реализации подавляющего большинства пользовательских сценариев. Если у вас есть сценарий, который не получается реализовать на нашем сервисе — напишите, это будет очень ценно.
Всё верно, Kafka для сценария FIFO является одной из самых производительных очередей, но, как правильно пишет ya-radix в соседнем комментарии, FIFO в некоторых сценариях использования только мешает — если порядок не важен. Поэтому YMQ — это, в первую очередь, стандартные очереди c at least once и отсутствием порядка, а FIFO — дополнительная, нишевая функциональность для тех случаев, когда нужен FIFO, не нужна высокая нагрузка и не хочется использовать две разных системы.
В любом случае, это место мы тоже будем оптимизировать, если будет спрос на это. 30 RPS только выглядит скромно — это достаточно много, зачастую сервису нужно хорошо постараться, чтобы генерировать такой RPS, в большинстве случаев сервисам хватает единиц RPS.
Как правильно отмечает librarian, так как интерфейс такой же, как у AWS SQS, можно использовать готовые AWS SDK для всех языков. Чуть позже мы и в нашу документацию добавим сэмплы кода для разных языков.
Вообще API YMQ настолько тривиален, что можно и так сразу пользоваться. :) Настраивать ничего не нужно, очередь создал и вперёд.
Что касается мимикрирования под другие сервисы — это интересная и правильная мысль, но тут зачастую просто реализацией клиента не обойдёшься, у других очередей другой набор функций, просто так не полетит. Либо надо на недостающие функции бросать исключения — и тогда далеко не все приложения протестируешь, либо доделывать недостающее в самом сервисе — а это уже дополнительное время на разработку. Но мы думаем в этом направлении.
Есть, мы об этом пишем в разделе «Yandex Message Queue API» — так как YMQ поддерживает AWS SQS API, то для работы можно использовать широкий набор AWS SDK, предлагаемых для самых разных языков.
А также YMQ можно использовать в фреймворках и библиотеках, которые поддерживают SQS как транспорт — например, в Celery, Laravel и т.п.
А какие нюансы могут быть с внешним хранилищем, которые что-либо усложняют?
At most once: если ни одна операция в системе не ретраится, как, при условии корректной реализации всех компонентов, могут появиться дубли? Я не говорю про систему без сбоев, только лишь про то, что в компонентах нет багов, которые приводят к дублям.
At least once: если каждый компонент ретраит запросы до победного конца, где могут появиться потери? При условии отсутствия бажных/чересчур оптимистично настроенных компонентов вроде стораджей, которые возвращают успех, никуда толком не сохранив.
Можно пример, который продемонстрировал бы, почему обеспечение этих поведений реализовать сложнее, чем описанные выше стратегии?
At-most-once, т.е. не более одного раза. При кажущейся очевидности, такое поведение крайне сложно гарантировать при краевых сценариях по типу падений, нарушение сетевой связности и другое
At-least-once, т.е. не менее одного раза. Схема более сложная. И граблей можно насобирать поболее
А почему так сложно гарантировать at most once? И что за грабли в at least once? Разве стратегии «никогда не ретраить»/«ретраить до упора» не обеспечивают поведения at most/at least once?
Спасибо за отзыв.
Punt используют в контексте «перенести на попозже». Punt a ticket to the next sprint, punt our meeting to next week.
В моей эпсилон-окрестности это используется достаточно часто, за всю отрасль не берусь говорить.
Согласен с тем, что его не стоит использовать, но скорее по причине того, что его всегда приходится объяснять. В этом, в общем-то, и есть посыл статьи.
Спасибо за отзыв.
Отказов в явной форме я не видел, но, думаю, что конечно они бывают. Сейчас рынок к целом очень плохой для соискателя – предложений мало, компенсации ползут вниз, к сожалению, так что надо быть готовым к тяжелой работе по поиску.
Визы оформляют, но есть затруднения. Британскую визу оформляют месяц-два, экспресс не работает. В Ирландию визу русских и белорусам дают только на однократный въезд.
Это хороший вопрос. Я думаю, что если язык правда позволяет, то стоит его качать с носителями, общаясь на темы вне работы. Я познакомился с парой южноафриканцев на почве детей, общаемся – там, конечно, уже совсем другие законы.
Ещё хочу попробовать зайти к Toastmasters, в нашем офисе есть группа. Слышал отзывы о том, что это неплохой способ попрактиковаться, но своего мнения пока нет.
Не, тут же нет посыла «делайте только так и никак иначе». Всё перечисленное — это только чтобы забутстрапиться и сдвинуться с мёртвой точки. Should an individual possess the ardent desire to refine the sophistication of their vernacular, let no impediment hinder their noble pursuit. Yeah?
Не знаю, за что минусуют – мысль-то верная. Я действительно в Яндексе научился многому сильно проще и быстрее. И в Амазоне сейчас выстраивание отношений с русскоязычными выходит на порядок-другой быстрее. И сейчас у меня группа почти целиком русскоязычная, что даёт серьёзное преимущество в скорости общения.
С другой стороны, таких масштабов и зрелости практик на локальных рынках не найти, думаю, нигде. Всё-таки работать на реальном острие прогресса (каким бы тупым это остриё не было иногда) дорогого стоит.
Думаю, что единственного правильного ответа нет, в конечном итоге всё зависит от желаний и целей конкретного человека, а они редко ограничиваются только работой. Эта статья для тех, кто определился с целью, но побаивается языка.
Всё так. Более того, нет ничего зазорного в том, чтобы на собес со шпаргалками приходить – просто спросите, можно ли их использовать, если у интервьюера вдруг другое мнение.
Например, если передаются сообщения, разброс времени обработки которых очень большой и сама обработка дорогая. Воркер обрабатывает «тяжёлое» сообщение минуту, за это время обрабатывается большое количество других сообщений. Если на обработке «тяжёлого» воркер падает, то все остальные успешно сообщения тоже надо заново переобрабатывать — прочтённые сообщения в партиции коммитятся по порядку, если какое-то ранее не закоммитили и упали, незакоммиченными будут и все следующие за ним.
Или другой пример — есть 100 партиций и 80 воркеров. Поровну не поделить, некоторые воркеры получат по две партиции. Если партиции «тяжёлые», воркеры с двумя партициями могут и не справляться. Нужно либо подгонять количество воркеров к количеству партиций — что может быть дорого и/или неудобно, либо количество партиций к воркерам — что та ещё задача, особенно если число воркеров меняется динамически. Здесь мешает не столько FIFO, сколько partition level parallelism, но это вещи связанные — порядок появляется как раз на потоке сообщений. Если бы был message level parallelism (и, соответственно, не было бы порядка), количество воркеров и партиций никак не были бы связаны.
В БД в любом случае держать не надо, при росте нагрузки там неминуемо будут проблемы и придётся куда-то мигрировать. Поэтому даже при небольших RPS в тех местах, где нужна очередь, лучше сразу использовать очередь — это асинхронные взаимодействия, постановка задач, пересылка сообщений без необходимости получения ответа и т.п. Жить и развиваться будет сильно проще. Тем более что очередь использовать очень просто, это как раз таблички в БД нужно «городить» — придумывать схему, как-то её поддерживать и развивать, мигрировать, делать какую-то библиотеку для работы с этими табличками, наступать примерно на все грабли разработчиков очередей (в статье как раз раскрываются некоторые примеры таких граблей), потом упереться в то, как это всё добро на MySQL тормозит, полгода оптимизировать и понять, что написали своё подобие сервиса очередей. Кому всё это нужно в 2019 году — непонятно.
А в YMQ три основных вызова — SendMessage, ReceiveMessage и DeleteMessage. Предельно просто и понятно, подставляешь endpoint и реквизиты для доступа и вперёд.
Сравнивать FIFO-очередь и Kafka бессмысленно, FIFO-очереди YMQ не ставят себе задачу заменить Kafka, в сценариях, где нужно передавать эти десятки тысяч RPS упорядоченных данных, нужно использовать заточенные под это инструменты — так, внутри Яндекса мы для передачи упорядоченных потоков тоже не используем FIFO-очереди YMQ, а используем Logbroker — наша собственная разработка система передачи данных, тоже поверх Yandex Database, и горизонтально масштабируется на огромные значения RPS и MB/s.
Даже стандартные очереди YMQ (которые уже сейчас при необходимости поддерживают те же десятки тысяч RPS в одну очередь, и это не предел оптимизаций) не стоит сравнивать с Kafka — функции и задачи у этих систем немного разные.
В простых сценариях, где сообщения не упорядочены и не требуется поддержка exactly once, нужно просто брать YMQ и не морочиться с нумерацией сообщений, количеством партиций и т.п.
В будущем, возможно, мы как раз будем предоставлять Logbroker в Яндекс.Облаке в том или ином виде, вот тогда можно будет вернуться к сравнению с Kafka.
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 функций уже сейчас достаточно для реализации подавляющего большинства пользовательских сценариев. Если у вас есть сценарий, который не получается реализовать на нашем сервисе — напишите, это будет очень ценно.
В любом случае, это место мы тоже будем оптимизировать, если будет спрос на это. 30 RPS только выглядит скромно — это достаточно много, зачастую сервису нужно хорошо постараться, чтобы генерировать такой RPS, в большинстве случаев сервисам хватает единиц RPS.
yc.Вообще API YMQ настолько тривиален, что можно и так сразу пользоваться. :) Настраивать ничего не нужно, очередь создал и вперёд.
Что касается мимикрирования под другие сервисы — это интересная и правильная мысль, но тут зачастую просто реализацией клиента не обойдёшься, у других очередей другой набор функций, просто так не полетит. Либо надо на недостающие функции бросать исключения — и тогда далеко не все приложения протестируешь, либо доделывать недостающее в самом сервисе — а это уже дополнительное время на разработку. Но мы думаем в этом направлении.
А также YMQ можно использовать в фреймворках и библиотеках, которые поддерживают SQS как транспорт — например, в Celery, Laravel и т.п.
At most once: если ни одна операция в системе не ретраится, как, при условии корректной реализации всех компонентов, могут появиться дубли? Я не говорю про систему без сбоев, только лишь про то, что в компонентах нет багов, которые приводят к дублям.
At least once: если каждый компонент ретраит запросы до победного конца, где могут появиться потери? При условии отсутствия бажных/чересчур оптимистично настроенных компонентов вроде стораджей, которые возвращают успех, никуда толком не сохранив.
Можно пример, который продемонстрировал бы, почему обеспечение этих поведений реализовать сложнее, чем описанные выше стратегии?
А почему так сложно гарантировать at most once? И что за грабли в at least once? Разве стратегии «никогда не ретраить»/«ретраить до упора» не обеспечивают поведения at most/at least once?