Netflix veri altyapısı maliyetlerini nasıl daha verimli hale getiriyor

Netflix'in dağıtık altyapı yapısı ve şirket içindeki "özgürlük ve sorumluluk" kültürü nedeniyle verimlilik sağlamak oldukça zor olduğundan, maliyet şeffaflığı sunmak ve verimlilikle ilgili bağlamı karar vericilere yaklaştırmak için özel panolar geliştirdi.

Bu "veri verimliliği panosunun" nasıl oluşturulduğu ve çıkarılan dersler

• Netflix'in veri platformu ortamı: iki kategoriye ayrılabilir

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

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

** Kullanım ve maliyet görünürlüğünü tek bakışta görmek **

Tüm platformların maliyetleri toplanıyor; her maliyet, anlamlı birimlere bölünebilmesini sağlayan bilgilerle birlikte derleniyor

→ birimler: tablo, indeks, column family, job vb.

Bu maliyet bilgisinin kaynağı temelde servis ve etiket bazında sınıflandırılmış AWS faturalama verilerine dayanıyor; ancak bu tek başına kaynak/takım bazında ayrım yapmaya yetmediği için şu yöntemler kullanılıyor:

• EC2 tabanlı platformlar

→ darboğaza neden olan metrikler (bottleneck metric) her platform için tanımlanıyor

→ örneğin Kafka ağa bağımlıyken, Spark CPU ve belleğe bağımlı.

→ Atlas, platform log'ları ve Rest API kullanılarak her kaynağa ait metrikler ayrıştırılıyor ve maliyet atanıyor

• S3 tabanlı platformlar

→ her kaynağa S3 prefix atanıyor ve depolama fiyatı esas alınarak kaynak başına maliyet hesaplanıyor

• Dashboard View

Apache Druid tabanlı özel bir pano kullanılarak her maliyet takımlara atanıyor.

Bu maliyet bilgisinin başlıca kullanıcıları mühendislik ve veri ekipleri. Bilgiyi temel alarak aksiyon alabilmeleri için sunuluyor.

Ek olarak, mühendislik liderlerine daha üst seviyeden görebilecekleri bir görünüm sağlanıyor.

Use case'e göre veri kaynağı birimi veya organizasyon birimi bazında gruplandırılmış şekilde görülebiliyor; veriler snapshot ve zaman serisi olarak incelenebiliyor

** Otomatik depolama önerileri - Time to Live (TTL) **

Bazı senaryolarda şeffaflık sağlamanın ötesine geçilerek optimizasyon önerileri de sunuluyor.

Veri depolama hem yoğun kullanılıyor hem de maliyet momentumu yüksek olduğundan (saklanıp sonra unutulması gibi),

veri kullanım desenlerine dayanarak en uygun depolama süresini (TTL) belirleyen analiz otomatikleştirildi.

S3 üzerindeki büyük veri ambarı tablolarına TTL önerileri uygulanıyor

• maliyet hesaplama ve iş mantığı

En büyük S3 maliyetleri transaction tablolarından geliyor ve bunlar genellikle tarihe göre partition ediliyor

S3 access log'ları ve S3 prefix-to-table-partition eşlemesi kullanılarak hangi tarih partition'larına erişildiği belirlenebiliyor.

Son 180 gündeki erişim (okuma/yazma) etkinliği incelenerek maksimum lookback günü tespit ediliyor.

Bu lookback gününe göre ilgili tablonun TTL değeri belirleniyor.

Bu hesaplanan TTL temel alınarak gerçekleştirilebilir yıllık tasarruf miktarı hesaplanıyor

• Dashboard View

Veri sahipleri ayrıntılı veri erişim desenlerini görebiliyor; önerilen TTL ile mevcut değeri karşılaştırabiliyor ve olası maliyet tasarrufunu da inceleyebiliyor

** İletişim ve kullanıcıları bilgilendirme **

Veri maliyetlerini takip etmek teknik ekiplerin günlük işi olmamalı. Özellikle de anlamsız veri maliyetleri söz konusuysa.

Bu nedenle, veri maliyeti farkındalığını artırmak için yalnızca veri kullanımı yüksek olan takımlara e-posta push bildirimi gönderen bir özellik geliştirildi.

Ayrıca yalnızca maliyet tasarrufu potansiyeli olan tablolar için otomatik TTL önerileri gönderiliyor.

Şu anda bu e-postalar her ay gönderiliyor

** Dersler ve zorluklar **

1. Her varlığın metadata'sını tanımlamak ve güncel tutmak, maliyet ataması için kritik önem taşıyor

→ bunun için Netflix Data Catalog (NDC) adlı bir metadata deposu kuruldu

→ veri erişimi ve araması kolaylaştığı için ister mevcut ister yeni veri olsun yönetilebiliyor

→ NDC, maliyet hesaplamasının başlangıç noktası olarak kullanılıyor

2. Zaman trendi verileri zorlu

→ trend verilerinin yönetim yükü snapshot'lardan çok daha fazla

→ veri tutarsızlıkları ve işleme gecikmeleri nedeniyle tutarlı bir görünüm sunmak zor

→ iki sorunun çözülmesi gerekti

→ - kaynak sahipliğinin değişmesi: snapshot'ların sahiplik değişikliklerini otomatik yansıtması gerekirken, zaman serisi görünümünde değişikliklerin metadata'ya da işlenmesi gerekiyor

→ - veri sorunu olduğunda durum kaybı: kaynak metadata'sı API üzerinden çeşitli kaynaklardan çekildiği için toplama sırasında başarısızlık olursa durum kaybı yaşanıyor. Bu veriler geçici olduğundan yalnızca API'den çekmek yeterli değil. Veriyi Keystone tarafına pompalamak gibi alternatifler bulunmalı

** Sonuç **

Yüksek derecede dağıtık bir veri platformunuz varsa, bu tür panolarla bir geri bildirim döngüsü oluşturup kullanım ve maliyet bağlamını birleştirerek verimliliği önemli ölçüde artırabilirsiniz.

Mümkünse otomatik önerilerle verimlilik daha da yükseltilmeli.

Netflix örneğinde veri saklama süresi önerileri yüksek ROI sağladı.

Bu pano ve TTL önerileri sayesinde tüm veri ambarının depolama alanı %10'dan fazla azaltılabildi.

[kunggom]

Görünüşe göre öneri özelliği yalnızca izleyiciler için değilmiş.

[heycalmdown]

Güzelmiş. Bir yerde, gerçek zamanlı izleme cihazını görebiliyorsanız istemsiz kasları da hareket ettirebileceğinize dair bir araştırma görmüştüm; nedense birden aklıma geldi.