Twitter ~Over Capacity~

Hai para pembaca! Apakah pembaca semua punya akun twitter? Ayo dong... Masa sih hari gini nggak punya akun di social network yang populer ini? Yah, meskipun nomer 2 dari Facebook, tapi tetap saja twitter ini telah memiliki banyak penggemar dari seluruh dunia. Bahkan di Indonesia, artis-artis juga banyak yang punya akun twitter (sekaligus menerima banyak masalah karena posting mereka yang tidak pikir panjang di twitter...) loh! Yah, karena hari ini saya akan banyak membahas masalah pada twitter, makanya saya juga harus sedikit mempromosikan web ini sebagai gantinya... Haha...

Bagi yang belum punya akun twitter, bisa daftar disini : http://twitter.com/
Bagi yang belum tahu apa itu twitter, silahkan buka : http://id.wikipedia.org/wiki/Twitter

Bagi yang sudah punya akun twitter dan rutin menggunakan situs jejaring sosial ini, pernah gak sih, sewaktu kalian ingin mengakses web ini, lantas yang keluar malah gambar paus yang lebih dikenal sebagai “fail whale” itu? Menurut kalian, apa sih maksudnya gambar itu? Jangan-jangan twitter bangkrut? Jangan-jangan internet saya down? Jangan-jangan... Sebaiknya kalian tidak berasumsi dahulu, sebenarnya kalau kalian-kalian sampai melihat gambar paus itu, berarti masalah bukan pada kalian, malainkan pada server twitter-nya...

(Gambar Fail Whale yang Populer itu...)

Lho? Kok bisa? Kenapa facebook yang notabane lebih besar, lebih populer, dan lebih banyak penggunanya tidak pernah mengalami hal seperti ini?

Masalah facebook akan saya bahas di lain kesempatan saja yah... Mari sekarang kita lihat, sebenarnya apa dan bagaimana sih proses internal di dalam twitter itu sendiri untuk dapat menjawab masalah “fail whale” itu...

Pada awalnya, sekitar tahun 2007-2008, Twitter menggunakan persistent queue server yang benama ‘Starling’, yang menggunakan bahasa pemrograman ‘Ruby’. Software Starling ini berguna untuk mengatur queue / antrian user yang ingin mengakses server twitter ini. Dan pada awalnya, semua akses dapat di-hadle dengan mudah. Tapi, kepopuleran website Twitter tiba-tiba melonjak dengan sangat drastis sekali... Terkesan melebih-lebihkan? Saya rasa tidak dengan adanya fakta user yang mendaftar meningkat sampai 1.500% (Seribu lima ratus persen) dan jumlah staff yang bekerja di kantor Twitter sendiri mengalami peningkatan sampai 500%. Selain itu, Twitter juga penggunaan teknologi API (Application Programming Interface) yang memungkinkan Twitter berintegrasi dengan aplikasi luar dan servis yang disediakan web lain, sehingga diluar sana juga diketahui terdapat lebih dari 70.000 software terdaftar yang dibuat untuk memudahkan mengupdate status twitter, dan saat ini, setiap harinya terdapat sekita 65 juta tweet setiap harinya. Itu baru software yang terdaftar, berapa banyak lagi software yang tidak terdaftar yang beredar diluar sana? Belum lagi yang mengakses twitter lewat telepon genggam... Fakta ini didapat lewat survey pada bulan Maret 2010.

Siapa yang tidak mau usahanya meningkat drastis seperti ini? Tapi, terkadang peningkatan yang terlalu drastis tidak disertai dengan peningkatan kemampuan pengelolaan yang lebih baik. Ibarat Anda membuka usaha katering, yang hari biasanya menerima 5-10 order setiap bulan, dan tiba-tiba saja usaha Anda meningkat drastis menjadi 100-150 order setiap bulannya. Kalau usaha katering sih, Anda tinggal tolak saja yang tidak bisa Anda handle, sambil pelan-pelan meluaskan usaha Anda. Tapi kalo twitter? Para pengguna menunutut Twitter untuk dapat memuaskan semua user SEGERA, atau, semuanya akan meninggalkan Twitter. Coba saja Anda pikir, biasanya akses Twitter sehari bisa 10 kali, tiba-tiba server jadi down, sampai-sampai Anda cuma bisa mengakses 2 kali sehari, itupun untung-untungan... Lama-lama semua orang jadi bosan dan malas kan untuk mengakses web yang “lemot” ini...

Masalah akses yang tidak dapat di-handle ini terjadi karena server Starling dan Bahasa pemrograman Ruby pada dasarnya memang tidak dapat “tumbuh” bersama dengan kebutuhan user yang meningkat drastis tersebut. Tentu saja hasilnya tidak semua akses terhandle, dan Twitter terpaksa memblok beberapa akses ke server mereka dan mengeluarkan gambar lucu “fail whale” sebagai gantinya, mungkin juga sebagai hiburan agar mereka-mereka yang akses Twitter-nya ditolak jadi tidak terlalu be-te...

Akhirnya, untuk dapat menjawab masalah ini, pihak Twitter mengganti software yang ditulis dengan bahasa pemrograman Ruby untuk mengelola website mereka dengan software yang ditulis dalam bahasa pemrograman Scala. Nama Scala sendiri memiliki kepanjangan “scalable language”, bahasa pemrograman yang dapat menyesuaikan diri dengan perubahan tuntutan kebutuhan user. Memang bahasa pemrograman ini tidak sempurna, seperti kata pepatah “nobody’s perfect”, tapi setidaknya Scala telah menjawab kebutuhan pihak Twitter tepat sasaran. Selain itu, Twitter akhirnya juga membatasi akses dari pihak-pihak yang memanfaatkan teknologi API menjadi 20 request per jam. Setidaknya orang-orang yang ingin mengakses web Twitter dari browser dapat lebih leluasa.

Apakah lantas masalah Twitter telah selesai sampai disini? Sayang sekali, kenyataannya sampai sekarang pun halaman “fail whale” masih eksis Twitter, meskipun memang tidak se-eksis tahun lalu... Bingung juga yah... Kenapa setelah mereka memperbaiki software dan memutuskan untuk memilih bahasa pemrograman lain, yang bahkan menurut mereka lebih bagus dari yang sebelumnya, kenyataannya masalah ini masih juga belum terselesaikan. Menurut analisa dan hasil pemikiran saya, dan dari hasil membandingkan teknologi yang digunakan Twitter dengan Facebook, saat ini solusi optimal untuk memperbaiki kondisi Twitter yang sering overload adalah dengan menambah jumlah server. Jika dibandingkan dengan Facebook yang memiliki banyak server untuk akses, kelihatannya Twitter masih kalah dari segi kuantitas. Kemudian, apabila Twitter berniat menambahkan server, maka mereka juga harus merancang algoritma untuk menentukan jalur yang paling efisien (kalau Anda terbiasa dengan istilah komputer, penentuan jalur ini adalah Routing).

Analoginya seperti ini, jika server diibaratkan sebagai jalan, penggunaan banyak server seperti menyediakan banyak jalan untuk menuju satu tempat yang sama. Masalahnya, sekalipun tersedia banyak jalan, bagaimana Anda tahu jalan mana yang sekarang sedang sepi? Nah, itulah tugas dari algoritma routing yang tadi saya singgung sedikit. Algoritma routing akan memungkinkan pengalokasian akses ke server yang paling tidak sibuk saat user berusaha mengakses web Twitter. Oleh karena itu, tanpa algoritma routing, mau menyediakan server sebanyak apapun, semuanya jadi sia-sia, karena akses akan tetap menumpuk dan macet di satu server.

Sekarang malah timbul satu pertanyaan lagi... Kalau dengan menambah server dan algoritma routing akan menyelesaikan masalah mereka, kenapa mereka belum juga melakukannya? Personally, saya juga tidak tahu, dan sebaiknya saya tidak berasumsi macam-macam... Lagipula, setahu saya, biaya yang harus dikeluarkan untuk pembelian dan pengimplementasian server maupun algoritma routing baru tidaklah murah...

Yah, barangkali rekan-rekan pembaca sekalian tertarik berbisnis dengan membuat situs jejaring sosial seperti ini? Belajar tidak melulu harus mengalami sendiri, tapi kita juga bisa belajar dengan melihat pengalaman orang lain. Siapa tahu dengan membaca artikel ini minat bisnis Anda jadi terbuka. Lagipula selama ini orang Indonesia jarang ada yang sampai ke tingkat pembuat, kebanyakan hanya sebagai user. Siapa tahu Anda jadi pelopor?