Atlassian признала проблемы с новыми инструментами миграции Jira в облако, которые оказались медленнее старых. Исправив узкие места и ошибки, компания заявляет, что новый инструмент готов к работе с крупными инсталляциями. — theregister.com
Компания Atlassian признала, что инструменты, разработанные для миграции пользователей Jira в облако, на самом деле работали медленнее, чем старый код, выполнявший ту же задачу, и что ее усилия по ускорению также столкнулись с проблемами производительности.
Австралийская компания, разрабатывающая ПО для совместной работы, в прошлом году решила прекратить поддержку своих продуктов для дата-центров и перевести пользователей на облачные аналоги. Это решение было принято через пять лет после того, как Atlassian отказалась от своих серверных продуктов.
Как объяснил старший инженер-программист Приянш Джайн в посте во вторник, Atlassian располагает командой по миграционным платформам, которая создала конвейер миграции на архитектуре, управляемой через API.
«Однако эта архитектура оказалась блокирующей и менее масштабируемой, а клиенты в нашем конвейере миграции были слишком крупными для миграции с использованием этого подхода», — написал Джайн.
Поэтому Atlassian разработала новую архитектуру миграции, которая, по словам Джайна, работает «упорядоченным образом и изящно избегает узких мест и проблем масштабируемости, существовавших в архитектуре, управляемой API». Компания выпустила ее для клиентов, которым требовалось перенести инсталляции Jira до 20 000 рабочих мест.
Но когда Atlassian провела тестирование, компания обнаружила, что новый конвейер миграции занимает примерно на 34 процента больше времени, чем предыдущие инструменты, а общая пропускная способность обработки элементов работы упала примерно на 60 процентов по результатам синтетических тестов».
«Для клиентов с десятками тысяч пользователей и огромными портфелями проектов исправление этого стало бескомпромиссным», — написал Джайн.
Исправление включало множество настроек.
«Мы провели бенчмаркинг различных размеров и конфигураций рабочих узлов. Изначальная настройка работала на небольших узлах; их масштабирование дало значительно лучшую пропускную способность, сбалансировав стоимость и производительность», — говорится в посте Джайна. Он утверждает, что Atlassian также ужесточила правила автоматического масштабирования, чтобы рабочие узлы быстро запускались при скачках использования ЦП, поддерживая высокую пропускную способность с самого начала».
Atlassian также «обнаружила некорректные настройки таймаута опроса. Обработка наших элементов работы часто занимала 60–120 секунд, но таймаут потребителя был установлен на 40 секунд. Это означало, что пакеты повторялись в процессе обработки, что приводило к потере работы и снижению пропускной способности на 30–40 процентов. Установка реалистичного таймаута — 300 секунд — немедленно решила проблему».
После множества исправлений ошибок у Atlassian появился инструмент, который обеспечил улучшение медианной пропускной способности для крупных миграций с несколькими проектами примерно в 6 раз.
Масштабирование
В посте Джайна не указано, сколько времени потребовалось Atlassian, чтобы исправить ситуацию, но говорится, что компания также начала работу над инструментами для миграции еще более крупных инсталляций Jira — до 50 000 рабочих мест.
«Задача была ясна: мигрировать тысячи проектов (примерно 6500) и до ~7,5 миллионов элементов работы менее чем за 36 часов, при этом фаза импорта должна уложиться примерно в 24 часа», — сообщил Джайн, добавив: «Мы не могли просто „выкрутить ручки на максимум“ и надеяться на лучшее».
Такая мудрость, безусловно, редка.
Но вернемся к главному: Джайн подробно описывает усилия по созданию нового инструмента, которые столкнулись с такими проблемами, как медленный старт миграций, набирающих скорость только через 45–60 минут, поскольку Atlassian привязала логику автоматического масштабирования к нагрузке на ЦП. Компания исправила это с помощью того, что Джайн описал как «механизм для упреждающего обеспечения работы минимального количества рабочих узлов при запуске значительной миграции. Импорт начинался на полную мощность, сокращая общее время миграции на 30–60 минут».
Это изменение пошло на пользу и самой Atlassian, поскольку позволило компании поддерживать меньший базовый объем ресурсов и масштабироваться только при необходимости — сократив ежемесячные расходы на инфраструктуру до 65 000 долларов.
Другая проблема заключалась в том, что крупные миграции вызывали ошибки API, «поскольку реплики чтения нашего кластера баз данных с трудом справлялись с высокой нагрузкой на запись».
Atlassian исправила все эти проблемы и на этот раз подтвердила готовность инструмента обслуживать клиентов с 50 000 рабочих мест.
«Сквозная система мигрировала более 6 тысяч проектов за один день. Теперь мы готовы обслуживать клиентов Jira масштаба 50K», — воодушевленно заявил Джайн. И на этот раз без деградации производительности. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Simon Sharwood