Рекомендации по приложениям Databricks

На этой странице перечислены важные рекомендации по разработке и запуску приложений Databricks. Эти рекомендации сосредоточены на требованиях к безопасности, производительности и платформе.

Общие рекомендации

• Используйте собственные функции Azure Databricks для обработки данных. Вычислительные процессы приложения оптимизированы для визуализации пользовательского интерфейса. Используйте Databricks SQL для запросов и наборов данных, заданий Lakeflow для пакетной обработки и обслуживания моделей для рабочих нагрузок вывода ИИ. Выгрузите тяжелую обработку данных в эти службы, чтобы избежать проблем с производительностью. Протестируйте приложение в ожидаемых условиях загрузки, чтобы убедиться, что оно соответствует вашим требованиям.

• Реализуйте грациозную обработку завершения работы. Приложение должно завершить работу в течение 15 секунд после получения SIGTERM сигнала, иначе оно будет принудительно завершено с использованием SIGKILL.

• Избегайте привилегированных операций. Приложения выполняются как не привилегированные пользователи и не могут выполнять действия, требующие повышенных разрешений, таких как корневой доступ. Невозможно установить пакеты на уровне системы с помощью таких диспетчеров пакетов, как apt-get, yumили apk. Вместо этого используйте пакеты Python из PyPI или Node.js пакетов из npm для управления зависимостями приложения.

• Общие сведения о сетевых сетях, управляемых платформой. Запросы пересылаются через обратный прокси-сервер, поэтому приложение не может зависеть от источника запросов. Azure Databricks обрабатывает завершение TLS и требует от приложений поддержки открытого текста HTTP/2 (H2C). Не реализуйте пользовательскую обработку TLS.

• Привязка к правильному узлу и порту. Приложение должно прослушивать 0.0.0.0 и использовать порт, указанный в переменной DATABRICKS_APP_PORT среды. Дополнительные сведения см. в переменных среды .

• Свести к минимуму время запуска контейнера. Упрощение логики инициализации для уменьшения задержки холодного запуска. Избегайте блокировки таких операций, как установка больших зависимостей или внешние вызовы API во время запуска. Загружайте ресурсоемкие ресурсы только при необходимости.

• Войдите в stdout и stderr. Azure Databricks записывает журналы из стандартных выходных данных и потоков ошибок. Используйте их для всех журналов, чтобы убедиться, что журналы отображаются в пользовательском интерфейсе Azure Databricks. Избегайте записи журналов в локальные файлы.

• Обработайте непредвиденные ошибки корректно. Реализуйте глобальную обработку исключений, чтобы предотвратить сбои от неуловимых ошибок. Возвращайте корректные ответы об ошибках HTTP без предоставления трассировки стека или конфиденциальных данных.

• Закрепление версий зависимостей. Используйте точные номера версий в файле requirements.txt, чтобы обеспечить согласованность окружений во всех сборках. Избегайте использования незакреченных или последних версий пакетов.

• Проверка и очистка входных данных пользователей. Всегда проверяйте входящие данные и очищайте их, чтобы предотвратить атаки на внедрение или неправильные входные данные, даже во внутренних приложениях.

• Используйте кэширование в памяти для дорогостоящих операций. Кэш часто используемых данных, таких как результаты запроса или ответы API, чтобы уменьшить задержку и избежать избыточной обработки. Используйте functools.lru_cache, cachetools или аналогичные библиотеки, и внимательно определяйте области кэша в многопользовательских приложениях.

• Используйте асинхронные шаблоны запросов для длительных операций. Избегайте синхронных запросов, ожидающих завершения операций, что может привести к тайм-ауту. Вместо этого выполните начальный запрос, чтобы запустить операцию, а затем периодически опрашивайте состояние ресурса или конечную точку, чтобы проверить статус завершения.

Рекомендации по обеспечению безопасности

• Следуйте принципу наименьших привилегий. Предоставьте только разрешения, необходимые для каждого пользователя или группы. Используйте CAN USE вместо CAN MANAGE, если полный контроль не требуется. Ознакомьтесь с рекомендациями по разрешениям.

• Тщательно выбирайте методы проверки подлинности. Используйте субъекты-службы, когда доступ к ресурсам и данным одинаковый для всех пользователей приложения. Реализуйте проверку подлинности пользователей только в рабочих областях с доверенными авторами приложений и кодом приложений, прошедших рецензирование, если приложение должно учитывать разрешения вызывающего пользователя.

• Используйте выделенные учётные записи службы для каждого приложения Не делитесь учетными данными служебного принципала между приложениями и пользователями. Предоставьте только необходимые минимальные разрешения, например CAN USE или CAN QUERY. Обновляйте учетные данные учетной записи службы, когда создатели приложений покидают вашу организацию. См. статью "Управление доступом приложений к ресурсам".

• Изоляция сред приложений. Используйте разные среды для разделения приложений разработки, тестирования и продуктовых приложений. Это предотвращает случайный доступ к рабочим данным во время разработки и тестирования.

• Доступ к данным с помощью соответствующих вычислений. Не настраивайте приложение для прямого доступа к данным или обработки данных. Используйте хранилища SQL для запросов, службы моделей для вывода ИИ и заданий Lakeflow для пакетной обработки.

• Управление секретами. Никогда не раскрывайте необработанные значения секретов в переменных среды. Используйте valueFrom в конфигурации вашего приложения и регулярно обновляйте секреты, особенно при изменении ролей команды. См. рекомендации.

• Минимизировать права доступа и фиксировать действия пользователя. При использовании авторизации пользователя запрашивайте только области, необходимые приложению, и регистрируйте все действия пользователей со структурированными записями аудита. Ознакомьтесь с рекомендациями по авторизации пользователей.

• Ограничение исходящего сетевого доступа. Разрешите только домены, необходимые приложению, например репозитории пакетов и внешние API. Используйте режим сухого запуска и журналы отказа для проверки конфигурации. Ознакомьтесь с рекомендациями по настройке политик сети.

• Следуйте рекомендациям по безопасному написанию кода. Параметризируйте запросы SQL для предотвращения атак внедрения и следования общим правилам безопасной разработки, таким как проверка входных данных и обработка ошибок. См. API выполнения инструкций: запуск SQL в хранилищах.

• Отслеживайте подозрительные действия. Регулярно просматривайте журналы аудита для необычных шаблонов доступа или несанкционированных действий. Настройте оповещения для критических событий безопасности.