AsiakasprojektitTietotekniikka

Hakurobotti AWS-pilvialustalle – Tekninen kuvaus asiakasprojektista

Tekninen kuvaus AWS-pilvialustalle toteutetusta hakurobotista. Yritys siirsi datan json-tiedostoina AWS S3-palveluun. Ajastetty python-skripti käynnistyi AWS EC2-instanssilla. EC2-virtuaalikoneella pyörinyt python-koodi kävi kyselemässä hakukonetuloksia Microsoft Azure Cognitive Services-palvelusta, joka oli käytännössä Bing-hakukone. Tulokset kirjoitettiin jälleen S3:een joko CSV- tai Excel-tiedostoina.

Tässä kirjoituksessa esitellään sivutoimisen yritykseni toteuttaman hakurobotin tekniset yksityiskohdat. Taustaksi voi lukea tämän projektikuvauksen. Tiivistettynä tarkoituksena oli etsiä netistä automatisoidusti vastaavia tuotteita, joita yritys julkaisi nettisivuillaan. Ratkaisu tehtiin AWS-pilvilaskenta-alustalle.

Käyn blogin pääkuvan kaavion läpi vaihe kerrallaan. Lukijan tulisi tietää termit AWS, Azure, palvelin, tietokanta ja rajapinta.

Yrityksen keskitetty tuotetietokanta

Kaavion vaihe 1

Prosessi lähti liikkeelle, kun yritys kirjasi uuden tuotteen järjestelmäänsä. Samalla uusi tuote julkaistiin yrityksen nettisivuilla, mahdollisesti useilla eri kielillä.

Tuotehallintajärjestelmä oli täysin itsenäinen suhteessa AWS-hakurobottiin.

S3 rajapintana yrityksen tietojärjestelmän ja AWS:n välillä

Kaavion vaihe 2 ja 3

Tiedot julkaistusta tuotteesta piti saada siirrettyä yrityksen tietokannasta AWS:ään. Alunperin ajatuksena oli, että yrityksen tietojärjestelmä siirtäisi datan automaattisesti Amazonin palveluihin [2A]. Loppuvaiheessa ilmeni, että myös ihmiskäyttäjän tulisi pystyä tekemään siirto tarpeen mukaan [2B].

Päätimme, että tuotetietojärjestelmä puskee json-tiedoston AWS:n S3-palveluun [3]. Json-tiedosto sisältäisi tuotteen nimen, julkaisuajankohdan, tuotekuvauksen kielen, avainsanat ja muita tietoja. Menetelmä toimisi myös ihmiselle, joka voisi luoda käsin vastaavan tiedoston ja tallentaa sen S3:een selaimen kautta [2B].

AWS S3:a voisi kuvailla verkkokansioksi, johon löytyy hyvät ohjelmointirajapinnat esimerkiksi Pythonille, Javascriptille ja Javalle.

Tiedostoja lähetettäisiin harvakseltaan, ei edes joka päivä.

S3 tuntuu myös jälkiviisaana loistavan yksinkertaiselta valinnalta tähän käyttötarkoitukseen. Toinen vaihtoehto olisi ollut lähettää tuotahallintajärjestelmästä viesti AWS SQS-jonoon, jonka jälkeen AWS Lambda-funktio olisi noutanut tiedoston.tuotahallintajärjestelmästä.

AWS Beanstalkilla ja Pythonin Flaskilla toteutettu web-sovellus olisi ollut käyttäjälle yksinkertainen, mutta toteutus olisi ollut työläämpi.

Tiedoston prosessointi EC2-virtuaalipalvelimella

Kaavion vaihe 4

Tein AWS:ään EC2-palvelimen, jonka ajastin suorittamaan Python-koodin minuutin välein. Jos S3:een ei ollut tullut uusia tiedostoja, Python-koodi ei tehnyt mitään.

Mikäli S3:ssa oli käsittelemätön json-tiedosto, Python muunsi datan Python-sanakirjaksi.

Vaikka EC2-pavelimen hinta on vain muutamia euroja kuukaudessa, käyttäisin nyt luultavasti AWS lambda-funktiota prosessointiin. Lambda mahdollistaa koodin suorittamisen ilman kehittäjälle näkyvää palvelinta. Lambda olisi edullisempi, ei vaatisi asentamista tai ylläpitoa, ja ajastuksen sijaan suoritus voitaisiin käynnistää automaattisesti uuden tiedoston saapumisen myötä.

AWS Elastic Beanstalk saattaisi olla hyvä vaihtoehto myös datan prosessointiin. Beanstalk ei päästä läpi toimimatonta versiota ohjelmasta, testausympäristön luominen olisi helppoa ja vikatilanteessa rikkinäinen palvelin korvattaisiin automaattisesti uudella. Myös Python ytimellä varustettu AWS Glue voisi tulla kyseeseen kertaprosessoinnissa.

Joissakin vaihtoehdoista koodin kontittaminen Dockeriin voisi olla perusteltua.

Tekninen kuvaus AWS-pilvialustalle toteutetun hakurobotin arkkitehtuurista. Yritys siirsi datan json-tiedostoina AWS S3-palveluun. Ajastetty python-skripti käynnistyi AWS EC2-instanssilla. EC2-virtuaalikoneella pyörinyt python-koodi kävi kyselemässä hakukonetuloksia Microsoft Azure Cognitive Services-palvelusta, joka oli käytännössä Bing-hakukone. Tulokset kirjoitettiin jälleen S3:een joko CSV- tai Excel-tiedostoina.
Sama AWS-arkkitehtuurikuva uudestaan.

Vastaavien tuotteiden etsiminen Microsoft Bing-rajapinnasta

Kaavion vaihe 5

Sama Python-koodi jatkoi suoritustaan. Json-tiedostosta puretut parametrit tuli valjastaa vastaavien tuotteiden löytämiseksi internetistä.

Ensimmäisenä mieleen tuli käyttää Googlen hakurajapintaa, eli tehdä Google-hakuja automatisoidusti.

Selvitystyön jälkeen menetelmä osoittautui toimivaksi. Varmuuden vuoksi kokeilin vielä muut vaihtoehdot, erityisesti Microsoft Bing-rajapinnan, joka löytyy Microsoftin Azure-pilvialustan Cognitive Services-palveluista.

HakukonerajapintaIlmaisia kyselyitäHinta / 1000 kyselyäHakutuloksia / KyselyHinta / 100k hakutulosta / kkHinta / 1M hakutulosta / kk
Google100 / Päivä5$1035$485$
Microsoft1000 / Kuukausi3$503$57$

Suurin etu Microsoftin hakurajapinnan hinnoittelussa oli 50 hakutulosta Googlen 10 hakutuloksen sijaan.

Bing-rajapinnalle lähtettiin json-tiedostosta parsitut ihmisen keksimät hakusanat. Vastauksena saatiin nippu aiheeseen liittyviä hakutuloksia, jotka Python tallensi Pandas DataFrameen.

Hakutulosten tallentaminen S3:een

Kaavion vaihe 6

Edelleen sama Python-koodi tallensi hakutulokset CSV- ja Excel-muodossa S3:een.

AWS S3:ssa tiedostot tallennetaan ”buckettiin” eli ”ämpäriin”. AWS-tilillä voi olla useita bucketteja. Ämpärissä voi olla edelleen kansiota. Kansio tosin ei ole mitään fyysistä, vaan tiedostoja vain nimetään käyttäen kauttaviivoja ”kansioina”, esim my-beautiful-bucket/2019/maaliskuu/tiedosto.csv.

Jos valitsisin nyt uudestaan, tekisin vain yhden ämpärin per kehitys-, testi- ja tuotantoympäristö. Jakaisin sisään tulevat tiedostot, virheelliset tiedostot [6A] ja hakutulostiedostot [6B] omiin kansioihinsa erillisten ämpäreiden sijaan. AWS:lla on nimittäin oletuksena 100 ämpärin rajoitus per tili.

Hakurobotin hakutulosten hyödyntäminen

Kaavion vaihe 7

Lopuksi yrityksen tietojärjestelmä voi käydä poimimassa hakutulokset S3:sta [7A]. Myös ihminen voi käydä lataamassa valmiin tiedoston selaimesta saamillaan käyttäjätunnuksilla [7B].

Tulosten hyödyntäminen oli yrityksen vastuulla. Vaikkakin jälkiviisaana voin todeta, että käyttötarpeita ei tulisi erottaa teknisestä toteutuksesta.

Yhteenveto AWS-hakurobotin teknisestä toteutuksesta

Muista tätä lukiessasi, että kirjoitukseni on yli vuoden ajatustyön tulos. Projektin alussa tarpeet olivat hyvin epäselviä ja osaamiseni yksityiskohdista vajavaisempaa.

Lähdin itse asiassa liikkeelle Phantom JS-työkalulla, jota olen käyttänyt vastaavissa tarpeissa. Phantom JS osoittautui nopeasti huonoksi valinnaksi. Työkalun kehitystyö on lopetettu, ja vanhalla Javascript versiolla homma meni sotkuiseksi.

Koitin vastaavaan tarpeeseen suunniteltua Puppeteer-työkalua. Sekä selainautomaatioon suunniteltua Seleniumia. Vasta näiden kokeilujen jälkeen ymmärsin ongelman luonteen.

AWS valikoitui pilvialustaksi, koska se oli minulle tutuin tapa luoda palvelimia. Sinänsä koodi kyllä pyörisi millä tahansa palvelimella.

Lopullisessa hakurobotin versiossa ihmisen täytyy luoda hakusanat ohjelmistorobotille. Reilun vuoden takaisin tekstianalytiikkaprojektin ansiosta osaisin nyt poimia sopivat hakusanat tuoteselosteesta automaattisesti koneoppimista hyödyntäen. Tämä olisi kuitenkin kosmetiikka verrattuna ajansäästöön, joka syntyy automatisoidusta Google-tai Bing-hausta ja hakutulosten prosessoinnista.

Myöhemmin hakukonetulosten ohella tarkasteluun voitaisiin ottaa myös sisältöä sosiaalisesta mediasta.

Jätä kommentti