Ваш мобільний додаток використовує хмарні сервери, але затримка між пристроєм і хмарою становить 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 і запропонуємо оптимальну архітектуру. Зв'яжіться з нами, щоб почати.