Изоляция ИИ в .NET-платформе: упавший Python-сервис дал HTTP 503, а не отказ всего API

Простой эксперимент хорошо показывает, как должна вести себя платформа с ИИ-компонентом. Автор разбора на Habr остановил Python-сервис с моделью машинного обучения, и .NET API остался работоспособным: запрос к ИИ-функции получил HTTP 503. После восстановления Python тот же запрос снова завершился кодом 200. Основное приложение никто не перезапускал.

Для команд, которые встраивают модели в существующие корпоративные системы, это главный практический вопрос. Модель сбоит чаще и непредсказуемее, чем остальной бэкенд. Задача в том, чтобы её отказ не превращался в простой всей платформы.

Зачем разделять .NET и Python

Большая часть ML-экосистемы живёт на Python: PyTorch, библиотеки для инференса, готовые обёртки над моделями. Бизнес-логика, авторизация, транзакции и интеграции в корпоративном мире нередко написаны на .NET. Соблазн соединить их в одном процессе понятен: меньше инфраструктуры, нет сетевых вызовов.

Цена такого решения в общей судьбе. Утечка памяти в нативной библиотеке, зависание из-за GIL или падение при загрузке тяжёлых весов затрагивает весь процесс. Отдельный Python-сервис задаёт границу отказа: он может упасть, перезагружаться и обновляться по собственному графику, а остальной API продолжает обслуживать клиентов.

Заголовок оригинала обещает решение «без лишних микросервисов». Речь идёт об одном выделенном сервисе под модель, без дробления всей системы на десятки узлов.

Что нужно предусмотреть на стыке

Сама по себе сетевая граница ничего не гарантирует. Если .NET будет ждать ответ от недоступного Python до бесконечности, отказ просто переедет в пул потоков. Для настоящей изоляции на стороне .NET обычно нужны несколько механизмов:

• жёсткие таймауты на каждый вызов модели;
• проверки состояния сервиса (health checks), чтобы быстро понимать, что он недоступен;
• circuit breaker: после серии ошибок вызовы временно прекращаются, и запросы сразу получают отказ;
• повторные попытки с экспоненциальной паузой и jitter, но только для идемпотентных операций;
• ограничение числа одновременных обращений к модели (bulkhead), чтобы медленный инференс не съел все ресурсы API.

Важна и семантика ответа. Код 503 говорит клиенту, что сервис временно недоступен, и это честнее, чем общая ошибка 500. Фронтенд и вызывающие системы могут отличить сбой ИИ-функции от поломки платформы. По описанию эксперимента, именно так и вёл себя API: 503 на время простоя и 200 сразу после возвращения Python.

Результат эксперимента

По опубликованному описанию, картина выглядит так:

• Python-сервис остановлен: .NET API продолжает работать.
• Запрос к ИИ-функции в это время: HTTP 503.
• Python-сервис восстановлен: тот же запрос завершается HTTP 200.
• Перезапуск основного приложения: не потребовался.

Автор не приводит здесь цифр по задержкам или нагрузке, так что это демонстрация принципа, а не бенчмарк. Подробности реализации читайте в оригинальной статье.

Что взять в работу

Для команды, которая собирается добавить модель в продакшен-систему, из этого следует несколько шагов. Сначала определите, какие функции действительно зависят от ИИ, и решите, что пользователь увидит при их недоступности: сообщение об ошибке, ответ из кэша или упрощённую логику без модели. Затем выставьте таймауты строго короче, чем у вышестоящих клиентов. Наконец, включите отказ ИИ-сервиса в регулярные учения: останавливайте его в тестовой среде и проверяйте, что остальной API отвечает штатно, как это сделал автор.

Если после остановки Python у вас начинают падать несвязанные эндпоинты, граница отказа проведена неверно, и дело не в модели.