Arsitektur Server Facebook KontakPerkasa Futures, Facebook kian lama kian digemari dan mempunyai banyak member. Padal bulan maret 2008 saja telah terjadi traffic data sebesar 200GB perhari. Permasalahan yang muncul adalah bagaimana caranya server yang dimiliki oleh facebook dapat melayani itu semua. Dalam bab ini akan dibahas mengenai trik dari facebook untuk membuat server mereka mampu melayani jutaan pengguna facebook.

 

Untuk sebuah sistem jejaring sosial, yang diperlukan adalah kenyamanan dalam penggunaan. Selain itu pelayanan yang bagus serta murah bahkan gratis (tidak dipungut biaya ketika mendaftar maupun menggunakan layanan) merupakan senjata ampuh yang digunakan facebook untuk menarik jutaan pengguna(300 juta).

 

1.1  Cara Optimalisasi transfer data.
Pertanyaan yang akan timbul setelah membaca ulasan diatas adalah bagai mana facebook menjaga servernya agar tidak down?. Jawabannya akan sangat banyak, karena facebook mempunyai berbagai cara untuk melayani ratusan juta penggunanya. Caranya dengan jumlah server, cache, dan hadoop hive, dll. Dibawah ini akan dijelaskan semua (tetapi yang paling ditonjolkan adalah penggunaan hadoop/hive). Penjelasan caranya adalah sepertti dibawah ini. adalah:
a. Jumlah server
Cara yang paling dasar dan wajib dilakukan adalah dengan membangun sebanyak mungkin sub server yang melayani sejumlah 300an juta pengguna sehingga beban server utama dapat dikurangi. Secara logika ini akan mudah tetapi tidak murah. Untuk saat ini facebook mempunyai jumlah server hampir 30.000 unit server. Tapi cara ini dirasa kurang efisien karena membutuhkan biaya yang sangat mahal untuk membangun server baru.

b. Cache
Cara kedua adalah dengan membuat cache data. Yaitu dengan software semacam hash yang dapat menyimpan data (string, integer, object,dll) didalam RAM sehingga data dapat cepat terproses. Tapi cara inin juga akan timbul masalah ketika kapasitas ruang cache yang tidak akan mencukupi ketika traffic yang ada terlalu tingi. Gambarannya adalah seperti dibawah ini.

Photobucket
c. Hive and Hadoop
Setelah solusi diatas dikemukakan, maka dirasa kurang efisien untuk menyelesaikan permasalahan yang ada. Kemudian pihak facebook mencoba untuk mencari cara yang efisien, murah dan efektif untuk melayani traffic data. Caranya adalah menggunakan Hadoop dan Hive. Hadoop dan Hive  adalah sebuah sistem yang biasanya digunakan untuk melayani traffic skala petabyte data.
Sebuah hadoop mempunyai beberapa keunggulan yaitu:
a. Superior didalam memanage(manageability), melakukan penyekalaan (scalability), ketersediaan (availibility)
b. Efisien dengan tidak membutuhkan banyak hardware.
c. Kemampuan untuk menskala data (memecah mecah data)
Kekurangannya

a.  Map-reduce sulit  diprogram (tidak seperti sql, phyton,dll)
b. Membutuhkan skema yang jelas  untuk mempublish data.

Jelas sekali penggunaan hadoop ini mutlak digunakan karena dapat memangae, memilah milah data dengan meminimalisir hardware sehingga sangat efisien bila digunakan untuk traffic dengan skala data petabyte.

Tetapi masih ada kekurangan yang dapat dilihat pada pemaparan sebelumnya. Makanya diperlukan Hive untuk mendukung sistem hadoop. Hive adalah sistem untuk memanage dan men query (mengantrikan) data yang dibuat diatas sistem hadoop. Untuk membuat kedua sistem ini sinkron maka digunakanlah SQL untuk alat penyimpanan data yang familiar.Dan yang perlu sipehatikan adalah tipe data yang biasanya digunakan, atau fungsi/scrip/format dari data itu sendiri . Cara ini digunakan untuk meningkatkan performa dari server itu sendiri (mempermudah server). Untuk mengetahui lebih lanjut penggunaan hadoop/hive sistem lebih lanjut akan dijelaskan pada bagian traffic data dibawah ini.

1.2  Traffic Data Pada Facebook
Cara cara diatas semua dilakukan oleh facebook untuk mengatisipasi trafic data dari facebook yang sangat besar. Sehingga selain cara diatas juga harus dilakukan atau dibuat sebuah architekture yang bagus sehingga kenyamanan dalam pengiriman data dilakukan dengan baik. Berikut ini akan ditampilkan gambaran aliran data pada facebook.

  • Photobucket
  • Secara umum dapat digambarkan bahwa data yang dikirim oleh user langsung diterima oleh server kemudian melalui scribe MidTier, lalu menuju filler yang nantinya masuk ke hive hadoop cluster bersama scribe hadoop cluster dengan menggunakan Mysql dan disimpan didalam adhoc hive hadoop cluster maupun oracle RAC.
  • Dengan menggunakan cara seperi diataslah facebook dapat digunakan dengan nyaman karena traffic data dapat difasilitasi dengan baik dengan metode hive-hadoop, dengan pengclusteran data menggunakan mysql yang kemudian diubah ke ORACLE.
  • Beberapa penjelasan mengenai diagram diatas adalah sebgai berikut:
    a. Scribe & hadoop cluster pada Fcebook
    Scribe & hadoop cluster digunakan untuk meng-log data dari web server. Dan cluster ditempatkan dengan webserver. Setiap cluster mempunyai 50 node. Statistik dari data yang di log perhari adalah 2TB perhari dan 99% data akan tersedia dalam 20 detik.
    b. Hadoop/hive cluster
    Hadoop/hive cluster ini memiliki :
    – 8400 core
    – Kapasitas RAW12.5PB
    – 8core+12TB per node
    – 32GB RAM tiap node
    – Didalam topologi level jaringan mempunyai kecepatan 1Gbit/sec dari node ke rack switch dan 4 Gbit/sec ke level tertinggi dari rack switch.
  • Mempunyai 2 macam cluster dimana satu untuk adhoc user dan satu untuk SLA jobs.
    1.3  Penggunaan Hive-Hadoop
    Statistik menunjukkan bahwa 12 TB data baru terkompresi setiap hari, 135TB data scan terkompresi tiap hari dan 7000 lebih Hive jobs perhari.
  • Dengan begitu maka Hive mencoba memudahkan hadoop. Facebokk melakukannya  dengan mengerahkan 200 orang perhari untuk mengurusi jobs pada hadoop/hive, mengerahkan engineer baru untuk mengembangka hive, dan menganalisis hadoop melalui hive.
  • Bahasa yang digunakan  dalam hive adalh SQL dengan meliputi tipe data integer, float, sting, bolean. Sistem ini juga menggunakan sistem Hash sebagai pemercepat  transfer data.
    Beberapa angota pengguna hive selain facebook adalah cnet, digg, chitika, bizo,g rooveshark, hi5, last.fm dll. (hnm)

Artikel: kontakperkasa futures.