Интересное на Ruby Russia 2022

Видео с конференции Ruby Russia уже здесь. В этом году мероприятие проходило в онлайн-формате и собрало вместе рубистов не только из России, но и за её пределами. Сегодня мы расскажем, что было интересного в докладах спикеров и о том, какие темы сейчас наиболее актуальны.

Сценарии автотестов на русском

Удивительно, но факт. Самая популярная платформа для автоматизации тестирования Cucumber создавалась в качестве дополнения к методологии разработки BDD (Behavior-driven development), успешно применяемой многими Agile-командами. По замыслу автора этот инструмент должен был стать связующим звеном между бизнес-аналитиками, разработчиками и тестировщиками.

Основная фишка Cucumber — использование естественного языка для написания сценариев тестирования. Например, если команда разработки русскоязычная, то будет разумно использовать русский язык. Такой подход сразу даёт +100 к восприятию. Если какой-либо тест завершается неудачей, то использование нативного языка позволяет сразу понять, в каком месте искать проблему.

Ещё одной заслугой использования родного языка — одна команда легко может передать код на поддержку другой. Cucumber активно применяется в крупных компаниях с множеством команд разработки. Яркий пример — Альфа-Банк. Там Cucumber стал прекрасным мостиком между бизнесом и разработкой. У них создано более тысячи описаний тестов на русском языке, которые значительно облегчают коммуникацию между командами.

Хотите подробностей? С нами поделилась опытом Елена Рыжкова, ведущий инженер по автоматизированному тестированию ПО в Альфа-Банке:

WebSockets vs Long polling

Когда что-то должно работать в реальном времени, возникает масса нюансов из-за существующих ограничений. Это и количество одновременно открытых соединений, и особенности протоколов.

Для обмена данными в real-time, серверу надо держать открытое соединение с браузерами клиентов. Для этого существует несколько вариантов. Самый простой — WebSockets. Фактически это отдельный протокол поверх TCP, созданный специально для этой цели.

Звучит вроде круто, но на деле есть неочевидные моменты. Если смотреть со стороны клиента, то есть неприятное ограничение в 256 подключений по WebSocket на все вкладки браузера. Кажется, что этого вполне достаточно. Но люди ведь открывают по сотне вкладок, новое соединение по WebSocket может просто не состояться.

Кроме того, мы вообще никак не можем гарантировать, что сообщение по Websocket доставлено. Сбалансировать нагрузку между разными серверами внезапно становится проблемой. А уж про мониторинг и говорить нечего. Но не так страшен чёрт, как его малютка малюют. Александр Уланов, Senior Full Stack Engineer из Learning Tapestry, Inc в своём выступлении рассказал, что их спас Long polling (LP), предшественник WebSockets:

Эту технологию во времена первой версии протокола HTTP недолюбливали. Причина — ограничение в 6 параллельных соединений на один домен. Но с приходом HTTP2 появилось мультиплексирование и проблема ушла. Были разработаны мощные инструменты, задействующие LP, например, MessageBus. Работающий в качестве middleware, он не только снимает ограничения, используя технику Rack Hijack, но и добавляет возможности мониторинга и балансировки нагрузки. Если вы ещё не слышали об этом, то советуем попробовать.

Как подружиться с Push-уведомлениями

SMS-уведомления — это хорошо и удобно… но дорого. Бизнес всегда стремится снизить издержки и переходит на практически бесплатные push-уведомления. Но это легко сделать только на бумаге. Реальность же встречает нас целой пачкой «подводных камней». Например, push-уведомления не имеют такой опции, как подтверждение доставки и легко могут потеряться по дороге. О последовательности доставки нескольких уведомлений речи также не идёт.

Кажется, что задача сводится к работе с двумя крупным экосистемами — Apple iOS и Google Android. А вы помните, что Huawei отделился от сервисов Google? Для доставки push на эти устройства требуется использовать их собственный сервис. Так что нужно будет либо писать больше кода, чтобы научить бэкенд отправлять данные в этот сервис, либо воспользоваться услугами агрегаторов.

Агрегаторы решают сразу две задачи. Во-первых, можно писать меньше кода и не разбираться в особенностях каждой платформы. Во-вторых, push-уведомления — отличный маркетинговый инструмент, а значит агрегатор может выполнять роль стыка между отделом маркетинга и конечными клиентами. Значит при выборе агрегатора надо не только смотреть на возможность отправки push на разные платформы, но и на интеграции с маркетинговыми CRM.

Это лишь малая часть подробностей, которыми с нами поделился Георгий Быков, Backend Developer в igooods:

Соколиный взгляд на Puma

Резкий рост нагрузки у современных сервисов давно стал обыденностью. Самый простой вариант решения для кластеров Kubernetes — автоскейлинг. Нужно больше золота. Нужно построить зиккурат. Но насколько эффективно расходуются ресурсы? Не выйдет ли, что зря тушим пожар нагрузки деньгами? В Самокате провели целое детективное расследование.

Ключевым для них было достижение показателя в 300 RPS на каждый разворачиваемый инстанс. В качестве веб-сервера использовалась Puma, а тест максимально соответствовал реальному профилю нагрузки (авторизация и затем запрос к БД). После первого же прогона теста были получены удручающие результаты. Половина тестовых запросов была отброшена с кодами ошибок 502 и 503.

Проанализировали логи, стало ясно, что при показателе в 170 RPS система справлялась без ошибок, но как только JMeter увеличивал количество потоков для достижения целевого значения в 300 RPS — резким скачком вырастала latency. Затем количество ошибок также резко возрастало, а потом телеметрия вообще обрывалась и восстанавливалась спустя некоторое время. Стало ясно, что выполнялся перезапуск пода.

Глянули на потребление CPU — оно поднималось максимум на 50 процентов от установленного лимита. Потребление оперативной памяти не отклонялось от нормы. Была высказана гипотеза, что сама архитектура веб-сервера становится источником проблем. Puma работает с потоками, переключая контекст между ними через равные промежутки времени. Тестовая нагрузка генерировала синхронные вызовы, которые блокировали потоки, тем самым впустую теряя кванты времени.

Проведённый тест без какого-либо ΙΟ показал, что гипотеза про блокирование потоков была верной. Увеличение количества потоков параметром RAILS_MAX_THREADS не принесло никаких результатов, лишь отсрочило момент перезапуска пода. Получалось, что вначале забивалась очередь запросов Puma, затем забивался socket backlog. Пакеты live probe от Kubernetes, проверяющие жив ли сервис, также оказывались в забитом бэклоге. Оркестратор считал, что сервис умер и перезапускал сбойнувший под.

Тот же самый тест, проведённый на другом веб-сервере Falcon окончательно развеял сомнения. В тех же самых условиях ни одной ошибки при желаемом уровне в 300 RPS не зафиксировано, а latency уменьшилась вдвое. Ни одна строчка кода не пострадала. Но этого показалось мало и было принято решение выжать из Falcon всё возможное. О результатах вы сможете узнать из доклада Александра Шермана, Product Teamlead компании Самокат.

Все видеозаписи Ruby Russia 2022 уже в открытом доступе.

 

Митапы