Bir programcı olarak en keyifli şeylerden biri, hakkında az bilgi sahibi olduğum sistemlere daha derinlemesine baktıkça, yüzeyde basit görünen bir sistemin aslında ne kadar karmaşık ve detaylı olduğunu görmek. Gerçeklik, şaşırtıcı miktarda ayrıntı barındırır. Bu yazıda, son birkaç gündür üzerinde düşündüğüm iş kuyruklarından bahsedeceğim. İş kuyruğu derken, toplu işleri gönderme, planlama ve çalıştırma kavramlarını içeren bir sistemi kastediyorum. Genellikle FIFO veya FIFO benzeri bir davranış beklenir, ancak bu zorunlu değildir. Çoğu zaman kuyruk, periyodik görev planlama için yerel bir yöntemle birlikte gelir; bu da gönderimlerin JSON veya YAML gibi yapılandırma dosyalarıyla belirtilmesine olanak tanır.
İş kuyrukları, yüksek verim ancak düşük gecikme gerektiren durumlarda doğal olarak ortaya çıkar. Sürekli entegrasyon (CI) bunun yaygın bir örneğidir. Bir diğeri ise veri analizi amacıyla oluşturulan özetlerdir. Son bir iki yıldır, sistem tasarımı hakkında düşünürken faydalı bulduğum birkaç mercek var: Kuyruklara karşı dikkatli olmak: Kuyruklar genellikle ya neredeyse dolu ya da neredeyse boş olma eğilimindedir, bu da uygun boyutlandırma konusunda düşünmeyi gerektirir. Marc Brooker'ın blogundan kuyrukların gecikme konusundaki sezgisel olmayan davranışlarını da öğrendim. Kuyruklarla ilgili okuduğum blog yazılarında odak genellikle gecikme üzerinedir, verim üzerine değil; bu da neden daha önce 'kuyruklar' ve 'iş kuyrukları'nı zihinsel olarak ilişkilendirmediğimi açıklıyor.
Limitler: Bu, TigerBeetle ekibi tarafından yazılan Tiger Style kılavuzuna dayanır ve çeşitli şeylerde açık limitlerden bahseder. Genelleme yapıldığında, bu tolerans kavramına ve modüler akıl yürütme için bütçelere sahip olmaya yol açar. İlginçtir ki, kariyerimin başlarında Apple'da, ekiplerin özellikle düşük seviyeli kod için ne kadar bellek bütçesi alacaklarını pazarlık ettikleri tartışmalara hafifçe şaşırdığımı hatırlıyorum. Zamanla bu yaklaşıma daha fazla saygı duymaya başladım.
Hata modelleri: Kabaca söylemek gerekirse, bir hata modeli, bağımlılıklarınızdaki hatalar ve güvenilirlikle ilgili varsayımlarınızı tanımlar. Bu konuyu TigerBeetle CEO'su Joran Dirk Greef'in konuşmalarından ve tweetlerinden ve Alex Miller'ın yazılarından öğrendim. Bu yazının ilerleyen kısımlarında bu merceklerin sistem tasarımına nasıl uygulanabileceğini göstermeye çalışacağım.
Detaylar ve Etkileri
Ele alacağımız problem: İş yerimizde, 'referans repo'ları paketlemek için bir arka plan işimiz var. Referans repo, agresif bir şekilde yeniden paketlenmiş bir git deposudur. Bu depolar nesne depolamada saklanır ve yeni bir repo, referans repoyu indirip varsayılan dalın ucundaki değişikliklerin delta'sını getirerek bir makinede kurulabilir. Çok büyük repolar için bu yaklaşım, tipik git clone işlemine kıyasla indirme gecikmesini azaltmaya yardımcı olur. Git'in agresif yeniden paketleme detayları bu yazı için çok önemli değil. Önemli olan, kabaca iki tür yeniden paketleme olduğudur: Toptan yeniden paketleme: Git, paketlemenin nasıl yapılması gerektiğine dair temel bilgileri yok sayar ve her şeyi sıfırdan yeniden hesaplar. Test altındaki repo için bu 7 saat sürer. Artımlı yeniden paketleme: Git, repoda zaten depolanmış temel bilgileri yeniden kullanır, yani yalnızca değişen şeyleri yeniden paketler. Bu da 2 saat sürer.
Bu durumda, daha pahalı olan seçenek (7 saat) daha küçük bir referans repo sağlar; bu da daha hızlı indirme, daha hızlı açma ve daha düşük disk kullanımı anlamına gelir. Toptan paketlenmiş bir repo, artımlı paketlenmiş bir repodan %50-60 daha küçük olabilir. Daha ucuz seçenek (2 saat) ise daha güncel referans repolar sağlar; bu da indirgeyicinin en son değişiklikleri almak için getireceği delta'nın daha küçük olması ve dolayısıyla daha hızlı olması ve sunucuya daha az yük bindirmesi anlamına gelir. Ancak ek disk kullanımı yüzlerce megabayt veya gigabayt seviyesindeyse bu iyi değildir. Ayrıca, bu bir kod deposu olduğu için, alt tüketiciler hafta içi hafta sonuna göre çok daha aktiftir.
Her iki dünyanın en iyisi mi? Yukarıdaki ikilemi gördükten sonra akla gelen doğal bir adım şudur: Neden hafta sonları toptan yeniden paketleme, hafta içi ise artımlı yeniden paketleme yapılmasın? Bu, hafta içi (daha fazla tüketicinin aktif olduğu) güncellik sağlarken, hafta sonu toptan yeniden paketleme referans repo boyutunun daha yavaş büyümesini garanti eder. Basitlik adına, referans repoları
Kaynak: typesanitizer.com
