Создание инфраструктуры для федеративного обучения может быть сложной задачей по ряду причин:
- Сложность инфраструктуры. Для федеративного обучения требуется сложная инфраструктура, включающая несколько компонентов, таких как локальные источники данных, центральный сервер и протоколы связи между арендаторами и центральным сервером. Управление всеми этими компонентами может быть затруднено, и модульная архитектура Terraform может помочь упростить этот процесс.
- Зависимость от платформы. Инфраструктура федеративного обучения может работать на различных платформах, включая облачные среды и локальную инфраструктуру. Terraform может помочь управлять этими зависимостями от платформы, но для правильной настройки инфраструктуры требуются специальные знания.
- Конфиденциальность данных. Федеративное обучение предназначено для защиты конфиденциальности данных за счет их локального и зашифрованного хранения. Однако управление ключами шифрования и обеспечение безопасности данных может быть проблемой. Terraform может помочь в управлении ключами шифрования и контролем доступа, но для этого требуется знание передовых методов шифрования и параметров конфигурации.
- Соображения безопасности. Федеративное обучение предполагает передачу данных между устройствами и центральным сервером, что может представлять угрозу безопасности, если данные не защищены должным образом. Несмотря на то, что передаваемые данные уже собраны и обычно зашифрованы, обеспечение дополнительного уровня безопасности на уровне связи по-прежнему важно для обеспечения конфиденциальности на всех уровнях. Terraform может помочь справиться с проблемами безопасности, но для этого требуется знание лучших практик безопасности и параметров конфигурации.
- Непрерывная интеграция и развертывание. Инфраструктура федеративного обучения должна регулярно обновляться и развертываться для поддержания производительности и безопасности. Для этого требуется надежный конвейер непрерывной интеграции и развертывания (CI/CD), который может быть сложным в настройке и обслуживании из-за сложности имеющейся архитектуры.
Архитектура
Глобальная архитектура разделена на четыре основные части, состоящие из одного исследовательского центра и трех больниц (арендаторов). Вся архитектура реализована в Azure Cloud. Каждый арендатор будет иметь одинаковую архитектуру, обеспечивающую конфиденциальность, в собственных подписках Azure Cloud. Архитектура написана на terraform, что позволяет нам очень легко масштабировать проект для большего количества арендаторов. Для обеспечения конфиденциальности и безопасности данных четвертая подписка будет действовать как центральный узел (исследовательский центр), отвечающий за сбор информации (модели и анализ данных) и предоставление окончательной модели. Такой подход к федеративному обучению позволяет нам обучать модель на данных с нескольких узлов, при этом данные никогда не покидают территорию арендатора и, таким образом, не раскрывают конфиденциальную информацию.
Основные компоненты архитектуры представлены ниже:
Центральный узел: Исследовательский центр
Исследовательский центр состоит из одной подписки на Azure. В рамках подписки существует одна группа ресурсов. Группа ресурсов состоит из виртуальной машины и учетной записи хранения. В учетной записи хранения есть несколько контейнеров, один из которых является сервером контейнеров, а остальные — клиентом контейнеров (по одному для каждого клиента). Каждый клиент-контейнер будет хранить параметры моделей и файлы конфигурации, чтобы обеспечить обучение моделей и отслеживание результатов на узлах-арендаторах.
Клиентские узлы: больницы
Есть три больницы, каждая из которых имеет собственную подписку Azure. Подписка Azure — это способ для организаций управлять службами Azure и оплачивать их. В каждой подписке Azure есть две отдельные группы ресурсов. Группа ресурсов — это контейнер, содержащий связанные ресурсы Azure. Первая группа ресурсов для каждой больницы содержит виртуальную машину с двумя контейнерами. Первый контейнер — это клиентский контейнер Docker, представляющий собой легкую портативную программную платформу для создания, упаковки и запуска приложений. Второй контейнер — это сервер контейнеров, представляющий собой программу, которая управляет контейнерами и обеспечивает связь между ними. Эта группа ресурсов открыта для связи и передачи данных к центральному узлу.
Вторая группа ресурсов для каждой больницы состоит из учетной записи хранения, в контейнере которой хранятся личные данные. Личные данные, хранящиеся в контейнере учетной записи хранения, могут включать сведения о пациентах, медицинские записи и другие конфиденциальные данные, которые следует защищать. Эта группа ресурсов содержит конфиденциальные данные, доступные только через первую группу ресурсов по соображениям безопасности.
В целом, такая конфигурация инфраструктуры позволяет больницам безопасно хранить конфиденциальные данные и управлять ими, а также обеспечивает масштабируемую и гибкую платформу для своих приложений и услуг.
Пиринг виртуальной сети
Существует двусторонний пиринг между центром и тремя другими арендаторами. Виртуальная сеть (VNet) — это основной строительный блок инфраструктуры Azure. Это логически изолированные сети, которые позволяют безопасно подключать ресурсы Azure друг к другу, к Интернету и локальным сетям. С помощью виртуальных сетей Azure мы создали частную и безопасную сеть в облачной среде, точно такую же, как у вас в локальной среде.
В этом случае между центральной больницей и тремя другими больницами существует двусторонняя виртуальная сеть. Это означает, что центральная больница может взаимодействовать с тремя другими больницами через пиринговое соединение виртуальной сети и наоборот. Однако виртуальные сети трех других больниц напрямую не взаимодействуют друг с другом. Это означает, что они не могут взаимодействовать друг с другом через пиринговое соединение виртуальной сети.
Эта архитектура позволяет обмениваться данными между центральной больницей и тремя другими больницами, а также гарантирует, что данные других больниц останутся конфиденциальными и безопасными. Если другим больницам необходимо общаться друг с другом, им придется делать это с помощью других средств, которые в данном случае полностью ограничены.
Панель управления для конечного пользователя
Для разных целевых пользователей доступны две панели мониторинга Power BI:
- Одна панель инструментов предназначена для группы специалистов по обработке и анализу данных больниц, чтобы они могли сравнивать свои данные с глобальными данными и статистикой из других больниц.
- Приборная панель для исследовательского центра, позволяющая отслеживать производительность различных моделей; просматривать результаты и статистику и сравнивать каждый результат из трех разных больниц, не получая доступа к реальным данным.
Наше решение
Для решения упомянутых выше проблем и реализации архитектуры мы использовали три основных компонента: Terraform, Docker и конвейер CI/CD (Github), что позволяет нескольким сторонам совместно создавать сложные модели машинного обучения, не делясь своими данными.
Терраформ
Terraform — это инструмент, который позволяет вам создавать и управлять вашей инфраструктурой как кодом, упрощая развертывание и удаление сред по мере необходимости и сохраняя все конфигурации вашей инфраструктуры в централизованном месте. В этом разделе мы кратко упомянем шаги, предпринятые для использования Terraform, инфраструктуры с открытым исходным кодом в качестве инструмента кода, для запуска виртуальных машин в группах ресурсов в Azure для реализации инфраструктуры федеративного обучения:
- Первым шагом была настройка среды Azure. Мы создали группу ресурсов для хранения всех необходимых ресурсов, включая виртуальные машины, сеть и хранилище (как для центрального узла, так и для клиентского узла). Эта группа ресурсов служила нашим центральным расположением для всех конфигураций инфраструктуры.
- Затем мы определили конфигурации наших виртуальных машин в Terraform. Мы указали размер виртуальной машины, образ операционной системы и сетевую конфигурацию. Мы также определили конфигурацию хранилища для виртуальной машины, включая размер и тип диска.
- После того, как мы определили конфигурации наших виртуальных машин, мы использовали Terraform для запуска виртуальных машин в нашей группе ресурсов.
Для описанных выше действий использовался поставщик azurerm от terraform.
Докер
Docker также был ключевой частью нашей реализации федеративного обучения. В Docker мы упаковали модели машинного обучения и все их зависимости в переносимый контейнер, который затем можно развернуть в любой среде, поддерживающей Docker. Это упростило совместное использование и развертывание наших моделей, а также обеспечение их согласованной работы в различных средах. Кроме того, Docker помог улучшить масштабируемость нашей инфраструктуры федеративного обучения, поскольку мы можем легко запускать новые контейнеры для обработки возросшей нагрузки.
В нашей федеративной инфраструктуре обучения мы обнаружили, что Docker помог нам оптимизировать наши рабочие процессы, улучшить согласованность и более эффективно масштабировать.
Мы использовали следующие шаги для использования Docker в нашей платформе федеративного обучения: контейнеризация моделей и кода машинного обучения (NVFlare и MLFlow), создание образов Docker, загрузка образов Docker в реестр, развертывание контейнеров Docker как на центральном узле, так и в качестве клиентских узлов и, наконец, мониторинг и отладка контейнеров.
Конвейер CI/CD
Наш конвейер CI/CD также сыграл важную роль в успехе нашей реализации федеративного обучения. Благодаря непрерывной интеграции и непрерывному развертыванию мы можем гарантировать, что любые изменения в нашем коде и инфраструктуре будут тщательно протестированы перед их развертыванием в рабочей среде. Это помогло снизить риск ошибок и простоев, а также повысить общую надежность нашей федеративной инфраструктуры обучения.
Мы использовали GitHub Actions, мощный и гибкий инструмент для автоматизации рабочих процессов программного обеспечения для наших конвейеров CI/CD. Он позволяет автоматизировать сборку, тестирование и развертывание вашего кода согласованным и воспроизводимым способом. GitHub Actions также обеспечивает интеграцию с популярными инструментами и службами, такими как Azure и Docker, и многими другими, что делает его идеальным выбором для нашего варианта использования.
На нашем GitHub есть обширная документация по конвейерам CI/CD, не стесняйтесь обращаться к ней, чтобы узнать подробности.
Отражение вызовов
При разработке инфраструктуры мы столкнулись с рядом проблем. Некоторые из их размышлений кратко изложены ниже:
Инфраструктура в Terraform. Одной из проблем, с которыми мы столкнулись, было определение сетевой конфигурации для наших виртуальных машин в трех разных больницах. Мы должны были обеспечить, чтобы каждая виртуальная машина имела уникальный IP-адрес и чтобы с ними нельзя было связаться другими способами. Мы решили эту проблему, определив одну виртуальную сеть и подсеть для нашей группы ресурсов (для больницы) и настроив наши виртуальные машины на использование только этих сетевых параметров. Основная проблема заключалась в том, чтобы обеспечить доступ к учетной записи хранения только для виртуальной машины. Решением этой проблемы было создание частной конечной точки для учетной записи хранения в той же подсети, что и виртуальная машина, и обеспечение того, чтобы никакие другие компьютеры (виртуальные машины) имеет доступ к этой подсети.
Docker: доставка установочных файлов NV Flare в больницу перед запуском контейнера была проблемой, которую мы решили, создав скрипт, проверяющий наличие файлов.
CI/CD: мы столкнулись с двумя проблемами, связанными с конвейером: обеспечение работы входа без пароля и создание пиринга виртуальной сети между подписками, поскольку Terraform одновременно запускает только одну подписку. Чтобы обеспечить вход без пароля, мы использовали OpenID connect. Для пиринга виртуальной сети мы создали дополнительный сценарий Terraform, который запускается после установки группы ресурсов и виртуальных машин и успешно завершает пиринг виртуальной сети.
Начать
В этом разделе мы проведем вас через процесс настройки развертывания федеративного обучения с использованием Trunk Based Development.
Trunk Based Development (TBD) — это методология разработки программного обеспечения, которая фокусируется на поддержании одной ветви в системе управления версиями (обычно называемой «основной») и поощряет частые слияния функциональных ветвей в основную ветвь. Мы считаем, что этот подход хорошо подходит для развертывания федеративного обучения, поскольку он упрощает совместную работу и уменьшает конфликты слияния, которые могут отнимать много времени и раздражать.
Чтобы начать развертывание федеративного обучения, вы можете разветвить собственную копию репозитория dataroots/federated-learning-project. Этот репозиторий содержит весь необходимый код для настройки инфраструктуры в Azure для рабочего процесса федеративного обучения. Получив копию репозитория, вы можете создать новую ветку функций. Убедитесь, что имя вашей ветки начинается с feature-. После того, как вы создали новую ветку функций, вы можете начать вносить изменения в код. Чтобы поддерживать качество и согласованность кода, мы предоставили набор перехватчиков перед фиксацией, которые запускаются автоматически, когда вы фиксируете изменения локально. Эти хуки можно включить, установив предварительную фиксацию и выполнив следующую команду:
pip install pre-commit
pre-commit install
После того, как хуки будут установлены, они будут работать с любыми новыми файлами, которые вы фиксируете, гарантируя, что код, который вы отправляете на удаленный сервер, соответствует базовому уровню качества. Если вы хотите запустить хуки для всей вашей кодовой базы, используйте следующую команду:
pre-commit run --all-files
Когда вы будете готовы объединить свои изменения обратно в основную ветку, вам нужно создать запрос на включение на вкладке Запросы на включение в Github. Перед слиянием важно убедиться, что ваш код работает правильно и правильно отформатирован. Мы предоставили конвейер CI/CD, который запускается автоматически при создании запроса на вытягивание. Ваши изменения будут объединены в основную ветку только в том случае, если конвейер пройдет успешно, гарантируя, что кодовая база останется стабильной и надежной.
Наконец, репозиторий развертывания федеративного обучения включает сценарий развертывания Terraform, который позволяет настроить необходимую инфраструктуру в Azure. Репозиторий включает в себя три среды (dev, mvp и prod), предназначенные для облегчения разработки и развертывания объединенных рабочих процессов обучения. Среда разработки предназначена для тестирования и может быть уничтожена несколько раз в день, в то время как среда mvp ориентирована на создание минимально жизнеспособного продукта, демонстрирующего базовую функциональность. Среда prod предназначена для конечного продукта.
Заключение
В заключение, федеративное обучение — это захватывающая разработка в области машинного обучения, и Dataroots успешно реализовала для него облачную инфраструктуру, используя комбинацию Terraform и Docker, а также надежный конвейер CI/CD. Имея эту инфраструктуру, мы можем продолжать исследовать новые приложения для федеративного обучения и расширять границы возможного в области науки о данных.
Чтобы получить краткое представление о нашем примере использования, облачной среде для федеративного обучения, обратитесь к приведенным ниже блогам. У нас также есть подробное руководство по структуре MLOps для федеративной среды обучения, которой вы можете следовать.
Вам также может понравиться
Терраформирующая Снежинка ❄️ — Лидия-Ана-Мария Бачу
