vikasietoisuusstream-prosessointihajautetut järjestelmätpilvipalvelutdatatekniikkaPilvi ja infrastruktuuri
Tavun siirtymän tarkistuspiste vs. tilaton palautus
Tavuoffset-tarkistuspisteytys ja tilaton palautus edustavat perustavanlaatuisesti erilaisia lähestymistapoja vikasietoisuuteen hajautetuissa järjestelmissä. Ensimmäinen säilyttää tarkat datavirran sijainnit tarkkaa jatkamisominaisuutta varten, kun taas jälkimmäinen rakentaa tilan uudelleen tyhjästä käyttämällä muuttumattomia tietolähteitä ja vähentää tallennustilan ylimääräistä kuormitusta rekonstruoinnin yksinkertaistamiseksi.
Korostukset
Tavun offset-tarkistuspisteet mahdollistavat millisekuntitason palautuksen jatkamalla tarkasta virran sijainnista sen sijaan, että tila rakennettaisiin uudelleen tyhjästä.
Tilaton palautus poistaa kokonaisen luokan hajautettujen järjestelmien ongelmia, jotka liittyvät tilannevedosten yhtenäisyyteen ja tilasynkronoimiseen.
Tarkistuspisteiden tehokkuus heikkenee merkittävästi epädeterminististen operaatioiden tai epäidempotenttien ulkoisten kutsujen yhteydessä, mikä luo piilevää monimutkaisuutta.
'Valtiottomuus'-leima on usein harhaanjohtava – todellinen valtiottomuus edellyttää tilan siirtämistä ulkoisiin järjestelmiin, mikä pikemminkin siirtää kuin poistaa operatiivista taakkaa.
Mikä on Tavun siirtymän tarkistuspiste?
Vikasietoisuustekniikka, joka tallentaa tarkat tavujen sijainnit tietovirroissa, jotta virheiden jälkeen voidaan palauttaa tiedot tarkasti.
Alun perin Apache Flinkin ja Kafka Streamin kaltaisissa stream-prosessointijärjestelmissä, jotka käsittelivät täsmälleen kerran tapahtuvaa semantiikkaa.
Tallentaa minimaalisesti metadataa (osiotunnus + offset) täydellisten tilakuvien sijaan, mikä pienentää tarkistuspisteen kokoa merkittävästi
Mahdollistaa alle sekunnin palautumisajat monissa tuotantokäyttöönotoissa välttämällä täydellisen tilan uudelleenrakentamisen
Vaatii kestävän, uudelleenpelattavan lokitiedostojen tallennustilan (yleensä Kafka, Pulsar tai Kinesis) toimiakseen oikein
Tulee monimutkaiseksi käsiteltäessä epädeterministisiä operaatioita tai idempotenssin puutteesta johtuvia ulkoisia järjestelmän vuorovaikutuksia
Mikä on Tilaton palautus?
Palautusparadigma, jossa prosessointisolmut rakentavat tilan kokonaan uudelleen raakadatasta ylläpitämättä paikallista pysyvää tilaa.
Ammentaa inspiraationsa Netflixin ja AWS Lambdan suosimista funktionaalisista ohjelmointiperiaatteista ja muuttumattomista infrastruktuurimalleista
Poistaa tarpeen hajautetuille tilannevedosten koordinointiprotokollille, kuten Chandy-Lamportille, mikä yksinkertaistaa järjestelmäarkkitehtuuria
Tyypillisesti johtaa hitaampiin palautumisaikoihin suhteessa uudelleenkäsiteltävien historiallisten tietojen määrään
Toimii tehokkaimmin yhdistettynä deterministisiin prosessointifunktioihin ja toistettaviin syötelähteisiin
On saavuttanut jalansijaa palvelimettomassa laskennassa ja mikropalveluissa, joissa lyhytaikaiset kontit ovat normi
Vertailutaulukko
Ominaisuus
Tavun siirtymän tarkistuspiste
Tilaton palautus
Tilatallennustila
Minimaalinen (vain siirtymät)
Ei mitään (kokonaan hylätty)
Palautumisnopeus
Erittäin nopea (jatkaa vikaantumiskohdasta)
Hitaampi (vaatii täydellisen uudelleenkäsittelyn)
Varastointikustannukset
Matala (kilotavua metadataa)
Nolla (ei säilytettyä tilaa)
Tietolähdevaatimus
Kestävä ja uudelleenpelattava loki
Täydellinen historiallinen aineisto saatavilla
Toteutuksen monimutkaisuus
Korkeampi (koordinointi, täsmälleen kerran käsittely)
Alempi (yksinkertaisempi käsitteellinen malli)
Soveltuvuus suurille valtioille
Erinomainen (ulkoistettu lokiin)
Huono (uudelleenkäsittely skaalautuu datamäärän mukaan)
Determinismin vaatimukset
Tiukka (epädeterminismi keskeyttää toipumisen)
Kohtalainen (idempotenssi edelleen tärkeä)
Yksityiskohtainen vertailu
Perusfilosofia
Tavun offset-tarkistuspisteet käsittelevät tapahtumalokia ainoana totuuden lähteenä ja ylläpitävät samalla tarkkoja kirjanmerkkejä kyseiseen lokiin. Järjestelmä tunnistaa tilan olemassaolon ja seuraa tarkasti sen alkuperää. Tilaton palautus puolestaan omaksuu lyhytaikaisuuden – mikä tahansa solmu voi kuolla milloin tahansa, koska siellä ei ole mitään todellista elämää. Tämä filosofinen jako heijastaa järjestelmäsuunnittelun laajempia jännitteitä optimoinnin ja yksinkertaisuuden välillä.
Toiminnalliset ominaisuudet
Tarkastuspisteillä varustettuja järjestelmiä käyttävät tuotantotiimit käyttävät merkittävästi suunnittelutyötä tarkastuspisteiden välisten välien hienosäätöön tasapainottaen palautumisnopeutta ajonaikaisten lisäkustannusten kanssa. Liian usein tehtävät tarkastuspisteet tuhlaavat resursseja, liian harvoin tehtävät tarkastuspisteet taastoistetaan liikaa dataa. Tilattomat järjestelmät korvaavat tämän hienosäätötaakan ennustettavissa olevilla, mutta mahdollisesti tuskallisilla palautusskenaarioilla, joissa solmun vikaantuminen ruuhka-aikaan voi laukaista kaskadoituvia uudelleenkäsittelyviiveitä.
Yhdenmukaisuustakuut
Tarkistuspistejärjestelmät voivat tarjota täsmälleen kerran tapahtuvan käsittelyn semantiikkaa yhdistettynä ulkoisiin järjestelmiin tehtäviin transaktionaalisiin päivityksiin, vaikka tämä vaatii sivuvaikutusten huolellista käsittelyä. Tilaton palautus luonnollisesti kallistuu ainakin kerran tapahtuvan semantiikan puoleen, koska uudelleenkäsittely on luontaista, mikä tekee siitä paremmin sopivan idempotentteihin operaatioihin tai tilanteisiin, joissa kaksoiskappaleiden käsittelyä tapahtuu alajuoksulla.
Resurssitaloustiede
Kokonaiskustannuskuva yllättää monia ammattilaisia. Checkpointing aiheuttaa jatkuvia tallennus- ja verkkokustannuksia metadatan osalta, mutta säästää laskentatehoa palautuksen aikana. Tilaton ratkaisu vaikuttaa halvemmalta siihen aamuyön kolmen aikaan asti, jolloin alueellinen käyttökatkos pakottaa kuuden kuukauden klikkausdatan täydelliseen uudelleenkäsittelyyn. Organisaatiot, joilla on ennustettavissa olevat ja rajatut toistotarpeet, pitävät usein tilatonta ratkaisua houkuttelevana; organisaatiot, joilla on tiukat palvelutasosopimukset ja suuret historialliset ikkunat, eivät yleensä pidä siitä.
Ekosysteemin ja työkalujen kypsyys
Apache Kafkan kuluttajaryhmäprotokolla on tehnyt offset-hallinnan lähes näkymättömäksi kehittäjille, ja automaattiset commitit ja kuluttajaviiveen seuranta ovat nyt vakiona. Tilattomat mallit ovat edelleen enemmän tee-se-itse-periaatteella, vaikka kehykset, kuten AWS Lambdan provisioitu samanaikaisuus ja Kubernetesin lyhytaikaiset säilöt, ovatkin lähestymässä hallittuja tilattomia primitiiviratkaisuja. Työkalukuilu kapenee, mutta ei ole umpeutunut.
Hyödyt ja haitat
Tavun siirtymän tarkistuspiste
Plussat
+Nopea vikaantuminen
+Alhainen tallennustilan käyttö
+Täsmälleen kerran semantiikka mahdollista
+Kypsä työkaluekosysteemi
+Tarkka edistymisen seuranta
Sisältö
−Monimutkainen täsmälleen kerran -toteutus
−Epädeterminismin käsittely
−Hajautetun koordinoinnin yleiskustannukset
−Ulkoisen järjestelmän riippuvuus
−Tarkastuspisteen taajuuden virittäminen
Tilaton palautus
Plussat
+Käsitteellinen yksinkertaisuus
+Ei tilannekuvan koordinointia
+Vaakasuuntainen skaalaus
+Ei valtion korruptioriskiä
+Infrastruktuurin joustavuus
Sisältö
−Hitaammat palautumisajat
−Täydelliset uudelleenkäsittelykustannukset
−Historiallisen datan saatavuus
−Oletusarvoisesti ainakin kerran
−Latenssi uudelleenrakennuksen aikana
Yleisiä harhaluuloja
Myytti
Tilaton palautus tarkoittaa, että järjestelmässä ei ole mitään tilaa.
Todellisuus
Todellinen tilattomuus on harvinaista; useimmat 'tilattomat' arkkitehtuurit yksinkertaisesti siirtävät tilan tietokantoihin, välimuisteihin tai objektien tallennustilaan. Suoritinsolmut itsessään voivat olla tilattomia, mutta järjestelmä kokonaisuutena hallitsee silti tilaa – vain erilaisten abstraktioiden avulla. Tämän eron ymmärtäminen estää arkkitehtonisia yllätyksiä skaalattaessa.
Myytti
Tavun offset-tarkistuspisteytys takaa täsmälleen kerran tapahtuvan automaattisen käsittelyn.
Todellisuus
Pelkkä tarkistuspisteytys tarjoaa vain vähintään kerran tapahtuvan toimituksen. Täsmälleen kerran tapahtuvan semantiikan saavuttaminen edellyttää transaktionaalisia päivityksiä nieluihin, idempotentteja toimintoja tai deduplikaatiomekanismeja. Offset-kirjanmerkki estää lähdedatan uudelleenlukemisen, mutta ilman sivuvaikutusten käsittelyä kaksoiskappaleet voivat silti levitä putkessa.
Myytti
Valtioton palautus on aina halvempaa käyttää.
Todellisuus
Vaikka tarkistuspisteiden tallennuksen poistaminen vähentää kustannuksia jonkin verran, palautuksen aikana tapahtuvan täydellisen uudelleenkäsittelyn vaatima laskentateho voi pienentää säästöjä. Järjestelmä, joka vikaantuu harvoin pienellä tilalla, saattaa tosin olla halvempi tilaton, mutta suuret vikaantumisasteet tai suuret historialliset ikkunat tekevät tarkistuspisteistä usein kokonaisuudessaan taloudellisempia.
Myytti
Nykyaikainen pilvi-infrastruktuuri tekee tarkastuspisteistä tarpeettomia.
Todellisuus
Palvelimettomien ja konttiorkestrointiratkaisujen edistysaskeleista huolimatta monet suuren läpimenon järjestelmät ovat edelleen riippuvaisia tarkistuspisteistä alle sekunnin nopeuden palautumisessa. Pilvinatiivi ei poista palautusnopeuden ja jälleenrakennuskustannusten välistä perustavanlaatuista kompromissia – se tarjoaa vain erilaisia toteutusvaihtoehtoja molemmille lähestymistavoille.
Myytti
Sinun on valittava yksinomaan näiden kahden lähestymistavan välillä.
Todellisuus
Hybridiarkkitehtuurit ovat yhä yleisempiä, ja kriittiset polut käyttävät nopeuden takaamiseksi tarkistuspisteitä ja apuprosessointi yksinkertaisuuden vuoksi tilattomia malleja. Tämä dikotomia on enemmän pedagoginen kuin käytännöllinen; kehittyneet järjestelmät usein kerrostavat molemmat lähestymistavat datan kriittisyyden ja latenssivaatimusten mukaan.
Usein kysytyt kysymykset
Mitä lennonaikaisille tiedoille tapahtuu, kun tarkastuspiste otetaan käyttöön?
Lennon aikainen data on yksi tarkastuspistejärjestelmien hankalimmista haasteista. Useimmissa toteutuksissa käytetään estemekanismia, jossa erityinen markkeri etenee datavirran läpi, ja kun kaikki operaattorit kuittaavat sen vastaanottamisen, tarkastuspiste tallentaa yhdenmukaisen tilannekuvan. Kaikki esteen jälkeen saapuva data kuuluu seuraavaan epookkiin. Tämä Apache Flinkin kehittämä lähestymistapa varmistaa, että jopa kesken käsittelyn oleva data osoitetaan johdonmukaisesti joko tarkastuspistettä edeltävään tai tarkastuspisteen jälkeiseen tilaan.
Miten tilaton palautus käsittelee virheet uudelleenkäsittelyn aikana?
Tässä kohtaa tilaton palautus paljastaa rekursiivisen haavoittuvuutensa. Jos solmu kaatuu jo palautumisen aikana, se yksinkertaisesti aloittaa alusta. Käytännössä tämä tarkoittaa, että tilattomat järjestelmät tarvitsevat erittäin luotettavan infrastruktuurin palautusjaksojen aikana tai ne ottavat käyttöön osittaisen edistymisen seurannan – mikä alkaa näyttää epäilyttävästi tarkistuspisteytykseltä. Useimmat tuotantoympäristössä olevat tilattomat järjestelmät lisäävät kevyitä syke- tai edistymismekanismeja estääkseen loputtomat palautussilmukat.
Voiko tavuoffset-tarkistuspisteytys toimia muiden kuin Kafka-suoratoistolähteiden kanssa?
Ehdottomasti, vaikka yksityiskohdat vaihtelevatkin. Pulsar käyttää kohdistimen sijainteja, Kinesis käyttää järjestysnumeroita ja mukautetut lokitoteutukset voivat määritellä omat offset-analoginsa. Keskeinen vaatimus on toistettava, järjestetty, kestävä loki, jolla on vakaa sijainti. Viestijonojärjestelmät, joilla ei ole näitä ominaisuuksia – kuten jotkut MQTT-välittäjät tai yksinkertaiset pub/sub-järjestelmät – eivät tue todellista offset-tarkistuspistettä ja vaativat erilaisia vikasietoisuusstrategioita.
Miksi jotkut insinöörit kutsuvat tilatonta palautumista "vian hyväksymiseksi" sen sijaan, että he käsittelisivät sitä?
Ilmaus kuvaa filosofista muutosta järjestelmäsuunnittelussa. Sen sijaan, että investoitaisiin voimakkaasti vikojen vaikutusten estämiseen tai minimointiin, tilaton palautus olettaa vikojen olevan normaaleja ja optimoi helpon jälleenrakennuksen. Se on samanlaista kuin Netflixin Chaos Monkey tarkoituksella aiheuttaa vikoja varmistaakseen vikasietoisuuden. "Omaksumis"-kehystys tunnustaa, että suurissa hajautetuissa järjestelmissä viat ovat väistämättömiä – tilaton palautus vain muuttaa sitä, miltä "käsittely" näyttää.
Mitä tietoturvavaikutuksia tarkastuspistetietojen tallentamiseen liittyy?
Tarkastuspisteiden metatiedot sisältävät arkaluonteisia tietoja käsittelypaikoista ja mahdollisesti liiketoimintalogiikan tilasta. Säännellyillä toimialoilla nämä tiedot saattavat vaatia salausta sekä levossa että siirron aikana, käyttöoikeuksien lokitietoja ja säilytyskäytäntöjä. Tilaton palautus pienentää hyökkäyspinta-alaa poistamalla pysyvät tilatallennukset, mutta tuo mukanaan riskejä tietojen uudelleenkäsittelyyn – historiallisten tietojen toistaminen saattaa altistaa ne vaarantuneille solmuille tai luvattomalle käytölle palautusjaksojen aikana.
Miten nämä lähestymistavat vertautuvat GDPR:n tai CCPA:n noudattamiseen?
Tarkistuspisteiden käyttö monimutkaistaa poisto-oikeutta koskevia pyyntöjä, koska siirtymät voivat viitata poistettaviin tietoihin. Järjestelmien on toteutettava lokien tiivistäminen, hautakivitys tai tarkistuspisteiden mitätöinti tämän käsittelemiseksi. Tilaton palautus yksinkertaistaa joitakin näkökohtia, koska mikään pysyvä tila ei sisällä henkilökohtaisia tietoja, mutta taustalla olevat toistettavat lokit sisältävät edelleen sääntelyn alaisia historiatietoja. Kumpikaan lähestymistapa ei poista vaatimustenmukaisuustyötä; ne vain siirtyvät sinne, missä monimutkaisuus ilmenee.
Onko tarkistuspisteistä suorituskykyrangaistus normaalin toiminnan aikana?
Kyllä, vaikka nykyaikaiset toteutukset minimoivat sen. Synkroniset tarkastuspisteet estävät prosessoinnin lyhyesti, kun taas asynkroniset tarkastuspisteet käyttävät kopioi-kirjoitustekniikkaa tilan tallentamiseen pysäyttämättä maailmaa. Rangaistus ilmenee lisääntyneenä viiveenä jitterinä, lisääntyneenä verkkoliikenteenä tarkastuspisteiden tiedonsiirtoa varten ja tallennustilan I/O:na. Virittäminen tarkoittaa sen optimaalisen pisteen löytämistä, jossa tarkastuspisteiden taajuus tarjoaa riittävän palautustarkkuuden hallitsematta järjestelmäresursseja.
Milloin yritys siirtyy yhdestä lähestymistavasta toiseen?
Migraatio seuraa tyypillisesti liiketoiminnan kehitystä. Startupit aloittavat usein tilattomina kehitysnopeuden vuoksi ja lisäävät sitten tarkistuspisteitä palvelutasosopimusten tiukentuessa ja asiakkaiden käyttöaikaodotusten kasvaessa. Toisaalta yritykset yksinkertaistavat joskus liian monimutkaisia tarkistuspisteillä varustettuja järjestelmiä tilattomiksi, kun ne huomaavat, että niiden todelliset palautumisaikatavoitteet ovat alun perin määriteltyjä löyhempiä tai kun operatiiviset kustannukset ylittävät nopean palautumisen arvon.
Miten pilvipalveluntarjoajan tarjoukset vaikuttavat tähän valintaan?
AWS Lambdan lyhytaikainen suoritusmalli suosii vahvasti tilattomia toimintamalleja, kun taas AWS Kinesis ja MSK tarjoavat hallittua offset-seurantaa, joka tekee tarkistuspisteistä lähes läpinäkyviä. Azure Event Hubs ja Google Cloud Pub/Sub tarjoavat samanlaista hallittua asemointia. Tarjoajan abstraktiotaso on tärkeä – alemman tason IaaS jättää enemmän päätöksiä arkkitehtien tehtäväksi, kun taas korkeamman tason PaaS-tarjoukset sisältävät yhä enemmän mielipiteisiin perustuvia palautusmekanismeja, jotka voivat rajoittaa tai yksinkertaistaa valintaa.
Mikä on täsmälleen kerran -semaniikan rooli näiden lähestymistapojen välillä valinnassa?
Tasan kerran -toteutus on usein ratkaiseva tekijä. Rahoitustapahtumat, varastonhallinta ja laskutusjärjestelmät vaativat sitä usein, mikä pyrkii kohti tarkistuspisteitä transaktionaalisten nielujen avulla. Analytiikka-, valvonta- ja suosittelujärjestelmät sietävät usein ainakin kerran -toteutuksen ja deduplikaation alavirran puolella, mikä tekee tilattomasta palautuksesta kannattavan. Tasan kerran -toteutuksen kustannukset tilattomissa järjestelmissä – tyypillisesti ulkoisten idempotenssiavainten avulla – ylittävät joskus pelkän tarkistuspisteiden käyttöönoton alusta alkaen.
Tuomio
Valitse tavuoffset-tarkistuspiste, kun järjestelmäsi käsittelee suurnopeuksisia tietovirtoja, joilla on tiukat latenssivaatimukset, ja voit investoida toiminnalliseen monimutkaisuuteen. Valitse tilaton palautus, kun yksinkertaisuus, horisontaalinen skaalautuvuus ja satunnaisten uudelleenkäsittelyviiveiden sietokyky ovat tärkeämpiä kuin välittömän vikasietoisuuden tarve. Monet kypsät organisaatiot omaksuvat lopulta hybridilähestymistapoja, joissa kriittiset polut tarkastetaan samalla, kun apukäsittely pidetään tilattomana.
