Interjú a Red Hat fejlesztési alelnökével és műszaki igazgatójával, Brian Stevens-szel, I. rész
Mesélj a Red Hat valósidejűséggel kapcsolatos terveiről, és arról, hogy az upstream rendszermaggal kapcsolatos munkával – beleértve Ingo Molnar munkáját – ez hogyan egyeztethető össze?
Brian Stevens: a valósidejűséggel kapcsolatos fejlesztések pontosan Ingo Molnar tevékenységén keresztül kezdődtek több évvel ezelőtt.Eredetileg néhány vállalat foglalkozott a Red Haten kívül valósidejű-fejlesztésekkel az ügyfeleik részére. Ingo a részese lett ezeknek az erőfeszítéseknek, azzal a céllal, hogy a valósidejűséget a Linux rendszermag alapvető részéve tegye. Így teljesítményi fejlesztéseket eszközölt a hang és az ütemezés, illetve sok más téren, és ezt a munkát tovább folytatja. Azóta teljes lett a kép: Ingo átvette a valósidejű Linux rendszermag-fa karbantartását, illetve felvettünk más fejlesztőket is, akik kiegészítik ezt a csapatot.
Elértünk egy olyan pontra, hogy ezek nagyrésze Andrew és Linus fájának részévé vált, de a legnagyobb beolvasztások közül néhány még hátra van, mint például a rendszer teljesen preemptibilissé tétele. Tehát a fejlesztések teljesen Linuxba olvasztásával kapcsolatban vár még ránk egy kis munka, de találtunk egy olyan termékmodellt, ami lehetővé teszi számunkra átmenetileg a teljes egyesítésig, hogy az ügyfelek számára ezt a funkcionalitást nyújthassuk. Tehát létrehozunk majd egy valósidejű előfizetési ajánlatot azoknak az ügyfeleknek, akiknek a teljesítmény és a rövid latencia által nyújtott előnyökre szükségük van.
Szerinted milyen Red Hat ügyfelek igénylik a valósidejűséget?
Kezdetben a valósidejű ügyfelek “egyediek” voltak abban az értelemben, hogy a válaszidőt valódi pénzben mérték, így a megcélzott ügyfelek először a pénzügyi szolgáltatásokban tevékenykedők voltak, melyek tőzsdei, illetve hálózati tevékenységet végeznek, melyeket előre nem megjósolható és nagy teljesítmény jellemez. A hadseregben és a kormányzati szolgáltatások terén is használják a valósidejűséget a hagyományos rendszerekben. Tehát már számos korai pilot projektmunkát végeztünk mind a két vertikumban.
Tehát a pénzügyi piacokon számos ügyfél az úthenger elől kapkodja fel a földről a pénzérméket?
Igen, pontosan.
És az ügyfelek milyen valósidejű metrikákat keresnek?
Az egész az üzenetküldési rétegben összpontosul. Azt látjuk, hogy amikor elkezdünk a valósidejűségről beszélni, a munkánk nagyrésze előrevetítődik még azelőtt, hogy az ügyfelekkel beszélnénk, mivel teljes mértékben tisztában vannak azzal, hogy a Linux rendszermag közösség éppen hol tart a valósidejű technológiában és Ingo munkájával. Jól ismert a Red Hat szerepe a Linuxos valósidejű technológiában, így már jóval azelőtt beszélhetünk az ügyfelekkel kialakított kapcsolatról, hogy terméket tudnánk ajánlani. Az ügyfelekkel folytatott beszélgetések alapján azt látjuk, hogy az üzenetküldési rendszer nagy jelentőséggel bír. Így mindig grid-szintű számításokról és elosztott rendszerekről gondolkodunk. Egy elszigetelt rendszer valósidejű teljesítménye nem igazán számít. Ami számít, az a válaszidő és a megjósolható teljesítmény az egész hálózatban. Így a tipikus terhelések, melyeket eddig láttunk, üzenetküldési sorokon keresztül kommunikáló rendszerek voltak.
Ez az ajánlat tartalmazná a fejlett üzenetküldési sorokon keresztül kommunikáló rendszerekkel kapcsolatos protokollt is (AMQP), amihez a Goldman Sachs, illetve a Red Hat és más vállalatok is hozzájárulnak?
Még nem tartalmazza. Így a szóban forgó, tipikus munkaterhelések az ügyfeleink kapcsán jelenleg nagyban olyan környezetekkel kapcsolatosak, mint a Tibco és MQSeries, illetve élesüzemű üzenetküldési megoldásokkal, melyek így a valósidejű terheléseket nagyon gyorsan letudják. Azonban van itt egy érdekes elágazás. Az AMQP-vel kapcsolatos fejlesztéseket a Red Hat kezdte kb. másfél éve, amivel kapcsolatban azt láthatjuk, hogy – ugyanazokat a termékeket megfigyelve, az általuk nyújtott teljesítménybeli növekedés szempontjából, alulról felfelé nézve, méghozzá a Linux rendszermag hálózati perspektívájából – a Linux x86-on jobban méretezhető, mint az üzenetküldési rendszerek.
Így valójában a kiindulási pont a nyílt forráskódú innovációs modell volt számunkra, amiben nagyon hiszünk az üzenetküldési probléma kapcsán. És így az AMQP projekt alapját az a felmérésünk képezte, mellyel azt szerettük volna megtudni, hogy melyik technológia jelentené a legjobb kiindulási pontot egy fejlettebb üzenetküldési rendszer számára. A kezdeti kódbeli hozzájárulás JP Morgan Chase-től származik, akivel a Red Hat felvette a kapcsolatot, mi pedig nyílt forráskódúvá tettük a technológiát azért, hogy létrejöjjön egy Apache-szerű közösség, és egy munkacsoport szabványosítsa a protokollt.
Jól tudom, hogy JP Morgan Chase-nek már van egy élesüzemű AMQP projektje?
Igen, így van. Már van egy élesüzemű implementációjuk, mivel már felfedezték a problémát. Ezen ügyfelek közül sokan rendelkeznek több, üzenetküldési sorokon keresztül kommunikáló rendszerrel, és próbálják az alkalmazásaikat összekapcsolni.
A különböző alkalmazások különböző problémákat oldanak meg. A JP Morgan Chase az üzenetküldési platformok közötti együttműködési problémákat próbálják áthidalni, és olyan dolgokkal foglalkoznak, mint az ESB, ami a rendszerek közötti interoperabilitást próbálja megvalósítani; ezeknek a rendszereknek természetüknél fogva nyitottaknak kell lenniük. Tehát ez már egy nagyon sikeres alkalmazás, ami jelentős hatással bír a saját üzletükre, és úgy gondolták, hogy a Red Hattel történő együttműködésen keresztül ezt magasabb szintre vihetik.
Az Apache pártfogása alatt az implementáció egy Java-alapú projekt, vagy vannak más nyelvek, amikre már implementálnak?
Az eredeti fejlesztés Java-alapú volt, és a Red Hat egy C++ brókert is kifejlesztett. Így lesz egy olyan több platformon működő bróker, ami Windows-on vagy Linuxon is fut, és lesz egy C bróker, ami minden teljesítményt optimalizál majd. Még a natív Linux I/O protokollokhoz is próbálunk üzenetküldési funkcionalitást adni. Tehát mind a kettőt támogatjuk, és az API-k szempontjából a fejlesztők a JMS, a C, a Ruby és a Python közül választhatnak.
Tehát bármilyen programozási stílushoz is szokott a fejlesztői csapat az üzenetküldési protokoll esetén, lehetséges, hogy valami hasonlót írjanak, és az AMQP-n keresztül bármilyen AMQP implementációval megvalósítható a kommunikáció?
Teljes mértékben. Ez a lényeg. Nem kell Javát használnunk, hogy ezt megtehessük. Vannak olyan meglévő szabványok, melyek lehetővé teszik az interoperabilitást a régi üzenetküldési sorokon keresztül kommunikáló rendszerekkel. Ez a kommunikációs protokoll szabványosításán keresztül valósul meg, amit még az AMQP-t implementáló tulajdonosi termékekkel is összeegyeztethetünk. Azt gondoltuk, hogy fontos lehet, hogy az üzenetküldési platform mindenhol használható legyen.
A Red Hat által vezetett nyílt forráskódú implementáció alapján, amit heterogén rendszerekre kell alkalmazzunk, nem gondoltuk, hogy tömeges elfogadásra számíthatunk. Így várjuk, hogy más gyártók tulajdonosi implementációkat készítenek, amivel mi együttműködünk. Végül itt térünk vissza a valósidejűséghez, amivel kapcsolatban most már beszélhetünk a szolgáltatás minőségéről (QoS) és áttörő teljesítményről minden hálózati rétegen keresztül. A valósidejű rendszermagon kívülről ezt eddig nem tudtuk megtenni, illetve nem tudtuk kezelni a szolgáltatás minősége prespektívájából.