Ваше мобильное приложение использует облачные серверы, но задержка между устройством и облаком составляет 50–150 мс. Для AR, IoT или гейминга это критично. Edge Computing на базе 5G MEC сокращает RTT до 1–10 мс, перенося вычисления на граничные узлы. Мы реализовали такие решения для логистики, ритейла и промышленности, и знаем, где edge действительно нужен, а где — излишняя сложность.
Рассмотрим типичную ситуацию: вы разрабатываете AR-приложение для навигации. Кадры видео отправляются в облако, алгоритм распознает объекты, возвращает аннотацию. При облачной архитектуре задержка 180–200 мс делает AR неестественным. С edge latency снижается до 45–60 мс — вполне приемлемо для плавного опыта. На одном из проектов для логистического оператора мы сократили затраты на облачную передачу данных на 40% за счет локальной обработки на MEC. Какая архитектура подойдет вашему проекту? Обращайтесь — проведем аудит.
Подходящие и неподходящие сценарии для Edge Computing
Edge Computing оправдан, когда latency критична (< 20 мс) или объём сырых данных слишком велик для передачи в облако.
Подходящие задачи:
- Обработка видеопотока в реальном времени (AR-аннотации, детекция объектов без отправки видео в облако)
- Управление IoT-устройствами с требованием отклика < 10 мс (промышленная автоматика, медицинские устройства)
- Multiplayer gaming с региональным матчмейкингом
- Локальная агрегация телеметрии перед батчевой отправкой в облако
Задачи, где edge не нужен:
- Обычные REST API запросы, где 100 мс неотличимы от 50 мс для пользователя
- ML-инференс моделей > 500 МБ (дешевле держать в облаке)
- Любая задача без жёстких требований к latency
Как реализовать service discovery?
На стороне мобильного приложения edge computing требует нескольких архитектурных изменений. Первое — обнаружение ближайшего edge-узла. При подключении к 5G-сети приложение запрашивает Edge Discovery Service (стандартизован в ETSI MEC 011) и получает эндпоинт ближайшего MEC-сервера:
// iOS let discoveryClient = MECDiscoveryClient(appId: "com.myapp.edge") let edgeEndpoint = try await discoveryClient.resolveNearestEdge( location: locationManager.location, serviceType: .videoProcessing ) Для платформ без ETSI MEC API (большинство коммерческих облаков — AWS Wavelength, Azure Edge Zones, Google Distributed Cloud Edge) — проприетарные SDK: AWSWavelengthClient, Azure SDK для Edge Zones.
Fallback на облако. Edge-узлы менее надёжны, чем облачные регионы. Код обязан обрабатывать недоступность edge: при timeout > 50 мс или HTTP 503 от edge — автоматический retry на облачный эндпоинт. Переключение должно быть прозрачным для UX. Реализуем через Circuit Breaker паттерн с половинным открытием: после 3 ошибок подряд — circuit open, все запросы идут в облако, через 30 секунд — половинное открытие (probe запрос на edge), если успешно — закрываем circuit.
Data partitioning. Не все данные идут через edge. Архитектура двух уровней:
| Тип данных | Маршрут | Причина |
|---|---|---|
| Видеокадры для обработки | Edge | Не нужно отправлять в облако, обработка локально |
| Результаты детекции | Облако | Малый объём, нужна персистентность |
| Пользовательские настройки | Облако | Доступность с любого устройства |
| Команды управления IoT | Edge | < 10 мс требование |
| История команд | Облако | Аудит, аналитика |
Сравнение задержек:
| Сценарий | Edge (мс) | Облако (мс) | Экономия |
|---|---|---|---|
| AR-аннотация | 45–60 | 180–200 | до 70% |
| IoT-команда | < 10 | 60–80 | > 85% |
| Видеоаналитика (1 кадр) | 100–150 | 300–400 | до 60% |
Реализация: AR с edge-инференсом
Практический пример: AR-приложение для складской логистики. Камера сканирует штрихкоды на коробках, edge-сервер на MEC распознаёт и возвращает данные о товаре, приложение накладывает AR-аннотацию.
Полный pipeline:
- Камера → буферизация кадра → JPEG compression (720p, quality 60)
- HTTP/2 POST на edge-эндпоинт (keep-alive, single connection)
- YOLOv8 инференс на GPU edge-сервера (15–30 мс)
- JSON с bounding boxes → AR overlay через ARKit / ARCore
Цель по latency: кадр → аннотация < 80 мс. С edge (20 мс до MEC) + инференс (15–30 мс на GPU) + network overhead (10 мс) = 45–60 мс. Реально достижимо. Через обычное облако (150 мс RTT) + инференс = 180–200 мс. AR при такой задержке выглядит неестественно.
На стороне iOS используем AVCaptureSession с AVCaptureVideoDataOutput, downscale через vImageScale_ARGB8888 перед отправкой. URLSession с HTTP/2 и keep-alive соединением — не создавать новое соединение на каждый кадр, это +30–50 мс handshake latency.
На Android — CameraX с ImageAnalysis.Analyzer, JPEG compression через YuvToRgbConverter → Bitmap → compress(JPEG, 60), OkHttp с HTTP/2 и connection pooling.
Частота запросов: не каждый кадр, а только при движении камеры > threshold или по таймеру 100 мс. Видео 30 fps = 30 запросов в секунду = неприемлемо. 10 запросов в секунду с интерполяцией overlay на клиенте — рабочий компромисс.
Что делать при потере 5G-соединения?
5G есть не везде, даже если приложение позиционируется как «5G-приложение». На 4G edge latency теряет смысл (RTT до MEC может быть 80–120 мс). На 3G/WiFi — работаем в режиме cloud-only или offline-first.
Детекция условий сети: NWPathMonitor (iOS) / ConnectivityManager.NetworkCallback (Android). При переходе на 4G — автоматически переключаем на облачный эндпоинт. При потере сети — local ML-инференс через CoreML / TensorFlow Lite с моделью, упакованной в приложение (меньший и менее точный вариант edge-модели).
Что входит в работу
- Проектирование архитектуры edge-взаимодействия (discovery, fallback, data routing)
- Интеграция SDK для MEC (ETSI или облачные провайдеры)
- Реализация Circuit Breaker и offline-логики
- Тестирование на реальных 5G-сетях и эмуляторах
- Документация по эксплуатации edge-модулей
- Поддержка после запуска (2 месяца)
Наш опыт: многолетняя практика в мобильной разработке, 50+ выполненных проектов с edge и 5G, сертифицированные инженеры (Apple Certified iOS, Google Associate Android). Получите консультацию по вашему проекту — мы оценим целесообразность edge и предложим оптимальную архитектуру. Свяжитесь с нами, чтобы начать.