Bagaimana Netflix Menangani 200 Juta Pengguna: Analisis Desain Sistem

Mengapa Angka "200 Juta Pengguna" Merupakan Tantangan yang Jauh Lebih Sulit daripada Kelihatannya

Sering kali kita tergoda untuk menganggap skala hanya sebagai "lalu lintas data yang besar", namun pandangan tersebut meremehkan tantangan teknis yang sebenarnya. Basis pengguna Netflix tidak tersebar secara merata sepanjang hari. Jumlah pengguna melonjak tajam pada malam hari, melonjak lebih tinggi lagi pada akhir pekan, dan mencapai tingkat lonjakan luar biasa saat ada peristiwa global. Satu acara siaran langsung saja bisa mendorong total pengiriman data hingga mencapai kisaran puluhan terabit per detik di seluruh jaringan distribusi Netflix; menariknya, hampir tidak ada lalu lintas data tersebut yang menyentuh pusat penyimpanan (cloud origin) milik Netflix sendiri, karena konten disajikan melalui perangkat keras caching yang secara fisik ditempatkan di dalam jaringan penyedia layanan internet (ISP) di seluruh dunia.

Detail terakhir inilah kunci untuk memahami filosofi Netflix secara keseluruhan, yaitu skala bukan sekadar masalah komputasi, melainkan masalah fisika dan geografi. Ukuran file videonya sangat besar, penggunanya tersebar di mana-mana, dan toleransi terhadap delay atau buffering hampir nol. Oleh karena itu, arsitektur Netflix harus memecahkan dua jenis tantangan skalabilitas yang sangat berbeda secara bersamaan. Pertama adalah masalah control plane, yaitu bagaimana menyajikan halaman beranda yang dipersonalisasi, fitur pencarian, rekomendasi, sistem penagihan, dan manajemen akun untuk ratusan juta sesi yang berlangsung serentak tanpa ada satu komponen pun yang menjadi hambatan. Kedua adalah masalah data plane, yaitu bagaimana memindahkan data video dalam jumlah yang sangat masif—hingga sulit dibayangkan—dari penyimpanan ke layar pengguna tanpa mengalami buffering ulang. Netflix mengatasi hal ini dengan dua sistem yang sebagian besar terpisah namun terkoordinasi dengan sangat erat; kita akan membahasnya satu per satu.

Dari Satu Database Tunggal Menjadi Ratusan Layanan Independen

Kita sering lupa bahwa Netflix tidak bermula seperti kondisinya saat ini. Pada masa awal layanan pengiriman DVD dan tahap awal streaming, perusahaan ini beroperasi menggunakan arsitektur monolitik yang cukup konvensional dengan dukungan database relasional. Pendekatan tersebut akhirnya kewalahan menghadapi beban kerja yang ada. Sebuah insiden kerusakan database yang signifikan pada tahun 2008 menyebabkan layanan tidak dapat diakses selama sekitar tiga hari; peristiwa ini menjadi titik balik yang mendorong Netflix beralih ke metode pengembangan software yang sangat berbeda. Pada tahun-tahun berikutnya, jajaran pimpinan teknis mengambil dua keputusan yang menjadi landasan bagi segala perkembangan selanjutnya, yaitu beralih dari pusat data milik sendiri ke public cloud, serta memecah sistem monolitik tersebut menjadi layanan-layanan kecil yang dapat diterapkan secara independen dan masing-masing memiliki tanggung jawab spesifik yang terbatas.

Menjelang tahun 2016, Netflix telah merampungkan migrasi ke Amazon Web Services, dan sistem monolitik lama telah sepenuhnya digantikan oleh ekosistem yang terdiri dari ratusan—dan pada akhirnya ribuan—microservice. Ini bukan sekadar penataan ulang tampilan luar semata. Langkah ini merupakan keputusan strategis yang didasari keyakinan bahwa mengisolasi kegagalan jauh lebih bernilai daripada sekadar memaksimalkan efisiensi pada satu komponen tertentu. Jika layanan rekomendasi mengalami gangguan, fitur pemutaran video harus tetap berjalan lancar. Jika layanan penilaian atau rating mengalami kegagalan, fitur pencarian tidak boleh ikut terganggu. Setiap layanan dapat dikembangkan oleh tim kecil, diterapkan sesuai jadwal masing-masing, ditingkatkan kapasitasnya secara independen berdasarkan pola lalu lintas datanya sendiri, dan—yang terpenting—diizinkan untuk mengalami kegagalan tanpa menyebabkan seluruh platform ikut lumpuh. Konsep merancang sistem yang tangguh menghadapi kegagalan—alih-alih mencoba mencegah kegagalan sepenuhnya—ini diterapkan di hampir setiap lapisan sistem Netflix, dan konsep ini akan kembali dibahas saat kita membicarakan chaos engineering.

Lapisan Edge: Tempat Pertama Mendaratnya Setiap Permintaan

Apa pun perangkat yang kita gunakan, permintaan kita tidak langsung menuju ke layanan backend tertentu. Permintaan tersebut pertama-tama tiba di lapisan edge Netflix, dan komponen perangkat lunak yang menjalankan tugas ini bernama Zuul. Zuul berperan sebagai API gateway dan pintu masuk tunggal bagi seluruh platform; ia bertanggung jawab mengarahkan permintaan masuk ke layanan internal yang tepat, menangani autentikasi, serta menanggung sebagian besar kompleksitas operasional sehingga setiap layanan individual tidak perlu lagi membuat ulang mekanisme seperti pembatasan laju atau penyaringan permintaan. Versi awal Zuul dibangun ulang menggunakan Netty agar sepenuhnya bersifat asinkron dan non-blocking. Hal ini sangat krusial mengingat besarnya volume lalu lintas data di Netflix, karena memungkinkan sejumlah kecil instance gateway untuk menangani koneksi konkuren dalam jumlah masif tanpa menyebabkan penumpukan thread yang menunggu respons lambat dari layanan hilir atau downstream.

Setelah permintaan melewati lapisan edge, sistem harus menemukan layanan backend spesifik yang mampu menanganinya. Di sinilah situasinya menjadi menarik, karena dalam sistem yang melibatkan ribuan instance layanan yang terus-menerus dimulai, dihentikan, disesuaikan skalanya, dan dipindahkan antar-mesin, penggunaan alamat IP yang dikodekan secara permanen (hardcoding) jelas bukan pilihan yang tepat. Netflix mengatasi masalah ini dengan alat penemuan layanan bernama Eureka. Setiap instance layanan mendaftarkan dirinya ke Eureka saat mulai aktif, mengirimkan sinyal heartbeat secara berkala untuk menunjukkan kondisinya yang sehat, serta menghapus pendaftarannya saat layanan tersebut dimatikan. Layanan lain kemudian bertanya kepada Eureka—pada dasarnya menanyakan, "siapa yang saat ini bisa menangani jenis permintaan ini?"—dan menerima daftar instance sehat yang aktual, bukan sekadar berkas konfigurasi statis yang mudah kedaluwarsa.

Mencegah Satu Layanan Lambat Melumpuhkan Seluruh Sistem

Sistem terdistribusi yang dibangun dari ratusan layanan yang saling bergantung menghadirkan kategori risiko baru yang tidak perlu dikhawatirkan oleh sistem monolitik, yaitu kegagalan berantai. Jika layanan A memanggil layanan B, dan layanan B tiba-tiba melambat—alih-alih langsung mati total—thread pada layanan A bisa menumpuk karena menunggu respons yang tak kunjung tiba tepat waktu. Bayangkan skenario ini terjadi di sepanjang rantai dependensi yang melibatkan banyak layanan; satu komponen yang lambat saja bisa diam-diam melumpuhkan seluruh platform, meskipun sebenarnya tidak ada komponen yang benar-benar "mati".

Solusi Netflix untuk masalah ini adalah pola circuit breaker, yang diimplementasikan melalui library bernama Hystrix. Konsep ini diadopsi langsung dari teknik kelistrikan, yaitu ketika sebuah dependensi mulai gagal atau merespons terlalu lambat, circuit breaker akan "memutus arus" (aktif), menghentikan pengiriman permintaan baru selama periode jeda, dan segera beralih menggunakan respons default atau cache sebagai gantinya. Hal ini memberikan ruang bagi layanan yang bermasalah untuk pulih tanpa terus-menerus dibebani oleh upaya percobaan ulang, sekaligus melindungi layanan pemanggil agar tidak membuang-buang sumber daya demi menunggu sesuatu yang tidak akan memberikan respons tepat waktu. Selain itu, Netflix menerapkan pola bulkhead (sekat kedap air)—yang diadaptasi dari desain kapal—di mana kompartemen kedap air mencegah kebocoran lambung di satu bagian menenggelamkan seluruh kapal. Dalam konteks software, ini berarti mengisolasi kumpulan sumber daya, seperti thread pool atau batas koneksi, sehingga satu dependensi yang kewalahan tidak menghabiskan sumber daya yang dibutuhkan oleh bagian lain sistem agar tetap dapat berfungsi.

Memilih Database yang Tepat untuk Setiap Kebutuhan

Salah satu pelajaran yang mungkin tidak lazim dari arsitektur Netflix adalah tidak adanya satu "database Netflix" tunggal. Berbagai masalah memiliki pola akses data yang secara mendasar berbeda, sehingga para insinyur Netflix memilih teknologi penyimpanan yang berbeda untuk setiap kebutuhan, alih-alih memaksakan semuanya melalui satu sistem.

Untuk data yang harus tersedia secara global, sering diperbarui, dan tidak boleh terhenti akibat kegagalan pada satu titik tunggal—seperti riwayat tontonan, preferensi pengguna, dan peringkat—Netflix sangat mengandalkan Apache Cassandra. Cassandra adalah database terdistribusi jenis wide-column yang dirancang dengan prinsip bahwa ketersediaan dan toleransi partisi lebih penting daripada konsistensi ketat untuk sebagian besar beban kerja tersebut. Teknologi ini sangat selaras dengan filosofi microservices terdesentralisasi Netflix, karena setiap layanan dapat mengelola tabel Cassandra-nya sendiri tanpa perlu berkoordinasi melalui database pusat yang digunakan bersama.

Untuk data yang perlu sering dibaca dan diakses dengan latensi dalam hitungan milidetik—seperti progres "lanjutkan menonton", metadata sesi, dan sinyal personalisasi—Netflix membangun dan merilis sebagai open-source lapisan caching buatannya sendiri yang disebut EVCache, yang berbasis pada Memcached. EVCache menangani volume operasi baca dan tulis yang sangat besar serta dirancang khusus agar tetap berfungsi meskipun terjadi kegagalan pada seluruh Availability Zone AWS atau bahkan satu wilayah penuh tanpa disadari oleh pengguna; hal ini dimungkinkan karena cache direplikasi lintas zona dan wilayah, bukan hanya tersimpan di satu lokasi. Untuk beban kerja yang benar-benar membutuhkan jaminan relasional tradisional—seperti penagihan dan catatan transaksi tertentu—Netflix tetap menggunakan database relasional seperti MySQL yang berjalan pada infrastruktur terkelola. Sementara itu, file video mentah disimpan dalam object storage, siap untuk diambil dan disalurkan melalui jaringan pengiriman konten yang dijelaskan pada bagian berikutnya.

Open Connect: Jaringan Pengiriman Konten Milik Netflix

Jika lapisan microservices adalah otak Netflix—yang menentukan apa yang ditampilkan kepada kita dan mengelola akun kita—maka jaringan Open Connect adalah sistem peredaran darah yang benar-benar mengalirkan video ke ruang tamu kita. Ini bisa dibilang merupakan elemen paling khas dari keseluruhan arsitektur Netflix; alih-alih hanya mengandalkan Content Delivery Network atau CDN pihak ketiga, Netflix membangun dan mengoperasikan jaringannya sendiri, bahkan menyediakan perangkat kerasnya secara cuma-cuma.

Komponen utamanya disebut Open Connect Appliance, yaitu server khusus yang dilengkapi penyimpanan berkapasitas ratusan terabyte. Netflix memproduksi dan mengirimkan perangkat ini secara gratis kepada penyedia layanan internet (ISP) yang ingin memasangnya di dalam jaringan mereka sendiri. Jadi, alih-alih permintaan video kita harus menempuh perjalanan melintasi internet publik menuju pusat data Netflix yang jauh, video tersebut disajikan dari perangkat yang secara fisik berada di dalam atau sangat dekat dengan infrastruktur ISP kita. Netflix menyatakan bahwa sebagian besar lalu lintas datanya secara global—sekitar 95 persen—disalurkan melalui cara ini, yakni lewat koneksi langsung ke ISP perumahan yang digunakan masyarakat untuk mengakses internet.

Hal yang membuat sistem ini sangat cerdas adalah sifat Open Connect yang proaktif, bukan reaktif. CDN konvensional biasanya hanya menyimpan konten yang menjadi populer setelah pengguna mulai memintanya. Sebaliknya, Open Connect memuat terlebih dahulu judul-judul baru dan populer ke dalam perangkat pada jam-jam di luar waktu sibuk di malam hari—yang secara internal disebut sebagai fill windows. Pada dasarnya, sistem ini memprediksi apa yang ingin ditonton oleh suatu wilayah bahkan sebelum ada yang memintanya. Saat pemutaran video dimulai, perangkat klien mengambil manifes dan segmen video dari perangkat terdekat. Jika karena alasan tertentu perangkat tersebut tidak memiliki cache konten yang dimaksud, sistem akan beralih secara mulus ke lokasi lain alih-alih langsung menggagalkan permintaan tersebut. Pada masa lonjakan permintaan yang luar biasa—seperti saat siaran langsung pertandingan olahraga besar—jaringan ini terbukti mampu mempertahankan pengiriman data dengan kecepatan agregat mencapai puluhan terabit per detik, tanpa hampir sama sekali melibatkan pusat data cloud utama Netflix.

Pengodean Video untuk Berbagai Layar dan Koneksi

Kecepatan pengiriman data hanya akan bermakna jika data itu sendiri efisien; di sinilah peran penting alur kerja pengodean video Netflix. Alih-alih mengodekan setiap judul film pada beberapa tingkat kualitas yang baku, Netflix memelopori pendekatan pengodean yang disesuaikan untuk setiap judul, dan kemudian berkembang menjadi penyesuaian per shot (potongan adegan). Urutan aksi yang bergerak cepat dan wawancara statis (di mana subjek hanya berbicara di depan kamera) memiliki kebutuhan kompresi yang sangat berbeda. Oleh karena itu, alih-alih menggunakan standar bitrate yang sama untuk semua konten, Netflix menganalisis kompleksitas visual nyata dari setiap konten dan menyesuaikan proses pengodeannya. Mereka sering menggunakan metrik kualitas perseptual—yang menilai bagaimana mata manusia benar-benar melihat hasilnya—ketimbang hanya mengandalkan rasio kompresi matematis semata. Hasilnya, Netflix mampu menyajikan kualitas gambar yang jauh lebih baik dengan ukuran file yang lebih kecil; hal ini sangat krusial saat mengirimkan file tersebut ke ratusan juta perangkat melalui berbagai jenis koneksi, mulai dari jaringan serat optik berkecepatan gigabit hingga jaringan seluler yang padat.

Dari sisi pemutaran, teknologi adaptive bitrate streaming terus memantau kondisi jaringan perangkat secara real-time dan beralih antar-tingkat kualitas secara dinamis. Sistem ini lebih mengutamakan kelancaran gambar tanpa gangguan dibandingkan memaksakan resolusi tertinggi dengan segala cara. Di sinilah sistem autentikasi edge dan DRM Netflix berperan; sistem ini berkoordinasi dengan kerangka kerja pemutaran yang dibangun di atas teknologi HTML5 Media Source dan Encrypted Media Extensions untuk menjaga kelancaran serta keamanan aliran video, tanpa perlu memuat ulang halaman atau melakukan negosiasi ulang setiap kali kondisi jaringan berubah.

Mengubah Setiap Klik Menjadi Sinyal

Mesin rekomendasi Netflix sering kali dianggap sebagai topik yang terpisah dari infrastrukturnya, padahal keduanya saling terkait erat. Setiap tindakan menjeda, memutar ulang, melompati bagian video, mengubah kualitas, hingga menyelesaikan episode direkam sebagai sebuah peristiwa dan dialirkan melalui pipeline data real-time yang dibangun di atas Apache Kafka; sistem ini berperan sebagai sistem saraf pusat yang memindahkan peristiwa-peristiwa tersebut dari lokasi kejadian ke tempat pemrosesannya. Dari sana, kerangka kerja pemrosesan berskala besar seperti Apache Spark mengolah data tersebut untuk memperbarui model rekomendasi, mendeteksi anomali, dan menyuplai data ke dasbor analitik—semuanya dilakukan tanpa mengganggu jalur latensi rendah yang sedang melayani pemutaran video bagi penonton yang sedang aktif. Pemisahan ini sangat penting karena memastikan bahwa tugas masif dan berat secara komputasi—yaitu memahami perilaku menonton dari dua ratus juta akun—tidak pernah berebut sumber daya dengan tugas yang jauh lebih sensitif terhadap waktu, yakni menjaga kelancaran pemutaran video bagi penonton saat itu juga.

Sengaja Merusak Sistem demi Membangun Ketangguhan

Mungkin aspek paling terkenal dari budaya rekayasa Netflix adalah pendekatannya terhadap pengujian ketangguhan, yaitu alih-alih berharap kegagalan tidak terjadi, Netflix menciptakan alat yang sengaja memicu kegagalan tersebut pada sistem yang sedang beroperasi. Hal ini bermula dari alat bernama Chaos Monkey, yang secara acak menghentikan instans layanan yang sedang aktif pada jam kerja. Tujuannya adalah memaksa tim rekayasa membangun sistem yang mampu bertahan meski kehilangan server secara tiba-tiba, tanpa disadari oleh pengguna. Chaos Monkey kemudian dikembangkan menjadi kumpulan alat yang lebih luas—yang terkadang disebut sebagai Simian Army—untuk menyimulasikan berbagai skenario, mulai dari kegagalan seluruh zona ketersediaan AWS hingga peningkatan latensi antar-layanan. Penambahan terbaru mencakup kerangka kerja Failure Injection Testing untuk penyuntikan gangguan yang sangat spesifik, serta Chaos Automation Platform otomatis yang menjalankan eksperimen chaos secara berkelanjutan—dengan pengawasan ketat dan pemantauan statistik—alih-alih sekadar latihan manual yang dilakukan sesekali.

Filosofi dasar di balik pendekatan ini patut dicermati, karena hal tersebut membalikkan cara pandang sebagian besar organisasi mengenai keandalan sistem. Alih-alih menganggap kegagalan sebagai peristiwa luar biasa yang harus dicegah, Netflix memandang kegagalan sebagai suatu kepastian yang harus diantisipasi. Pada sistem terdistribusi berskala besar, selalu ada komponen yang mengalami kegagalan di suatu tempat—baik itu cakram penyimpanan, koneksi jaringan, satu instans layanan, maupun seluruh wilayah pusat data. Satu-satunya pilihan nyata bagi tim rekayasa adalah menentukan apakah sistem mampu menyerap kegagalan tersebut dengan mulus atau justru mengalami pemadaman layanan. Dengan terus-menerus melakukan simulasi kegagalan secara aman, Netflix membangun sistem—dan budaya rekayasa—yang menjadikan ketangguhan sebagai sebuah kebiasaan, bukan sekadar harapan.

Menyebarkan dan Memantau Ribuan Layanan Secara Bersamaan

Menjalankan ribuan layanan independen akan sangat sulit dikelola tanpa investasi serius pada perangkat (tooling) untuk deployment dan observabilitas. Netflix membangun Spinnaker untuk menangani pengiriman berkelanjutan di berbagai wilayah cloud, yang memungkinkan tim meluncurkan pembaruan secara bertahap dan aman, alih-alih meluncurkan semuanya sekaligus. Deployment baru sering kali dilakukan sebagai canary, yaitu rilis berskala kecil yang dibandingkan secara otomatis dengan versi yang sedang berjalan menggunakan alat bernama Kayenta. Alat ini menganalisis metrik secara statistik, seperti tingkat kesalahan dan latensi, untuk mendeteksi masalah sebelum berdampak pada seluruh basis pengguna. Kontainer itu sendiri berjalan di atas Titus, platform manajemen kontainer buatan Netflix yang dirancang khusus untuk beroperasi dalam skala cloud di AWS, jauh sebelum Kubernetes menjadi standar industri seperti sekarang ini.

Semua ini tidak akan berguna tanpa visibilitas terhadap apa yang sebenarnya terjadi di seluruh armada layanan; di sinilah peran Atlas, sistem telemetri internal buatan Netflix. Atlas menyerap metrik time-series dalam volume sangat besar dari berbagai layanan di seluruh platform dan mendukung evaluasi streaming secara real-time. Dengan demikian, sistem peringatan dapat merespons masalah yang sedang berkembang dalam hitungan detik, bukan menunggu hingga pekerjaan batch terjadwal mendeteksi adanya kegagalan. Secara keseluruhan, rangkaian teknologi penyebaran dan observabilitas inilah yang memungkinkan para insinyur Netflix meluncurkan perubahan ke lingkungan produksi berkali-kali dalam sehari tanpa menjadikan kecepatan perubahan tersebut sebagai sumber ketidakstabilan sistem.

Apa yang Sebenarnya Bisa Dipelajari Insinyur Lain dari Hal Ini
Ada baiknya kita bersikap jujur ​​mengenai satu hal sebelum mengakhiri pembahasan ini, yaitu hampir tidak ada pihak yang perlu membangun sistem persis seperti milik Netflix, dan upaya menirunya secara mentah-mentah biasanya merupakan sebuah kesalahan. Arsitektur Netflix lahir dari kebutuhan spesifik—yakni layanan video berskala sangat masif dan sangat sensitif terhadap latensi—yang dipadukan dengan organisasi teknik yang besar dan matang serta proses iterasi selama bertahun-tahun. Tim yang sedang membangun aplikasi web pada umumnya tidak memerlukan perangkat keras CDN kustom sendiri yang ditempatkan di dalam pusat data ISP.

Namun, hal yang dapat diterapkan dalam konteks lain adalah logika atau penalaran dasarnya. Mengisolasi domain kegagalan agar kerusakan pada satu komponen tidak melumpuhkan keseluruhan sistem adalah langkah yang bermanfaat pada hampir semua skala. Memilih teknologi penyimpanan berdasarkan pola akses yang sebenarnya—alih-alih selalu menggunakan satu jenis database relasional untuk segala kebutuhan—merupakan kebiasaan yang patut diadopsi sejak awal. Memisahkan jalur cepat yang sensitif terhadap latensi (yang ditunggu-tunggu pengguna) dari tugas analitik yang lebih lambat dan berat di latar belakang dapat mencegah berbagai masalah kinerja yang signifikan. Selain itu, menguji asumsi mengenai kegagalan sistem sebelum masalah tersebut benar-benar muncul di lingkungan produksi jauh lebih hemat biaya dan tidak terlalu menyakitkan dibandingkan harus mengetahui adanya titik lemah saat terjadi gangguan layanan yang nyata. Netflix tidak mencapai semua ini secara kebetulan; fakta bahwa banyak aspek dari sistem mereka telah didokumentasikan dan dirilis sebagai open-source untuk publiklah yang menjadikannya studi kasus yang sangat berharga bagi siapa pun yang serius mendalami sistem terdistribusi.