Video Streaming için Bant Genişliği Planlaması Rehberi

Video streaming’de doğru bant genişliği planı yapılmadığında iki sorun aynı anda ortaya çıkar: sayfa/oynatma gecikmesi ve maliyetin hızla artması. Bu rehberde bitrate (bit/sn), eşzamanlı kullanıcı (concurrent) ve CDN (Content Delivery Network) etkisini tek bir hesap mantığında birleştiriyoruz. Hedef, saniye saniye değil ama planlama için “net” bir ölçek ve kapasite aralığı çıkarmak; kurulumdan önce sürprizi azaltmaktır.

Aşağıdaki bölümlerde; bir kullanıcının ne kadar veri çektiğini nasıl hesaplayacağınızı, pik saatlerde kaç megabit/kaç terabayt gerektiğini nasıl çıkaracağınızı ve hangi ölçümleri hangi sıklıkla izlemeniz gerektiğini göreceksiniz.

1) Bant genişliği hesabının temelinde bitrate var

Streaming’de tüketilen veri miktarı; video çözünürlüğü ve kodeğe göre değişen bitrate ile doğrudan ilişkilidir. Basit yaklaşım şudur:

• 1 kullanıcı video izlerken ortalama tüketim: bitrate × oynatma süresi
• Bant genişliği (bit/s) ihtiyacı ise eşzamanlı kullanıcı sayısı ile ölçeklenir

Bitrate nasıl okunur?

Bitrate genellikle iki şekilde görülür:

1. Video bitrate (ör. 2.5 Mbps): Sık kullanılan teknik ifade
2. Toplam bant genişliği (ör. 3.0-4.0 Mbps): Ses + video + kapsayıcı (container) etkileriyle yükselmiş değer

Planlama için pratik kural: Elinizde bitrate değeri varsa bunun üzerine %15-25 arası tampon ekleyin. Çünkü ABR (Adaptive Bitrate) oynatmada istemci daha yüksek bir kalite seviyesine geçebilir; ayrıca segment başına istekler ve protokol overhead’i vardır.

Hesap örneği (tek kullanıcı)

Varsayım: Ortalama bitrate = 3.0 Mbps.

• 1 kullanıcı 1 saat izlerse veri tüketimi yaklaşık:
• 3.0 Mbps = 3.0/8 = 0.375 MB/s
• 0.375 MB/s × 3600 s ≈ 1350 MB ≈ 1.35 GB

Bu hesap; CDN olmadan doğrudan origin sunucudan çekiliyorsa, origin için de benzer trendi verir. CDN varsa origin yerine CDN şebekesi daha çok yük alır.

2) Eşzamanlı kullanıcıdan saniyelik bant genişliğiye geçiş

Bant genişliği planlamanın kritik noktası, “günlük izlenme” değil pik eşzamanlı izleyen sayısıdır. Çünkü bitrate saniyelik (ve parça başına) akar.

Temel formül:

• Gerekli ortalama bant genişliği (Mbps) = eşzamanlı kullanıcı × ortalama toplam bitrate (Mbps)

Aşağıdaki tabloda net bir ölçek görmeniz için örnekler verdim. Tam sayı seviyesinde plan yapmak için tamponla (örn. × 1.2) çarpma yaklaşımı kullanılır.

Ortalama toplam bitrate = 3.0 Mbps için tamponlu yaklaşım: 3.0 × 1.2 = 3.6 Mbps

“Ortalama” yetmez: neden pik değer eklemek gerekiyor?

ABR akışta bazı kullanıcılar segmentleri daha yüksek kaliteye çekebilir. Ayrıca istemciler aynı anda küçük parça istekleri yapar. Bu yüzden sistemler genellikle:

• Ortalama bant genişliği × 1.1 ila 1.3

aralığında ek kapasite ister. Büyük projelerde bu, gecikmeyi ve yeniden denemeleri azaltmak için önemlidir.

3) CDN etkisini doğru yerde hesaba katın

CDN, kullanıcının videoyu origin yerine yakındaki POP (Point of Presence) üzerinden çekmesini sağlar. Bu, iki açıdan kritik:

• Origin çıkış (egress) trafiği azalır
• Bant genişliği maliyetinin önemli kısmı CDN tarafından karşılanır

CDN kullanmıyorsanız origin sunucunuzun toplam çıkışına göre plan yaparsınız. CDN kullanıyorsanız origin planlaması için iki değer gerekir:

1. CDN’den “cache kaçıran” istekler (miss)
2. Yeni içeriklerin ilk yayılma dönemindeki trafik

CDN ile planlama için pratik hedefler

NetKıyas tarzı karşılaştırmalarda sık görülen CDN sağlayıcıları için kesin oranlar; içerik türü, coğrafya, cache TTL ve kullanıcı davranışına göre değişir. Bu yüzden planlama için şu yöntemi kullanın:

• “Sıcak içerik” oranını belirleyin: İlk saatlerde izlenen içerikler toplam izlenmenin %X’ini oluşturuyor mu?
• Ortalama cache hit oranı hedefi koyun (ör. %70-%90 bandı)

Sonra origin çıkışını yaklaşık şu şekilde tahmin edin:

• Origin’den çıkış (Mbps) ≈ Toplam bant genişliği × (1 - cache hit oranı)

Örnek: Toplam bant genişliği 900 Mbps, cache hit %80 ise:

• Origin ≈ 900 × (1 - 0.80) = 180 Mbps

Bu oran, CDN konfigürasyonu doğruysa genellikle sürdürülebilirdir.

4) Aylık veri (TB/ay) hesabı: faturalamayı netleştirin

Çoğu barındırma / bulut sağlayıcısı ücretlendirmeyi bant genişliği veya çıkış trafiğine göre kurgular. Bu nedenle sadece Mbps değil, aylık tüketim (TB/ay) hesaplamak gerekir.

Temel adımlar

1. Ortalama toplam bitrate (Mbps) seçin
2. İzleme süresi (saat) ortalamasını çıkarın
3. Aylık toplam izlenme veya eşzamanlılık üzerinden kullanıcı saatini hesaplayın

En basit yaklaşım:

• Aylık toplam tüketim (GB) ≈ Aylık toplam izleme saati × saniyelik tüketim (GB/saat)

Bitrate → GB/saat dönüştürmesi için pratik pratik değer:

• 1 Mbps ≈ 0.45 GB/saat (yaklaşık)

Dolayısıyla:

• 3.0 Mbps ≈ 1.35 GB/saat (yukarıdaki tek kullanıcı örneğiyle uyumlu)

Kullanılabilir bir senaryo tablosu

Aşağıdaki tabloda net bir planlama çerçevesi için, ortalama toplam bitrate = 3.0 Mbps ve tamponlu yaklaşım = 3.6 Mbps alınmıştır. Bu durumda tüketim yaklaşık:

• 3.6 Mbps ≈ 1.62 GB/saat

Bu hesap, faturalama için “yakın” bir öngörü verir. Gerçekte ABR kalite geçişleri, ses/bant genişliği oranları ve segment yeniden denemeleri farklılık yaratır; bu yüzden ölçümle doğrulayın.

5) Video streaming için bant genişliği planlamasında kontrol listesi

Bant genişliği hesabını tek sayıya indirgemek cazip olsa da, pratikte birkaç değişken toplam maliyeti belirler. Aşağıdaki maddeler planlama sırasında net cevap gerektirir.

5.1 Ortalama kalite mi, dağılım mı?

Tek bir bitrate ile başlamak mümkündür ama ABR dağılımı maliyeti etkiler. Şu dağılım senaryolarını planınıza dahil edin:

• Kullanıcıların %60’ı 720p (örn. 2.5 Mbps)
• Kullanıcıların %30’u 1080p (örn. 4.0 Mbps)
• Kullanıcıların %10’u 480p (örn. 1.2 Mbps)

Dağılımlı ortalama bitrate:

• Ortalama Mbps = 0.60×2.5 + 0.30×4.0 + 0.10×1.2
• Ortalama Mbps = 1.5 + 1.2 + 0.12 = 2.82 Mbps

Tampon ekleyip 3.3 Mbps civarı bir değerle plan yapılabilir. Bu yöntem “herkes 3 Mbps izliyor” varsayımından daha doğru sonuç verir.

5.2 Segmented streaming (HLS/DASH) overhead’i

HLS (HTTP Live Streaming) ve DASH, videoyu segmentlere böler. Segment başına istekler ve manifest (playlist/manifest) yenilemeleri overhead doğurur. Bunun büyüklüğü genellikle videonun toplam süresine göre sınırlıdır; ancak başlangıçta (ilk dakikalar) kullanıcı başına daha fazla manifest/segment istekleri görülür.

Pratik öneri:

• Ortalama bitrate hesaplarını yapın
• Bant genişliği için en az %15 tampon ekleyin
• İlk yayında ölçümle revize edin

5.3 Origin sunucu değil, egress hesabı önemli

Planlama yaparken “CPU/RAM” kadar şu başlık net olmalı:

• Origin’den çıkan trafik (egress)
• CDN ile origin isteklerinin azalması (cache hit)

Özellikle statik dosyalar (manifest + segment) için doğru cache başlıkları, TTL ve “range requests” davranışı maliyet farkı yaratır.

5.4 Ölçüm: hangi metrikler doğru karar verir?

Planlama tamam ama sürdürülebilir olması gerekir. Aşağıdaki metrikleri izleyin:

• Concurrent viewers (eşzamanlı izleyici): pik saatleri yakalar
• Outbound traffic (çıkış trafiği): TB/ay hedefini doğrular
• Cache hit ratio (CDN): origin yükünü açıklar
• Manifest/segment 4xx/5xx oranları: yeniden denemeleri tetikler
• Rebuffering / playback failure: bant genişliği kadar gecikme de önemlidir

Hedef: Her yeni içerik dalgasında (ör. yeni sezon) eşiklerin “kaymadan” yönetildiğini görmek.

6) Somut kapasite önerisi: Mbps ve aylık TB nasıl belirlenir?

Aşağıda iki farklı senaryo üzerinden, “hangi kapasiteyi hedefleyeyim?” sorusunu sayısal yanıtlıyorum.

Senaryo A: CDN yok (origin doğrudan çıkış yapıyor)

Varsayımlar: - Pik eşzamanlı = 250 - Tamponlu ortalama bitrate = 3.6 Mbps

Gerekli pik bant genişliği ≈ 250 × 3.6 = 900 Mbps

Maliyet riskini azaltmak için kapasiteyi bir üst seviyede düşünün: - Hedef: 1 Gbps (tepeyi karşılamak için)

Aylık veri için: - Ortalama 3.6 Mbps ile ~1.62 GB/saat - Aylık toplam izleme saati 100.000 saat ise: 162 TB/ay

Bu noktada sağlayıcınızın “TB/ay” bandına uygun planı olmalı; yoksa 1-2 içerik dalgası faturalamayı beklenmedik seviyeye taşır.

Senaryo B: CDN var (origin cache miss üzerinden çalışıyor)

Varsayımlar: - Toplam pik bant genişliği = 900 Mbps - Cache hit = %85

Origin’e kalan trafik ≈ 900 × (1 - 0.85) = 135 Mbps

Burada origin sunucu planlamasını genellikle 100-200 Mbps ölçeğinde yapmak daha gerçekçidir. Bu, işlemci kullanımını da bant genişliğine bağlayan sorunları azaltır.

Aylık origin egress ise toplam izleme üzerinden değil, cache miss oranı üzerinden tekrar tahmin edilmelidir.

Sonuç: Planı pik + tampon + ölçüm üçlüsüyle kurun

Video streaming bant genişliği planlamasında en doğru yaklaşım; pik eşzamanlı kullanıcıyı baz almak, bitrate’e %15-25 tampon eklemek ve CDN kullanıyorsanız origin yükünü cache hit üzerinden yeniden hesaplamaktır. İlk yayında tahmin ile gerçek ölçümü yan yana koyun: concurrent ve outbound trafik netleşince, TB/ay hedefinizi sabitleyip kapasiteyi “artık sürpriz üretmeyecek” seviyeye getirin.

Aksiyon önerisi: Metrik altyapısını (eşzamanlı izleyici, outbound traffic, CDN cache hit) kurun; ilk 7-14 günün verisiyle ortalama bitrate dağılımınızı çıkarın. Sonra pik bant genişliğine 1.1-1.3 çarpanı ekleyerek (tepe toleransı) sunucu/CDN ölçeğinizi kesinleştirin.