Tokopedia didirikan oleh dua orang dengan latar belakang IT, William Tanuwijaya (aslinya berasal dari Pematang Siantar, Sumut) dan Leontinus Alpha Edison (aslinya berasal dari Pontianak, Kalbar), tentunya dibantu juga oleh Victor Fungkong (CEO Indonusa -pemodal pertama Tokopedia). Mereka mulai membangun Tokopedia sejak Januari 2009. Untuk mengejar pertumbuhan pengguna yang sangat pesat, teknologi Tokopedia pun harus terus berusaha menyesuaikan diri. Simak pengalaman mereka.
Setelah Blibli.com yang membuka arsitektur teknologi di belakangnya, beberapa waktu lalu giliran Tokopedia yang berbagi pengalaman. Ini adalah inisiasi dari StartupBisnis bersama CodePolitan untuk mengadakan seminar online dengan mengundang Leon (panggilan Leontinus) untuk membagikan pengalamannya dengan teknologi di belakang Tokopedia. Tulisan ini merangkum berbagai poin yang menarik untuk disimak dari inisiasi tersebut.
Arsitektur I
Walaupun Leon sebenarnya memang seorang engineer, dia sendiri mengaku bahwa dirinya hanya “half-engineer”. Latar belakangnya adalah bekerja untuk klien enterprise. Itulah sebabnya mengapa sewaktu pertama kali ia membangun Tokopedia dia memilih Oracle sebagai pilihan database, Perl sebagai bahasa pemrogramannya dan Apache mod_perl sebagai webservernya. “..ya pakai apa yang saya bisa aja”, ujarnya. Belakangan, sekitar 1 bulan sebelum Tokopedia meluncur, Leon merekrut satu orang engineer, kali ini real engineer.
Oracle yang digunakan saat itu adalah Oracle Express Edition 4G. Ini adalah versi “gratisan” dari Oracle dengan berbagai batasannya. Server yang digunakan adalah server fisik, dan kedua server ini identik.
Arsitektur ini terbilang sangat sederhana. Wajar memang untuk startup yang baru dibangun. Saat itu semua berkas yang diupload merchant dan pengguna langsung saja disimpan di webserver, tanpa CDN (Content Delivery Network) ataupun cloud storage. Leon bahkan mengaku saat itu tidak tahu apa itu CDN. Tidak hanya tentang CDN, ia bahkan belum tahu tentang Awstat ataupun Google Analytics (perangkat untuk memonitor trafik kunjungan website).
Arsitektur II
Sekitar satu bulan setelah Tokopedia meluncur, trafik tumbuh pesat. Server Tokopedia pun mulai melambat. Arsitektur Tokopedia pun segera menyesuaikan. Apache server dipecah menjadi 2. Satu untuk berkas static, satu lagi untuk konten dinamis (dynamic content).
Namun ini pun tidak bertahan lama. Server Tokopedia kembali mulai melambat. Penyebabnya ada beberapa:
- Oracle yang mereka gunakan mencapai batasnya (versi ini kapasitasnya hanya terbatas hingga 4GB)
- Tidak ada partisi
- Tidak ada replikasi database
- Indexing yang jelek
- Semua aktivitas read/write dilakukan pada database server yang sama
Arsitektur III
Leon dan timnya segera berbenah. Mereka melakukan beberapa perbaikan. Database akhirnya mereka ganti ke PostgreSQL -sebuah aplikasi database yang populer di dunia open source. Karena PostgreSQL memang sudah mendukung replication, maka Tokopedia pun memecah databasenya menjadi master-slave.
Pilihan jatuh ke PostgreSQL karena menurut Leon ada banyak kemiripan dengan Oracle. Salah satu contohnya adalah format datetime-nya.
Di bulan April 2015, Tokopedia sempat mengalami masalah cukup besar selama 21 hari akibat PostgreSQL. Penyebabnya adalah versi PostgreSQL yang mereka gunakan ternyata memiliki bug pada bagian indexing-nya. Akibat bug ini hasil query ke database menjadi kacau. Leon memberi contoh, ketika mereka melakukan query ke 1 record spesifik, yang keluar bisa jadi 3 record. Sayang Leon tidak menjelaskan lebih lanjut bagaimana akhirnya mereka mengatasi masalah ini.
Arsitektur IV
Tokopedia.com kembali melambat. Kali ini permasalahannya di bagian search-nya. Walaupun tidak disebutkan, dugaan saya pada masa ini fitur search di Tokopedia masih langsung dilakukan ke database PostgreSQL. Itu sebabnya ketika semakin banyak penjual yang mengunggah produknya (bisa hampir tiap detik) performanya menjadi semakin melambat.
Akhirnya Tokopedia memilih menggunakan SOLR. Ini adalah mesin untuk pencarian yang sangat populer, karena selain cepat dan relatif mudah, aplikasi ini juga open source dan gratis. Walaupun secara default menggunakan Tomcat webserver, tidak perlu tahu banyak soal Java dan Tomcat untuk bisa membenamkan SOLR ke dalam sebuah aplikasi website, bahkan untuk website berbasis CMS seperti WordPress.
Tetapi pertumbuhan pengguna Tokopedia memang tak terbendung. Situs Tokopedia pun mulai melambat lagi. Leon mengatakan jika mereka akhirnya menemukan penyebabnya di antaranya adalah pengguna Apache mod_perl yang memakan banyak sumber daya (resource). Selain itu juga karena ada bagian dari kode pemrograman yang menyebabkan terjadinya memory leaks.
Arsitektur V
Terbentur dengan Apache yang memang sudah banyak dikenal haus akan sumberdaya, Leon akhirnya tahu tentang Nginx -sebuah server yang bisa digunakan sebagai web server, reverse proxy, maupun load balancer (pemecah beban berdasarkan request ke server). Nginx sebenarnya sudah mulai populer di tahun 2009.
Tokopedia sendiri menggunakan nginx sebagai load balancar dan web server. Dan karena Tokopedia masih menggunakan Perl, maka tentunya Nginx mod_perl juga digunakan.
Awalnya mereka menggunakan metode round robin untuk loadbalancer-nya. Tetapi dengan metode ini mereka kesulitan menemukan server yang bermasalah ketika terjadi kegagalan. Akhirnya metodenya diubah menjadi kombinasi dengan clustering. Beberapa Nginx server digabungkan menjadi satu kelompok, dan di dalam kelompok ini dilakukan round robin. Dengan begitu akan lebih mudah memantau server sesuai dengan kelompoknya masing-masing.
Masalah timbul lagi. Situs Tokopedia terbentur pada keterbatasan hardware. Kapasitas penyimpanan hardisk sudah hampir habis, penggunaan sumber dayanya 90-100%, tidak ada cadangan dan tidak ada failover. Ini salah satunya juga disebabkan karena penggunaan hardisk tipe SATA, yang lebih lambat (namun lebih murah harganya) ketimbang SSD.
Salah satu tim sys admin Tokopedia akhirnya menyarankan untuk menggunakan GlusterFS -sebuah network file system di cloud. Dengan GlusterFS kita bisa membuat tempat penyimpanan dengan kapasitas yang sangat besar dan terdistribusi. Tokopedia menggunakan 8 server dengan 4 node untuk GlusterFS ini.
Namun GlusterFS tidak digunakan lama. Leon bercerita kalau mereka pernah mengalami kegagalan besar saat penggunaan GlusterFS. Contoh kasusnya, proses unggah gambar berhasil ke dalam GlusterFS, tetapi gambar tersebut tidak pernah muncul saat diakses pengguna. Belakangan Tokopedia akhirnya menggunakan penyedia layanan CDN yang bernama EdgeCast. EdgeCast adalah penyedia layanan CDN terbesar kedua setelah Akamai.
Agak mengejutkan juga mengetahui GlusterFS tidak bekerja seperti yang diharapkan. Terlebih di bagian akhir seminar online ini, Leon mengatakan bahwa 2 orang engineer (sekaligus co-founder) GlusterFS juga sempat membantu mereka langsung.
Arsitektur VI
Kini arsitektur Tokopedia sudah lebih kompleks. Beberapa bagian sudah dipecah lagi menjadi lebih spesifik.
Diagram diatas menggambarkan secara garis besar bagaimana arsitektur teknologi yang digunakan Tokopedia saat ini. Gambar emoticon senyum itu adalah awal masuknya pengguna ke Tokopedia. Dari situ request akan dibagi ke 2 load balancer: load balancer untuk konten statis, dan load balancer untuk aplikasi.
Di diagram ini juga bisa kita lihat kalau penyimpanan berkas Tokopedia sudah menggunakan platform dari AWS (Amazon Web Service) yaitu S3. Selain itu Leon juga mengatakan jika mesin pencari Tokopedia kini juga sudah menggunakan CloudSearch dari AWS. Secara total kurang lebih sudah 20% arsitektur Tokopedia berada di AWS.
Masalah dengan ISP
Leon juga mengungkapkan mengenai hal menarik lainnya yaitu masalah eksternal. Jadi kadangkala terjadi permasalahan-permasalahan yang terjadi di luar kontrol Tokopedia. Misal, masalah dengan ISP yang digunakan oleh pengguna Tokopedia.
Berkali-kali Tokopedia mendapatkan laporan ada pengguna yang tidak bisa mengakses Tokopedia. Padahal situsnya baik-baik saja. Setelah diusut ternyata khusus dari ISP pengguna itu saja yang tidak bisa mengakses Tokopedia. Untuk mengatasi ini, akhirnya Tokopedia menggunakan Geo Module dari Nginx. Dengan begitu pengguna yang mengakses dari ISP tertentu akan diarahkan untuk terhubung dengan CDN yang sudah dipastikan bisa diakses melalui ISP tersebut.
Masalah lain dengan ISP adalah interstitial ads. Ada saja ISP yang menyelipkan iklan ke dalam situs Tokopedia ketika diakses penggunanya. Selain praktek ini memang menurut saya tidak beretika, ISP ini juga benar-benar kelewatan. Tidak peduli request apa yang masuk ke server, mereka selalu menginjeksikan kode iklan mereka.
Dalam dunia aplikasi website, sudah sangat awam banyak request AJAX terjadi. Request AJAX ini kembaliannya tentu saja tidak hanya HTML, tetapi juga format JSON. Tentu saja banyak bagian dari sebuah website yang menjadi tidak bekerja ketika data dalam format JSON digabungkan dengan kode-kode iklan dari ISP. Ini jugalah yang terjadi dengan Tokopedia.
Praktek “nakal” ISP ini akhirnya ditangani Tokopedia dengan menerapkan HTTPS ke seluruh bagian websitenya. Dengan penerapan HTTPS ini maka ISP tidak bisa lagi menginjeksikan iklan-iklannya ke dalam halaman Tokopedia.
Leon dan William juga sudah mencoba untuk berdialog dengan ISP mengenai hal ini, termasuk melalui forum e-commerce idEA. Tapi masih belum ada hasil berarti hingga saat ini.
Sebenarnya praktek “nakal” ISP ini memang tidak terjadi di Indonesia saja, tapi juga terjadi secara global. Karena itulah hadir gerakan net neutrality.
Struktur Organisasi
Leon dan William banyak berdiskusi dengan investor mereka, termasuk dikenalkan dengan para pemain lain di industri teknologi. Dari berbagai hasil diskusi tersebut mereka memutuskan model organisasi yang digunakan adalah divisional bukan fungsional.
Sebagai contoh, tim Tokopedia dibagi menjadi divisi-divisi berikut:
- Seller Platform
- Search & Discovery
- Product & Catalogue
- Logistic
- Messaging
Tiap-tiap divisi ini memiliki tim:
- Product Owner
- Engineer
- Quality Assurance (QA)
- IT Infrastructure
- Business
- Security
Dengan struktur seperti ini, maka akan lebih mudah untuk bekerja sama satu sama lain, karena goalnya sama. Misal, divisi Logistic mempunyai target KPI untuk menyediakan integrasi dengan Go-Jek. Dengan begitu tim bisnis akan memikirkan bagaimana bentuk kerja samanya, tim engineer akan memikirkan bagaimana integrasi teknologinya ke dalam aplikasi, dst.
Saat ini jumlah personil tim Engineer, QA, UI/UX di Tokopedia sudah mencapai sekitar 150-an. Tentunya jumlah ini akan terus bertambah.
Tim engineer Tokopedia ini dipimpin oleh seorang VP Engineer (CTO). Posisi ini dijabat oleh seorang ekspatriat yang bernama Qasim Zaidi. Leon dan William diperkenalkan dengan Qasim oleh salah satu investor mereka, Sequoia Capital. Sebelum bergabung dengan Tokopedia Qasim bekerja di perusahaan sejenis di India, namanya Paytm. Karena Qasim sudah pernah menangani jumlah transaksi Paytm yang jauh lebih besar daripada Tokopedia saat ini, harusnya ia memang orang yang tepat untuk mengisi posisi ini.
Target ke Depan
Dengan pertumbuhan pengguna yang begitu pesat, plus dipimpin oleh CTO yang sangat berpengalaman, tentunya Tokopedia terus berkembang. Mereka memiliki beberapa target ke depan, di antaranya:
- Menjadi perusahaan yang mengutamakan mobile (mobile first company)
- Secara penuh menggunakan platform cloud – Walaupun ini jadinya agak bertentangan dengan idealisme Leon dan William
- Mengubah arsitekturnya ke SoA (Service oriented Architecture)
- Membuka API ke publik
- Mengganti beberapa teknologi. Contohnya Perl sedang dalam proses untuk diganti dengan bahasa program buatan Google, Go.
- Sistem peringatan (alert) dan pemantauan yang lebih canggih – Dulu hanya menggunakan bash manual, sekarang dalam proses untuk menggunakan Runscope, Ichinga dan DataDoc.
- Menggunakan beberapa pihak ketiga – Sebagai contoh, EdgeCast yang sebesar itu saja masih pernah mati layanannya.
- Menggunakan datawarehouse: Cubes, Pentaho – Untuk Business Intelligence
- Terus mengembangkan machine learning untuk anti phising, customer care, dll. – Tokopedia sedang dalam pengembangan membuat bot yang bisa memberikan jawaban paling relevan dari pertanyaan yang masuk ke sistem Customer Service (CS). Saat ini masih menjadi assisting tool, CS akan diberikan 3 pilihan jawaban yang paling relevan dari pertanyaan pengguna. Sejauh ini tingkat akurasinya sudah 60%.
- Lebih perhatian lagi pada keamanan (infosec)
Catatan: Walaupun scaling itu rumit dan seringkali disebut “sebaiknya dilakukan sejak awal” ini tidak berarti serta merta dilakukan berlebihan. Apa jadinya kalau sejak awal Leon justru terlalu sibuk bereksperimen dengan Haskell, Hadoop, Erlang, CouchDB, dll.
Menyenangkan melihat semakin banyak perusahaan teknologi yang mau berbagi pengalaman mereka soal teknologinya. Selain Blibli, SaleStock juga sudah pernah membagikan pengalaman mereka dengan teknologi yang digunakan.
Berbagi pengalaman soal “kisah sukses” tentu punya nilai positif, tetapi berbagi pengalaman soal hal-hal yang nyata seperti ini tentu akan sangat membantu mereka-mereka yang bekerja “di lapangan” mewujudkan mimpi para pendiri startup.
TIPS: Untuk yang masih penasaran bagaimana cara scaling para perusahaan teknologi besar itu, sering-seringlah berkunjung ke HighScalability.com. Saya sering mampir ke situs ini sejak awal 2009. Di sana diulas arsitektur YouTube, Twitter, Flickr, dll.