В современном мире CI/CD-процессов GitHub Actions стал одним из самых популярных инструментов для автоматизации сборок и тестирования. Однако несмотря на широкое распространение и удобство, многие пользователи сталкиваются с ограничениями, связанными с производительностью кэширования. Именно кэш играет ключевую роль в времени выполнения задач: медленные операции с кэшем напрямую замедляют весь процесс, ухудшая опыт разработчиков и увеличивая затраты. Поэтому тема оптимизации GitHub Actions cache вызывает особый интерес среди инженеров по всему миру. Недавно команда специалистов из Blacksmith Software решила полностью переосмыслить традиционный подход к кэшированию в GitHub Actions, взявшись за сложнейшую задачу – реверс-инжиниринг внутреннего протокола и построение быстрой альтернативы, работающей без какого-либо вмешательства со стороны пользователей.
Это позволило добиться повышения производительности кэша в 10 раз по сравнению с оригинальным сервисом GitHub, что является значительным техническим достижением и открывает новые горизонты для оптимизации CI/CD-пайплайнов. До начала работы над проектом у команды Blacksmith уже имелась собственная, более быстрая версия кэширования, но она была реализована через форки популярных первых действий GitHub. Основная проблема этой реализации заключалась в необходимости изменять рабочие файлы и поддерживать множество самостоятельных веток с изменённым кодом. Поддержка такого решения оказалась ресурсоёмкой и плохо масштабировалась, что заставило инженеров подумать об альтернативном подходе, который не требовал бы никаких правок от пользователей. Первым важным шагом стало детальное изучение внутренней архитектуры GitHub Actions cache.
Ранее GitHub использовал собственные действия, завязанные на устаревших технологиях, но недавно была совершена смена инфраструктуры: сервис перешёл на протокол Twirp, основанный на Protobuf, и стал использовать Azure Blob Storage SDK для хранения объектов. Такая радикальная смена архитектурных решений initially выглядела препятствием, но вскоре открыла новые возможности благодаря понятной схеме обмена данными в формате Protobuf. Использование искусственного интеллекта, в частности последних языковых моделей, сыграло ключевую роль в расшифровке взаимодействия API и создании протокольного описания. Это позволило инженерам полностью понять сигналы управления и логику взаимодействия с сервисом. Благодаря этому появился шанс спроектировать легковесную альтернативу, полностью совместимую с оригинальным протоколом, но гораздо более быструю и эффективную.
Другой сложностью стало несоответствие используемых хранилищ: GitHub применял Azure Blob Storage, а Blacksmith использовал MinIO — совместимый с AWS S3 объектный сервер. В реальном мире идеальная взаимозаменяемость облачных хранилищ пока недостижима, поэтому необходимо было тщательно проанализировать структуру сетевых запросов и адаптировать их под API MinIO без нарушения логики работы SDK и протоколов. Для полностью прозрачной работы без изменений со стороны пользователей была реализована система сети-прокси. Запросы виртуальных машин на операции с кэшем направлялись не к оригинальному хранилищу GitHub, а к локальным прокси-серверам. Внутри каждой VM запускался легковесный NGINX-прокси, перенаправляющий трафик на хост-уровень, где работал основной прокси с умной маршрутизацией.
Такой подход позволил ловить все кэш-запросы, фильтруя остальные обращения к сервисам GitHub, например, артефактам. NGINX был выбран за его готовность к установке на стандартные root filesystem и простоту настройки, что исключало сложности при развертывании и поддержке. Такой слой проксирования внутри ВМ также обеспечивал перехват запросов из Docker-контейнеров, что повышало совместимость и удобство для конечного пользователя. Однако одной перенаправляющей прокси недостаточно: Azure SDK ведёт себя иначе в зависимости от имени хоста, оптимизируя операции с blob только для доменов Azure. Чтобы повторить эти оптимизации, разработчикам пришлось создавать собственные URL-обертки, которые затем декодировались и трансформировались внутри прокси в стандартные S3-запросы, позволяя сохранять высокую производительность для загрузок и выгрузок.
Первой попыткой маршрутизации стала подмена DNS внутри виртуальных машин, но для корректного направления трафика требовалась дополнительная настройка iptables. Из-за большого числа VMs и нагруженности системы эти правила быстро стали источником нестабильности и конфликтов, что заставило команду перейти на nftables — современный и более структурированный фильтр пакетов Linux с поддержкой атомарных обновлений конфигураций и простым управлением правилами в рамках пространств имён. После интеграции этой продвинутой системы фильтрации вся релевантная передача данных проходила через прокси, что дало полный контроль над сетью и позволило построить собственный SDK для проксирования запросов между Azure Blob и AWS S3, идеально оптимизированный для потоковой передачи данных. Использование Go и его библиотеки io дало мощные инструменты для реализации пайплайнов данных с минимальным копированием, что критично на больших скоростях передачи множественных параллельных потоков. Любопытной особенностью кэширования является то, что в определённых сценариях лучше не пытаться получить кэш, если есть вероятность задержек из-за проблем с сетью.
Иногда отказ (кэш-мисс) и восстановление кэша с нуля дают лучший пользовательский опыт по сравнению с медленными попытками достать данные. Внедрение такой философии, основанной на реальных наблюдениях в процессе испытаний на масштабе, помогло создать максимально устойчивую систему. В процессе разработки чётко прослеживалась важность тестирования в реальных условиях, поскольку именно реальные пользовательские сценарии выносили на поверхность все тонкости работы c Protobuf, различия в интерпретации данных и несовместимости среди популярных действий от сторонних разработчиков. Вместо стремления к идеальной корректности с нуля команда приняла стратегию «обучения на ошибках», улавливая и исправляя проблемы по мере появления реальной нагрузки. Итогом всех усилий стал быстрый, полностью прозрачный для пользователя кэшинг с значительным опережением стандартного сервиса GitHub Actions.
Клиенты Blacksmith отмечают увеличение скорости операции с кэшем до десяти раз и заметное уменьшение времени работы CI-процессов без необходимости менять ни единую строку в своих workflow-файлах. Данный кейс иллюстрирует, что глубокое понимание внутренних механизмов, грамотное применение современных технологий проксирования и умелое использование инструментов разработки позволяют не просто догнать, а значительно превзойти существующие решения. Помимо технической изящности, этот подход приносит очевидные бизнес-преимущества — уменьшение затрат на инфраструктуру, улучшение пользовательского опыта и рост эффективности команд разработчиков. В конечном счёте, проект Blacksmith по реверс-инжинирингу и ускорению GitHub Actions cache — это наглядный пример того, как инновационный взгляд на давно знакомую проблему в сочетании с современными технологиями может преобразить рабочие процессы и задать новые стандарты качества в индустрии CI/CD.
