Huomautus. käännös: Tämän materiaalin kirjoittaja on Cindy Sridharan, imgixin insinööri, joka on erikoistunut API-kehitykseen ja erityisesti mikropalvelutestaukseen. Tässä materiaalissa hän jakaa yksityiskohtaisen näkemyksensä hajautetun jäljityksen ajankohtaisista ongelmista, joissa hänen mielestään puuttuu todella tehokkaita työkaluja kiireellisten ongelmien ratkaisemiseen.
[Kuva otettu hajautetusta jäljityksestä.]
Uskotaan, että vaikea toteuttaa, ja sen tuotto . On monia syitä, miksi jäljitys on ongelmallista. Usein viitataan siihen, että kunkin järjestelmäkomponentin konfiguroinnissa tarvittiin työtä lähettämään asianmukaiset otsikot jokaisen pyynnön yhteydessä. Vaikka tämä ongelma on olemassa, se ei ole mitenkään ylitsepääsemätön. Muuten, se ei selitä, miksi kehittäjät eivät todellakaan pidä jäljittämisestä (vaikka se on jo toiminnassa).
Hajautetun jäljityksen suurin haaste ei ole tietojen kerääminen, tulosten jakelu- ja esittämismuotojen standardoiminen tai näytteenoton ajankohdan, missä ja miten määrittäminen. En yritä kuvitella triviaali nämä "ymmärrettävyysongelmat" ovat itse asiassa melko merkittäviä teknisiä ja (jos tarkastelemme todella avointa lähdekoodia) ) poliittiset haasteet, jotka on voitettava, jotta nämä ongelmat voidaan katsoa ratkaistuiksi.
Jos kuitenkin kuvittelemme, että kaikki nämä ongelmat on ratkaistu, on suuri todennäköisyys, että mikään ei muutu merkittävästi loppukäyttäjäkokemus. Jäljityksestä ei ehkä silti ole käytännön hyötyä yleisimmissä virheenkorjausskenaarioissa – edes sen käyttöönoton jälkeen.
Niin erilainen jälki
Hajautettu jäljitys sisältää useita eri osia:
- sovellusten ja väliohjelmistojen varustaminen ohjaustyökaluilla;
- hajautettu kontekstin siirto;
- jälkien kerääminen;
- jälki varastointi;
- niiden poimiminen ja visualisointi.
Paljon puhetta hajautetusta jäljityksestä on tapana käsitellä sitä eräänlaisena unaarina toimintona, jonka ainoa tarkoitus on auttaa järjestelmän täydellisessä diagnosoinnissa. Tämä johtuu suurelta osin siitä, miten hajautettua jäljitystä koskevat ajatukset ovat historiallisesti muodostuneet. SISÄÄN , tehty kun Zipkin-lähteet avattiin, mainittiin, että se [Zipkin] tekee Twitteristä nopeamman. Ensimmäiset kaupalliset tarjoukset jäljittämiseen mainostettiin myös nimellä .
Huomautus. käännös: Jotta lisätekstiä olisi helpompi ymmärtää, määritellään kaksi perustermiä sen mukaan :
- jänneväli — hajautetun jäljityksen peruselementti. Se on kuvaus tietystä työnkulusta (esimerkiksi tietokantakyselystä), jossa on nimi, alkamis- ja lopetusajat, tunnisteet, lokit ja konteksti.
- Jakovälit sisältävät yleensä linkkejä muihin jaksoihin, mikä mahdollistaa useiden jänteiden yhdistämisen Jäljittää — pyynnön käyttöiän visualisointi sen siirtyessä hajautetun järjestelmän läpi.
Jäljet sisältävät uskomattoman arvokasta tietoa, joka voi auttaa tehtävissä, kuten tuotantotestauksessa, katastrofipalautustestauksessa, virheen lisäystestauksessa jne. Itse asiassa jotkut yritykset käyttävät jo jäljitystä samankaltaisiin tarkoituksiin. Aloitetaan sillä on muita käyttötarkoituksia kuin pelkkä välien siirtäminen tallennusjärjestelmään:
- Esimerkiksi Uber jäljittää tuloksia testiliikenteen ja tuotantoliikenteen erottamiseksi toisistaan.
- Facebook jäljittää tietoja kriittisten polkujen analysointiin ja liikenteen vaihtamiseen säännöllisten katastrofipalautustestien aikana.
- Myös sosiaalinen verkosto Jupyter-muistikirjat, joiden avulla kehittäjät voivat suorittaa mielivaltaisia kyselyjä jäljitystuloksille.
- Kannattajia (Lineage Driven Failure Injection) jaettu jälkiä testausta varten virheinjektiolla.
Mikään yllä luetelluista vaihtoehdoista ei koske skenaariota kokonaan virheenkorjaus, jonka aikana insinööri yrittää ratkaista ongelman katsomalla jälkiä.
Kun se tulee vielä saavuttaa virheenkorjauskomentosarjan, ensisijainen käyttöliittymä on kaavio traceview (vaikka jotkut myös kutsuvat sitä "Gantt-kaavio" tai "vesiputouskaavio"). Alla traceview я kaikki jänteet ja niihin liittyvät metatiedot, jotka yhdessä muodostavat jäljen. Jokainen avoimen lähdekoodin jäljitysjärjestelmä sekä jokainen kaupallinen jäljitysratkaisu tarjoaa a traceview käyttöliittymä jälkien visualisointiin, yksityiskohtiin ja suodattamiseen.
Kaikkien tähän mennessä näkemieni jäljitysjärjestelmien ongelmana on, että tuloksena on visualisointi (traceview) heijastaa lähes täysin jäljenmuodostusprosessin piirteitä. Vaikka vaihtoehtoisia visualisointeja ehdotetaan: lämpökarttoja, palvelutopologioita, latenssihistogrammeja, ne päätyvät kuitenkin lopulta traceview.
Menneisyydessä minä joihin useimmat "innovaatiot" UI/UX-seurannassa näyttävät rajoittuvan lisää metadataa jäljittää, sijoittamalla niihin tietoa suurella kardinaalisuudesta (korkea kardinaliteetti) tai tarjoaa mahdollisuuden porautua tiettyihin alueisiin tai suorittaa kyselyitä inter- ja intra-trace... Jossa traceview on edelleen ensisijainen visualisointityökalu. Niin kauan kuin tämä tilanne jatkuu, hajautettu jäljitys on (parhaimmillaan) 4. sija virheenkorjaustyökaluna mittareiden, lokien ja pinojälkien jälkeen, ja pahimmillaan se osoittautuu rahan ja ajan hukkaa.
Ongelma traceview'n kanssa
kohtalo traceview — antaa täydellinen kuva yksittäisen pyynnön liikkeestä hajautetun järjestelmän kaikkien komponenttien välillä, joihin se liittyy. Joissakin kehittyneemmissä jäljitysjärjestelmissä voit porautua yksittäisiin jänteisiin ja tarkastella erittelyä ajan kuluessa sisällä yksi prosessi (kun jänteillä on toiminnalliset rajat).
Mikropalveluarkkitehtuurin peruslähtökohtana on ajatus siitä, että organisaatiorakenne kasvaa yrityksen tarpeiden mukana. Mikropalvelujen kannattajat väittävät, että erilaisten liiketoimintatehtävien jakaminen yksittäisiin palveluihin mahdollistaa pienten, itsenäisten kehitystiimien hallinnan tällaisten palveluiden koko elinkaaren ajan, mikä antaa heille mahdollisuuden itsenäisesti rakentaa, testata ja ottaa käyttöön näitä palveluita. Tämän jakelun haittana on kuitenkin tiedon menetys siitä, miten kukin palvelu on vuorovaikutuksessa muiden kanssa. Tällaisissa olosuhteissa hajautettu jäljitys väittää olevansa välttämätön työkalu virheenkorjaus monimutkainen vuorovaikutus palveluiden välillä.
Jos todella , silloin kukaan ei pysty pitämään sitä päässään saattaa loppuun kuva. Itse asiassa työkalun kehittäminen, joka perustuu olettamukseen, että se on jopa mahdollista, on jonkinlaista anti-mallia (tehoton ja tuottamaton lähestymistapa). Ihannetapauksessa virheenkorjaus vaatii työkalun, joka auttaa rajaa hakualuettasi, jotta suunnittelijat voivat keskittyä osajoukkoon ulottuvuuksista (palvelut/käyttäjät/isännät jne.), jotka ovat olennaisia tarkasteltavan ongelmaskenaarion kannalta. Vian syytä määrittäessään insinöörien ei tarvitse ymmärtää, mitä vian aikana tapahtui kaikki palvelut kerralla, koska tällainen vaatimus olisi ristiriidassa mikropalveluarkkitehtuurin idean kanssa.
Traceview on kuitenkin nimittäin Tämä. Kyllä, jotkin jäljitysjärjestelmät tarjoavat pakattuja jäljitysnäkymiä, kun jäljityksen jaksojen määrä on niin suuri, ettei niitä voida näyttää yhdessä visualisoinnissa. Kuitenkin johtuen suuresta tietomäärästä, joka sisältyy jopa tällaiseen riisuttuihin visualisointeihin, insinöörit silti pakko "seuloa" se, rajaamalla valikoiman manuaalisesti palveluiden joukkoon, jotka aiheuttavat ongelmia. Valitettavasti tällä alalla koneet ovat paljon nopeampia kuin ihmiset, vähemmän alttiita virheille ja niiden tulokset ovat paremmin toistettavissa.
Toinen syy, miksi traceview on mielestäni väärä, on se, että se ei ole hyvä hypoteesilähtöiseen virheenkorjaukseen. Sen ytimessä on virheenkorjaus iteratiivinen hypoteesilla alkava prosessi, jota seuraa systeemistä saatujen erilaisten havaintojen ja tosiasioiden todentaminen eri vektoreita pitkin, johtopäätökset/yleistykset ja hypoteesin totuuden lisäarviointi.
Tilaisuus nopea ja halpa hypoteesien testaaminen ja henkisen mallin parantaminen sen mukaisesti on kulmakivi virheenkorjaus Minkä tahansa virheenkorjaustyökalun pitäisi olla interaktiivinen ja kavenna hakutilaa tai, jos kyseessä on väärä viittaus, anna käyttäjän palata taaksepäin ja keskittyä järjestelmän eri alueeseen. Täydellinen työkalu tekee tämän ennakoivasti, joka kiinnittää käyttäjän huomion välittömästi mahdollisiin ongelma-alueisiin.
Valitettavasti, traceview ei voida kutsua työkaluksi, jossa on interaktiivinen käyttöliittymä. Parasta, mitä voit toivoa käyttäessäsi sitä, on löytää jokin lisääntyneen latenssin lähde ja tarkastella kaikkia siihen liittyviä mahdollisia tunnisteita ja lokeja. Tämä ei auta insinööriä tunnistamaan kuviot liikenteessä, kuten viivejakauman erityispiirteet, tai havaita korrelaatioita eri mittausten välillä. voi auttaa kiertämään joitakin näistä ongelmista. Todella, onnistunut analyysi koneoppimisen avulla tunnistamaan poikkeavia jaksoja ja tunnistamaan tunnisteiden osajoukko, joka saattaa liittyä epänormaaliin käyttäytymiseen. En kuitenkaan ole vielä nähnyt vakuuttavia visualisointeja koneoppimisesta tai tiedonlouhinnan löydöksistä, joita sovellettaisiin alueille, jotka eroavat merkittävästi jäljitysnäkymästä tai DAG:sta (suunnattu asyklinen kaavio).
Välit ovat liian alhaiset
Traceview'n perusongelma on se ulottuu ovat liian matalan tason primitiivit sekä latenssianalyysiin että perussyyanalyysiin. Se on kuin jäsentäisi yksittäisiä prosessorikomentoja poikkeuksen ratkaisemiseksi tietäen, että on olemassa paljon korkeamman tason työkaluja, kuten backtrace, joiden kanssa on paljon helpompi työskennellä.
Lisäksi otan vapauden väittää seuraavaa: ihannetapauksessa emme tarvitse koko kuva tapahtui pyynnön elinkaaren aikana, jota edustavat nykyaikaiset jäljitystyökalut. Sen sijaan vaaditaan jonkinlainen korkeamman tason abstraktio, joka sisältää tietoa mistä meni väärin (samanlainen kuin backtrace) sekä konteksti. Sen sijaan, että katsoisin koko jälkiä, katson sen mieluummin часть, jossa tapahtuu jotain mielenkiintoista tai epätavallista. Tällä hetkellä haku suoritetaan manuaalisesti: insinööri vastaanottaa jäljen ja analysoi itsenäisesti jännevälit etsiessään jotain mielenkiintoista. Lähestymistapa, jossa ihmiset tuijottavat jaksoja yksittäisinä jälkinä epäilyttävän toiminnan havaitsemisen toivossa, ei skaalaudu ollenkaan (varsinkin kun heidän on ymmärrettävä kaikki eri jaksoihin koodatut metatiedot, kuten jaksotunnus, RPC-menetelmän nimi, jaon kesto 'a, lokit, tunnisteet jne.).
Vaihtoehtoja traceviewille
Jäljitystulokset ovat hyödyllisimpiä, kun ne voidaan visualisoida tavalla, joka tarjoaa ei-triviaalisen käsityksen siitä, mitä järjestelmän toisiinsa liittyvissä osissa tapahtuu. Kunnes tämä tapahtuu, virheenkorjausprosessi jatkuu suurelta osin inertti ja riippuu käyttäjän kyvystä havaita oikeat korrelaatiot, tarkistaa järjestelmän oikeat osat tai koota palapelin palaset yhteen - toisin kuin työkalu, joka auttaa käyttäjää muotoilemaan nämä hypoteesit.
En ole visuaalinen suunnittelija tai UX-asiantuntija, mutta seuraavassa osiossa haluan jakaa muutaman idean siitä, miltä nämä visualisoinnit voisivat näyttää.
Keskity tiettyihin palveluihin
Aikana, jolloin ala keskittyy ideoiden ympärille , vaikuttaa järkevältä, että yksittäiset tiimit varmistavat, että heidän palvelunsa ovat näiden tavoitteiden mukaisia. Seuraa, että palvelusuuntautunutta visualisointi sopii parhaiten tällaisille ryhmille.
Jäljet, varsinkin ilman näytteenottoa, ovat hajautetun järjestelmän jokaista komponenttia koskevan tiedon aarreaitta. Nämä tiedot voidaan syöttää ovelalle prosessorille, joka toimittaa käyttäjille palvelusuuntautunutta Löydökset. Ne voidaan tunnistaa etukäteen – jopa ennen kuin käyttäjä katsoo jälkiä:
- Latenssijakaumakaaviot vain erittäin näkyville pyynnöille (outlier-pyynnöt);
- Viiveen jakautumiskaaviot tapauksissa, joissa palvelun SLO-tavoitteita ei saavuteta;
- Yleisimmät, mielenkiintoisimmat ja omituisimmat tagit kyselyissä, jotka useimmiten toistetaan;
- Latenssin erittely tapauksissa, joissa зависимости palvelut eivät saavuta SLO-tavoitteitaan;
- Latenssijakauma useille loppupään palveluille.
Joihinkin näistä kysymyksistä ei yksinkertaisesti vastata sisäänrakennetuilla mittareilla, mikä pakottaa käyttäjät tarkastelemaan jaksoja. Tämän seurauksena meillä on erittäin käyttäjävihollinen mekanismi.
Tämä herättää kysymyksen: entä monimutkainen vuorovaikutus eri tiimien hallitsemien eri palveluiden välillä? Eikö olekin traceview eikö sitä pidetä sopivimpana välineenä tällaisen tilanteen tuomiseksi esiin?
Mobiilikehittäjät, valtiottomien palvelujen omistajat, hallittujen tilallisten palvelujen (kuten tietokannat) omistajat ja alustan omistajat voivat olla kiinnostuneita jostain muusta esittely hajautettu järjestelmä; traceview on liian yleinen ratkaisu näihin pohjimmiltaan erilaisiin tarpeisiin. Jopa erittäin monimutkaisessa mikropalveluarkkitehtuurissa palvelun omistajat eivät tarvitse syvällistä tietoa kahdesta tai kolmesta ylä- ja loppupään palvelusta. Pohjimmiltaan useimmissa skenaarioissa käyttäjien tarvitsee vain vastata kysymyksiin rajoitettu palveluvalikoima.
Se on kuin katsoisi pientä osajoukkoa palveluista suurennuslasin läpi tarkastelun vuoksi. Tämä antaa käyttäjälle mahdollisuuden esittää kiireellisempiä kysymyksiä näiden palvelujen monimutkaisista vuorovaikutuksista ja niiden välittömistä riippuvuuksista. Tämä on samanlainen kuin backtrace palvelumaailmassa, jossa insinööri tietää että väärin, ja hänellä on myös jonkinlainen käsitys siitä, mitä ympäröivissä palveluissa tapahtuu miksi.
Edistämäni lähestymistapa on täysin päinvastainen ylhäältä alas suuntautuvalle, traceview-pohjaiselle lähestymistavalle, jossa analyysi alkaa koko jäljestä ja sitten vähitellen alas yksittäisiin jaksoihin. Sitä vastoin alhaalta ylös -lähestymistapa alkaa analysoimalla pientä aluetta lähellä tapahtuman mahdollista syytä ja laajentaa sitten hakualuetta tarpeen mukaan (mahdollista tuoda muita tiimejä analysoimaan laajempaa palveluvalikoimaa). Toinen lähestymistapa soveltuu paremmin alkuhypoteesien nopeaan testaamiseen. Kun konkreettisia tuloksia on saatu, voidaan siirtyä kohdennetumpaan ja yksityiskohtaisempaan analyysiin.
Topologian rakentaminen
Palvelukohtaiset näkymät voivat olla uskomattoman hyödyllisiä, jos käyttäjä tietää joka palvelu tai palveluryhmä on vastuussa viiveen lisäämisestä tai virheiden aiheuttamisesta. Monimutkaisessa järjestelmässä loukkaavan palvelun tunnistaminen voi kuitenkin olla ei-triviaali tehtävä vian aikana, varsinkin jos palveluista ei ole raportoitu virheilmoituksia.
Palvelutopologian rakentaminen voi olla suuri apu sen selvittämisessä, mikä palvelu kokee virheprosentin piikin tai viiveen kasvun, joka aiheuttaa palvelun huomattavan heikkenemisen. Kun puhun topologian rakentamisesta, en tarkoita palveluiden kartta, joka näyttää kaikki järjestelmässä saatavilla olevat ja siitä tunnetut palvelut . Tämä näkymä ei ole parempi kuin suunnattuun asykliseen kuvaajaan perustuva jäljitysnäkymä. Sen sijaan haluaisin nähdä dynaamisesti luotu palvelutopologia, joka perustuu tiettyihin attribuutteihin, kuten virheprosenttiin, vasteaikaan tai mihin tahansa käyttäjän määrittelemään parametriin, joka auttaa selvittämään tilanteen tietyillä epäilyttävissä palveluilla.
Otetaan esimerkki. Kuvitellaanpa hypoteettinen uutissivusto. Kotisivupalvelu (Etusivu) vaihtaa tietoja Rediksen, suosituspalvelun, mainospalvelun ja videopalvelun kanssa. Videopalvelu ottaa videoita S3:sta ja metatiedot DynamoDB:stä. Suosituspalvelu vastaanottaa metatiedot DynamoDB:stä, lataa tiedot Rediksestä ja MySQL:stä sekä kirjoittaa viestejä Kafkaan. Mainospalvelu vastaanottaa tietoja MySQL:stä ja kirjoittaa viestejä Kafkaan.
Alla on kaavamainen esitys tästä topologiasta (monet kaupalliset reititysohjelmat rakentavat topologian). Siitä voi olla hyötyä, jos sinun on ymmärrettävä palveluriippuvuudet. Kuitenkin aikana virheenkorjaus, kun tietyllä palvelulla (esimerkiksi videopalvelulla) on pidentynyt vasteaika, tällainen topologia ei ole kovin hyödyllinen.
Palvelukaavio hypoteettisesta uutissivustosta
Alla oleva kaavio sopisi paremmin. Palvelussa on ongelma (video) kuvattu aivan keskellä. Käyttäjä huomaa sen välittömästi. Tästä visualisoinnista käy selväksi, että videopalvelu toimii epänormaalisti johtuen S3-vasteajan pidentymisestä, mikä vaikuttaa pääsivun osan latausnopeuteen.
Dynaaminen topologia, joka näyttää vain "kiinnostavia" palveluita
Dynaamisesti luodut topologiat voivat olla tehokkaampia kuin staattiset palvelukartat, erityisesti joustavassa, automaattisesti skaalautuvassa infrastruktuurissa. Mahdollisuus verrata ja vastakohtana palvelutopologioita antaa käyttäjälle mahdollisuuden esittää asiaankuuluvampia kysymyksiä. Tarkemmat järjestelmää koskevat kysymykset johtavat todennäköisemmin ymmärtämään paremmin järjestelmän toimintaa.
Vertaileva näyttö
Toinen hyödyllinen visualisointi olisi vertaileva näyttö. Tällä hetkellä jäljet eivät ole kovin sopivia rinnakkaisiin vertailuihin, joten vertailut ovat yleensä ulottuu. Ja tämän artikkelin pääidea on juuri se, että jännevälit ovat liian alhaiset, jotta jäljitystuloksista saadaan arvokkainta tietoa.
Kahden jäljen vertailu ei vaadi täysin uusia visualisointeja. Itse asiassa histogrammi, joka edustaa samaa tietoa kuin jäljitysnäkymä, riittää. Yllättäen jopa tämä yksinkertainen menetelmä voi tuottaa paljon enemmän hedelmää kuin pelkkä kahden jäljen tutkiminen erikseen. Vielä tehokkaampi olisi mahdollisuus visualisoida jälkien vertailu Yhteensä. Olisi erittäin hyödyllistä nähdä, kuinka äskettäin käyttöön otettu tietokannan konfiguraatiomuutos GC:n (rokkakeräyksen) mahdollistamiseksi vaikuttaa myöhemmän virran palvelun vasteaikaan useiden tuntien mittakaavassa. Jos se, mitä tässä kuvailen, kuulostaa A/B-analyysiltä infrastruktuurin muutosten vaikutuksista monissa palveluissa käyttämällä jälkiä, et ole liian kaukana totuudesta.
Johtopäätös
En kyseenalaista itse jäljityksen hyödyllisyyttä. Uskon vilpittömästi, että ei ole olemassa muuta menetelmää kerätä niin rikasta, kausaalista ja kontekstuaalista dataa kuin jäljessä oleva. Uskon kuitenkin myös, että kaikki jäljitysratkaisut käyttävät näitä tietoja erittäin tehottomasti. Niin kauan kuin jäljitystyökalut pysyvät jumissa traceview-esityksessä, niiden kyky hyödyntää mahdollisimman paljon arvokasta tietoa, joka voidaan poimia jälkien sisältämistä tiedoista, on rajoitettu. Lisäksi on olemassa vaara, että kehitetään edelleen täysin epäystävällinen ja epäintuitiivinen visuaalinen käyttöliittymä, joka rajoittaa vakavasti käyttäjän kykyä suorittaa sovelluksen virheiden vianmääritystä.
Monimutkaisten järjestelmien virheenkorjaus, jopa uusimmilla työkaluilla, on uskomattoman vaikeaa. Työkalujen pitäisi auttaa kehittäjää muotoilemaan ja testaamaan hypoteesi, tarjoamalla aktiivisesti asiaankuuluvat tiedot, poikkeavien tekijöiden tunnistaminen ja viiveiden jakautumisen piirteet. Jotta jäljityksestä tulisi kehittäjien valinnanvarainen työkalu tuotantohäiriöiden vianmäärityksessä tai useiden palvelujen kattavien ongelmien ratkaisemisessa, tarvitaan alkuperäisiä käyttöliittymiä ja visualisointeja, jotka vastaavat paremmin palveluita luovien ja operoivien kehittäjien mentaalista mallia.
Vaatii huomattavaa henkistä työtä sellaisen järjestelmän suunnittelussa, joka edustaa jäljitystuloksissa saatavilla olevia erilaisia signaaleja tavalla, joka on optimoitu analyysin ja päätelmien helpottamiseksi. Sinun on mietittävä, kuinka abstrakti järjestelmän topologia virheenkorjauksen aikana auttaa käyttäjää voittamaan kuolleet kulmat katsomatta yksittäisiä jälkiä tai jänteitä.
Tarvitsemme hyvät abstraktio- ja tasoitusominaisuudet (etenkin käyttöliittymässä). Sellaisia, jotka sopivat hyvin hypoteesilähtöiseen virheenkorjausprosessiin, jossa voit iteratiivisesti esittää kysymyksiä ja testata hypoteeseja. Ne eivät automaattisesti ratkaise kaikkia havainnointiongelmia, mutta ne auttavat käyttäjiä terävöittämään intuitiota ja muotoilemaan älykkäämpiä kysymyksiä. Vaadin harkittumpaa ja innovatiivisempaa lähestymistapaa visualisointiin. Täällä on todellinen mahdollisuus laajentaa horisonttia.
PS kääntäjältä
Lue myös blogistamme:
- «";
- «";
- «'.
Lähde: will.com