Analüütiline ülevaade füüsilistest, majanduslikest ja arhitektuursetest jõududest, mis viivad arvutusi ümber andmekeskusest tööstuslüüsi, ning argument, miks lüüs kujutab endast äärte arvutuslaine praegust tasakaalupunkti.
Preambula
Arvutustehnika ajalugu on ühel lugemisel olnud tsentraliseerimise ja jaotamise vahelise võnkejada. Suurarvuti andis teed miniarvutile, mis andis teed personaalarvutile, mis andis teed klient-serverile, mis andis teed veebile, mis andis teed pilvele. Lõpliku sünteesina on selles osalejad jutustanud iga tsükli. Ükski pole olnud.
Praegune võnkumine – erinevalt märgistatud servaarvutus, uduarvutus, pilvenarvutus ja mitme juurdepääsuga servade arvutus – tähistab teist faasinihet. Arvutamine liigub hüperskaalarite andmekeskustest andmete genereerimise punktide poole. Populaarne narratiiv käsitleb seda ühtse nähtusena. Ei ole. Edge on muutunud katusterminiks, mis peidab endas vähemalt nelja erinevat arhitektuurimustrit, millest igaüks on ajendatud erinevate jõudude poolt ja mida piiravad erinevad reaalsused.
See artikkel teeb kolme asja. Esiteks teeb see üheselt mõistetavaks termini servaarvutus, pakkudes välja kihilise taksonoomia. Teiseks uurib see füüsilisi, majanduslikke ja regulatiivseid jõude, mis suunavad arvutusi võrgu perifeeria poole. Kolmandaks ja kõige kesksemalt väidab ta, et lüüsikiht – seadme ja pilve vaheline kohapealne tööstusliku andmetöötluse tasand – esindab selle migratsiooni praegust tasakaalupunkti. Lüüs ei ole äärelaine lõppsihtkoht, kuid see on koht, kus praegused jõud koonduvad: riistvaravõime, turbetopoloogia, halduspiir ja majanduslik stiimul joonduvad siin nii, et need ei joondu seadme serva või võrgu servaga.
Argument on mõeldud olema kasulik nii süsteemiarhitektidele, kes kavandavad tööstusliku IoT kasutuselevõttu, kui ka teadlastele, kes uurivad hajutatud andmetöötluse poliitilist ökonoomiat.
"Edge" taksonoomia
Segamine on äärearvutusdiskursuse peamine segaduse allikas. Kui hüperskaleerija turustab serva, tähendab see tavaliselt piirkondlikku asukohapunkti lõppkasutajatest ~50–100 km kaugusel. Kui telekommunikatsioonioperaator turustab edge'i, tähendab see tavaliselt raadiojuurdepääsuvõrgu infrastruktuuriga ühist asukohta arvutamist. Kui tööstusautomaatika müüja turustab edge, tähendab see tavaliselt lüüsi või PLC-d tehase põrandal. Kui mikrokontrolleri müüja turustab edge, tähendab see tavaliselt otse anduriseadmel töötamist. Need ei ole samad asjad ja ühest kontekstist koostatud arhitektuurilised soovitused kukuvad tavaliselt teise ülekandmisel läbi.
Rangem ravi eristab vähemalt nelja taset:
Seadme serv. Arvutamine on anduri või täiturmehhanismi kaasresident. Riistvara ulatub 32-bitistest ARM Cortex-M mikrokontrolleritest (töötavad alla 1 W) kuni väikeste ARM Cortex-A rakendusprotsessoriteni. Mälu mõõdetakse tavaliselt kilobaitides kuni madalate megabaitideni. Tarkvaravirnad on metallist, RTOS-põhised (FreeRTOS, Zephyr) või eemaldatud Linux. Sellele tasemele sobivates töökoormustes domineerivad signaali konditsioneerimine, lihtne lävimine, kerge järeldus (TinyML) ja protokolli tõlkimine.
Lüüs / kohapealne serv. Arvutamine koondamispunktis, mis asub koos seadmega, mida see teenindab, kuid ei ole manustatud üksikutesse seadmetesse. Riistvara on tavaliselt lüüsiklassi: ARM Cortex-A53/A72/A76 või tagasihoidlik x86, 512 MB kuni 16 GB muutmäluga, mis töötab 5-25 W ümbrises. Määravaks tunnuseks on piisav võime käitada Linuxi täielikku distributsiooni konteinerite, mitme samaaegse töökoormuse ja tagasihoidliku ML-i järeldamisega, jäädes samas koguseliselt juurutamiseks piisavalt odavaks. Seda taset käesolev artikkel peamiselt puudutab.
Network edge / multi-access edge computing (MEC). Arvutus, mida haldab võrgupakkuja, tavaliselt telekommunikatsioonioperaator, mis majutatakse raadiojuurdepääsuvõrgu infrastruktuuris või koondamissaitides või nende läheduses. Standarditud ETSI GS MEC 003 [1] ja sellega seotud spetsifikatsioonide alusel. Riistvara on serveriklass. Edasi-tagasi latentsus lõppseadmeteni on 5G URLLC stsenaariumide korral suurusjärgus 1–10 ms. Administratiivne omandiõigus on vedajal, mitte rakenduse omanikul – fakt, mille olulisust sageli alahinnatakse.
Piirkondlik serv. Arvutus, mida juhivad suurlinnapiirkonna rajatiste hüperskaalajad või sisuedastusvõrgud. Näited hõlmavad AWS-i kohalikud tsoonid, Azure Edge'i tsoonid, Google Distributed Cloud Edge, Cloudflare Workers ja laiem CDN-i arvutuskiht (Fastly Compute@Edge, Akamai EdgeWorkers). Edasi-tagasi latentsus lõppseadmeteni on piirkonnas tavaliselt 10–40 ms. Riistvara on andmekeskuse klass.
Need tasemed erinevad vähemalt seitsme sõltumatu dimensiooni järgi: edasi-tagasi reisi latentsusaeg, energia ümbris, arvutusvõimsus, administratiivne omand, turvapiirkond, juurutustihedus ja majanduskulu arvutusühiku kohta. Töökoormuse optimaalne paigutus määratakse selle järgi, milliste mõõtmete suhtes see on kõige tundlikum, ja tasandite segamine varjab neid kompromisse.
Ülejäänud osa sellest artiklist puudutab teist taset – lüüsi – ja põhjuseid, miks see on kujunenud tööstuslikes kontekstides tänapäevase servade juurutamise domineerivaks asukohaks.
Edge migratsiooni teoreetilised draiverid
Miks arvutamine üldse väljapoole liigub? Ränne põhjustab viis erineva vanuse ja analüütilise täpsusega jõudu.
2.1 Latency Floor
Enim tsiteeritud autojuht on ka füüsiliselt kõige vältimatum: valguse kiirus. Kiududes levivad elektromagnetilised signaalid kiirusega umbes 200 000 km/s – ligikaudu kaks kolmandikku valguse vaakumi kiirusest. Edasi-tagasi reis Frankfurdi ja Põhja-Virginia, Euroopa ja Põhja-Ameerika pilvede läbilaskevõime geograafiliste keskuste vahel, läbib ligikaudu 6200 km kiudude teed, mis annab teoreetiliseks minimaalseks edasi-tagasi reisi ajaks 62 ms enne mis tahes ümberlülitamist, järjekorda või protokolli lisakulusid. Täheldatud RTT-d on praktikas 80-100 ms.
See põrand ei sõltu ribalaiusest, protokolli disainist ega eelarvest. See on füüsika funktsioon. Juhtkontuuride puhul, mis peavad sulguma 10 ms jooksul – rutiinne nõue liikumisjuhtimises, robootikas ja teatud protsessijuhtimisrakendustes – peab kogu tagasisidetee asuma ligikaudu 1000 km kiust raadiuses. Praktikas tähendab see kohapealset või kõige agressiivsema stsenaariumi korral suurlinnapiirkonda.
Peenem punkt: latentsusaeg ei ole oluline mediaan (p50), vaid saba (p99 või p99.9). Interneti-teedel on märkimisväärne latentsusaja erinevus järjekordadest, BGP-konvergentsi sündmustest ja mikropakettidest. 80 ms keskmise RTT-ga tee võib näidata 200–500 ms saba latentsust. Juhtimissüsteemid peavad olema konstrueeritud vastu saba, mitte mediaani, mis vähendab veelgi pilvevahendatud juhtimisahelate jaoks saadaolevat tegelikku latentsusaega.
2.2 Andmete gravitatsiooni ja ribalaiuse ökonoomika
Jim Gray "Distributed Computing Economics" [2] sõnastas 2003. aastal selle, mida on pärast seda korduvalt uuesti avastatud: üldiselt on odavam saata arvutusi andmetesse kui andmeid arvutada, kui andmemaht ületab tagasihoidliku läve. Põhimõte on taaspopulariseeritud kui andmete gravitatsioon [3].
Tööstuslik andur muudab aritmeetiliseks konkreetseks. Pöörleval varal asuv vibratsiooniandur, mis võtab diskreetimissagedusega 25,6 kHz üle kolme telje ja 24-bitise eraldusvõimega, toodab umbes 220 KB toorandmeid sekundis vara kohta või 19 GB päevas. 500 sellise anduriga keskmise suurusega tehas genereerib ainuüksi vibratsiooni töötlemata andmeid päevas 9,5 TB. Selle voogesitamine hüperskalerile standardsete väljumiskiirustega on majanduslikult ebaotstarbekas. Isegi kui see oleks taskukohane, oleks mobiilside- või kiudoptiline üleslüli küllastunud.
Majanduslik argument on otsekohene: enamikul töötlemata tööstusandmetel ei ole nende töötlemata kujul analüütilist väärtust. Spektriomadused, mähisjoone statistika ja anomaaliate skoorid kannavad diagnostikasignaali. Arvutus, mis eraldab need funktsioonid lüüsist, vähendab üleslingi helitugevust kahe kuni kolme suurusjärgu võrra, säilitades samal ajal – ja sageli parandades – analüütilist täpsust.
2.3 Jaotustolerants kui töönõue
CAP teoreem [4][5] vormistab piirangu, millega tööstussüsteemid on alati kokku puutunud: võrgusektsioonide olemasolul peavad hajutatud süsteemid valima järjepidevuse ja kättesaadavuse vahel. Valik ei ole vabatahtlik; seda sunnib võrgutõrgete füüsiline reaalsus.
Ohutuskriitiliste ja paljude protsessikriitiliste rakenduste puhul ei ole kättesaadavus läbiräägitav. Juhtimisloogika peab jätkama toimimist, kui pilve laiaulatuslik link on kättesaamatu. Pilv võib olla registreerimissüsteem, pikaajalise poliitika korraldaja ja analüütika koht, kuid see ei saa olla hetkest-hetke kontrolli koht, välja arvatud juhul, kui pilve ja vara vahelist võrku koheldakse kõva reaalajas võrgustikuna – mida ärilistel mobiilside- või Interneti-linkidel see ei ole.
Arhitektuurne tähendus seisneb selles, et juhttasand võib asuda pilves, kuid andmetasand — juhttoimingu sulgev silmus — peab asuma lokaalselt. Lüüs on andmetasandi loomulik asukoht: varale piisavalt lähedal, et olla partitsioonitaluvus ja piisavalt võimeline mahutama olulist loogikat.
2.4 Õigusaktide killustatus ja andmete suveräänsus
Piiriülese andmeedastuse õiguslik keskkond on viimase kümnendi jooksul muutunud oluliselt piiratumaks. Andmekaitse üldmäärus [6], NIS2 direktiiv [7], Hiina küberjulgeoleku seadus ja selle isikuandmete kaitse seadus, India digitaalsete isikuandmete kaitse seadus, sektoripõhised eeskirjad (autotööstus Saksamaal, meditsiinilised andmed enamikus jurisdiktsioonides, finantsandmed peaaegu kõikjal) ja Schrems II otsus [8] on ühiselt muutnud kõik andmed automaatselt vaikimisi pilveeelsesse süsteemi ja arhivaalselt liidetud pilveautosse.
Edge töötlemine toetab andmete suveräänsust, võimaldades andmete minimeerimist allikas. Isiklikult tuvastatavaid või äriliselt tundlikke andmeid saab töödelda, muuta ja koondada territooriumil; ainult tuletatud, anonüümseks muudetud või koondatud väljundid ületavad jurisdiktsiooni piire. See ei ole marginaalne vastavuse eelis – mõne töökoormuse jaoks mõnes jurisdiktsioonis on see ainus seaduslikult lubatud arhitektuur.
2.5 Privaatsus kui arhitektuuriline primitiiv
Lisaks eeskirjadele järgimisele käsitleb kasvav tehnikaklass privaatsust esmaklassilise arhitektuurilise probleemina. Diferentsiaalne privaatsus [9] lisab seotud teabelekkega seotud statistikale kalibreeritud müra. Liitõpe [10] koolitab mudeleid hajutatud seadmete vahel ilma toorandmeid tsentraliseerimata. Turvaline liitmine [11] võimaldab arvutada kogu elanikkonna summasid, ilma et ükski osapool – sealhulgas koondaja – jälgiks individuaalseid panuseid. Konfidentsiaalne andmetöötlus [12] hõlmab arvutusi ennast.
Kõik need tehnikad nihutavad tööd andmete asukoha suunas. Lüüs kui seadmete populatsiooni koondamispunkt on nende tehnikate jaoks vajalike müra lisamise, ühendatud värskenduse või turvaliste liitmistoimingute loomulik koht. Tehnikate matemaatiline struktuur viitab arhitektuursele asukohale.
Miks just Gateway?
jaotise jõud suruvad arvutusi väljapoole. Nad ei määra ise, kuhu rajal see maandub. Värav on muutunud tööstuskeskkonnas domineerivaks asukohaks ja põhjuseid tasub hoolikalt uurida.
Gateway equilibrium across edge placement criteria
bar chart3.1 Arvutusliku elujõulisuse lävi
Seadme serv on ressursiga tugevalt piiratud. Tüüpiline tööstusliku sensoriga mikrokontroller töötab alla 100 mW, millel on kilobaiti RAM-i. See võib käitada kvantiseeritud närvivõrgu klassifikaatorit (TinyML), kuid ei saa majutada üldotstarbelist operatsioonisüsteemi, konteineri käituskeskkonda ega mittetriviaalset rakenduste pinu. Selle tarkvara tarnitakse monoliitse püsivarana, seda värskendatakse harva ja seda on raske arendada.
Piirkondlik serv on seevastu võimekas, kuid kauge. 10–40 ms RTT on paljude rakenduste jaoks vastuvõetav, kuid välistab kõige tihedamad juhtimisahelad. Veelgi olulisem on see, et piirkondlik serv on administratiivselt heterogeenne – töökoormused sõltuvad neid majutava vedaja või hüperskaalaja tegevuspoliitikast, mis ei ole alati kooskõlas tööstusettevõtte turvamudeliga.
Lüüsil on positsioon, millel pole samaväärset kummalgi küljel. Kaasaegne tööstuslik lüüs neljatuumalise ARM Cortex-A53, 2–6 TOPSi [13][14] ja 2–8 GB muutmäluga närviprotsessoriga on võimeline:
See on väikseim arvutusplatvorm, millel toimib üldotstarbeline hajutatud süsteemide tööriistaahel, ja suurim arvutusplatvorm, mis ühildub tööstuslikul kasutuselevõtul vastuvõetavate energia- ja kuludega.
- Täieliku Linuxi distributsiooni käitamine
- Konteineri käitusaja (konteiner, Podman) või orkestraatori (K3s, KubeEdge) hostimine
- Tagasihoidliku ML-i järelduse teostamine (kujutise klassifikatsioon, anomaaliate tuvastamine, ennustavad hooldusmudelid)
- Rakenduse püsiva oleku säilitamine manustatud andmebaasides
- Tööstuslike protokollide (Modbus, OPC UA, EtherNet/IP) ühendamine pilvepõhiste protokollidega (MQTT, HTTPS, gRPC)
3.2 Haldus- ja turvapiiride joondamine
Igas mittetriviaalses tööstusvõrgus on lüüsiks juba piir operatiivtehnoloogia (OT) ja infotehnoloogia (IT) vahel. See on koht, kus tulemüürid lõpevad, kus tekivad VPN-tunnelid, kus toimub protokolli tõlkimine ja kus jõustatakse juurdepääsukontroll. IEC 62443 tsoonide ja kanalite mudel [15] vormistab selle: lüüs asub OT-tsooni ja välise tsooni vahelises kanalis.
Arvutamise asukoha määramine sellel piiril joondab turvaperimeetri töökoormuse perimeetriga. Lüüsis täidetavad töökoormused pääsevad juurde OT-andmetele ilma täiendavaid usalduspiire ületamata, samas kui nende väljundid läbivad olemasoleva IT-kanali. Alternatiiv – töökoormuste käitamine pilves ja töötlemata OT-andmete väljapoole tõmbamine – loob iga töökoormuse jaoks uue ründepinna, mitmekordistades kanaleid, mida tuleb kaitsta.
See joondamine on rohkem kui mugavus. Tõelistest tööstusjuhtumitest – Triton, Industroyer, IT/OT piiri ületanud erinevad lunavarasündmused – koostatud ohumudelites on värav just see koht, mida tuleb tugevdada. Arvutamine sinna ei too kaasa uut riski; see konsolideerib riski, mis oli juba olemas.
3.3 Agregatsiooni tihedus ja statistilised töökoormused
Paljud majanduslikult kõige väärtuslikumad analüütilised töökoormused tööstuslikes tingimustes on statistilised või rahvastikupõhised: anomaaliate tuvastamine sarnaste varade pargis, prognoositavad hooldusmudelid, mis on koolitatud kohordi käitumise kohta, energia optimeerimine kogu koormuse ulatuses. Need töökoormused nõuavad oma olemuselt koondamist mitme seadme vahel.
Seadme serv ei saa definitsiooni järgi liitmist teostada – see on seadmepõhine. Pilv saab, kuid algandmete voogesituse ja partitsiooniriski talumise hinnaga. Lüüs on väikseim tasand, kus N-1 liitmine toimub loomulikult: see teenindab konstruktsiooni järgi seadmete populatsiooni. Arvutusressursse ei pea seadme kohta kordama; they can be amortized.
See mõjutab eelkõige ML töökoormust. Liitõpe töötab lüüsitasemel isegi siis, kui see seadmetasandil ei tööta – lüüsidel on osalemiseks mälu ja arvutus, ühenduvus koordineerimiseks ja koondamisulatus statistiliselt tähenduslike kohalike värskenduste loomiseks.
3.4 Töökoormuse liikuvus orkestreerimise kaudu
Kuni viimase ajani hallati lüüsiklassi riistvara fikseeritud funktsiooniga seadmetena: püsivara kujutist, mida värskendatakse harva, piiratud toimimispaindlikkusega. Viimase viie aasta areng, mis on äärearvutite ökonoomikat enim muutnud, on kerge orkestratsiooni valmimine: K3s [16], KubeEdge [17], OpenYurt, Akri ja laiem CNCF-i servaökosüsteem.
Need tööriistad toovad konteineri orkestreerimise – deklaratiivse töökoormuse spetsifikatsiooni, jooksvad värskendused, jälgitavuse, teenindusvõrgu – lüüsiklassi riistvarasse. Lüüsist saab sõidukipargi sõlm, mida hallatakse sama tööriistaahelaga nagu pilve. Töökoormused määratakse deklaratiivselt (Kubernetese manifestid, Helmi diagrammid) ja koonduvad soovitud olekusse GitOpsi kontrollerite (Argo CD, Flux, Fleet) kaudu.
The consequence is that gateways are no longer static appliances; they are programmable computing platforms with substantial portability of workload between cloud and edge. The same container image that runs in the cloud for development can run on a gateway in production with minimal modification. See välistab serva kasutuselevõtu ajaloolise karistuse – eritellimusel ehitatavad torujuhtmed, käsitsi värskendamise protseduurid, habras sõidukipargi haldamine – ja on praktiline vahend, mis on muutnud lüüsi tasandi servaarvutuse mastaapselt majanduslikult elujõuliseks.
Arhitektuurimustrid
Taksonoomiast ja draiverite komplektist ei piisa; lüüsitasandil esile kerkinud arhitektuurid väärivad omaette uurimist.
4.1 Voo töötlemine servas
Paljud tööstuslikud töökoormused väljenduvad kõige loomulikumalt voogedastusarvutustena: sissetulevad andurite andmed teisendatakse, akendatakse, koondatakse ja väljastatakse tuletatud voogudena. Pilvemastaabis vootöötluses esile kerkinud arhitektuurimustritel – lambda-arhitektuuri [18] ja lihtsama kappa-arhitektuuri [19] variandid – on ääretaseme analoogid.
Apache NiFi on muutunud tavaliseks töövoo tööriistaks lüüsitasandil (selle MiNiFi alamprojekt on suunatud täpselt sellele nišile). Ühe sõlme juurutustega Kafka või kergemad alternatiivid, nagu Redpanda, töötavad võimekatel lüüsidel. Keerukama vootöötluse jaoks laiendavad Apache Flink ning hiljutine Arroyo ja sarnased projektid mudelit.
Põhiline analüütiline küsimus lüüsitasandil on sama, mis pilveskaalal – täpselt ühe korra semantika tõrgete korral, vesimärgid korrast ära andmete jaoks, olekuhaldus üle taaskäivituste –, kuid ressursside ümbrik on erinev. Gateway vooprotsessorid peavad töötama sadade megabaitide RAM-is, mitte kümnetes gigabaitides, mis on loonud spetsiaalselt selle piirangu jaoks loodud vootöötlustööriistade põlvkonna.
4.2 ML järeldus servas
ML-i järeldamine lüüsis ei ole peamiselt seotud koolitusega; jutt käib tööajast. Mudeli koolitamine on ühekordne (või perioodiline) pilve mastaabis töökoormus. Koolitatud mudeli käitamine – järeldus – on pidev, latentsustundlik töökoormus, mis kasu on oluliselt servade paigutusest.
Tehnilised alused on hästi välja kujunenud. Kvantimist arvestav koolitus [20] vähendab mudeli kaalu 32-bitiselt ujukomalt 8-bitistele täisarvudele minimaalse täpsuskadu, mälumahu vähenemise 4 korda ja järelduste proportsionaalselt kiirendamisega. Teadmiste destilleerimine [21] koolitab kompaktseid "õpilaste" mudeleid suurematest "õpetaja" mudelitest. Struktureeritud pügamine eemaldab üleliigsed parameetrid. Närviarhitektuuri otsing [22] avastab kompaktsed arhitektuurid, mis on loodud servade juurutamiseks.
Käitusaja tööriistad on samaväärselt arenenud: TensorFlow Lite, ONNX Runtime, ExecuTorch, NVIDIA TensorRT diskreetsete GPU-dega suurema võimekusega lüüside jaoks. Riistvaraline kiirendus on lähenenud spetsiaalsetele närviprotsessoritele: Rockchipi RK3588 NPU annab 6 TOPS-i [13], lisandmooduli Hailo-8 kiirendi 26 TOPS-i [14], NXP i.MX 8M Plus integreerib tööstusliku välimusega 2.3 ja peaaegu kõigis kaasaegsetes TOPS-i seadmetes.
Tulemuseks on see, et töökoormused, mida oleks peetud alles 2018. aastal ainult pilvepõhiseks – objektide reaalajas tuvastamine, mitme muutujaga aegridade anomaalia tuvastamine, tingimuslik kõnetuvastus –, on nüüd rutiinselt juurutatud lüüsitasandil.
4.3 Ühendatud õppe- ja privaatsust säilitav koondamine
Algne koondatud keskmistamisalgoritm [10] oli mõeldud mobiilseadmete jaoks, kuid selle eeldused – osaline osalemine, statistiline heterogeensus, sidega piiratud uuendused – kehtivad otse lüüsi tasandi juurutamisel. Iga lüüs koolitab kohalikku värskendust oma kohapeal vaadeldud seadmete populatsiooni kohta; perioodilised värskendused koondatakse lüüside vahel, tavaliselt pilves asuva koordinaatori kaudu, et luua globaalne mudel, mis saab kasu elanikkonnaülesest teabest ilma toorandmeid tsentraliseerimata.
Praktiline kasutuselevõtt peab võitlema mitme mittetriviaalse väljakutsega. Statistiline heterogeensus (andmete mitte-IID olemus lüüside vahel) halvendab lähenemist; FedProx [23] ja SCAFFOLD tegelevad sellega erinevate dispersioonide vähendamise vormidega. Side tõhusust parandab gradiendi tihendamine ja kvantimine. Privaatsusrünnakud gradiendi inversiooni [24] kaudu motiveerivad erinevat privaatsust ja turvalist koondamist [11].
Praegune tehnika tase on see, et liitõpe on paljude tööstuslike ML-töökoormuste jaoks toimiv, kuid selle kasutuselevõtt ja toimimine on tsentraliseeritud koolitusest oluliselt keerulisem. Kasu peab õigustama tegevuskulusid, mis on enamasti nii, kui tsentraliseeritud andmed on iseenesest regulatiivsed või ärilised.
4.4 GitOps ja deklaratiivne servahaldus
Põhimõte on arusaadav: masinapargi soovitud olekut kirjeldatakse versiooniga juhitavas hoidlas ja lüüsid lähenevad selle oleku poole tõmbepõhiste kontrollerite kaudu. Kontroller (Argo CD, Flux) jälgib lõhet vaadeldava ja soovitud oleku vahel ning rakendab selle sulgemiseks vajalikke muudatusi.
Sellel mudelil on tuhandetest lüüsidest koosneva autopargi jaoks olulised eelised tõukepõhise juhtimise ees. Värskendused on aatomipõhised ja tagasipööratavad. Süsteem talub ajutiselt võrguühenduseta lüüsi; nad jõuavad uuesti ühenduse loomisel järele. Pargi täielik tööajalugu on salvestatud Giti ajaloosse, pakkudes auditeeritavust, mis vastab enamikule vastavusrežiimidele.
Muster on laenatud pilvepõhistest operatsioonidest peaaegu muutmata. Selle edukas tõlkimine ääretasemele on viimaste aastate üks suuremaid edusamme.
4.5 Edge-Native State Management
Rakenduse olek lüüsis peab olema vastupidav kogu taaskäivitamisel, samaaegse juurdepääsu korral ühtlane ja sünkroonitav kesksüsteemidega, kui ühenduvus seda võimaldab. Tööhobuseks jääb SQLite, mis on küps, sisseehitatud ja hästi mõistetav. Aegridade andmete jaoks on DuckDB kujunenud tugevaks analüütiliseks võimaluseks, samas kui VictoriaMetrics ja ühe sõlmega InfluxDB teenindavad operatiivmõõdikute töökoormust.
Mitme põhistsenaariumi puhul – kus mitu lüüsi või lüüs ja pilv kirjutavad samu loogilisi andmeid – pakuvad konfliktivabad replikeeritud andmetüübid (CRDT) [25] põhimõttelise aluse võimalikule järjepidevusele ilma tsentraliseeritud koordineerimiseta. CRDT-te käsitlev kirjandus on küps; tootmine tööstuslikuks servaks on endiselt esile kerkiv, kuid kiirenev (Automerge, Yjs ja sarnaseid teeke kasutatakse üha enam).
Avage Probleemid
Lüüsi tasand ei ole lahendatud süsteem. Tähelepanu väärivad mitmed lahtised probleemid.
Pargi jälgitavus mastaabis. Tuhat lüüsi, millest igaüks kiirgab telemeetriat, toodab oma telemeetria tulevooliku. Lahendamata disainiprobleem on valida, milliseid mõõdikuid väljastada, millise täpsusega, millise diskreetiga ja kuidas neid keskselt koondada, ilma et kaotaks diagnostilist täpsust. OpenTelemetry on olukorda pilvetasandil parandanud, kuid servaspetsiifilised juhised jäävad nõrgaks.
Konfidentsiaalne andmetöötlus äärel. Usaldusväärsed täitmiskeskkonnad – Intel SGX, ARM TrustZone, AMD SEV – pakuvad riistvarast isoleeritud täitmist, mis sobib tundlike andmetega töötavate töökoormustega. Nende kasutuselevõtt lüüsiklassi riistvaras on ebaühtlane: TrustZone on laialdaselt saadaval, kuid piiratud võimalustega, samas kui rikkalikumad enklaavid puuduvad lüüsiturul domineerivatest ARM-i rakendusprotsessoritest. Töökoormuste puhul, mis nõuavad lüüsis enklaavitaseme kaitset, jäävad valikud piiratud.
Mudelite elutsükli haldamine. Uue järeldusmudeli juurutamine tuhandete lüüside pargis ilma sellest sõltuvat töökoormust katkestamata nõuab A/B testimist, kanaari levitamist ja tagasipöördumist. Tööriistad on olemas pilvetasandil; selle kohandumine servatasemega on puudulik.
Skeemi areng. Kui andmemudel areneb – uus väli, ümbernimetatud mõõdik, erinev ühik –, peavad lüüsid ja pilv jääma sidusaks. Skeemiregistrid, lepingute testimine ja selgesõnaline versioonide loomine on pilvepõhiste arhitektuuride puhul hästi mõistetavad. Nende järjekindel rakendamine üle lüüsi piiri on pigem käimasoleva inseneripraktika valdkond kui lahendatud probleem.
Energiaproportsionaalne andmetöötlus. Lüüsid töötavad tavaliselt ööpäevaringselt. Tühikäigul olev energiatarve on oluline nii termiliste ümbriste kui ka kasutuskulude osas. Dünaamiline pinge ja sageduse skaleerimine, mida lauaarvuti- ja serveriprotsessorid kasutavad, on lüüsiturul domineerivate manustatud SoC-de puhul vähem tõhus. Energiatõhusus lüüsitasandil on süsteemiuuringutes vähe uuritud valdkond.
Tasakaaluargument
Keskmise väite juurde tagasi pöördudes: lüüs ei ole servaarvutuslaine lõppsihtkoht. It is the current equilibrium point.
Jõud on dünaamilised. Räni tihedus paraneb jätkuvalt; seadme tasand neelab töökoormused, mis tänapäeval nõuavad lüüsiklassi arvutusi. Konfidentsiaalne andmetöötlus küpseb sisseehitatud räni kasutamisel, mis kaotab osa lüüsi eelistest turvaperimeetri joondamisel. 5G ja 6G ülimalt töökindel madala latentsusajaga side, kui seda tegelikult mastaapselt kasutusele võetakse, võib teatud töökoormust võrgu serva poole tõmmata. Kõik need vahetused jaotavad töökoormuse nelja astme vahel.
Kuid ettenähtava horisondi – nimetage seda viieks kuni kümneks aastaks – lüüsitasand on koht, kus praegused jõud lähenevad. Selle riistvara on piisavalt võimeline üldotstarbeliste töökoormuste käitamiseks. Selle administratiivne positsioon ühtib kehtestatud turvapiiridega. Selle koondtihedus vastab väärtuslike tööstuslike töökoormuste statistilisele struktuurile. Selle tööriistad on arenenud nii kaugele, et see pole enam eritellimusel arendustöö, vaid pilvepõhiste toimingute laiendus.
Tänapäeval tööstuslikku asjade Interneti juurutamist kavandavale praktikule on see otsene mõju. Käsitlege lüüsi kui esmaklassilist arvutusplatvormi, mitte kui protokollisilda. Investeerige töökoormuse teisaldatavusse lüüsi ja pilve vahel, mitte lukustage kummagiga. Kavandage orkestreerimist, vaadeldavust ja mudeli elutsükli juhtimist algusest peale, mitte järelmõtetena. Lüüsitasand premeerib inseneriinvesteeringuid proportsionaalselt selle investeeringuga ja karistab kasutuselevõttu, mis käsitleb seda staatilise seadmena.
Serv ei ole see, kuhu arvutamine läheb. See on koht, kus compute osaliselt juba elab. Värav on koht, kus praegu asub suurem osa sellest.
References
[1] ETSI. Mobile Edge Computing (MEC); Raam- ja võrdlusarhitektuur. ETSI GS MEC 003, 2016 (muudetud).
[2] J. Gray. "Hajutatud arvutiökonoomika." Microsofti uurimistöö tehniline aruanne MSR-TR-2003-24, 2003.
[3] D. McCrory. "Andmete gravitatsioon pilvedes." 2010. aasta.
[4] E. A. Brewer. "Tugevate hajutatud süsteemide poole." Keynote, PODC 2000.
[5] S. Gilbert ja N. Lynch. "Breweri oletus ja järjepidevate, saadaolevate ja partitsioonile vastupidavate veebiteenuste teostatavus." ACM SIGACT News, 33(2), 2002.
[6] Euroopa Parlament ja nõukogu. Määrus (EL) 2016/679 (andmekaitse üldmäärus). 2016. aasta.
[7] Euroopa Parlament ja nõukogu. Direktiiv (EL) 2022/2555 (NIS2). 2022. aasta.
[8] Euroopa Liidu Kohus. Data Protection Commissioner vs. Facebook Ireland and Schrems (kohtuasi C-311/18), 2020.
[9] C. Dwork. "Erinevus privaatsus." ICALP-i toimetised, 2006.
[10] H. B. McMahan et al. "Süvavõrkude sidetõhus õppimine detsentraliseeritud andmetest." AISTATS, 2017.
[11] K. Bonawitz jt. "Praktiline turvaline koondamine privaatsust säilitava masinõppe jaoks." ACM CCS, 2017.
[12] Confidential Computing Consortium. Konfidentsiaalse andmetöötluse tehniline analüüs. 2021. aasta.
[13] Rockchip Electronics. RK3588 tehniline kasutusjuhend. 2022. aasta.
[14] Hailo Technologies. Hailo-8 AI Accelerator andmeleht. 2021. aasta.
[15] Rahvusvaheline elektrotehnikakomisjon. IEC 62443-3-3: Tööstuslikud sidevõrgud. Võrgu- ja süsteemiturve. Osa 3-3: Süsteemi turbenõuded ja turbetasemed. 2013. aasta.
[16] Rancher Labs / SUSE. K3s: kerge Kubernetes. https://k3s.io
[17] CNCF. KubeEdge: Kubernetese omapärane Edge Computing Framework. https://kubeedge.io
[18] N. Marz ja J. Warren. Suurandmed: skaleeritavate reaalajas andmesüsteemide põhimõtted ja parimad tavad. Manning, 2015.
[19] J. Kreps. "Lambda arhitektuuri küsitlemine." O'Reilly radar, 2014.
[20] B. Jacob et al. "Närvivõrkude kvantifitseerimine ja treenimine tõhusaks täisarvu aritmeetiliseks järelduseks." CVPR, 2018.
[21] G. Hinton, O. Vinyals ja J. Dean. "Teadmiste destilleerimine närvivõrgus." NeurIPSi süvaõppe töötuba, 2014.
[22] B. Zoph ja Q. V. Le. "Närviarhitektuuri otsing tugevdusõppega." ICLR, 2017.
[23] T. Li jt. "Födereeritud optimeerimine heterogeensetes võrkudes." MLSys, 2020.
[24] L. Zhu, Z. Liu ja S. Han. "Deep Leakage from Gradients." NeurIPS, 2019.
[25] M. Shapiro et al. "Konfliktivabad kopeeritud andmetüübid." SSS, 2011.
See artikkel on osa Modibusi tehnilisest sarjast. Modibus MB213 lüüsiplatvorm koos konteineripõhise rakenduskeskkonna, NPU-kiirendatud järelduste tegemise võimaluse ja deklaratiivse autopargi haldamisega on loodud siin kirjeldatud arhitektuurimustrite järgi. Tehniliste arutelude või platvormiga seotud küsimuste korral võtke ühendust [info@modibus.com](mailto:info@modibus.com).