Cara Netflix Mengefisienkan Biaya Infrastruktur Data

Karena struktur infrastruktur Netflix yang terdistribusi dan budaya internal "freedom and responsibility", efisiensi merupakan pekerjaan yang cukup sulit. Untuk memberikan transparansi biaya dan menempatkan konteks terkait efisiensi lebih dekat ke para pengambil keputusan, mereka mengembangkan dasbor khusus.

Cara mereka membuat "Data Efficiency Dashboard" ini dan pelajaran yang didapat

• Lingkungan platform data Netflix: dapat diklasifikasikan menjadi dua

1. Data at Rest : Snowflake, S3, Hive, RDS, ElasticSearch, Cassandra, Druid

2. Data in Motion : Keystone, Flink, Mantis, Spark, Kafka, Presto

** Visibilitas penggunaan dan biaya dalam sekali lihat **

Mereka menggabungkan biaya dari semua platform, sambil tetap menyertakan informasi yang memungkinkan tiap biaya dipecah ke unit-unit yang bermakna.

 → Unit: tabel, indeks, column family, job, dan lain-lain

Sumber informasi biaya ini pada dasarnya bergantung pada informasi billing AWS yang diklasifikasikan berdasarkan layanan dan tag, tetapi itu saja tidak cukup untuk membedakan per resource/tim, sehingga mereka menggunakan metode berikut.

• Platform berbasis EC2

 → Mendefinisikan metrik bottleneck untuk tiap platform

 → Misalnya, Kafka terikat pada jaringan, sedangkan Spark terikat pada CPU dan memori.

 → Dengan memanfaatkan Atlas, log platform, dan REST API, mereka membedakan metrik per resource lalu mengalokasikan biayanya

• Platform berbasis S3

 → Menambahkan S3 prefix untuk tiap resource, lalu menghitung biaya per resource berdasarkan harga storage

• Tampilan Dashboard

Menggunakan dasbor khusus berbasis Apache Druid untuk mengalokasikan tiap biaya ke tim.

Pelanggan utama informasi biaya ini adalah tim engineering dan data, agar mereka dapat mengambil tindakan berdasarkan informasi tersebut.

Selain itu, informasi ini juga disediakan untuk para engineering leader dalam tampilan yang lebih tingkat tinggi.

Sesuai use case, data dapat dilihat dengan pengelompokan berdasarkan unit resource data atau unit organisasi, baik sebagai snapshot maupun time series

** Rekomendasi storage otomatis - Time to Live (TTL) **

Dalam beberapa skenario, mereka tidak hanya memberikan transparansi, tetapi juga rekomendasi optimasi.

Karena data storage memiliki penggunaan yang besar dan momentum biaya yang tinggi (seperti disimpan lalu terlupakan),

mereka mengotomatiskan analisis untuk menentukan periode penyimpanan optimal (TTL) berdasarkan pola penggunaan data.

Rekomendasi TTL diterapkan untuk tabel-tabel big data warehouse di S3

• Perhitungan biaya dan logika bisnis

Biaya S3 terbesar berasal dari transaction table, yang umumnya dipartisi berdasarkan tanggal

Dengan menggunakan S3 access log dan pemetaan S3 prefix-to-table-partition, mereka dapat menentukan partisi tanggal yang diakses.

Mereka melihat aktivitas akses (baca/tulis) selama 180 hari terakhir untuk memeriksa maksimum hari lookback.

Nilai TTL tabel tersebut ditentukan oleh hari lookback ini.

Berdasarkan TTL yang dihitung ini, mereka menghitung potensi penghematan tahunan yang dapat direalisasikan

• Tampilan Dashboard

Pemilik data dapat melihat pola akses data yang detail, membandingkan nilai rekomendasi TTL dengan nilai saat ini, dan juga memeriksa potensi penghematan biaya

** Komunikasi dan memberi tahu pengguna **

Memeriksa biaya data seharusnya tidak menjadi pekerjaan rutin sehari-hari bagi tim teknis, terutama jika itu adalah biaya data yang tidak bermakna.

Karena itu, mereka mengembangkan fungsi push notification via email hanya untuk tim dengan penggunaan data tinggi agar kesadaran terhadap biaya data bisa meningkat.

Selain itu, nilai rekomendasi TTL juga dikirim secara otomatis hanya untuk tabel yang memiliki potensi penghematan biaya.

Saat ini, email seperti ini dikirim setiap bulan

** Pelajaran dan tantangan **

1. Mengidentifikasi dan memelihara metadata tiap aset penting untuk alokasi biaya

 → Untuk itu, mereka membangun repositori metadata bernama Netflix Data Catalog (NDC)

 → Akses dan pencarian data menjadi lebih mudah, sehingga baik data lama maupun data baru dapat dikelola

 → NDC digunakan sebagai titik awal perhitungan biaya

2. Data tren waktu itu menantang

 → Dibanding snapshot, data tren memiliki beban pengelolaan yang jauh lebih besar

 → Sulit menyediakan tampilan yang konsisten karena ketidaksesuaian data dan latency pemrosesan

 → Mereka harus menyelesaikan dua tantangan berikut

  - Perubahan kepemilikan resource: pada snapshot, perubahan kepemilikan harus otomatis tercermin, dan untuk tampilan time series, bahkan perubahan tersebut juga perlu tercermin dalam metadata

  - Kehilangan state saat terjadi masalah data: karena metadata resource diekstrak dari berbagai sumber melalui API, jika terjadi kegagalan saat pengumpulan maka state bisa hilang. Data semacam ini bersifat sementara, sehingga hanya mengandalkan ekstraksi API ada batasnya. Mereka perlu mencari alternatif seperti memompa data ke sisi Keystone

** Kesimpulan **

Jika Anda memiliki platform data yang sangat terdistribusi, membuat feedback loop melalui dasbor seperti ini dan mengintegrasikan konteks penggunaan serta biaya dapat sangat meningkatkan efisiensi.

Jika memungkinkan, efisiensi sebaiknya ditingkatkan melalui rekomendasi otomatis.

Dalam kasus Netflix, rekomendasi periode retensi data menunjukkan ROI yang tinggi.

Melalui dasbor ini dan rekomendasi TTL, mereka dapat mengurangi ruang penyimpanan seluruh data warehouse lebih dari 10%.

[kunggom]

Ternyata fitur rekomendasi bukan hanya untuk penonton.

[heycalmdown]

Bagus. Saya tiba-tiba teringat pernah melihat penelitian di suatu tempat yang mengatakan bahwa jika kita bisa melihat alat pemantauan waktu nyata, bahkan otot tak sadar pun bisa digerakkan.