Principy edge computingu a jeho odlišnosti od cloudu

Proč se výpočet přesouvá z cloudu na „edge“

Edge computing je přístup, při kterém se zpracování dat, rozhodování a částečně i ukládání přesouvá z centrálních cloudových regionů co nejblíže ke zdrojům dat – na síťový okraj (edge): do zařízení, bran (gateways), lokálních mikro-datacenter nebo přímo do 5G/MEC infrastruktury. Cílem je redukce latence, úspora přenosového pásma, vyšší odolnost vůči výpadkům a lepší kontrola nad daty. Cloud naopak nabízí elastickou kapacitu, globální škálování a spravované služby. V praxi vzniká kontinuum cloud–edge–device, ve kterém si každá vrstva přebírá úlohy, pro které je technicky i ekonomicky nejvhodnější.

Definice a modely nasazení

• Device edge – výpočty probíhající přímo v koncových zařízeních (senzory, roboti, kamery, vozidla) s omezenými zdroji CPU/GPU/TPU.
• Gateway/On-prem edge – průmyslové PC nebo appliance umístěné lokálně (továrna, obchod, nemocnice), sloužící jako sběrnice, cache, inference server nebo broker.
• Network edge / MEC – výpočetní uzly v přístupové síti operátora (5G/ISP) s milisekundovou latencí k zařízením.
• Cloud – regionální datacentra s masivní škálou, vysokou dostupností služeb a globálním dosahem.

Hlavní motivace: latence, šířka pásma, suverenita a spolehlivost

• Latence: mnohé řídicí smyčky vyžadují end-to-end odezvu < 10–50 ms (strojové vidění, AR/VR, robotika). Vzdálený cloud často přidává stovky ms.
• Pásmo a náklady na přenos: surové video či telemetrie generují desítky Mb/s na zařízení; na edge se proto provádí předzpracování, filtrování a inference, a do cloudu putují pouze agregáty či události.
• Suverenita, compliance: citlivá data (biometrie, zdravotnictví, průmyslová tajemství) zůstávají lokálně, do cloudu směřují pouze anonymizované výstupy.
• Odolnost: lokální rozhodování pokračuje i při výpadku WAN; edge zajišťuje graceful degradation.

Architektura: datový tok a vrstvy

1. Ingest: sběr dat (OPC UA, Modbus, CAN, RTSP, BLE, Zigbee, MQTT).
2. Normalizace a obohacení: časová synchronizace, validace, jednotky, metadata, časové okno.
3. Analýza a inference: streamové agregace, CEP, ML inference (ONNX/TensorRT/OpenVINO) s kvantizací pro edge akcelerátory.
4. Akce v reálném čase: PLC/aktuátory, lokální API, HMI.
5. Persist a replikace: krátkodobá cache (TSDB/kv-store) na edge, dlouhodobé uložení a re-trénink v cloudu.

Rozdíl oproti cloudu: vlastnosti a kompromisy

• Škálování: cloud = elastické a centrálně řízené; edge = horizontální ve velkém počtu malých uzlů, vyžaduje flotilový management.
• Stálost konektivity: cloud předpokládá dostupný WAN; edge počítá s přerušováním a řeší store-and-forward.
• Konzistence dat: cloud preferuje silnou konzistenci; edge často volí eventual consistency a konflikt-free replikaci (CRDT, verze/časová razítka).
• Bezpečnostní perimetr: v cloudu centralizovaný; na edge je perimeter rozptýlený, s větším důrazem na zero-trust a identitu zařízení.
• Operace: cloudové DevOps vs. edge GitOps/FleetOps s OTA aktualizacemi, canary rollout a break-glass postupy pro offline servis.

Síť a latence: model cesty signálu

Celková odezva T se skládá z: T = Tprop + Tqueue + Tproc + Tapp. Edge zkracuje T_prop (fyzická vzdálenost) i T_queue (méně přetížených uzlů) a často i T_app (menší stack, lokální API). V 5G/MEC je běžná jednociferná ms latence k aplikaci, zatímco regionální cloud přidává desítky až stovky ms.

Provozní odolnost: vzory návrhu

• Fail-open/Fail-closed: určete, zda má systém bez cloudu běžet (např. výroba) nebo se bezpečně zastavit (například zdravotnictví).
• Backpressure a vyhlazování: fronty (MQTT/Kafka na edge), vyrovnávací paměti a rate-limit vůči cloudu.
• Store-and-forward: lokální log/TSDB s retenční politikou, replikace po obnovení konektivity.
• Idempotence a de-dup: zabránění duplicitám při opakovaném odeslání.

Orchestrace a softwarový stack na edge

• Kontejnerizace: Docker/OCI obrazy, lehké runtime (containerd), rootless režimy.
• Orchestrátory: K3s/MicroK8s pro nízké nároky, Nomad jako single-binary; u MEC plnohodnotné Kubernetes s node-taints, affinity, Topolvm/Local PV.
• IoT runtimy: lokální MQTT broker, stream procesory (Flink Lite, EdgeX), funkce (Knative/Function as a Service na edge).
• Model serving: Triton, OpenVINO, TensorRT server; HW akcelerace (GPU, NPU, TPU, VPU).

Hardware pro edge: průmyslové parametry

• Robustnost: teplotní rozsah, vibrace, odolnost vůči prachu (IP krytí), bezventilátorové provedení, napájení 12/24 V s přepěťovou ochranou.
• Akcelerace: nízkopříkonové GPU/NPU (MIPI/PCIe), inference 5–50 TOPS, NVMe pro lokální úložiště, ECC paměť.
• Konektivita: 5G (slicing), Wi-Fi 6/7, TSN Ethernet pro deterministické průmyslové sítě.

Bezpečnost: zero-trust a životní cyklus zařízení

• Root of Trust, TPM/SE, zabezpečené bootování, měření integrity.
• Identita zařízení (X.509/IoT Hub registr), vzájemné TLS, krátkodobé certifikáty s pravidelnou rotací.
• Segmentace: micro-segmentation, SD-WAN, politiky na úrovni L3–L7; deny-by-default.
• Aktualizace OTA: A/B oddíly, rollback, podepisované artefakty, staged rollout.
• Hardening: minimal base image, sběr auditních logů lokálně s dávkovou replikací.

Data governance: suverenita, soukromí a minimalizace dat

• Data minimization: na edge provádějte filtrování/anonimizaci (např. rozostření obličejů na kameře), do cloudu posílejte pouze agregáty.
• Retention a klasifikace: oddělené retenční politiky pro surová vs. odvozená data; evidujte původ (provenienci) a verze modelů.
• Šifrování: v klidu (LUKS/NVMe OPAL) i za provozu; správa klíčů s lokálním envelope a pravidelnou rotací.

Ekonomika: kde edge šetří a kde přidává náklady

• Úspora přenosů: menší objem egressu do cloudu, nižší opakované poplatky za data.
• CAPEX: hardware a lokální instalace, servisní zásahy, redundantní napájení a klimatizace.
• OPEX: flotilový management, monitoring, patching; náklady rostou s počtem lokalit.

ML/AI na edge: MLOps a životní cyklus modelů

1. Trénink probíhá v cloudu (GPU farmy, datová jezera).
2. Komprese modelů: kvantizace (INT8), pruning, distilace, kompilace pro NPU/VPU.
3. Distribuce na edge (OTA), správa verzí, canary nasazení, shadow inference.
4. Monitorování výkonu (drift, přesnost), telemetrie a zpětný sběr vzorků pro re-trénink.

Observabilita a správa flotily

• Metriky/Logy/Traces lokálně s agregací (Prometheus/Vector/Tempo) a dávkovou replikací do cloudu.
• Inventář a desired state: deklarativní GitOps, device twin, compliance skeny.
• SLA/SLO: definujte lokální cíle dostupnosti a latence, nejen cloudová SLO.

Typické scénáře použití

• Průmysl (IIoT): detekce anomálií, prediktivní údržba, kontrola kvality pomocí vizuálního rozpoznání v linkách (< 50 ms).
• Retail: analýza provozu, dynamické reklamy, samoobslužné pokladny, offline provoz.
• Zdravotnictví: lokální inference medicínského obrazu, ochrana soukromí dat, nízká latence pro lékařská zařízení.
• Automotive/V2X: asistenční systémy, mapové dlaždice z MEC, kooperativní vnímání.
• Media/AR/VR: renderování blízko uživatele, nízká latence streamingu.

Vzory integrace cloud–edge

• Edge-native + cloud analytics: kritická logika běží na edge, dlouhodobé uložení a BI v cloudu.
• Cloud-assisted edge: cloud orchestruje distribuci modelů, konfigurací a agregaci metrik.
• Split inference: extrakce předzpracovaných znaků na edge, náročný model v cloudu/MEC.
• Content caching: CDN/MEC cache pro AR mapy nebo firmware.

Standardy a protokoly (výběr)

• Průmyslové: OPC UA, TSN, DDS pro real-time pub-sub.
• IoT: MQTT 3.1.1/5.0, CoAP, LwM2M pro správu zařízení.
• Datové: Arrow/Parquet pro batch zpracování, gRPC pro nízkolatenční RPC.
• Bezpečnost: mTLS, OAuth2/OIDC na branách, X.509 pro zařízení.

Časté chyby a jak se jim vyhnout

• Ignorování offline režimů: nutnost store-and-forward, idempotence a lokální pravidla.
• Monolitické nasazení: preferujte malé, izolované služby s jasně definovanými SLA.
• Nedostatečná správa tajemství: používání vault/PKI, rotace klíčů, vyvarujte se statických hesel v obrazech.
• Podcenění provozního hluku: log rate-limit, lokální sampling, backoff strategie.
• Bez testů latence: měřte reálnou end-to-end odezvu, nejen CPU/GPU benchmarky.

Rozhodovací rámec: kdy edge, kdy cloud

• Preferujte edge, pokud požadavek na odezvu je < 100 ms, připojení je omezené nebo drahé, je potřeba datová suverenita, případně provoz při výpadku WAN.
• Preferujte cloud, pokud požadujete masivní škálování, kolaborativní zpracování, datová jezera, pokročilé spravované služby (ML trénink, DWH) a globální dostupnost.
• Volte hybridní řešení, jestliže časově kritické části běží lokálně a zbytek (archiv, fleet management, BI) v cloudu.

Kontrolní seznam pro návrh edge řešení

1. Definujte SLO latence, režimy při výpadku a požadavky na suverenitu dat.
2. Zvolte edge topologii (device/gateway/MEC) a HW akceleraci dle workloadu.
3. Návrh datové cesty: ingest, filtry, inference, akce, lokální persistenci, replikaci.
4. Orchestrace a OTA strategie (A/B, canary, rollback), GitOps workflow.
5. Bezpečnost: root of trust, mTLS, správa klíčů, segmentace, audit.
6. Observabilita: metriky, logy, traces, inventář, zdravotní sondy, alerty.
7. Ekonomika: TCO (CAPEX/OPEX), úspory na egressu vs. náklady na správu flotily.
8. Testy: E2E latence, výpadky WAN, degradace HW, dlouhodobý soak test.

Závěr: edge a cloud jako komplementární vrstvy

Edge computing nepř