Разработка распределенной платформы для парсинга веб-страниц, такой как Apify, сопряжена с некоторыми уникальными проблемами по сравнению с созданием монолитного приложения. Поскольку через систему ежедневно проходят десятки взаимосвязанных сервисов и терабайты данных, оптимизация нашей локальной среды разработки имеет решающее значение для команды инженеров Apify.
В этом обзоре изнутри я расскажу, как мы решили некоторые из этих проблем, чтобы обеспечить быструю итерацию и сотрудничество, поскольку наша платформа продолжает покорять новые высоты. Я расскажу о нашем стеке разработки, управлении инфраструктурой, стратегиях тестирования и многом другом, основываясь на своем собственном опыте опытного инженера по парсингу веб-страниц.
Почему местное развитие имеет значение
Поскольку платформа Apify теперь обрабатывает миллиарды веб-запросов в месяц на тысячах серверов, повышение скорости разработки стало более важным, чем когда-либо. Нам необходимо свести к минимуму трения, чтобы быстро тестировать изменения, прототипировать функции и исправлять ошибки, о которых сообщают наши пользователи.
Облачные среды, такие как GitPod, могут работать для некоторых приложений, но задержка в сети препятствует созданию желаемой жесткой обратной связи. Кроме того, разработка непосредственно на производственной инфраструктуре приводит к таким вредным привычкам, как оставление операторов отладки и ненужный вход в зафиксированный код.
Полностью имитируя нашу производственную среду локально, инженеры Apify могут оставаться в потоке. Мы получаем полный контроль над каждой зависимостью, устраняем изменчивость сети и предотвращаем загрязнение производственных ресурсов.
На протяжении многих лет мы вложили значительные средства в то, чтобы местное развитие стало первоклассным опытом. Результаты говорят сами за себя: наша команда, состоящая всего из 34 разработчиков, может выпускать улучшения несколько раз в неделю!
Распределенные сервисы
Платформа Apify представляет собой сложную оркестровку микросервисов и управляемых зависимостей:
Более 20 основных микросервисов – Apify API, автомасштабирование, планировщик, хранилище значений ключей и т. д.
10+ управляемых услуг – MongoDB, PostgreSQL, реестр Docker, RabbitMQ и т. д.
15+ сторонних сервисов – Redis, S3, DynamoDB, Algolia и т. д.
Каждая деталь имеет решающее значение для правильного функционирования системы. Даже небольшие изменения могут иметь каскадный эффект, поэтому необходимо комплексное тестирование.
Настройка полной экосистемы на местном уровне требует нескольких дней усилий на каждого разработчика. Мы потратили больше времени на борьбу с проблемами конфигурации, чем на написание кода. Было ясно, что нам нужно упростить ситуацию.
Войдите в стек разработчиков Apify
В 2019 году мы начали разработку внутреннего инструмента под названием Apify Dev Stack. Его целью было автоматизировать сложный процесс установки всей платформы Apify на машину разработчика.
Ключевые особенности Dev Stack:
- Docker Compose для определения и запуска служб
- Сценарии оболочки для управления жизненным циклом
- Готовые изображения за каждую управляемую услугу
- Автоматическое сопоставление портов из контейнеров на хост
- Моки для внешних сервисов как S3, Алголия и т. д.
После более чем года итераций любой инженер Apify теперь может запустить полную локальную среду с помощью одной команды:
dev-stack upПри этом создается более 30 контейнеров, представляющих все службы и зависимости, необходимые для перестройки, тестирования и запуска платформы.
По мере развития стека разработчиков наше среднее время установки сократилось с От 4 часов до 5 минут! Это улучшение в 85 раз.
Издевательство над внешними зависимостями
Dev Stack позволил нам консолидировать сложную цепочку зависимостей, необходимую для локальной разработки. Но мы по-прежнему полагались на множество внешних сервисов, которые было сложно или дорого запускать локально.
Мы смягчили это, разработав макеты реализации этих сервисов, которые точно имитируют реальные API:
- Эластичный MQ – API-совместимый макет AWS SQS
- Альголит – Наша собственная поисковая система, имитирующая Алголию.
- Поддельный S3 – Генерирует заранее подписанные URL-адреса с надлежащей поддержкой CORS.
Интеграция этих инструментов позволяет нам разрабатывать с уверенностью, что в производстве все будет вести себя одинаково.
При необходимости мы даже направим нашу промежуточную среду на макеты, чтобы протестировать системную интеграцию перед развертыванием в рабочей среде.
Оптимизация внутреннего цикла разработчика
Решив проблемы с инфраструктурой, мы сосредоточили свое внимание на оптимизации жесткой обратной связи с разработчиками, которая происходит десятки раз в день.
Небольшая неэффективность циклов кодирования/сборки/выполнения со временем может привести к значительному снижению производительности. Мы черпали вдохновение из проектов Meteor и create-react-app, чтобы создать сверхэффективный внутренний цикл.
Инкрементная компиляция TypeScript
За последние два года Apify постепенно переносила свою кодовую базу с JavaScript на TypeScript. Это привело к более строгой типизации и интеллектуальному анализу, но за счет более медленного выполнения кода.
Мы были полны решимости не мешать разработчикам компиляцию. Наше решение:
tsc – смотреть – Работает в фоновом режиме, отслеживая изменения источника. Затем он выполняет инкрементную перекомпиляцию только измененных файлов.
нодмон – Перезапускает процесс Node.js при каждом изменении выходных файлов JS.
одновременно – Запускает tsc и nodemon параллельно.
Это позволяет нашим разработчикам писать TypeScript как обычно, получая при этом обратную связь за доли секунды всякий раз, когда они нажимают кнопку «Сохранить». Бесшовный и производительный.
Замена горячего модуля Meteor
Для консоли Apify, созданной с использованием Meteor, мы включили превосходную поддержку горячей замены модулей Meteor.
Теперь, когда разработчики меняют код консоли, измененные файлы внедряются непосредственно в работающий экземпляр приложения. Никаких перезапусков или полных обновлений страниц не требуется!
Состояние сохраняется при всех изменениях, что позволяет быстро выполнять итерации потоков пользовательского интерфейса.
Тестирование компонентов с помощью Storybook
Мы активно используем Storybook для оптимизации изолированной разработки и тестирования компонентов пользовательского интерфейса React.
Storybook позволяет визуализировать компоненты со множеством вариантов реквизитов, стилей и т. д. Мы можем точно настраивать компоненты без необходимости подключать их в реальном приложении.
Например, при создании нового компонента Table мы можем определить такие истории:
- Состояние загрузки
- Пустое состояние
- С 5 рядами
- С 500 рядами
- Сортируемые столбцы
- Столбцы с изменяемым размером
- и так далее
Просмотр этих историй дает быструю информацию о том, как изменения влияют на различные варианты использования. Мы можем быстрее выявлять ошибки и предотвращать регрессии.
Строгое тестирование
Учитывая размер и сложность кодовой базы платформы Apify, комплексное тестирование на всех уровнях является обязательным.
Мы используем различные методы, такие как модульное, интеграционное, моментальное тестирование, сквозное (E2E), нагрузочное и мутационное тестирование, чтобы охватить наши базы.
Вот некоторые инструменты, на которые мы полагаемся:
Шутка – Для модульного и моментального тестирования. Снимки помогают защититься от регрессий.
Супертест – Интеграционное тестирование конечных точек и проверка ответов.
ТестКафе – Мощная среда E2E-тестирования браузеров. Мы тестируем полные потоки пользователей в консоли.
k6 – Сценарии загрузки и стресс-тестирования для проверки производительности в масштабе.
Stryker – Мутационное тестирование для обеспечения полного охвата крайних случаев.
Наш набор тестов дает нам уверенность в том, что каждое изменение будет вести себя ожидаемым образом в рабочей среде во множестве возможных сценариев. Тесты выполняются для каждого изменения кода в CI, чтобы предотвратить регрессии.
Мониторинг и Наблюдение
Для эффективной работы распределенной платформы необходима глубокая видимость всех систем. Мы используем такие инструменты, как:
- Прометей – Для сбора метрик и оповещения
- графана – Панели показателей
- Егерь – Распределенная трассировка
- Часовой – Мониторинг ошибок
- Datadog – Дополнительный мониторинг и анализ журналов
Во время локальной разработки мы передаем наши метрики и трассировку в экземпляр Prometheus, предоставляемый Dev Stack. Эти данные помогают нам оптимизировать производительность и быстро устранять проблемы.
В производстве мы направляем данные телеметрии в наши специализированные службы метрик и мониторинга. Это обеспечивает полную возможность наблюдения за состоянием и производительностью платформы Apify.
Автоматизация управления инфраструктурой
Инфраструктура Apify работает на тысячах серверов AWS. Управлять этим флотом вручную было бы невозможно.
Мы широко используем такие инструменты, как Terraform, Packer и Ansible, для автоматизации выделения и развертывания ресурсов.
Наши сервисы работают в группах автоматического масштабирования, управляемых модулями Terraform. Мы определяем топологию кластера и типы экземпляров в коде.
Образы серверов предоставляются с помощью Packer, а Ansible настраивает сеть, системные пакеты и многое другое.
С помощью одной команды мы можем развернуть на AWS отточенный стек, подготовленный для запуска платформы Apify.
Эти инструменты позволяют нашей небольшой операционной команде управлять инфраструктурой в значительных масштабах. При необходимости мы можем расширить мощности по всему миру за считанные минуты.
Присоединяйтесь к нашей полностью удаленной команде!
Этот пост лишь коснулся поверхности технологии, лежащей в основе платформы Apify и процесса разработки.
Если вам нравится решать сложные масштабные задачи, мы всегда ищем талантливых инженеров, которые присоединятся к нашей полностью удаленной команде!
Лично я считаю, что создание инструментов, расширяющих возможности людей, чрезвычайно полезно. Автоматизация веб-скрапинга позволяет людям любого происхождения получать доступ к веб-данным.
Подайте заявку, если вы хотите оказать влияние. Я рад ответить на любые вопросы!
