Sistem Gereksinimlerinin Yaklaşık Tahmini (Back-of-the-Envelope Estimation)
System Design Interview kitabının ikinci bölümünün türkçe çevirisidir.
Bir sistem tasarımı mülakatında (system design interview), bazen bir sistemin kapasitesini veya performans gereksinimlerini sistem gereksinimlerinin yaklaşık tahmini (back-of-the-envelope estimation) yöntemiyle tahmin etmeniz istenir.
Google Kıdemli Araştırmacısı Jeff Dean’e göre, “zarf arkası hesaplamaları; düşünce deneylerini ve yaygın performans değerlerini bir arada kullanarak, hangi tasarımların gereksinimlerinizi karşılayacağı konusunda iyi bir fikir edinmek için yaptığınız tahminlerdir.” [1]
Sistem gereksinimlerinin yaklaşık tahminini etkili bir şekilde yapabilmek için ölçeklenebilirliğin temel prensiplerine hâkim olmanız gerekir. Aşağıdaki kavramların iyi anlaşılması gerekir: İkinin kuvvetleri [2], her programcının bilmesi gereken gecikme değerleri ve kullanılabilirlik değerleri.
İkinin Kuvvetleri (Power of Two)
Dağıtık sistemlerle çalışırken veri hacmi çok büyük boyutlara ulaşabilse de yapılan hesaplamalar temelde basit prensiplere dayanır. Doğru hesaplamalar yapabilmek için 2’nin kuvvetlerini kullanarak veri hacmi birimlerini bilmek kritik öneme sahiptir. Bir byte, 8 bitten oluşan bir dizidir. Bir ASCII karakteri 1 byte (8 bit) bellek kullanır. Aşağıda veri hacmi birimlerini açıklayan bir tablo yer almaktadır (Tablo 2–1).
Her Programcının Bilmesi Gereken Gecikme Değerleri (Latency numbers every programmer should know)
Google’dan Dr. Dean, 2010 yılında tipik bilgisayar işlemlerinin ne kadar sürdüğünü ortaya koymuştur [1]. Bilgisayarlar daha hızlı ve güçlü hâle geldikçe bazı değerler güncelliğini yitirmiştir. Bununla birlikte, bu değerler farklı bilgisayar işlemlerinin ne kadar hızlı veya yavaş olduğu konusunda hâlâ bize bir fikir verebilir.
Notes
— — — — — —
ns = nanosecond, µs = microsecond, ms = millisecond
1 ns = 10^-9 seconds
1 µs= 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 µs = 1,000,000 ns
Google’da çalışan bir yazılım mühendisi, Dr. Dean’in sayılarını görselleştirmek için bir araç geliştirmiştir. Bu araç aynı zamanda zaman faktörünü de hesaba katmaktadır. Şekil 2–1, 2020 yılı itibarıyla görselleştirilmiş gecikme değerlerini göstermektedir (şekillerin kaynağı: kaynakça [3]).
Şekil 2–1'deki sayıları analiz ederek aşağıdaki sonuçlara ulaşabiliriz:
• Bellek hızlıdır ancak disk yavaştır.
• Mümkünse disk aramalarından kaçının.
• Basit sıkıştırma algoritmaları hızlıdır.
• Mümkünse internet üzerinden göndermeden önce verileri sıkıştırın.
• Veri merkezleri genellikle farklı bölgelerde bulunur ve aralarında veri göndermek zaman alır.
Kullanılabilirlik Değerleri (Availability numbers)
Get Zeynal Abidin Ünlü’s stories in your inbox
Join Medium for free to get updates from this writer.
Yüksek kullanılabilirlik, bir sistemin istenen uzun bir süre boyunca kesintisiz olarak çalışabilme yeteneğidir. Yüksek kullanılabilirlik yüzde olarak ölçülür; %100, hiç kesinti yaşanmayan bir hizmet anlamına gelir. Çoğu hizmet %99 ile %100 arasında bir değere sahiptir.
Hizmet düzeyi anlaşması (Service Level Agreement — SLA), hizmet sağlayıcılar tarafından yaygın olarak kullanılan bir terimdir. Bu, sizin (hizmet sağlayıcı) ile müşteriniz arasında yapılan bir anlaşmadır ve bu anlaşma, hizmetinizin sağlayacağı çalışır durumda olma süresini (uptime) resmi olarak tanımlar. Bulut sağlayıcıları Amazon [4], Google [5] ve Microsoft [6], SLA’larını %99,9 veya daha yüksek olarak belirlemektedir. Çalışır durumda olma süresi (uptime) geleneksel olarak dokuzlar (nines) üzerinden ölçülür. Dokuzların sayısı arttıkça, hizmetin kullanılabilirliği de artar. Tablo 2–3'te gösterildiği gibi, dokuzların sayısı beklenen sistem kesinti süresiyle ilişkilidir.
Örnek: Twitter’ın QPS ve depolama gereksinimlerini tahmin edin (Estimate Twitter QPS and storage requirements)
Lütfen aşağıdaki sayıların yalnızca bu çalışma için kullanıldığını ve Twitter’a ait gerçek sayılar olmadığını unutmayın.
Varsayımlar:
• Aylık 300 milyon aktif kullanıcı (monthly active users).
• Kullanıcıların %50'si Twitter’ı her gün kullanıyor.
• Kullanıcılar günde ortalama 2 tweet paylaşıyor.
• Tweetlerin %10'u medya içeriği içeriyor.
• Veriler 5 yıl boyunca saklanıyor.
Tahminler:
Saniye başına sorgu (Query per second — QPS) tahmini:
• Günlük aktif kullanıcı sayısı (DAU) = 300 milyon * %50 = 150 milyon
• Tweet QPS = 150 milyon * 2 tweet / 24 saat / 3600 saniye = ~3500
• Yoğun saat QPS’i (Peak QPS) = 2 * QPS = ~7000
Burada yalnızca medya depolama alanını tahmin edeceğiz.
• Ortalama tweet boyutu:
• tweet_id: 64 byte
• metin: 140 byte
• medya: 1 MB
• Medya depolama alanı: 150 milyon * 2 * %10 * 1 MB = 30 TB/gün
• 5 yıllık medya depolama alanı: 30 TB * 365 * 5 = ~55 PB
İpuçları (Tips)
Sistem gereksinimlerinin yaklaşık tahmini tamamen süreçle ilgilidir. Problemi çözme süreci, sonuçları elde etmekten daha önemlidir. Görüşmeyi yapan kişiler, problem çözme becerilerinizi test edebilir. Aşağıda takip edebileceğiniz birkaç ipucu yer almaktadır:
- Yuvarlama ve Yaklaşık Hesaplama. Mülakat sırasında karmaşık matematiksel işlemleri yapmak zordur. Örneğin, “99987 / 9.1” işleminin sonucu nedir? Karmaşık matematik problemlerini çözmek için değerli zamanınızı harcamanıza gerek yoktur. Kesinlik beklenmez. Yuvarlanmış sayıları ve yaklaşık hesaplamaları kendi avantajınıza kullanın. Bölme işlemi şu şekilde basitleştirilebilir: “100.000 / 10”.
- Varsayımlarınızı yazın. Daha sonra tekrar bakmak için varsayımlarınızı yazılı olarak belirtmek iyi bir fikirdir.
- Birimlerinizi belirtin. “5” yazdığınızda, bu 5 KB mi yoksa 5 MB mi demektir? Bu durum kafanızı karıştırabilir. Belirsizliği ortadan kaldırmaya yardımcı olması için birimleri mutlaka yazın; örneğin “5 MB” ifadesi belirsizliği ortadan kaldırır.
- Sık sorulan sistem gereksinimlerinin yaklaşık tahminleri: QPS, yoğun saat QPS’i (peak QPS), depolama alanı, önbellek (cache), sunucu sayısı vb. Bir mülakata hazırlanırken bu hesaplamaları yaparak pratik yapabilirsiniz. Pratik yapmak mükemmelleştirir.
Buraya kadar geldiğiniz için tebrikler! Şimdi kendinizi bir kez olsun takdir edin. Harika iş çıkardınız!
Kaynakça
[1] J. Dean.Google Pro Tip: Use Back-Of-The-Envelope-Calculations To Choose The Best Design:
http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelopecalculations-to-choo.html
[2] System design primer: https://github.com/donnemartin/system-design-primer
[3] Latency Numbers Every Programmer Should Know: https://colin-scott.github.io/personal_website/research/interactive_latency.html
[4] Amazon Compute Service Level Agreement: https://aws.amazon.com/compute/sla/
[5] Compute Engine Service Level Agreement (SLA): https://cloud.google.com/compute/sla
[6] SLA summary for Azure services: https://azure.microsoft.com/enus/support/legal/sla/summary/
