Технологии 1 мая 2026 · 11 мин чтения 103 0

Edge, Fog и Cloud computing — где обрабатывать данные

Распределённые вычисления вышли далеко за рамки централизованных дата-центров. Современные системы обрабатывают данные там, где это выгоднее по латентности, пропускной способности или стоимости — в облаке, на пограничных узлах рядом с источником данных или в промежуточном слое между ними. Эти три модели — cloud, edge и fog computing — не конкурируют, а дополняют друг друга, формируя многоуровневую вычислительную инфраструктуру.

Разница между моделями определяется тем, где физически выполняется обработка, какая допускается задержка ответа и сколько данных передаётся по сети. Понимание этих границ позволяет архитектору правильно разместить компоненты системы: одни задачи требуют миллисекундного отклика и обрабатываются на устройстве, другие — массивных вычислений и уходят в облако, третьи живут в промежуточном слое сетевых шлюзов и базовых станций.

Что такое cloud computing

Cloud computing — модель, при которой вычислительные ресурсы предоставляются как услуга через интернет из централизованных дата-центров. Пользователь арендует вычислительную мощность, хранилище и сетевые ресурсы у провайдера, не владея железом физически. Концепция оформилась в середине 2000-х годов и стала доминирующей моделью развёртывания за следующее десятилетие.

Архитектурно облако строится вокруг крупных региональных дата-центров с десятками тысяч серверов, объединённых высокоскоростными сетями. Внутри каждого региона несколько зон доступности обеспечивают изоляцию отказов. Между регионами работают приватные магистрали с задержкой от единиц до сотен миллисекунд в зависимости от географии.

Сильные стороны облачной модели

  • Эластичность: ресурсы выделяются и освобождаются за минуты, оплата по фактическому потреблению
  • Глобальное покрытие: десятки регионов у крупных провайдеров позволяют разворачивать сервисы рядом с пользователями
  • Зрелые управляемые сервисы: базы данных, очереди, аналитика, ML-платформы доступны как готовые компоненты
  • Экономия на масштабе: стоимость единицы ресурсов ниже, чем при содержании собственной инфраструктуры малого и среднего размера

Слабые места

Главное ограничение облака — латентность. Запрос от устройства до ближайшего региона провайдера занимает от 10 до 100 миллисекунд, а с учётом обработки и обратного ответа суммарная задержка может выйти за пределы, допустимые для интерактивных систем. Второй фактор — стоимость передачи данных. Исходящий трафик из облака тарифицируется отдельно и при больших объёмах становится значимой статьёй расходов.

Что такое edge computing

Edge computing размещает вычисления максимально близко к источнику данных — на самом устройстве, на локальном сервере в офисе или на пограничном узле сети. Цель — сократить задержку, снизить нагрузку на каналы связи и обеспечить автономную работу при перебоях с подключением. Edge не заменяет облако, а выносит из него те задачи, для которых критична близость к данным.

Под edge подразумевают разные уровни приближения. На уровне устройства это микроконтроллеры и SBC с ограниченной мощностью, выполняющие предобработку и фильтрацию. На уровне локальной сети — отказоустойчивые серверы в производственных помещениях, магазинах, на нефтяных платформах. На уровне сетевой инфраструктуры — MEC-узлы операторов связи, размещённые в базовых станциях 5G.

Когда edge выигрывает у облака

  1. Промышленная автоматика, где цикл управления требует отклика менее 10 миллисекунд
  2. Системы компьютерного зрения с обработкой видео в реальном времени без отправки потока в облако
  3. Автономные транспортные средства и роботы, не имеющие гарантированного соединения
  4. Сценарии с жёсткими требованиями к локализации данных, когда регуляторика запрещает вывоз информации за пределы страны
  5. Точки продаж и POS-терминалы, которые должны работать при обрыве связи с центральным сервером

Что такое fog computing

Fog computing — промежуточный слой между edge и cloud, который агрегирует данные с множества пограничных узлов, выполняет промежуточные вычисления и решает, что передавать дальше в облако. Термин предложила Cisco в 2012 году для описания инфраструктуры, обслуживающей сценарии IoT с большим числом подключённых устройств.

Туман — это сеть распределённых серверов и шлюзов, объединённых общей платформой управления. В отличие от edge, где каждый узел работает относительно автономно, fog подразумевает координацию между узлами: балансировку нагрузки, миграцию задач, общее состояние. Типичная роль fog-узла — собирать телеметрию с десятков или сотен устройств, агрегировать её, выполнять детекцию аномалий и передавать в облако только сжатые отчёты или сработки правил.

Где живёт fog

Физическое размещение fog-узлов — региональные мини-дата-центры, серверные комнаты на крупных промышленных объектах, узлы связи провайдеров. Это не оборудование рядом с конкретным датчиком, как в edge, и не централизованное облако за тысячи километров — это слой посередине, обеспечивающий локальную пропускную способность для группы edge-устройств в радиусе десятков километров.

Сравнение трёх моделей

Параметр Cloud Fog Edge
Расположение Региональные дата-центры Промежуточные узлы, MEC Устройство или локальная сеть
Латентность 10–100 мс 2–10 мс < 1 мс
Вычислительная мощность Практически неограниченная Средняя, ограничена объёмом узла Низкая или средняя
Объём хранилища Петабайты Терабайты Гигабайты
Автономность Требует постоянного подключения Частичная автономность Полная автономность
Стоимость единицы вычислений Низкая Средняя Высокая
Сложность развёртывания Низкая Средняя Высокая
Управление данными Централизованное Гибридное Локальное

Латентность как ключевая метрика

Выбор модели чаще всего определяется требованиями к задержке. Бюджет латентности — суммарное время от события до реакции — складывается из распространения сигнала по сети, обработки на узле и обратной передачи результата. Скорость света в оптоволокне даёт около 200 километров на миллисекунду, что само по себе закладывает физический минимум для удалённого подключения.

Сценарий Допустимая задержка Рекомендуемая модель
Промышленная робототехника, ЧПУ < 1 мс Edge на устройстве
Дополненная реальность, гарнитуры 5–20 мс Edge или fog
Облачный гейминг 20–50 мс Fog с MEC
Видеоконференции 100–150 мс Cloud с региональной близостью
Веб-приложения, API 200–500 мс Cloud
Пакетная обработка, ETL Секунды–часы Cloud
Архивирование, аналитика Часы–сутки Cloud

Когда бюджет латентности измеряется единицами миллисекунд, физика не оставляет выбора — обработка должна происходить рядом с источником данных. Когда речь о сотнях миллисекунд и более, облако работает приемлемо при условии разумного географического выбора региона.

Архитектурные паттерны распределения

Реальные системы редко используют только одну модель. Чаще встречаются гибридные архитектуры, где функции распределены между уровнями по принципу «обрабатывать там, где выгоднее». Несколько распространённых паттернов:

Преобработка на edge, обучение в облаке

Сценарий распространён в системах машинного зрения и предиктивной аналитики. Edge-устройство выполняет инференс на заранее обученной модели: распознаёт объекты, классифицирует сигналы, фильтрует поток данных. В облако уходит не сырой поток, а агрегированная метрика и редкие интересные кадры. Обучение и периодическое обновление модели происходит в облаке, новая версия выкатывается на устройства через OTA.

Cache-aside на fog-узлах

Fog-узел кеширует часто запрашиваемые данные из облака для группы пользователей или устройств в своём регионе. CDN — классический пример такого подхода для статического контента, но та же логика применяется к динамическим данным: каталогам товаров, тарифам, конфигурациям. Запросы обслуживаются с задержкой нескольких миллисекунд вместо десятков.

Eventual consistency между уровнями

Локальные узлы работают на своих копиях данных, синхронизация с облаком происходит асинхронно. Подход подходит для сценариев, где временное расхождение допустимо: складская логистика, торговые точки, телеметрия. При обрыве связи узел продолжает работать на локальных данных, а после восстановления сливает накопленные изменения.

Стоимостная модель: где экономика

Облако оптимально по стоимости единицы вычислений и хранения при больших объёмах. Edge выигрывает на трафике: передавать сырой видеопоток с десятка камер 24/7 в облако обойдётся в сотни долларов в месяц только за исходящий трафик, тогда как локальная обработка с отправкой одних метаданных снижает счёт в десятки раз.

Стоимость владения edge-инфраструктурой включает закупку и обновление железа, питание, охлаждение, физическую безопасность площадки и удалённое управление парком устройств. На малых масштабах эти расходы съедают экономию на трафике, edge становится выгоден от десятков устройств и выше. Fog работает как компромисс: меньше точек присутствия, чем у edge, но ближе к источнику данных, чем cloud.

Ориентировочные диапазоны затрат

Статья Cloud Edge
Стоимость 1 vCPU/час $0.01–0.05 $0.05–0.20 (амортизация)
Стоимость 1 ГБ хранения $0.02–0.10 в месяц $0.05–0.30 в месяц
Исходящий трафик 1 ГБ $0.05–0.12 $0 локально
Капитальные вложения Нет $500–5000 на узел
Эксплуатация в месяц $0 (включено) $50–200 на узел

Платформы и инструменты

Крупные облачные провайдеры активно расширяют свои предложения в сторону edge и fog, понимая, что чисто централизованная модель уступает рынок. Появилось несколько категорий платформ:

  • Расширения публичного облака на edge: AWS Outposts, Azure Stack Edge, Google Distributed Cloud Edge — стойки, физически размещённые у клиента и управляемые через те же API, что и облачные регионы
  • Telco MEC: AWS Wavelength, Azure Public MEC размещают вычисления в зонах операторов 5G, обеспечивая задержку менее 10 миллисекунд для абонентов мобильной сети
  • Edge-оркестраторы: K3s, KubeEdge, OpenYurt — облегчённые версии Kubernetes для управления распределённым парком узлов с ограниченными ресурсами
  • IoT-платформы: AWS IoT Greengrass, Azure IoT Edge, Eclipse ioFog — фреймворки для разработки и развёртывания приложений на пограничных устройствах
  • CDN с вычислительными возможностями: Cloudflare Workers, Fastly Compute@Edge, Akamai EdgeWorkers — выполнение кода на тысячах точек присутствия по всему миру

Безопасность распределённой инфраструктуры

Чем шире распределение, тем сложнее обеспечить безопасность. Облачные дата-центры физически охраняются провайдером и сертифицированы по серии стандартов. Edge-узлы, размещённые в производственных помещениях или общественных пространствах, доступны для физического воздействия — кражи, замены, подключения внешних устройств.

Векторы угроз edge

  • Физический доступ: возможность извлечь накопитель, подключить отладочные интерфейсы, заменить прошивку
  • Сетевые атаки на устройство: устаревшие протоколы, открытые порты управления, слабые пароли по умолчанию
  • Компрометация цепочки поставок: вредоносный код в прошивке от производителя или вендора OS
  • Распределённые ботнеты: захваченные edge-устройства становятся узлами атак на другие цели

Базовые меры защиты включают шифрование данных на устройстве, аппаратный root of trust, безопасную загрузку, подписанные обновления, удалённую аттестацию состояния, изоляцию приложений в контейнерах с минимальными привилегиями. Подход zero trust здесь применяется буквально: ни одно устройство не считается доверенным по умолчанию.

Сетевая инфраструктура и роль 5G

Распространение 5G и стандарта URLLC дало edge-вычислениям инфраструктурную базу. Базовая станция 5G способна выступать как MEC-узел, обрабатывая трафик абонентов локально без выхода в магистральную сеть. Latency между устройством и MEC-узлом составляет 1–5 миллисекунд, тогда как до облачного региона уходит 20–50 мс.

Сценарии, которые становятся реалистичны на 5G MEC: дополненная реальность с реакцией на движение головы, удалённое управление промышленным оборудованием, кооперативное вождение автомобилей с обменом данными между машинами, телехирургия. Эти задачи технически невозможны на классической облачной архитектуре из-за задержки.

Когда edge не нужен

Edge — не золотая пуля. Если приложение нечувствительно к задержке, не работает с большими потоками данных и не имеет требований автономности, его развёртывание в облаке будет проще, дешевле и надёжнее. Распространённые антипаттерны использования edge:

  1. Корпоративные приложения с десятками пользователей в одном офисе, которые прекрасно работают через облако
  2. Сценарии аналитики и отчётности, где задержка минуты-часы допустима
  3. Системы, требующие глобальной согласованности данных в реальном времени
  4. Проекты без зрелой команды эксплуатации распределённой инфраструктуры

Edge решает конкретные проблемы — задержку, локализацию, автономность. Если этих проблем нет, добавление edge только увеличит сложность и стоимость без выгоды.

Тренды и куда движется индустрия

За последние годы граница между моделями размывается. Облачные провайдеры выпускают аппаратные стойки для размещения у клиента, операторы связи открывают свои базовые станции для размещения вычислений, производители сетевого оборудования встраивают runtime для контейнеров прямо в свитчи. Концепция compute everywhere предполагает, что вычисления — это утилита, доступная в любой точке инфраструктуры.

Параллельно развиваются специализированные ускорители для edge: NPU и TPU с энергопотреблением единицы ватт, способные выполнять инференс нейронных сетей на батарейке. Это открывает классы задач, которые раньше требовали обязательной отправки данных в облако — распознавание речи на устройстве, обработка фото локально, носимая электроника с ML на борту.

Часто задаваемые вопросы

Чем edge отличается от fog простыми словами

Edge — это вычисления на самом устройстве или в его непосредственной близости, обычно автономный узел. Fog — промежуточный слой между edge и облаком, координирующий работу группы edge-узлов и выполняющий агрегацию. Edge ближе к данным, fog — ближе к облаку, но не настолько далеко, как классические дата-центры.

Можно ли построить систему только на edge без облака

Технически да, но непрактично для большинства задач. Edge-устройства плохо подходят для долговременного хранения больших объёмов данных, обучения ML-моделей, глобальной аналитики, обновления ПО. Гибридная архитектура почти всегда выгоднее: edge — для отклика, облако — для масштаба и тяжёлых вычислений.

Какие облачные провайдеры лидируют в edge-направлении

На рынке представлены предложения AWS (Outposts, Wavelength, Snow Family, IoT Greengrass), Microsoft (Azure Stack Edge, Azure IoT Edge, Public MEC), Google (Distributed Cloud Edge, Anthos at the Edge). Среди специализированных игроков — Cloudflare с глобальной сетью Workers, Fastly с Compute@Edge, ZEDEDA для управления edge-парком.

Насколько сложно эксплуатировать edge-инфраструктуру

Существенно сложнее облака. Главные вызовы — управление парком из сотен и тысяч устройств, развёртывание обновлений без полной остановки, мониторинг состояния, диагностика проблем удалённо. Требуется зрелый процесс GitOps, инструменты управления конфигурацией, продуманная стратегия отката. Без этого парк edge-устройств быстро превращается в неуправляемый зоопарк.

Подходит ли edge для небольших компаний

Зависит от задачи. Один-два edge-узла для конкретного сценария (видеонаблюдение, торговая точка) развернуть несложно — есть готовые решения вендоров. Полноценная распределённая edge-платформа требует ресурсов крупной компании. Малому бизнесу чаще достаточно облака с региональной близостью или managed-сервисов edge от провайдеров.

Какие протоколы используют edge-устройства для связи

Для связи с облаком и шлюзами популярны MQTT, AMQP, HTTP/2 с gRPC, CoAP. Между edge-устройствами в локальной сети применяются те же протоколы плюс OPC UA в промышленных сценариях, Modbus в legacy-системах, протоколы поверх Bluetooth и Zigbee для устройств с низким энергопотреблением. Выбор зависит от пропускной способности канала, требований к надёжности и совместимости с существующим оборудованием.

Заключение

Cloud, edge и fog computing — три точки на спектре распределения вычислений. Облако даёт неограниченную мощность за счёт удалённости, edge даёт мгновенный отклик за счёт ограниченных ресурсов, fog занимает промежуточную позицию для координации множества edge-узлов. Современная архитектура распределённой системы — это вопрос не выбора одной модели, а правильного распределения функций между всеми тремя.

Решение о размещении компонентов опирается на бюджет латентности, объём передаваемых данных, требования автономности и регуляторные ограничения по локализации. Облачный-первый подход остаётся разумным выбором по умолчанию для большинства приложений. Edge добавляется там, где облако физически не справляется с требованиями. Fog появляется в крупных распределённых системах, где нужна координация между множеством локальных узлов.