Реалізація 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 — автоматично переключаємо на хмарний ендпоінт. При втраті мережі — локальний ML-інференс через CoreML / TensorFlow Lite з моделлю, упакованою в додаток (менший та менш точний варіант edge-моделі).
Вартість розраховується індивідуально — залежить від провайдера MEC-інфраструктури, обсягу трафіку та складності edge-логіки. Терміни розробки мобільної частини з edge-інтеграцією: від 2 до 4 місяців. Розробка самої edge-логіки (ML-моделі, processing pipeline) — окрема робота, оцінюється після аналізу вимог.