Back of the Envelope Estimation
Bir projeye başlayacağınızı hayal edin. Projenin amacı hızlı bir şekilde yüksek trafikli bir web uygulaması tasarlamak olsun. Bir mühendis olarak hızlıca tahminlemeler yapmamız gerekmektedir. Ne kadar yük altında çalışacak bir uygulama olacak, kaç saat hizmet verecek, kaç farklı kullanıcı tarafından kullanılacak vb. sorular gibi soruları sorarak ve cevaplandırarak hızlı tahminlemeler yapmamız gerekmektedir. İşte tam bu noktada Back of the Envelope (BOE), mühendislerin işini kolaylaştıran bir kılavuz olmuştur.
BOE Nedir?
“Back of the Envelope Estimation” aslında adını çok basit bir yerden alır: Bir mühendis, genellikle cebinden çıkardığı bir kağıdın arkasına, sistemin karmaşıklığını hızlıca tahmin etmek için bazı hesaplamalar yapar. Bu hesaplamalar, genellikle birkaç dakikalık bir işlemle yapılır ve detaylı bir mühendislik analizi kadar kesin olmasa da, proje için önemli bir rehberlik sağlar.
BOE, sistem tasarımının ilk aşamalarında, özellikle kritik kararlara varmadan önce doğru yönde ilerlemenin temelidir. Bir mühendis, BOE kullanarak en baştan doğru bir temel atabilir ve bu temele dayalı olarak daha karmaşık hesaplamalara geçebilir. Hızla yapılan tahminler, doğru çözüm yolları seçmeye yardımcı olabilir.
BOE Temelleri
BOE’nin özü, yüksek seviyeli hesaplamalarla başlamak ve ardından tahminleri daha detaylı hale getirmektir. Bu yaklaşım, yazılım mühendisliğinde ve özellikle sistem tasarımında kullanılan en yaygın yöntemlerden birisidir. Örneğin, bir web uygulamasının trafiği, veri tabanı boyutu veya depolama gereksinimleri hakkında tahminler yaparken, ilk adımda çok karmaşık modellere girmeyiz. Bunun yerine, temel seviyede bazı kabuller yaparak basit hesaplamalar yaparız.
Farz edelim ki, bir e-ticaret uygulaması tasarlıyoruz. Günlük 1 milyon aktif kullanıcı hedefliyoruz. Bu durumda, kullanıcı başına kaç istek yapılır? ve veri tabanında ne kadar alan gerekecek? gibi soruları kısa bir süre içinde tahmin etmemiz gerekebilir. BOE kullanarak, kullanıcı başına ortalama 5 istek yapıldığını varsayarak, bu bilgiyi hızla çarpıp ihtiyacımız olan sistem kapasitesini tahmin edebiliriz.
Tabii ki, bu tahminler %100 doğruluk taşımaz. Ama en azından projeye başlarken ne kadar kaynağa ihtiyacımız olduğunu anlamamıza yardımcı olur.
İkinin Gücü (Power of two)
BOE kavramında hesaplama tamamen temellere dayanır. Doğru hesaplamalar elde etmek için, 2'nin kuvvetini kullanarak veri birimini bilmek kritik öneme sahiptir. Bir bayt, 8 bitlik bir dizidir. Bir ASCII karakteri bir bayt bellek kullanır. (8 bit)
Yapılan her işlemin bir maliyeti vardır. Bilgisayarlar daha hızlı ve daha güçlü hale geldikçe bazı sayılar güncelliğini kaybeder. Ancak bu veriler yine de bize işlemlerin hızı ve yavaşlığı hakkında fikir vermektedir.
High availability(Yüksek kullanılabilirlik), bir sistemin istenen uzunlukta bir süre boyunca sürekli olarak çalışır durumda olma yeteniğini gösterir. High availability, yüzde olarak ölçülür. Günümüzde çoğu servisin %99 ile %100 arasında olduğunu biliyoruz. Bu oranlar oldukça yüksek olsa bile gün, hafta, ay ve yıl bazında ne kadar kesintiye uğradıklarına bir bakalım.🧐
%99 oranında hizmet verdiğiniz bir senaryoda günde 14 dakika, haftada 1 saat ayda 7 saat ve yılda 3 gün gibi bir sürede hizmet veremediğiniz anlamına gelir.
BOE’nin Uygulama Alanları
BOE, sistem tasarımında farklı alanlarda yaygın olarak kullanılır.
- Veritabanı Tasarımı:
Bir veritabanı tasarımında BOE kullanarak, veritabanı boyutlarını ve sorgu performansını tahmin edebiliriz. Örneğin 1 milyon aktif kullanıcı ve her kullanıcı için günlük 100 kayıt olacağını varsayarsak, toplamda 100 milyon kayıt olacağı tahmin edilebilir. Bu tür tahminler, veri tabanı kapasitesinin planlanmasında önemli bir rol oynar. - Yük ve Trafik:
Bir web uygulamasının trafik yükünü tahmin etmek, BOE’nin bir başka kullanım alanıdır. Milyonlar kullanıcıyı barındıracak bir sistemde, trafiğin nasıl dağılacağını ve hangi noktaların tıkanabileceğini tahmin etmek kritik bir adımdır. Örneğin, her kullanıcı saatte 5 istek gönderirse, günde 5 milyon istek alınacağı tahmin edilebilir.
Kullanılacak Metodolojiler ve Teknikler:
BOE’nin doğru uygulanabilmesi için bazı metodolojiler ve teknikler vardır. Bunlar, tahminlerin doğruluğunu artırmak için kullanılır:
Top-Down ve Bottom-Up Yaklaşımları:
- Top-Down: Sistemi genel hatlarıyla inceleyerek, büyük resme odaklanırız. Örneğin, tüm kullanıcı trafiğini tahmin ettikten sonra, her bir bileşenin (veritabanı, API, sunucular) gereksinimlerini hesaplarız.
- Bottom-Up: Küçük bileşenlerden başlayarak, sistemin her parçasını tahmin ederiz. Bu yaklaşım daha ayrıntılıdır ve daha hassas tahminler yapmamızı sağlar.
Ortalama ve En Kötü Durum Tahminleri:
BOE’nin temel bir yöntemi de olasılıkların göz önünde bulundurulmasıdır. Sistem tasarımı yaparken, en iyi durum senaryosu ve en kötü durum senaryosu ile tahminler yapabiliriz. Bu yaklaşım, sistemin olası tüm yük durumlarını dikkate alarak daha güvenli tahminler yapılmasını sağlar.
Varsayımlar ve İstatistikler:
BOE, büyük oranda tahminler ve istatistiklere dayanır. Kullanıcı başına işlem sayısı, veri büyüklüğü ve diğer faktörler hakkında bazı varsayımlar yapılır. Bu varsayımlar, genellikle geçmiş verilere dayanarak oluşturulur ve sistemin işleyişine dair güvenli tahminler yapmamıza olanak tanır.
BOE’nin Sınırlamaları ve Zorlukları:
Her ne kadar BOE hızlı ve kullanışlı bir yöntem olsa da, bazı sınırlamaları vardır. Tahminler çoğu zaman gerçek değerlerden farklı olabilir. Ayrıca, çok karmaşık sistemlerde kullanılan basit hesaplamalar, büyük hatalara yol açabilir. Bu nedenle, BOE’yi sadece ilk aşama için kullanmak ve daha sonra detaylı analizlere geçmek daha doğru olacaktır.
Back of the Envelope Estimation için İpuçları
- Sayıların yuvarlanması ve yaklaşık olarak hesaplanması Örneğin 92 olarak bulduğunuz sayıyı 100 olarak alabilirsiniz.
- Hesaplamanın anlaşılır olması için sonuçları etiklemek ve birimleri muhakkak kullanmak oldukça faydalı olacaktır.
- Tüm işlemleri saniye başına işlem formatına dönüştürün. operation/second. Örneğin günde 1 milyon istek = saniyede 12 istek
- BOE yaparken muhakkak varsayımlarda bulunacaksınız. Bu varsayımları not alın.
Back of the Envelope Estimation için Hesaplama Türleri
En yaygın hesaplama türleri şunlardır:
- traffic estimation
- storage estimation
- memory estimation
- bandwidth estimation
- resource estimation
- latency estimation
Derinlemesine Örnek URL Shortener
URL kısaltma servisleri, uzun URL’leri kısa ve yönetilebilir hale getirerek kullanıcıların kolayca paylaşmasını sağlar. Örneğin, bit.ly, t.co (Twitter), goo.gl (eski Google URL Shortener) gibi servisler bu mantıkla çalışır.
Bu sistemin temel amacı:
- Uzun URL’leri alıp benzersiz bir kısa URL ile eşleştirmek,
- Kullanıcılar kısa URL’ye tıkladığında, onları orijinal uzun URL’ye yönlendirmek.
Bu sistem için Trafik, Depolama (Storage), Bant Genişliği (Bandwidth) ve Bellek (Memory) ihtiyaçlarını tahmin edelim.
Trafik Hesaplaması (RPM & RPS)
Öncelikle bir URL shortener sisteminin ne kadar trafik aldığını tahmin edelim.
Veri varsayımlarımız:
- Günlük aktif kullanıcı sayısı: 100 milyon
- Her kullanıcı günde ortalama 5 URL kısaltıyor.
- Her kısa URL, günde ortalama 20 kez tıklanıyor.
- İsteklerin %1'i yeni URL oluşturma, %99'u yönlendirme isteği.
İstek türleri:
- Yeni URL oluşturma (1%) (write)
- URL yönlendirme (99%) (read)
URL Kısaltma Trafiği (Yeni Kayıt)
- Günlük URL oluşturma:
100M×5=500M URL record/day
- Dakika başına istek (RPM):
500M1440≈347,000 RPM
- Saniye başına istek (RPS):
500M86400≈5,800 RPS
Yönlendirme Trafiği
- Günlük yönlendirme istekleri:
500M×20=10B redirect/day
- Dakika başına istek (RPM):
10B/1440≈6.94M RPM
- Saniye başına istek (RPS):
10B/86400≈115,740 RPS
Depolama İhtiyacı (Storage Estimation)
URL kısaltıcı sistemler her kısa URL için bir kayıt tutar.
Bir URL kaydının tipik bileşenleri:
- ID (Short URL Key) → 8 karakter (Base62–6 byte)
- Long URL (Orijinal URL) → 100 byte (ortalama)
- Metadata (tıklama sayısı vb.) → 50 byte
Toplam bir kaydın boyutu:
6+100+50=156 byte
Günlük Depolama İhtiyacı
- Günlük yeni URL sayısı: 500M
- Günlük veri artışı:500M×156=78GB
Yıllık Depolama İhtiyacı
- 1 yılda üretilen URL sayısı:500M×365=182.5B kayıt
- 1 yıllık depolama ihtiyacı:182.5B×156=28.5TB
- 5 yıllık depolama ihtiyacı:28.5TB×5=142.5TB
Bant Genişliği (Bandwidth Estimation)
Her bir yönlendirme, short URL sorgusu yapıp orijinal URL’yi döndürür.
Ortalama HTTP response boyutu:
- Short URL için gelen GET isteği: 500 byte
- Geri dönen uzun URL cevabı: 1 KB
- Toplam veri transferi: 1.5 KB
Günlük Veri Transferi
- Günlük yönlendirme isteği: 10B
- Günlük veri transferi:10B×1.5KB=15PB (Petabyte)
Bant Genişliği Hesaplaması (Saniye Başına)
- Saniye başına yönlendirme isteği: 115,740 RPS
- Saniye başına veri transferi:115,740×1.5KB=173MB/s
Bellek İhtiyacı (Memory Estimation)
Bellekte cache kullanarak sık erişilen kısa URL’leri RAM’de tutabiliriz. URL yönlendirme taleplerinin %20'sinin en popüler %1'lik URL’lere gittiğini varsayalım.
En sık kullanılan kısa URL’lerin sayısı:
- %1'lik popüler URL’ler:10B×1%=100M (en çok kullanılan URL)
Her cache kaydı bellek boyutu:
- Short URL Key: 6 byte
- Long URL: 100 byte
- Metadata: 50 byte
- Toplam: 156 byte
Günlük Cache İhtiyacı
- Popüler URL sayısı: 100M
- Toplam RAM ihtiyacı:100M×156=15.6GB
Sonuç olarak, büyük ölçekli bir URL shortener servisi tasarlarken, yüksek trafik yükünü yönetmek, verimli bir depolama stratejisi belirlemek, bant genişliği tüketimini optimize etmek ve bellek kullanımını dengelemek kritik öneme sahiptir. 121,540 RPS gibi bir trafikle başa çıkmak için cache mekanizmaları, CDN kullanımı ve dağıtık veri tabanı çözümleri kaçınılmazdır. Ayrıca, sharding, partitioning ve replication gibi tekniklerle sistemin ölçeklenebilirliği sağlanmalıdır. Gerçek dünya sistem tasarımı, yalnızca teorik hesaplamalarla değil, sürekli test edilen, optimize edilen ve gerçek kullanım senaryolarına uyum sağlayan bir mimariyle başarılı olur. Bu analiz yöntemini, hem System Design mülakatlarında nasıl düşünmeniz gerektiğine dair güçlü bir temel sunarken, aynı zamanda karşılaştığınız problemlere ürettiğiniz çözümleri daha sağlamlaştıran pratikler sunmaktadır.
Umarım faydalı olur.
