Facebook szolgáltatások Lóránt Marcell Miről lesz szó?

 A Facebook története röviden

 Szolgáltatásainak bemutatása

 Architektúra, technikai megvalósítás

 Fájlok tárolása

 Megjelenítési réteg

 Technikai részletek

 Scribe

 Chat

 Adattárolás A Facebook története

 A legnagyobb közösségi portál, 1,2 milliárd felhasználóval

 Alapítója: Mark Zuckerberg

 Székhelye: Menlo Park, California

 2003-2005: Thefacebook néven jött létre a Harvard hallgatói számára

 2006-2011: nyílt regisztráció, Microsoft-partnerség, gyors növekedés

 2012: 1 milliárd felhasználó

http://en.wikipedia.org/wiki/Facebook A Facebook növekedése évről évre

http://news.bbcimg.co.uk/media/images/72744000/gif/_72744565_facebook_624v2.gif Szolgálatásai

 A Facebook felépítése  Alkalmazások

 Hírfolyam  Események

 Ismerősök  Piactér

 Idővonal (régebben üzenőfal)  Jegyzetek

 Kedvelés  Helyek

 Üzenetek, chat  Csoportok

 Értesítések  Kérdések

 Képek, videók

 Smartphone integráció  Facebook Paper

 iOS, Android, Windows Phone Hírfolyam, bejegyzések, adatvédelem

 Ismerőseink állapota, megosztásai láthatóak a hírfolyamon (2006 óta létezik)

 Azok a bejegyzések is megjelennek itt, amelyek az általunk követett személyektől származnak, és publikusak

 Saját közleményeink adatvédelmi szintje beállítható

 Csak ismerősök/mindenki

 Egyéni: pl. család, barátok, vagy megadott személyek számára (nem) elérhető

 Lehetőség van a helyszín megadására

 A bejegyzéseket lehet kedvelni, megosztani másokkal

 A megadott felhasználók által megosztott bejegyzések kiszűrhetők

 A kifogásolható tartalmak jelenthetők a moderátorok felé Hírfolyam http://img.svbtle.com/pugis6oroxzxcg.png Kereső, ismerősök, oldalak

 A kereső univerzális: találatai között szerepelnek emberek, oldalak, helyek…

 Az oldal felhasználói ismerősnek jelölhetők, visszaigazolásuk után az ismerősünkké válnak (limit: 5000)

 Az ismerősök törölhetők, szükség esetén letilthatók

 Tiltás esetén semmilyen kapcsolatba nem tudnak lépni velünk a továbbiakban a tiltás feloldásáig

 Cégek, szervezetek esetében egyre népszerűbb a Facebook-oldal: ezeket kedvelhetjük

 Ismerősök és oldalak idővonalára közzétehetünk bejegyzéseket, amennyiben a másik fél adatvédelmi beállításai ezt lehetővé teszik Események, csoportok, helyek

 Események

 Megadható helyszín, időpont, meghívottak listája

 Adatvédelem: esemény láthatósága, résztvevők joga további emberek meghívására

 Visszaigazolás: részt vesz / nem vesz részt / talán

 Csoportok

 Azonos érdeklődési körű felhasználók csoportokat alkothatnak, saját hírfolyammal

 Adatvédelem: nyílt / zárt / jelentkezéses

 Egy csoportnak több adminisztrátora lehet

 Helyek

 Lehetőség van vélemény írására, bejelentkezésre (check in) Üzenetek, chat

 Ismerőseinknek üzenetet küldhetünk vagy valós időben chatelhetünk velük

 Látható a beszélgetőpartner jelenléte, valamint a legutolsó aktivitása óta eltelt idő

 Szabályozható, hogy mely felhasználók számára akarunk elérhetőek lenni

 Beépített hangulatjelek, matricák

 Fényképek, hang, videó küldés

 Facebook Messenger

 Elérhető: Android, iOS, Windows Phone

 Főképernyőn megjelenő chat ikonok  gyors és egyszerű váltás az ablakok között

 Beépített VoIP kliens: ingyenes hanghívás Messenger http://o.aolcdn.com/hss/storage/adam/8348bc3c12f47f15c03fa8b7ec10dbed/facebook-messenger-newUI.jpg Képek, videók, jegyzetek

 Lehetőségünk van képeket, videókat közzétenni

 Beépített automatikus vagy manuális képjavító funkció

 A képen szereplő emberek megjelölhetők (tag-elés), ezt arcfelismerő funkció segíti

 A képek, videók elnevezhetők, albumokba rendezhetők

 Jegyzetek

 Egy hagyományos bejegyzésnek túl hosszú közleményt elmenthetünk jegyzetként

 Ezekhez lehet megjegyzést fűzni, megosztani, kedvelni

 Az adatvédelmi beállítások itt is alkalmazhatók További szolgáltatások

 Hangulatjelek: mára a rejtettekkel együtt 200+ db

 Megbökés: lényegében semmit nem jelent

 URL rövidítő: fb.me domain (2009 óta)

 Ticker: oldalsáv, melyen valós időben követhetők nyomon az ismerősök tevékenységei (2011 óta)

 Feliratkozás: egy személy követése, akit nem feltétlenül ismerünk (2011 óta)

 Ellenőrzött fiókok: széles körben ismert személyek megerősíthetik regisztrációjukat, így a találati listában magasabb prioritással szerepelnek, valamint egy kék pipa jelenik meg a nevük mellett (2012 óta)

 Hashtag-elés: azonos témájú bejegyzések megjelölése (2013 óta) Üzleti modell

http://bmimatters.com/2012/04/10/understanding-facebook-business-model/ Fájlok tárolása

 Hagyományos, POSIX szabványnak megfelelő fájlrendszerben történik

 Tárolásra kerülő metaadatok

 Fájl hossza

 Eszközazonosító

 Tároló blokk mutatók

 Fájl tulajdonosa

 Csoport tulajdonosa

 Hozzáférési jogok: írás, olvasás, futtatás

 Létrehozás, módosítás, hozzáférés ideje

 Hivatkozások száma Fájlok tárolása (folyt.)

 Feltöltési réteg: feltöltések kezelése, képek skálázása, tárolása az NFS kiszolgálón  a képek innen töltődnek le HTTP-n keresztül

 Az NFS kiszolgáló réteg kereskedelmi termékek felhasználásával készült

 Problémák:

 A legtöbb fájlrendszerben nagyszámú fájl tárolása, rendszerezése nehézkes

 Túl sok a metaadat ahhoz, hogy elférjen a memóriában

 Ezért az adatok lekéréséhez rengeteg I/O művelet szükséges

 Nem a tárhely, sokkal inkább az I/O a szűk keresztmetszet Fájlok tárolása (folyt.)

 Megoldás:

 Tárolók tehermentesítése a rengeteg kisméretű kép gyorsítótárazása által

 Ezek továbbítása CDN-en (Content Delivery Network) keresztül, alacsonyabb válaszidőt eredményezve

 Gyorsítótárazás a memóriában a skálázhatóság, redundancia és teljesítmény végett

 NFS file handle gyorsítótárazás: csökkenti a metaadatok által okozott overhead-et

 Haystack

 Generikus HTTP-alapú objektumtároló

 Komponensei: HTTP szerver, Photo Store szerver, Haystack Object Store, XFS fájlrendszer, tárolószerver (Blade)

 Az első generációs megoldáshoz képest tizedannyi I/O művelet fényképenként Megjelenítési réteg

 PHP: egyszerű nyelv, de CPU- és memóriaigényes

 Ezért optimalizálni kell:

 Késleltetett betöltés (lazy loading) és előgyorsítótárazás

 Egyedi memcache kliens kiegészítés, sorosítási formátum, naplózás, statisztikagyűjtés, monitorozás, valamint aszinkron eseménykezelés Megjelenítési réteg (folyt.)

 HipHop for PHP forráskód-átalakító: PHP kódból jól optimalizált C++ kódot állít elő, majd g++ segítségével lefordítja azt

 A Facebook saját fejlesztése

 Azok számára lehet hasznos, akik hatalmas PHP-s infrastruktúrával rendelkeznek, és nem szeretnék a komplex logikát C/C++-ba átírni

 50%-kal kevesebb CPU használat az Apache+PHP kombinációhoz képest

 A Facebook API rétege kétszer annyi kérést képes kiszolgálni 30%-kal kevesebb CPU használattal

 Beágyazott egyszerű webszerver libevent felett

 Tornado webszerver keretrendszer, Node.js A HipHop for PHP hatékonyságának növekedése

http://regmedia.co.uk/2011/03/31/facebook_hip_hop_improvment.png Technikai részletek

 Maga a Facebook egyetlen monolit alkalmazás, egy 1,5 GB méretű bináris adathalmaz

 Ezt BitTorrent-alapú átviteli rendszerrel juttatják el a szerverekre

 Kb. 15-15 perc a build és a release time, de nem okoz leállást

 HBase alapú kombinációs platform szolgál az adatok elosztott tárolására

 Az új események naplófájlokba íródnak, ahonnan azokat kiolvasva az adatok a tárolóba kerülnek

 A felhasználói interfész kiveszi innen az adatokat és megjeleníti azokat Technikai részletek (folyt.)

 A kérések kezelése AJAX használatával történik

 Ezek naplófájlokba íródnak Scribe segítségével (ez a Facebook fejlesztése)

 Az adatok kiolvasása Ptail-lel történik (belső fejlesztésű eszköz)

 A kiolvasott adat 3 részre osztódik és eljut a különböző adatközpontokba

 Kötegelt adatfeldolgozás minden 1,5 másodpercben

 Ezt követően az adatok PHP formátumban kerülnek kiküldésre

 A backend-et Java-ban fejlesztik, a PHP-s résszel való kommunikációhoz a Thrift üzenő formátum használatos

 Cache-elés az oldalak gyorsabb megjelenítése végett A Scribe-ról

 Thrift szolgáltatás, amely elosztott naplófájlok kezelését teszi lehetővé

 Aggregálja a naplófájl folyamokat

 Daemon szolgáltatás, amely az adatközpont minden csomópontján fut

 Továbbítja a naplófájlokat bármely az adott gépen futó folyamattól a központi gyűjtőkig

 Tervezési szempont: alacsony CPU használat, skálázhatóság, hibatűrés

 Ha a központi Scribe szerver nem elérhető, a helyi kiszolgáló helyben tárolja az adatokat, majd ha a központi szerver újra elérhetővé válik, továbbítja felé A Facebook adatáramlási architektúrája

http://www.techthebest.com/wp-content/uploads/2011/11/facebook.png Chat, üzenetek

 A valós idejű beszélgetés a legnagyobb kihívás

 A felhasználót értesíteni kell, ha egy ismerőse chat üzenetet küld neki, vagy letölt egy Facebook-oldalt (tehát jelen van)

 Számon kell tartani a távollétet is: mióta nem vagyunk a gépnél, és erről tudatni a másik felet is

 Ezekből következik, hogy akár böngésszük az oldalt, akár nem, mindenképpen terheljük a szervert

 Facebook chat

 Naplózási alrendszer: C++

 Epoll-vezérlésű web szerver: Erlang

 Tervezési szempontok: megbízhatóság, hibatűrés Chat: felmerült problémák, kihívások

 Erlang csatorna-kiszolgáló

 Az Erlang string problémája miatt a memóriafoglalás nagy

 Takarítás, ha új üzenetre várunk

 Csatorna-kiszolgáló futásidejű monitorozása

 C++ naplózó

 Memória tördelődés

 Jelenlét-kiszolgáló

 Jelenlét frissítése a csatorna kiszolgáló adataiból

 Jelenléti információ kigyűjtése a jelenlét-kiszolgálóra

 Zlib tömörítés a sávszélesség-megtakarítás végett Adattárolás

 2008: 200 GB/nap

 2009 április: több mint 2 TB tömörített nyers adat naponta

 Ez az év végére a duplájára nőtt

 2014 április: 600 TB/nap

 HIVE: strukturált adatok kezelése és lekérdezése

 MapReduce a futtatáshoz

 HDFS (Hadoop Distributed File System) az adatok tárolására

 A metaadatok RDBMS-ben vannak tárolva

 Alapelvek: kiterjeszthetőség (típusok, funkciók, formátumok, szkriptek), skálázhatóság, teljesítmény, interoperabilitás A Facebook adatközpontja http://siliconangle.com/files/2013/09/Facebook-Data-Center-Project.jpg Felhasznált irodalom

 http://en.wikipedia.org/wiki/Facebook

 http://en.wikipedia.org/wiki/Facebook_features

 http://bmimatters.com/2012/04/10/understanding-facebook-business- model/

 http://www.slideshare.net/mozion/facebook-architecture-for-600m-users Köszönöm a figyelmet! Kérdések?