Clouddal nyerte meg Obama a választást

Túlzás lenne azt mondani, hogy a technológia nyeri meg a választásokat, de az igaz, hogy az eszközöket jól használók könnyen jutnak plusz eredményekhez. Ezt a választást is az emberek nyerték meg Obamának, de a kampányszervezet eddig nem látott komplexitású informatikai támogatást használt az adatok gyűjtéséhez, rendszerezéséhez, kommunikációs feladatokhoz és elemzésekhez. A technológiához híresen vonzódó, első győzelme előtt a Google alapítóitól is tanácsot kérő elnök stábja a kampányhoz szükséges számításokat pontosabban végezte el, a szavazókkal szorosabb kapcsolatot hozott létre és jobban kihasználta az elköteleződésből származó előnyöket is.

Obama stábjának egy dedikált, külön technológiai csoportja, valódi IT műhelye volt, kivétel nélkül technológiai szakértőkből, gurukból, akik úgy üzemeltették a projektet, mint egy internetes startup céget. A felhasznált technológiák részét képezték nyílt forráskódú szoftverek, webes szolgáltatások, a cloudból elérhető dinamikusan skálázható számítási kapacitások. Az eredménnyel kapcsolatban Scott VanDenPlas, Obama tech csapatának vezetője Twitteren osztott meg néhány érdekes adatot, amit követően az Ars Technica szerkesztősége készített egy alapos elemzést.

Óriás terhelés

A háttérrendszereknek akkor is komoly adatmennyiséggel kell megbirkóznia, ha csak egy egyszerű, de hirtelen népszerűvé váló mobilalkalmazásról vagy webes szolgáltatásról beszélünk, de itt az amerikai elnökválasztás volt a támogatandó kampány, ami egy 300 milliós ország esetén eleve komoly volumen, erre rakódik ballasztként a külföldi figyelem, ami az amerikai választásokat kíséri.

A feladat nagyságának szemléltetésére néhány számadat: a tech csapat 3 adatközpontban bérelt kapacitást, amit 2000 node szolgált ki. A teljes adatbázis 180 terabájt volt és összesen 8,5 milliárd lekérést kellett feldolgozniuk. A csúcsidőszakban 4 Gbps sávszélességet foglaltak és másodpercenként 10 ezer lekérdezést szolgáltak ki. Mindezt úgy, hogy összesen 583 napjuk volt arra, hogy megtervezzék, megépítsék, üzembe helyezzék a rendszert, majd a választások végeztével az egészet összecsomagolják és felszámolják.

Négy évvel ezelőtt még nem volt ilyen átgondolt a helyzet, ott Obama abban a helyzetben volt, mint Romney most: nagyon későn derült ki, hogy az előválasztások után neki kell országos kampányt indítania, s hiába készült rá, hiába voltak tech szakértők körülötte, nem volt előre felépített, dedikált IT-csapat mögötte. 2008-ban az Obama-kampányt főleg külső beszállítók és önkéntesek támogatták technológiával, a kampány pedig a közösségi oldalakon illetve a klasszikus informatikai csatornákon, például emailen folyt.

A cloudot épp az ilyen esetekre teremtették

2008-ban a Project Houdini nevű titkos fegyvert vetették be, aminek segítségével minden ingadozó államban a megfigyelők egyesével regisztrálták a bejegyzett szavazókat és egy automata telefonos rendszeren keresztül gyűjtötték az adatokat. Az amerikai kampánynak hagyományos része az ismert támogató szavazók célzott mozgósítása, ennek megvalósításához azonban rengeteg önkéntesre van szükség. A kampány nagy ötlete a folyamat automatizálása volt, ami működött is, de a rendszer nehezen tűrte a túlterhelést. Ezzel szemben idén az Obama-csapat szinte kizárólag az Amazon cloudra támaszkodott mind számítási kapacitásban, mint tárhely tekintetében.

Egy saját szolgáltatás felépítésébe kezdett a csapat Harper Reed vezetésével, ennek kódneve a Narwhal lett. Az egész kampánytámogató rendszer kapott egy saját API-t, ehhez kapcsolódott minden egyes kampányalkalmazás és ezen keresztül futott be minden adat és információ. Az API révén menet közben is könnyedén lehetett új alkalmazásokat készíteni és azokat integrálni a már meglévő rendszerekbe. Az alaprendszer egy összetett analitikai programmal is rendelkezett, ami a Dreamcatcher nevet kapta. Ez egy eszköz, amivel mikrotargetálni lehetett a választókat, ami kritikus fontosságú a kampányban: a cél ugyanis a saját választókat minél inkább választásra ösztönözni, miközben az ellenfél szavazóit a leginkább békén hagyni - ehhez nagyon fontos a pontos célzás. Az egész platform tetejére pedig a Dashboard került, egy központi irányítóközpont, ami egy olyan virtuális iroda alkalmazás, ami minden helyszínen segítette az önkénteseket kommunikálni és közösen dolgozni.

A cél teljesült: a kampány teljesen be lett drótozva, minden réteg testreszabott IT-megoldásokkal fegyverkezett fel, amit teljes egészében a cloudra és mobil kliensekre épített Reed és csapata. A csapatról annyit érdemes tudni, hogy itt is érvényesült a startup módszertan. Egy maroknyi mérnök kezdte el a munkát, de Reed a projekt elejétől kezdve toborzott a piacon lévő helyi tehetségek közül is, illetve sikerült elcsábítania több veteránt például a Google, Facebook, Twitter vagy a TripIt csapatából. Reed egyáltalán nem akart új dolgokat feltalálni, hanem megnézte, hogy az ipar mit termelt ki eddig, összeszedte a szükséges darabokat és a feladatnak megfelelően összeillesztette azokat - pont mint egy modern, felhős-mobilos startup esetében.

"Agresszíven támaszkodtunk az olyan óriásokra mint az Amazon és használtuk azokat a technológiákat, amit más emberek felépítettek. Nagyon jó kultúrája alakult ki a nem ide feltalált technológiák használatának, nem ijedtünk meg ettől - mondta Reed. Néhány esetben persze óvatosak voltak. Hiába volt meg egy megoldás, ha azt még nem próbálta ki senki ilyen nagyságrendben, akkor azt általában inkább elkerülték.

API, API, API

A lényeg az volt, hogy létrejöjjön egy központi hely, ahová minden adat áramlik a partnerek felől, de az új alkalmazások is hozzáférnek azokhoz. Egy olyan API kellett, amivel bármelyik projekt képes kommunikálni, bármilyen programozási nyelv vagy bármilyen webes keretrendszer legyen is mögötte. A Narwhal végül Pythonban íródott, szerveroldalon pedig sztenderd HTTP szolgálta ki a kéréseket. A tech csapat a teljes adatbázist az Amazon MySQL-alapú RDS-ére bízta, ami lehetővé tette, hogy az adatok átfejthetőek legyenek S3 instance-okba anélkül, hogy biztonsági mentéseket kellene róluk készíteni.

A megfelelő alapozás persze azt is magával hozta, hogy az alkalmazások rétege is gyors tempóban fejlődött. A fejlesztők egyre több appot tettek a terepen dolgozó önkéntesek és stáb kezébe, változatos feladatokat szolgálva ki. A leginkább nyilvánvaló felület a fent említett Dashboard, illetve a telefonhívásokat segítő eszköz volt. A Dashboard 2012 elején már működött, s ugyan amiatt, hogy közvetlenül nem tudott az adatbázissal kommunikálni, csak a Narwahl API-n keresztül, kissé kényelmetlen volt, de magabiztos támogatást adott a helyi kampányirodák létesítéséhez.

B-terv

A Dashboard webes alkalmazás, ami egyébként még mindig éles, segített automatizálni a toborzási folyamatot. Nem helyettesítette a helyi irodákat, inkább csak a 2008-as egységes eszköztárból fakadó fejetlenséget és problémákat oldotta fel. Az önkéntesek egyszerűbben kapcsolatba léphettek egymással, a történések követhetővé, kiszámíthatóvá váltak. Ugyanez a könnyedség jelent meg a telefonos mozgósítás terén. Ráadásul minden egyes mozzanat adatait betápláltak az adatbázisba, így a Dreamcatcher és más analitikai alkalmazások folyamatosan mutatták a kampány alakulását.

A Sandy hurrikán megjelenése próbára tette a rendszer stressztűrő képességét is. Alapjában véve az Obama tech csapata az Amazon észak-virginiai adatközpontjaiba tervezte az elsődleges infrastruktúrát, de két másik helyszínt is tartalékban tartott. Amikor jött a hurrikán, akkor a kampányt kiszolgáló 500 EC2-instance azonnal replikálódott és munkába állt az Amazon nyugati-parti adatközpontjában. Nem volt más választásuk, a teljes infrastruktúrát áttelepítették, viszont ez alig néhány napot vett igénybe.

Minden más fenyegetés viszont kalkulálható volt, tudták előre, hogy mikor lesznek csúcsok a levelezésben, adatbázis-lekérdezésekben és más forgalomban. Amikor a választás elindult, akkor a számítógépesített “robothívások” is indulhattak, csakúgy, mint az e-mail kampány. Ha viszont rendelkezésre áll egy kiváló koordinációs rendszer, akkor miért is kéne csak a technológiára hagyatkozni? Sokkal hatásosabb, ha igazi emberek, igazi szavakkal, igazi meggyőzést alkalmaznak. A Call Tool és a Dashboard segítségével az önkéntesek bármelyik államból betelefonálhattak az éppen fontos helyszínekre.

Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.

"Nem a technológia volt a termék" - jegyzi meg Reed. A sikert nem az hozta, hanem maguk az emberek, a háttérrendszer egyszerűen lehetővé tette, hogy a dolgok megvalósuljanak. Az egész rendszer a teljes kampány alatt összesen körülbelül 30 percet állt, s időközben ha kellett, akkor új képességeket, alkalmazásokat, felületeket lehetett létrehozni hozzá. Fontos megjegyezni, hogy  hiába áll rendelkezésre a legjobb technológia, ha rossz a termék. Obama esetében az informatikai innováció egyébként önmagában is hiteles, s úgy tűnik minden működött. Nem állt le a cloudszolgáltató, nem ment tönkre semmi, nem történt olyan esemény, amit ne lehetett volna áthidalni. És persze végül Obama tényleg megnyerte az amerikai elnökválasztást.

Romney, az ellenpélda

Az idők szavát a republikánus párt is hallja, a Romney-kampány is komoly informatikai infrastruktúrát épített ki. A választások után azonban kiderült, hogy az Orca névre keresztelt rendszer pontosan a kritikus pillanatban, a választás napján mondta fel a szolgálatot és részlegesen leállt, ami akár szavazatok tízezreit is elvihette a republikánus jelölttől.

A republikánus stratégia szerint önkéntesek tízezrei monitorozták az ingadozó államokban a részvételt, így a választások folyamán is egészen pontosan követték, hogy mely államok, mely megyék, mely szavazókörök állnak nyerésre és melyek vesztésre. A stratégia szerint a stabilan győztes államokból az erőforrások (a személyes telefonos megkeresések) átcsoportosíthatóak az éppen billegő államokba, így maximalizálni lehet a kampánystáb hatékonyságát.

Az Orca leállásához, illetve az egész napos lassú válaszidőkhöz az elégtelen tesztelés vezetett, amelyet ráadásul nem is a szerverpark végleges helyén végeztek. A saját szervereken futó rendszer csúcsidőben 1200 adatbázishívást kapott percenként, amivel nem tudott megbirkózni. További problémát jelentett, hogy az internetszolgáltató egy időre saját hatáskörben megszakította a kapcsolatot, mert DDoS támadást sejtett a nagyon sűrű, azonban kis adatátvitellel járó hálózati forgalom mögött.