Реализация Edge Computing обработки данных для 5G мобильного приложения
5G даёт latency 1-10ms до базовой станции. Но между базовой станцией и вашим облачным сервером — ещё 50-150ms RTT через обычные магистрали. Edge computing перемещает вычисления ближе к устройству: на MEC-серверы (Multi-access Edge Computing), установленные рядом с базовыми станциями 5G. Для правильных задач это даёт реальную разницу. Для неправильных — только сложность и расходы.
Когда edge имеет смысл, а когда нет
Edge computing оправдан, когда latency критична (< 20ms) или объём сырых данных слишком велик для передачи в облако.
Подходящие задачи:
- Обработка видеопотока в реальном времени (AR-аннотации, детекция объектов без отправки видео в облако)
- Управление IoT-устройствами с требованием отклика < 10ms (промышленная автоматика, медицинские устройства)
- Multiplayer gaming с региональным матчмейкингом
- Локальная агрегация телеметрии перед батчевой отправкой в облако
Задачи, где edge не нужен:
- Обычные REST API запросы, где 100ms неотличимы от 50ms для пользователя
- ML-инференс моделей > 500MB (дешевле держать в облаке)
- Любая задача без жёстких требований к latency
Архитектура мобильного приложения с edge
На стороне мобильного приложения edge computing требует нескольких архитектурных изменений.
Service Discovery. Приложение не знает заранее адрес ближайшего 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 > 50ms или HTTP 503 от edge — автоматический retry на облачный эндпоинт. Переключение должно быть прозрачным для UX. Реализуем через Circuit Breaker паттерн с половинным открытием: после 3 ошибок подряд — circuit open, все запросы идут в облако, через 30 секунд — половинное открытие (probe запрос на edge), если успешно — закрываем circuit.
Data partitioning. Не все данные идут через edge. Архитектура двух уровней:
| Тип данных | Маршрут | Причина |
|---|---|---|
| Видеокадры для обработки | Edge | Не нужно отправлять в облако, обработка локально |
| Результаты детекции | Облако | Малый объём, нужна персистентность |
| Пользовательские настройки | Облако | Доступность с любого устройства |
| Команды управления IoT | Edge | < 10ms требование |
| История команд | Облако | Аудит, аналитика |
Реализация: AR с edge-инференсом
Практический пример: AR-приложение для складской логистики. Камера сканирует штрихкоды на коробках, edge-сервер на MEC распознаёт и возвращает данные о товаре, приложение накладывает AR-аннотацию.
Полный pipeline: камера → буферизация кадра → JPEG compression (720p, quality 60) → HTTP/2 POST на edge → YOLOv8 инференс на GPU edge-сервера → JSON с bounding boxes → AR overlay через ARKit / ARCore.
Цель по latency: кадр → аннотация < 80ms. С edge (20ms до MEC) + инференс (15-30ms на GPU) + network overhead (10ms) = 45-60ms. Реально достижимо. Через обычное облако (150ms RTT) + инференс = 180-200ms. AR при такой задержке выглядит неестественно.
На стороне iOS используем AVCaptureSession с AVCaptureVideoDataOutput, downscale через vImageScale_ARGB8888 перед отправкой. URLSession с HTTP/2 и keep-alive соединением — не создавать новое соединение на каждый кадр, это +30-50ms handshake latency.
На Android — CameraX с ImageAnalysis.Analyzer, JPEG compression через YuvToRgbConverter → Bitmap → compress(JPEG, 60), OkHttp с HTTP/2 и connection pooling.
Частота запросов: не каждый кадр, а только при движении камеры > threshold или по таймеру 100ms. Видео 30fps = 30 запросов в секунду = неприемлемо. 10 запросов в секунду с интерполяцией overlay на клиенте — рабочий компромисс.
Оффлайн и деградация
5G есть не везде, даже если приложение позиционируется как «5G-приложение». На 4G edge latency теряет смысл (RTT до MEC может быть 80-120ms). На 3G/WiFi — работаем в режиме cloud-only или offline-first.
Детекция условий сети: NWPathMonitor (iOS) / ConnectivityManager.NetworkCallback (Android). При переходе на 4G — автоматически переключаем на облачный эндпоинт. При потере сети — local ML-инференс через CoreML / TensorFlow Lite с моделью, упакованной в приложение (меньший и менее точный вариант edge-модели).
Стоимость рассчитывается индивидуально — зависит от провайдера MEC-инфраструктуры, объёма трафика и сложности edge-логики. Сроки разработки мобильной части с edge-интеграцией: от 2 до 4 месяцев. Разработка самой edge-логики (ML-модели, processing pipeline) — отдельная работа, оценивается после анализа требований.