# OTT platform ölçeklenebilirliği: 100 binden fazla canlı izleyiciyi karşılayın **Source:** https://vodlix.com/tr/blog/ott-platform-scalability **Summary:** OTT platformlarının ölçeklenebilir CDN'ler, uyarlanabilir yayın, dayanıklı altyapı, izleme ve yük testleriyle 100 binden fazla eşzamanlı izleyiciyi nasıl karşılayabileceğini öğrenin. **Published:** 2026-08-11 **Publisher:** Vodlix --- 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. ## 100 bin eşzamanlı izleyiciyi zorlaştıran nedir? {#100-bin-eşzamanlı-izleyiciyi-zorlaştıran-nedir} 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. ## Ölçeklenebilir canlı yayının arkasındaki mimari {#ölçeklenebilir-canlı-yayının-arkasındaki-mimari} 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](https://aws.amazon.com/media/resources/live-streaming/)'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: | **Kalite** | **Tipik kullanım** | | --- | --- | | 360p | Düşük bant genişliği / mobil | | 480p | Temel izleme | | 720p | HD yayın | | 1080p | Full HD | | 4K | Premium / yüksek bant genişliğiyle izleme | 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ı](https://vodlix.com/features/hls-mpeg-dash) 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. ## Origin darboğaza dönüşmemeli {#origin-darboğaza-dönüşmemeli} 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](https://www.cloudflare.com/learning/video/what-is-a-video-cdn/) 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. ## Ortalamaya değil, zirveye hazırlanın {#ortalamaya-değil-zirveye-hazırlanın} 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. ## Kimlik doğrulama ve DRM'in kendi ölçeklenebilirlik planı olmalı {#kimlik-doğrulama-ve-drm-in-kendi-ölçeklenebilirlik-planı-olmalı} 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. ## İzlemeyi etkinlik başlamadan önce devreye alın {#i-zlemeyi-etkinlik-başlamadan-önce-devreye-alın} Ö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â](/blog/ai-in-streaming), 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. ## Yük testi isteğe bağlı değildir {#yük-testi-isteğe-bağlı-değildir} 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 aşaması** | **Amaç** | | --- | --- | | 10.000 kullanıcı | Temel seviyeyi doğrulama | | 25.000 kullanıcı | Erken darboğazları belirleme | | 50.000 kullanıcı | Ölçekleme davranışını sınama | | 75.000 kullanıcı | Zirveye hazırlığı doğrulama | | 100.000+ kullanıcı | Beklenen etkinlik kapasitesini sınama | | Arıza testi | Yedeklilik ve kurtarmayı doğrulama | 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. ## OTT şirketleri büyük bir canlı etkinlik öncesinde ne yapmalı? {#ott-şirketleri-büyük-bir-canlı-etkinlik-öncesinde-ne-yapmalı} 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](/blog/state-of-ott-streaming) 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. ## Vodlix ölçeklenebilir OTT yayıncılığını nasıl destekliyor? {#vodlix-ölçeklenebilir-ott-yayıncılığını-nasıl-destekliyor} 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ı](https://vodlix.com/features) kurmadan yayına geçmek isteyen şirketler için Vodlix; [canlı yayın](https://vodlix.com/features/stream-live-video-online), [VOD](https://vodlix.com/features/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](https://vodlix.com/features/white-label); 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](https://vodlix.com/features/tv-apps) 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. ## Sonuç {#sonuç} 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. **Q: OTT platform ölçeklenebilirliği nedir?** OTT platform ölçeklenebilirliği, bir yayın hizmetinin artan izleyici sayısını, video isteklerini, bant genişliği ihtiyacını ve uygulama trafiğini kayda değer bir performans kaybı olmadan karşılayabilme yeteneğidir. **Q: Bir OTT platformu 100 bin eşzamanlı izleyiciyi nasıl karşılayabilir?** Ölçeklenebilir bir mimari genellikle CDN tabanlı dağıtımı, uyarlanabilir bit hızlı yayını, dayanıklı origin altyapısını, ölçeklenebilir kimlik doğrulamayı, izlemeyi ve kapsamlı yük testlerini bir araya getirir. **Q: Canlı yayında CDN neden önemlidir?** CDN, videoyu izleyiciye yaklaştırır ve doğrudan origin tarafından sunulması gereken trafiği azaltır; bu da ölçeklenebilirliği ve oynatma performansını iyileştirir. **Q: Uyarlanabilir bit hızlı yayın ölçeklenebilirliği artırır mı?** Bant genişliğini yönetmeye yardımcı olur ve oynatmayı iyileştirir; çünkü her izleyici, ağ ve cihaz koşullarına uygun bir kalite seviyesi alır. **Q: 100 bin izleyicilik bir etkinlik öncesinde neler test edilmeli?** Video dağıtımını, CDN performansını, origin yükünü, kimlik doğrulamayı, DRM'i, API'leri, analitiği, oynatma başlangıcını, ara belleğe almayı ve arızadan kurtarmayı test edin. **Q: 100 bin eşzamanlı yayın ne kadar bant genişliği gerektirir?** Dağıtılan bit hızına bağlıdır. İzleyici başına ortalama 5 Mbps'te, 100.000 eşzamanlı izleyici yaklaşık 500 Gbps toplam video verimine karşılık gelir. **Q: Vodlix canlı yayını destekliyor mu?** Evet. Vodlix; canlı TV'yi, canlı etkinlikleri, HLS ve MPEG-DASH yayınını, CDN dağıtımını, uyarlanabilir bit hızlı yayını, analitiği, gelir modellerini ve birden fazla platforma dağıtımı destekler. **Q: OTT platformları ortalama trafiğe göre mi, zirve trafiğe göre mi tasarlanmalı?** Ek kapasite ve yedeklilikle birlikte beklenen zirve trafiğe göre tasarlanmalı ve test edilmelidir. Ortalama trafik, büyük canlı etkinlikler için güvenilir bir ölçü değildir. **Q: Canlı yayın platformları trafik sıçramalarında neden çöker?** Yaygın nedenler arasında yetersiz CDN kapasitesi, aşırı yüklenmiş origin'ler, kimlik doğrulama ve DRM darboğazları, yeterince test edilmemiş API'ler, zayıf izleme ve yetersiz yedeklilik yer alır. **Q: Canlı OTT platformları için yük testi gerekli mi?** Evet. Yük testleri, gerçek bir etkinlik beklenmedik bir eşzamanlılık sıçraması yaratmadan önce altyapı darboğazlarını ortaya çıkarır.