ОПИСАНИЕ ФУНКЦИОНАЛЬНЫХ ХАРАКТЕРИСТИК: ПРОГРАММА ДЛЯ ЭВМ «ПРОГРАММА РЕШЕНИЯ ЗАДАЧ «ОПТИПОИНТ»
Настоящий документ содержит описание функциональных характеристик, а также процессов, обеспечивающих поддержание жизненного цикла специального программного обеспечения.
Обеспечение предоставления облачного сервиса для решения задач дискретной оптимизации и поиска решений системы линейных уравнений
2.1 Основной функционал
2.1.1 Поддерживаемые методы оптимизации
Сервис поддерживает несколько классов алгоритмов оптимизации, включая:
2.1.1.1 LP (Linear Programming) — решение задач линейного программирования с непрерывными переменными.
2.1.1.2 MILP (Mixed Integer Linear Programming) — решение задач смешанного целочисленного линейного программирования, где часть переменных является целочисленной (включая бинарные переменные).
2.1.1.3 CP (Constraint Programming) - решение задач посредством программирования с ограничениями, что подходит для комбинаторных задач с дискретными ограничениями (например, расписания, головоломки и др.).
2.1.2 Типы решаемых задач
Поддерживается широкий спектр задач дискретной оптимизации. Это включает классические задачи оптимизации, такие как задачи распределения ресурсов, планирования и расписания, задачи маршрутизации и транспортные задачи, задачи назначений, покрытий и раскроя, а также любые другие задачи, которые могут быть сформулированы в виде LP, MILP или CP модели. Пользователь формулирует свою задачу в допустимом формате, и солвер подбирает соответствующий метод решения (линейное программирование для непрерывных моделей, целочисленное — для комбинаторных, CP — для логико-комбинаторных формулировок).
2.1.3 Ограничения на входную модель
Входные данные задачи должны быть заданы только в формате MPS. MPS (Mathematical Programming System) — стандартный текстовый формат для задания задач линейного и целочисленного программирования. Это означает, что модель должна быть описана линейными ограничениями и линейной целевой функцией (нелинейные зависимости необходимо линеаризовать заранее). Все данные (коэффициенты ограничений, правые части, границы переменных и т. д.) задаются численно в файле MPS.
1.1.3.1 Неподдерживаемые конструкции Модели, содержащие нелинейные функции или ограничения, специализированные ограничения (например, логические ограничения, не выраженные через бинарные переменные) или нестандартные типы переменных, не принимаются напрямую сервисом. Они должны быть преобразованы пользователем в эквивалентную MILP/LP форму, пригодную для записи в MPS.
1.1.3.2 Ограничения по размеру Предполагается, что сервис способен решать крупномасштабные задачи (сотни тысяч переменных и ограничений), однако могут существовать практические ограничения по размеру файла MPS или по числу элементов в модели, обусловленные доступными вычислительными ресурсами. В случае превышения этих лимитов сервис может отклонить задачу или потребовать от пользователя разбить её на более мелкие части.
2.2 API
2.2.1 Протокол и взаимодействие
Доступ к функционалу солвера осуществляется через RESTful API по протоколу HTTPS. Пользователи могут программно взаимодействовать с сервисом, выполняя HTTP-запросы к заданным endpoint’ам.
2.2.2 Методы API
2.2.3 Основные методы взаимодействия включают:
Отправка задачи на решение - HTTP POST /solve с прикрепленным MPS-файлом задачи и параметрами решения. В ответ сервис принимает задачу в очередь на обработку и возвращает уникальный идентификатор задачи (job ID) и начальный статус.
Проверка статуса задачи - GET /status/{id} позволяет узнать текущее состояние решения (например, «в очереди», «в процессе решения», «решение найдено», «время вышло» и т. п.).
Получение результатов - GET /solution/{id} возвращает результат решения. Решение предоставляется в виде файла с решением для программного разбора.
Отмена задачи - POST /cancel/{id} для отмены выполнения задачи пользователем, если решение больше не требуется (актуально для долгих вычислений).
2.2.4 Формат входных данных API принимает модель задачи только в формате MPS Пользователь должен подготовить MPS-файл самостоятельно с помощью сторонних средств (например, экспортеров из AMPL/GMPL, Python-библиотек или другими инструментами).
2.2.5 Безопасность передачи данных Все взаимодействие происходит по защищенному протоколу HTTPS, что гарантирует шифрование передаваемых моделей и результатов. Данные пользователя (модель задачи, решения) изолированы и недоступны другим клиентам. Хранилище, используемое сервисом для временного сохранения загруженных моделей и полученных решений, также обеспечивает защиту данных (шифрование «at-rest», резервное копирование при необходимости).
2.2.6 Аутентификация и авторизация Для доступа к API требуется аутентификация пользователя. Поддерживаются механизмы выдачи API-ключа или токена доступа после регистрации пользователя в сервисе. Ключ/токен передается с каждым запросом (например, в HTTP-заголовке Authorization) для подтверждения прав доступа. Сервис реализует многоуровневую авторизацию: каждый пользователь работает в пределах своего изолированного пространства задач; доступ к чужим задачам или данным невозможен.
2.2.7 Ограничение доступа и квоты В целях безопасности и стабильности предусмотрены ограничения на использование API: например, лимиты на число одновременно решаемых задач, ограничение размера загружаемых MPS-файлов, а также защита от перегрузки (rate limiting) — ограничение числа запросов в секунду с одного аккаунта. Эти меры предотвращают злоупотребления и обеспечивают равномерное использование ресурсов всеми клиентами.
2.2.8 Журналирование и мониторинг Сервис ведет журнал действий (audit log) для безопасности, фиксируя факты обращения к API и изменения состояний задач. Также реализован мониторинг здоровья и производительности сервисов, позволяющий оперативно обнаруживать и предотвращать несанкционированный доступ или аномальную нагрузку.
2.3 Масштабируемость
2.3.1 Обработка больших моделей Архитектура сервиса рассчитана на работу с крупномасштабными задачами. Поддерживается решение моделей с очень большим числом переменных и ограничений. Сервис использует технологии предобработки (упрощение модели перед решением).
2.3.2 Горизонтальное масштабирование Сервис реализован по облачной архитектуре, что позволяет динамически масштабировать его в ответ на рост нагрузки. При увеличении числа одновременных задач или пользователей платформа автоматически поднимает дополнительную вычислительную мощность — запускаются новые экземпляры солверов на разных серверах. Балансировщик нагрузки распределяет входящие задачи между этими экземплярами, добиваясь эффективного использования всех доступных узлов. Благодаря этому, даже при большом числе запросов, время ожидания начала решения минимально. Масштабирование прозрачно для пользователя: он всегда обращается к единой точке API, а внутренняя инфраструктура сама решает, на каком узле выполнить задачу.
2.3.3 Многоарендность и изоляцияСервис спроектирован как многоарендный (multi-tenant) — одновременно могут обслуживаться множество независимых пользователей. Для обеспечения масштабируемости и надежности, данные и процессы каждого пользователя изолированы друг от друга (каждая задача выполняется в контейнере или отдельном процессе, что исключает взаимное влияние). Масштабируемость достигается без ущерба для безопасности: добавление новых вычислительных узлов увеличивает общую пропускную способность, но задачи пользователей остаются изолированными на логическом уровне.
2.3.4 Авто-масштабирование и эластичностьПлатформа постоянно мониторит загрузку (число очередных задач, использование CPU/RAM) и способна автоматически увеличивать или уменьшать число активных solver-узлов. Например, в часы пик добавляются дополнительные виртуальные машины/контейнеры с запущенными решателями, а при спаде нагрузки лишние узлы освобождаются, оптимизируя затраты. Это гарантирует экономичное использование ресурсов и стабильное время отклика сервиса под переменной нагрузкой.
2.3.5 Доступность и отказоустойчивость: В архитектуре предусмотрено резервирование компонентов — несколько экземпляров сервисов управления задачами и хранилищ данных работают параллельно. В случае сбоя отдельного узла его задачи автоматически перераспределяются на другие узлы в кластере. Таким образом, сервис масштабируется не только по производительности, но и обеспечивает высокую доступность (High Availability), продолжая работу при выходе из строя отдельных серверов.
2.1 Основной функционал
2.1.1 Поддерживаемые методы оптимизации
Сервис поддерживает несколько классов алгоритмов оптимизации, включая:
2.1.1.1 LP (Linear Programming) — решение задач линейного программирования с непрерывными переменными.
2.1.1.2 MILP (Mixed Integer Linear Programming) — решение задач смешанного целочисленного линейного программирования, где часть переменных является целочисленной (включая бинарные переменные).
2.1.1.3 CP (Constraint Programming) - решение задач посредством программирования с ограничениями, что подходит для комбинаторных задач с дискретными ограничениями (например, расписания, головоломки и др.).
2.1.2 Типы решаемых задач
Поддерживается широкий спектр задач дискретной оптимизации. Это включает классические задачи оптимизации, такие как задачи распределения ресурсов, планирования и расписания, задачи маршрутизации и транспортные задачи, задачи назначений, покрытий и раскроя, а также любые другие задачи, которые могут быть сформулированы в виде LP, MILP или CP модели. Пользователь формулирует свою задачу в допустимом формате, и солвер подбирает соответствующий метод решения (линейное программирование для непрерывных моделей, целочисленное — для комбинаторных, CP — для логико-комбинаторных формулировок).
2.1.3 Ограничения на входную модель
Входные данные задачи должны быть заданы только в формате MPS. MPS (Mathematical Programming System) — стандартный текстовый формат для задания задач линейного и целочисленного программирования. Это означает, что модель должна быть описана линейными ограничениями и линейной целевой функцией (нелинейные зависимости необходимо линеаризовать заранее). Все данные (коэффициенты ограничений, правые части, границы переменных и т. д.) задаются численно в файле MPS.
1.1.3.1 Неподдерживаемые конструкции Модели, содержащие нелинейные функции или ограничения, специализированные ограничения (например, логические ограничения, не выраженные через бинарные переменные) или нестандартные типы переменных, не принимаются напрямую сервисом. Они должны быть преобразованы пользователем в эквивалентную MILP/LP форму, пригодную для записи в MPS.
1.1.3.2 Ограничения по размеру Предполагается, что сервис способен решать крупномасштабные задачи (сотни тысяч переменных и ограничений), однако могут существовать практические ограничения по размеру файла MPS или по числу элементов в модели, обусловленные доступными вычислительными ресурсами. В случае превышения этих лимитов сервис может отклонить задачу или потребовать от пользователя разбить её на более мелкие части.
2.2 API
2.2.1 Протокол и взаимодействие
Доступ к функционалу солвера осуществляется через RESTful API по протоколу HTTPS. Пользователи могут программно взаимодействовать с сервисом, выполняя HTTP-запросы к заданным endpoint’ам.
2.2.2 Методы API
2.2.3 Основные методы взаимодействия включают:
Отправка задачи на решение - HTTP POST /solve с прикрепленным MPS-файлом задачи и параметрами решения. В ответ сервис принимает задачу в очередь на обработку и возвращает уникальный идентификатор задачи (job ID) и начальный статус.
Проверка статуса задачи - GET /status/{id} позволяет узнать текущее состояние решения (например, «в очереди», «в процессе решения», «решение найдено», «время вышло» и т. п.).
Получение результатов - GET /solution/{id} возвращает результат решения. Решение предоставляется в виде файла с решением для программного разбора.
Отмена задачи - POST /cancel/{id} для отмены выполнения задачи пользователем, если решение больше не требуется (актуально для долгих вычислений).
2.2.4 Формат входных данных API принимает модель задачи только в формате MPS Пользователь должен подготовить MPS-файл самостоятельно с помощью сторонних средств (например, экспортеров из AMPL/GMPL, Python-библиотек или другими инструментами).
2.2.5 Безопасность передачи данных Все взаимодействие происходит по защищенному протоколу HTTPS, что гарантирует шифрование передаваемых моделей и результатов. Данные пользователя (модель задачи, решения) изолированы и недоступны другим клиентам. Хранилище, используемое сервисом для временного сохранения загруженных моделей и полученных решений, также обеспечивает защиту данных (шифрование «at-rest», резервное копирование при необходимости).
2.2.6 Аутентификация и авторизация Для доступа к API требуется аутентификация пользователя. Поддерживаются механизмы выдачи API-ключа или токена доступа после регистрации пользователя в сервисе. Ключ/токен передается с каждым запросом (например, в HTTP-заголовке Authorization) для подтверждения прав доступа. Сервис реализует многоуровневую авторизацию: каждый пользователь работает в пределах своего изолированного пространства задач; доступ к чужим задачам или данным невозможен.
2.2.7 Ограничение доступа и квоты В целях безопасности и стабильности предусмотрены ограничения на использование API: например, лимиты на число одновременно решаемых задач, ограничение размера загружаемых MPS-файлов, а также защита от перегрузки (rate limiting) — ограничение числа запросов в секунду с одного аккаунта. Эти меры предотвращают злоупотребления и обеспечивают равномерное использование ресурсов всеми клиентами.
2.2.8 Журналирование и мониторинг Сервис ведет журнал действий (audit log) для безопасности, фиксируя факты обращения к API и изменения состояний задач. Также реализован мониторинг здоровья и производительности сервисов, позволяющий оперативно обнаруживать и предотвращать несанкционированный доступ или аномальную нагрузку.
2.3 Масштабируемость
2.3.1 Обработка больших моделей Архитектура сервиса рассчитана на работу с крупномасштабными задачами. Поддерживается решение моделей с очень большим числом переменных и ограничений. Сервис использует технологии предобработки (упрощение модели перед решением).
2.3.2 Горизонтальное масштабирование Сервис реализован по облачной архитектуре, что позволяет динамически масштабировать его в ответ на рост нагрузки. При увеличении числа одновременных задач или пользователей платформа автоматически поднимает дополнительную вычислительную мощность — запускаются новые экземпляры солверов на разных серверах. Балансировщик нагрузки распределяет входящие задачи между этими экземплярами, добиваясь эффективного использования всех доступных узлов. Благодаря этому, даже при большом числе запросов, время ожидания начала решения минимально. Масштабирование прозрачно для пользователя: он всегда обращается к единой точке API, а внутренняя инфраструктура сама решает, на каком узле выполнить задачу.
2.3.3 Многоарендность и изоляцияСервис спроектирован как многоарендный (multi-tenant) — одновременно могут обслуживаться множество независимых пользователей. Для обеспечения масштабируемости и надежности, данные и процессы каждого пользователя изолированы друг от друга (каждая задача выполняется в контейнере или отдельном процессе, что исключает взаимное влияние). Масштабируемость достигается без ущерба для безопасности: добавление новых вычислительных узлов увеличивает общую пропускную способность, но задачи пользователей остаются изолированными на логическом уровне.
2.3.4 Авто-масштабирование и эластичностьПлатформа постоянно мониторит загрузку (число очередных задач, использование CPU/RAM) и способна автоматически увеличивать или уменьшать число активных solver-узлов. Например, в часы пик добавляются дополнительные виртуальные машины/контейнеры с запущенными решателями, а при спаде нагрузки лишние узлы освобождаются, оптимизируя затраты. Это гарантирует экономичное использование ресурсов и стабильное время отклика сервиса под переменной нагрузкой.
2.3.5 Доступность и отказоустойчивость: В архитектуре предусмотрено резервирование компонентов — несколько экземпляров сервисов управления задачами и хранилищ данных работают параллельно. В случае сбоя отдельного узла его задачи автоматически перераспределяются на другие узлы в кластере. Таким образом, сервис масштабируется не только по производительности, но и обеспечивает высокую доступность (High Availability), продолжая работу при выходе из строя отдельных серверов.
Напишите нам
Сообщение об успешной отправке!