OTT platform ölçeklenebilirliği: 100 binden fazla canlı izleyiciyi karşılayın

Bir canlı yayın 10.000 izleyiciyle kusursuz çalışabilir, ama birkaç dakika içinde 100.000 kişi katıldığında yine de çökebilir.

İşte OTT platform ölçeklenebilirliğinin asıl zorluğu budur.

Canlı spor, son dakika haberleri, konserler, ürün lansmanları, dini etkinlikler ve büyük eğlence içerikleri; normal yayın talebinden çok farklı, ani trafik sıçramaları yaratabilir. Platformun, binlerce izleyici neredeyse aynı anda katılırken videoyu alması, işlemesi, yetkilendirmesi, dağıtması ve izlemesi gerekir.

Çözüm yalnızca daha fazla sunucu eklemek değildir. Ölçeklenebilir bir OTT mimarisi, dağıtım işinin büyük kısmını uç noktalara taşımalı, origin'i korumalı, uyarlanabilir bit hızlı yayını desteklemeli ve arızalardan sağ çıkacak kadar yedekliliğe sahip olmalıdır.

Bu rehber, bir OTT platformunu 100 binden fazla eşzamanlı izleyiciye hazırlamak için nelerin gerektiğini ve yayın şirketlerinin büyük bir canlı etkinlik öncesinde neleri test etmesi gerektiğini anlatıyor.

Eşzamanlı izleyici, toplam izleyiciden farklıdır.

Bir platformun milyonlarca kayıtlı kullanıcısı olabilir, ancak aynı anda izleyenlerin oranı küçüktür. Buna karşılık büyük bir etkinlik sırasında binlerce kullanıcı neredeyse aynı anda gelebilir.

Örneğin normalde 15.000 eşzamanlı izleyiciye hizmet veren bir platform düşünün. Bir şampiyonluk maçı başlıyor ve dakikalar içinde 100.000 kullanıcı izlemeye çalışıyor.

Bu, birçok katmanda baskı yaratır:

• Video alımı (ingest)

• Kodlama ve transkodlama

• Origin altyapısı

• CDN dağıtımı

• Kimlik doğrulama

• DRM

• API'ler ve veritabanları

• Oynatıcı istekleri

• Analitik

• Ödeme veya erişim hakkı sistemleri

Bu nedenle en önemli ilke basittir:

100.000 izleyicinin oluşturduğu trafiğin, her izleyici bağımsız bir video bağlantısıymış gibi origin'inize ulaşmasına izin vermeyin.

Dağıtım yükünün büyük bölümünü CDN üstlenmelidir. Video CDN'leri içeriği izleyiciye yaklaştırır ve origin'e geri dönmesi gereken trafiği azaltır.

Yüksek eşzamanlılığa sahip bir OTT mimarisi bir hat (pipeline) olarak düşünülebilir:

Canlı kaynak → Alım → Kodlama → Paketleme → Origin → CDN → Oynatıcı

Her katmanın sorumluluğu farklıdır.

1. Güvenilir alım

Canlı sinyal başlangıç noktasıdır. Giriş çökerse, hiçbir CDN kapasitesi yayını kurtaramaz.

Büyük etkinliklerde yedekli alım yollarını değerlendirmek yerinde olur. AWS'in canlı yayın çözümü gibi referans mimariler, dayanıklılığı artırmak için birincil ve ikincil girişler kullanır.

2. Uyarlanabilir bit hızlı kodlama

Yüksek bit hızlı tek bir yayın her izleyiciye uygun değildir.

Kodlayıcı birden fazla kalite seviyesi üretmeli ki oynatıcı, mevcut bant genişliğine ve cihaz performansına göre bunlar arasında geçiş yapabilsin.

Örneğin:

Kesin bit hızı merdiveni; içeriğe, cihazlara, kodeğe ve hedef kitleye göre belirlenmelidir.

Vodlix, HLS ve MPEG-DASH uyarlanabilir yayını destekler; böylece birden fazla kalite varyantı web, mobil ve TV ortamlarına dağıtılabilir.

3. Önce CDN yaklaşımıyla dağıtım

Eşzamanlılık sıçramasını karşılamada CDN en kritik bileşenlerden biridir.

Her izleyicinin video parçalarını tekrar tekrar origin'den istemesi yerine, CDN uç noktaları önbelleğe alınmış içeriği kullanıcıya daha yakın sunabilir.

AWS'in bir canlı yayın referans mimarisi, origin/paketleme katmanını Amazon CloudFront'un arkasına konumlandırır; yayını izleyicilere dağıtma işini CDN üstlenir.

100 bin izleyicilik bir etkinlikte bu ayrım kritiktir.

Uygulama sunucularınız öncelikle uygulama mantığını yürütmelidir. CDN'iniz ise ağır video dağıtım yükünü üstlenmelidir.

Canlı yayında en büyük hatalardan biri, origin'in izleyici sayısıyla birlikte kendiliğinden ölçekleneceği varsayımıyla tasarım yapmaktır.

100.000 izleyicinin aynı canlı parçayı istediğini düşünün. Bu istekler sürekli origin'e ulaşırsa altyapı kısa sürede boğulabilir.

Önbellekleme stratejisi, origin shielding ve verimli parça dağıtımı tam da bu yüzden önemlidir.

Canlı yayın özellikle zorlayıcıdır; çünkü manifestler sürekli değişir ve parçalar sık aralıklarla gelir. Bu nedenle mimari, canlı videonun istek desenine göre tasarlanmalı, sıradan web trafiği gibi ele alınmamalıdır.

İşe yarar bir kural şudur:

Yalnızca uygulama sunucularını değil, dağıtım katmanını ölçekleyin.

Cloudflare de benzer şekilde, video CDN'lerinin içeriği izleyiciye yakın sunarak gecikmeyi azalttığını ve origin'in aşırı yüklenmesini önlediğini belirtiyor.

Normal trafiğiniz 20.000 eşzamanlı izleyiciyse, altyapıyı tam olarak 20.000 için tasarlamak risklidir.

Önemli olan sayı, beklenen zirve eşzamanlılığınız artı bir güvenlik payıdır.

Basit bir planlama modelini düşünün:

Beklenen zirve = 100.000 izleyici

100.000'i sisteminizin tolere etmesi gereken üst sınır olarak görmek yerine, beklenmedik talep ve altyapı arızaları için ek kapasite oluşturun.

Kapasite planınız şunları dikkate almalıdır:

• Zirve eşzamanlı izleyici sayısı

• İzleyici artış hızı

• Ortalama video bit hızı

• CDN bölgelerinin sayısı

• Parça (segment) süresi

• Kalite varyantlarının sayısı

• Kimlik doğrulama istekleri

• API trafiği

• Analitik trafiği

• DRM/lisans istekleri

• Trafiğin beklenen coğrafi dağılımı

Bant genişliği ihtiyacı da bit hızıyla birlikte çarpıcı biçimde değişir.

Örneğin, ortalama 5 Mbps'lik bir dağıtım bit hızında:

100.000 izleyici × 5 Mbps = 500 Gbps

Bu trafiği doğrudan uygulama sunucularından ya da tek bir origin'den geçirmeye çalışmanın neden mantıklı bir mimari olmadığı buradan anlaşılır.

Video dağıtımı sistemin yalnızca bir parçasıdır.

Büyük bir etkinlik başladığında izleyiciler aynı anda şunları yapabilir:

1. Uygulamayı açmak.

2. Giriş yapmak.

3. Aboneliğini kontrol ettirmek.

4. Oynatma yetkisi istemek.

5. DRM lisansı istemek.

6. Yayını yüklemek.

7. Analitik olayları göndermek.

Tüm bu istekler aynı arka uç servisine giderse, CDN kusursuz çalışsa bile uygulama çökebilir.

Mümkün olan yerlerde iş yüklerini ayırın.

Kimlik doğrulama, erişim hakkı kontrolleri, API'ler, DRM, analitik ve video dağıtımı tek bir büyük bağımlılık zinciri oluşturmamalıdır.

Premium içerikte güvenlik, yoğun trafikte de etkin kalmalıdır. Vodlix, OTT platformunun bir parçası olarak canlı yayın güvenliği özellikleri, içerik kontrolleri ve çoklu platform DRM yetenekleri sunar.

Ölçeklenebilirlik, etkinlik başladıktan sonra sunucu CPU'suna bakarak doğrulanmaz.

Yayın hattının tamamına gerçek zamanlı görünürlük gerekir.

Önemli metrikler arasında şunlar var:

• Eşzamanlı izleyiciler

• Oynatma başlangıçları

• Başlatma süresi

• Ara belleğe alma (buffering) oranı

• Video bit hızı

• CDN isabet oranı

• Origin trafiği

• HTTP hata oranları

• Kimlik doğrulama gecikmesi

• DRM yanıt süresi

• Parça dağıtım hataları

• Yeniden ara belleğe alma olayları

• Coğrafi performans

Vodlix, video ve izleyici performansını izlemek için gerçek zamanlı analitik ve raporlama sunar. Giderek artan biçimde yayıncılıkta yapay zekâ, platformların içeriği zenginleştirmesine ve erişilebilirliği geniş ölçekte iyileştirmesine yardımcı oluyor.

Amaç, bozulmayı izleyiciler bildirmeye başlamadan önce yakalamaktır.

Bir etkinliğin 100.000 eşzamanlı izleyici çekmesi bekleniyorsa, ilk ölçeklenebilirlik testiniz canlı etkinlik olmasın.

Yayına almadan önce test edin.

İşe yarar bir test kurgusu şöyle olabilir:

Test, salt video oynatmadan çok daha fazlasını simüle etmelidir.

Giriş dalgalarını, API isteklerini, oynatma yetkilendirmesini, manifest isteklerini, CDN dağıtımını, DRM'i, analitiği ve bileşen arızalarından kurtarmayı test edin.

En değerli test, çoğu zaman var olduğunu bilmediğiniz darboğazı ortaya çıkaran testtir.

Etkinlik öncesi pratik bir kontrol listesi şunları içermelidir:

1. Zirve eşzamanlılığı doğrulayın.
Beklenen izleyici sayısını geçmiş etkinlikler, kayıtlar, pazarlama erişimi ve geçmiş trafik verileriyle tahmin edin.

2. CDN kapasitesini doğrulayın.
Dağıtım mimarinizin beklenen coğrafi dağılımı ve bant genişliği talebini karşılayabildiğinden emin olun.

3. Origin'i test edin.
Origin altyapısının ani istek selinden korunduğundan emin olun.

4. Kimlik doğrulama ve DRM'i test edin.
Kullanıcılar oynatma yetkisi alamıyorsa ölçeklenebilir bir video hattının hiçbir anlamı kalmaz.

5. Birden fazla bit hızı profilini test edin.
İzleyicilerin oynatma kesintiye uğramadan kalite değiştirebildiğini doğrulayın.

6. Gerçekçi bir yük testi yapın.
Hedef sayıda durmak yerine beklenen zirvenin ötesini test edin.

7. İzleme ve uyarıları kurun.
Hangi metriğin eskalasyonu tetiklediğini net biçimde bilin.

8. Bir yedek plan hazırlayın.
Kritik yayınlarda alım, işleme ve dağıtım için mümkün olan her yerde yedeklilik bulunmalıdır.

Tüm bu altyapıyı kendi bünyenizde kurmak; mühendislik, bulut, CDN, güvenlik, izleme ve operasyon alanlarında ciddi uzmanlık gerektirebilir.

Sıfırdan tüm OTT yığınını kurmadan yayına geçmek isteyen şirketler için Vodlix; canlı yayın, VOD, TV yayıncılığı, CDN entegrasyonu, uyarlanabilir yayın, analitik, gelir modelleri ve çoklu platform dağıtımını kapsayan, kullanıma hazır bir OTT platformu sunar. Vodlix tümüyle beyaz etiketli bir OTT platformudur; böylece kendi markanızla yayına geçip büyüyebilirsiniz.

Vodlix'in canlı yayın altyapısı üst düzey CDN'leri kullanır ve ölçeklenebilir canlı dağıtım için tasarlanmıştır. Platform ayrıca HLS ve MPEG-DASH'i, uyarlanabilir bit hızlı yayını, gerçek zamanlı analitiği ve web, mobil ile TV uygulamalarında canlı içeriği destekler.

Büyük canlı etkinliklere hazırlanan şirketler için bu, odağın her altyapı bileşenini ayrı ayrı kurmaktan; içeriği, kitleyi, gelir modelini ve izleme deneyimini yönetmeye kaymasını sağlar.

100 binden fazla eşzamanlı izleyiciyi karşılamak, 100.000 kişiyi taşıyacak kadar güçlü tek bir sunucu bulmak değildir.

Bu bir mimari sorunudur.

Ölçeklenebilir bir OTT platformu; video dağıtımını uygulama iş yüklerinden ayırır, içeriği dağıtmak için CDN altyapısı kullanır, origin'i korur, uyarlanabilir bit hızlı yayını destekler, kimlik doğrulama ve DRM'i ölçeklenebilir tutar, izleyici deneyimini gerçek zamanlı izler ve zirve koşullarını etkinlikten önce test eder.

En önemlisi, ölçeklenebilirlik trafik sıçraması gelmeden önce tasarlanmalıdır.

İşletmeniz büyük canlı etkinlikler bekliyorsa ortalama kitleye göre kurgulamak yetmez. Herkesin aynı anda Oynat'a bastığı an için kurgulayın.