Butler Lampson ve Xerox PARC: Ölçekli Sistemler İçin Dersler

Butler Lampson hâlâ neden ölçekli sistemler için önemli?

Butler Lampson son yarım yüzyılın en etkili bilgisayar sistem tasarımcılarından biriydi. 1970'ler ve 80'lerde Xerox PARC'ta, ağlı bilgisayarların nasıl davranması gerektiğini—izole makineler olarak değil, programların, dosyaların, yazıcıların ve insanların güvenilir şekilde etkileştiği paylaşılan bir ortamın parçaları olarak—şekillendirmeye yardımcı oldu.

Lampson’un çalışmasının olağanüstü dayanıklı olmasının nedeni temel meselelere odaklanmasıydı: ölçeklenen arayüzler, birleştirilebilen mekanizmalar ve gerçek dünya hatalarını istisna olarak değil varsayan sistemler.

“Ölçekli sistemler” gerçekte ne demek

“Ölçek” sadece devasa bir veri merkeziye sahip olmak demek değildir. Systeminizde birçok kullanıcı, birçok makine ve gerçek dünya düzensizliği olduğunda olanlardır. Düşünün: yüzlerce dizüstü ve servislerin aynı girişler ve dosyaları paylaştığı bir ofis; aynı anda binlerce müşterinin kullandığı bir ürün; ya da bir sunucu düştüğünde, ağ bağlantısı yavaşladığında veya bir güncelleme kusurlu yayıldığında bile çalışmaya devam etmesi gereken bir şirket uygulaması.

Bu noktada zor problemler değişir. Artık “Bilgisayarımda çalışıyor mu?” sorusunu sormayı bırakırsınız ve şunları sormaya başlarsınız:

• Bir parça isteğin ortasında arızalanırsa ne olur?
• İsimler ve konumlar değiştiğinde doğru hizmeti veya kaynağı nasıl bulursunuz?
• Bayat veya yanlış veri sunmadan performansı nasıl yüksek tutarsınız?

Bu makaleden ne alacaksınız

Bu, trivia ya da nostalji turu değil. Lampson’un çalışması faydalı çünkü dayanan tasarım fikirleri üretti: temiz arayüzler, basit yapı taşları ve hatayı göz önünde bulundurarak inşa edilmiş sistemler.

Ağın, RPC'nin, adlandırmanın, önbelleklemenin ve pratik güvenliğin modern işletim sistemleri ve dağıtık hesaplama üzerindeki taşıyıcı kavramlarına odaklanacağız—böylece bu desenleri bugünün mimarilerinde tanıyıp kendi servislerinize uygulayabilirsiniz.

Xerox PARC tek bir resimde: Ağlı bir işyeri

Her kişinin masasında güçlü bir kişisel bilgisayar, paylaşılan servislerle bağlı ve tüm işyerinin tek bir tutarlı sistem gibi hissettirdiği bir ofisi hayal edin. Xerox PARC'ın bahsi buydu: sadece “bir bilgisayar” değil, hesaplama, belgeler ve iletişimin insanlar ve makineler arasında kolayca aktığı ağlı bir ortam.

PARC'ın inşa etmeye çalıştığı şey

PARC, kişisel hesaplamayı günlük iş için pratik hale getirmeyi amaçladı—yazma, tasarlama, dosya paylaşma, taslak yazdırma ve işbirliği—bir ana bilgisayar operatörü veya özel ritüellere ihtiyaç duymadan. Amaç tek bir çığır açan cihaz değil; gün boyu içinde yaşayabileceğiniz bir çalışma düzeniydi.

Temel bileşenler (ve neden önemliydiler)

Alto “kişisel” parçaydı: etkileşimli çalışma için tasarlanmış bir bilgisayar. Ethernet “işyeri” parçasıydı: Altoların birbirleriyle ve paylaşılan kaynaklarla konuşmasını sağlayan hızlı bir yerel ağ.

Bu paylaşılan kaynaklar isteğe bağlı ekstra değil, temel öğelerdi:

• Paylaşılan yazıcılar yüksek kaliteli çıktıyı iş akışının normal bir adımı haline getirdi.
• Dosya sunucuları depolamayı ve paylaşımı, birinin masasının altındaki disk yığını değil bir hizmet haline getirdi.

Bu birleşim yeni bir zihniyeti teşvik etti: bilgisayarınız kendi başına güçlüdür, ama ağ servislerini güvenilir şekilde kullanabildiğinde çok daha faydalı olur.

Bir çekirdek tema: tüm sistemi kurun, sonra gerçek kullanımı izleyin

PARC prototiplerde veya izole gösterilerde takılmadı. Tam sistemler—donanım, işletim sistemleri, ağ ve uygulamalar—kurup insanların gerçekten nasıl çalıştığından öğrendiler.

Bu geri besleme döngüsü sadece pratikte ortaya çıkan zor problemlere ışık tuttu: nesneleri adlandırma, aşırı yükle başa çıkma, hatalarla uğraşma, performansı öngörülebilir tutma ve paylaşılan kaynakları “uzak” değil “yakın” hissettirme.

“PARC tarzı”

Birçok PARC sistemi tanınabilir bir yaklaşımı yansıtır: basit ilkelere güçlü mühendislik disiplini eşlik eder. Arayüzleri küçük ve anlaşılır tutun, servisleri temizce bileşenleştirin ve fikirleri gerçek dağıtımlarda test edin. Bu stil, derslerin modern takımlara aktarılmasının büyük bir sebebidir.

Alto ve İstemci/Sunucu Zihniyeti

Xerox Alto sadece “masada bir bilgisayar” değildi. Kişisel bir makine, yüksek kaliteli grafik arayüzü ve sizi paylaşılan kaynaklara bağlayan hızlı bir yerel ağı tek bir günlük deneyimde birleştirmesiyle dönüm noktasıydı.

Bu birleşim beklentileri sessizce yeniden yapılandırdı. Bilgisayarınız size aitmiş gibi hissettiriyordu—tepkisel, etkileşimli ve her zaman kullanılabilir—ama aynı zamanda paylaşılan dosya sunucuları, yazıcılar ve işbirliği araçlarına açılan bir kapı gibi hissediliyordu. Bu, istemci/sunucu zihniyetinin tohumu.

Ağı varsayan bir kişisel bilgisayar

Alto tarzı sistemlerden önce hesaplama sık sık makineye (veya bir terminale) gitmeyi gerektiriyordu. Alto bunu tersine çevirdi: “istemci” kullanıcıyla birlikte yaşadı ve ağ güçlü paylaşılan yetenekleri yakın hissettirdi.

Pratikte, “istemci/sunucu” bir diyagram değildi—bir iş akışıydı. Bazı işler anlık geri bildirim gerektirdiği için yereldeydi: metin düzenleme, çizim, pencerelerle etkileşim. Diğer işler paylaşıma doğal olduğundan veya her masada çoğaltmak pahalı olduğu için uzaktaydı: yetkili belgelerin saklanması, yazıcıların yönetimi, erişim koordinasyonu ve daha sonra paylaşılan servislerin çalıştırılması.

Bugün de yaşadığımız aynı ayrım

“Alto”yu “dizüstü” ve “dosya/yazıcı sunucusu”nu “bulut servisleri” ile değiştirirseniz, zihniyet tanıdıktır. Cihazınız hâlâ istemcidir: UI'yi render eder, verileri önbelleğe alır ve düşük gecikmeli etkileşimleri işler. Bulut hâlâ sunucu tarafıdır: paylaşılan durum, işbirliği, merkezi politika ve elastik hesaplama sağlar.

Ders şudur: iyi sistemler bu bölünmeyi kabul eder, ona karşı durmaz. Kullanıcılar yerel tepkisellik ve çevrimdışı tolerans ister; organizasyonlar ise paylaşılan gerçeği ve koordine erişimi ister.

İşletim sistemi tasarım baskısı: hızlı yerel, tutarlı küresel

Bu ayrım işletim sistemi ve sistem tasarımcıları için sürekli bir gerilim yaratır:

• Yerel tepkisellik: UI ağı bekleyemez.
• Ağ üzerinde tutarlılık: paylaşılan dosyalar, kimlikler ve izinler aynı anda birden çok istemci hareket ettiğinde öngörülebilir davranmalıdır.

PARC dönemi çalışmaları bu gerilimi erken görünür kıldı. Ağı bilgisayarın bir parçası olarak varsaydığınızda, “yerel” ile “uzak”ın bir sistem gibi hissetmesi için arayüzleri, önbellekleme ve hata davranışını tasarlamak zorunda kalırsınız—ama aynı olmadıklarını iddia etmeden.

Ethernet: Dağıtık Hesaplamanın Gizli Etkeni

Ethernet “sadece ağ” gibi göründüğü için göz ardı edilmesi kolaydır. Xerox PARC'ta, kişisel makinelerle dolu bir odanın paylaşılan bir sistem gibi davranmasını sağlayan pratik kırılmaydı.

PARC'ta Ethernet neden önemliydi

Ethernet'ten önce bilgisayarları bağlamak genellikle pahalı, özel bağlantılar gerektiriyordu. Ethernet ekonomiyi değiştirdi: birçok makinenin aynı anda bağlanabileceği nispeten ucuz, paylaşılan bir ortam.

Bu varsayılanı “bir büyük bilgisayar”dan “birbirleriyle işbirliği yapan birçok küçük bilgisayar”a kaydırdı, çünkü işbirliği artık kahramanca altyapı gerektirmiyordu.

Aynı zamanda Ethernet’in paylaşılan doğası yeni bir sistem tasarımını teşvik etti: servisler farklı makinelerde yaşayabilir, yazıcılar ve dosya sunucuları ağa eklenebilir ve ekipler bağlantı nadir olmadığından hızla yineleyebilirdi.

Modern çeviri: ağ temel bir bağımlılıktır

Bugün ağı, bir işletim sisteminin belleğe veya depolamaya davrandığı şekilde ele alıyoruz: eklenti değil, platformun bir parçası. Uygulamanızın “yerel” davranışı sık sık uzak çağrılara, uzak verilere, uzak kimliğe ve uzak yapılandırmaya bağlıdır.

Bunu kabul ettiğinizde, ağ nazikçe yolunuzdan çekilecekmiş gibi tasarlamayı bırakırsınız.

Birinci dereceden sonuç: tıkanıklık ve hatalar normaldir

Paylaşılan bir ağ rekabet anlamına gelir. Paketler gecikebilir, düşebilir veya yeniden sıralanabilir. Eşler yeniden başlatılabilir. Anahtarlar aşırı yüklenebilir. Hiçbir şey “bozulmamış” olsa bile sistem bozuk hissedebilir.

Doğru tavır, kusurlu koşullar altında normal operasyon için inşa etmektir:

• Erken ölçümleyin: loglar, temel metrikler ve istek izleme ile zamanın nereye gittiğini görün.
• Zaman aşımlarını varsayılan yapın, son dakika yaması olarak değil.
• Retry'leri dikkatle tasarlayın (backoff ve limitlerle) böylece toparlanma tıkanıklığı büyütmesin.

Ethernet dağıtık hesaplamayı mümkün kıldı; aynı zamanda dağıtık hesaplamanın gerektirdiği disiplini zorunlu kıldı.

Servisler, Monolitler Değil: Erken Dağıtık Sistem Yapı Taşları

Xerox PARC'ta bir “servis”, ağ üzerindeki başkaları için tek işi yapan bir bilgisayar programıydı.

Bir dosya servisi belgeleri sakladı ve geri döndürdü. Bir yazıcı servisi belge kabul edip kağıt çıktı üretti. Bir dizin (veya adlandırma) servisi doğru dosya sunucusunu, yazıcıyı veya kişiyi makine detaylarını ezberlemeden bulmanıza yardımcı oldu. Her servis açık bir amaca, tanımlı bir arayüze ve ona bağımlı kullanıcılara (insanlar veya diğer programlar) sahipti.

Servislere bölünmek neden yardımcı oldu

Büyük bir sistemi daha küçük servislere ayırmak değişimi daha güvenli ve hızlı yaptı. Yazdırma sistemi yeni özelliklere ihtiyaç duyduğunda dosya depolamayı yeniden tasarlamak zorunda kalmazdı. Sınırlar sorumlulukları da netleştirdi: “dosyalar buradadır” ile “yazdırma burada olur” ayrıldı.

Aynı derecede önemli olarak, servisler önce arayüz tasarlama alışkanlığını teşvik etti. Programınız başka bir makineyle konuşmak zorunda kaldığında, girişleri, çıktıları ve hataları belirtmek zorunda kalırsınız—tek parçalı monolit içinde çoğu zaman belirsiz kalan detaylar.

Takas: daha fazla çağrı, daha fazla hata nedeni

Daha fazla servis daha fazla ağ isteği demektir. Bu gecikmeyi artırabilir, yükü çoğaltabilir ve yeni hata modları yaratabilir: dosya servisi up iken yazdırma servisi down olabilir veya dizin servisi yavaşlayabilir.

Bir monolit “hepsi birden” çöker; dağıtık servisler kısmi, kafa karıştırıcı şekillerde başarısız olur. Çözüm servislerden kaçınmak değil—kısmi hatalar için açık tasarım yapmaktır.

Güncel paralel (abartısız)

Birçok bulut uygulaması artık iç servisler olarak çalışır: kullanıcı hesapları, faturalama, arama, bildirimler. PARC dersi hâlâ geçerli: açıklık ve bağımsız evrim için bölün—ancak ağ gecikmeleri ve kısmi arızalar için baştan plan yapın.

Pratik rehberlik için ekipler genellikle servis sınırlarını temel zaman aşımları, retry'ler ve net hata mesajları ile eşleştirir (bkz. /blog/failure-is-normal).

Uzaktan Prosedür Çağrısı (RPC): Ağı Yerel Hissettirmek

Remote Procedure Call (RPC) basit ama büyük kazançlı bir fikirdir: başka bir makinede bir fonksiyonu sanki yerelmiş gibi çağırmak. İsteği elle paketleyip ağı gönderip yanıtı açmak yerine, RPC bir programın “getUser(42) çalıştır” demesini sağlar ve sistem mesajlaşmayı arka planda halleder.

Bu “yerel hissettirme” hedefi Xerox PARC'ın dağıtık hesaplama çalışmalarının merkezindeydi—ve bugün ekiplerin hala istediği şey: net arayüzler, öngörülebilir davranış ve uygulama koduna daha az hareketli parça açığa çıkarmak.

İyi bir RPC için gerekenler (yanıltmaması için)

Tehlike, RPC'nin normal bir fonksiyon çağrısına fazla benzemesidir. Yerel bir çağrı ya çalışır ya da sürecinizi çökertebilir; ağ çağrısı yavaş olabilir, kaybolabilir, kısmen tamamlanabilir veya başarılı olup haber alamayabilirsiniz. İyi RPC tasarımları eksik gerçekleri gömüleştirir:

• Adlandırma / servis keşfi: çağıranın hangi makine veya servis örneğinin çağrıyı işleyeceğini güvenilir şekilde bulması gerekir. Adlandırma yoksa, RPC sadece “paket gönder ve um” olur.
• Sürümleme: istemciler ve sunucular evrilir. Bir RPC arayüzü alanları veya yöntemleri eklemeye izin vermeli ve eski istemcileri kırmama politikası olmalıdır.
• Zaman aşımı: sonsuza dek beklemek nadiren doğrudur. Zaman aşımı “bilinmeyeni” eylemlendirilebilir bir sonuca çevirir.
• Hata işleme: RPC, çağıranın neyi yeniden deneyeceğini, kullanıcıya ne göstereceğini ve neye alarm kurulacağını seçebilmesi için net bir hata modeli (iletim hataları, sunucu hataları, yetkilendirme hataları) gerekir.

Idempotentlik: istenmeyen yan etkiler olmadan güvenli retry

Zaman aşımı ve düşen yanıtlar retry'leri kaçınılmaz kılar. Bu yüzden idempotentlik önemlidir: bir işlemi bir kez veya birden fazla kez yapmak aynı etkiye sahipse idempotenttir.

Basit bir örnek: chargeCreditCard(orderId, amount) varsayılan olarak idempotent değildir—zaman aşımından sonra yeniden denemek iki kez tahsilata yol açabilir. Daha güvenli bir tasarım, chargeCreditCard(orderId) şeklinde orderIdnin tahsili benzersiz tanımlaması ve sunucunun tekrarları “zaten yapıldı” olarak işlemesiyle olur. Yani retry güvenli hale gelir çünkü sunucu çoğaltmaları ayırt edebilir.

Bunun bugünkü API'lerle bağlantısı (gRPC/REST ve benzerleri)

Modern API'ler RPC zihniyetinin doğrudan torunlarıdır. gRPC uzak yöntem çağırma modelini tipli mesajlar ve tanımlı arayüzlerle açık hale getirir. REST genellikle yöntem odaklı olmaktan ziyade kaynak odaklı görünse de amaç benzer: servislerin konuşma şeklini standardize etmek, sözleşmeleri tanımlamak ve hatayı yönetmektir.

Tarz ne olursa olsun, PARC dersi geçerlidir: ağ bir araçtır, göz ardı edilecek bir detay değil. İyi RPC dağıtımı kolaylaştırır—ücretsizmiş gibi davranmadan.

Adlandırma ve Dizinler: Şeyleri Güvenilir Bulmak

Dağıtık bir sistem sadece “dağıtık” hissedildiğinde kırılır. Çoğu gün sistem, bir şeyi bulamıyor diye bozuk hisseder.

Adlandırma zordur çünkü gerçek dünya sabit kalmaz: makineler değiştirilir, servisler yeni hostlara taşınır, ağlar yeniden numaralandırılır ve insanlar hâlâ “dosya sunucusu” veya “LaserWriter'a yazdır” gibi hatırlanabilir yollar bekler. Eğer yazdığınız isim aynı zamanda konumsa, her değişiklik kullanıcıya görünür bir kesinti olur.

İsimler vs. konumlar

PARC döneminden gelen ana fikir, istediğiniz şey ile şu anda nerede bulunduğunu ayırmaktır. Bir isim sabit ve anlamlı olmalı; bir konum ise değişebilen uygulama ayrıntısıdır.

Bu ikisi birleştiğinde kırılgan sistemler oluşur: kestirme yollar, hard-coded IP'ler ve konfigürasyon sürüklenmesi.

Dizinler yapıştırıcı gibidir

Dizin servisleri “X şimdi nerede?” sorusunu isimleri konumlara haritalayarak (ve genellikle tür, sahibi veya erişim kuralları gibi meta verileriyle) yanıtlar. En iyi dizinler sadece arama sonuçlarını saklamaz—bir organizasyonun nasıl çalıştığını kodlar.

İyi adlandırma ve dizin tasarımları genellikle şu pratik özellikleri paylaşır:

• Stabilite: isimler donanım yenilemelerini ve taşınmaları atlatır.
• Delegasyon: ekipler kendi alt ağaçlarını merkezi darboğaz olmadan yönetebilir.
• Önbellekleme: istemciler sürekli tur yapmayı önlemek için cevapları tutar.
• Güncellemeler ve tazelik: değişiklikler güvenli şekilde yayılır, önbelleklerin eski cevaplara ne kadar süre güveneceğine dair net kurallar vardır.

Modern yankı: DNS ve servis keşfi

DNS klasik örnektir: insan dostu bir isim, TTL kontrolü ile değişen IP kümesine bağlanır. Şirket içi servis keşif sistemleri (“service-a.prod”ı destekleyenler gibi) aynı deseni tekrarlar: sabit servis isimleri, değişen örnekler ve önbellek performansı ile güncelleme hızı arasında sürekli gerilim.

Ders basittir: eğer ölçeklenen ve anlaşılır kalan sistemler istiyorsanız, adlandırmayı sonradan eklenen bir detay değil, birinci sınıf tasarım problemi olarak ele alın.

Önbellekleme: Performans Kazançları ve Tutarlılık Takasları

Önbellekleme basit bir fikirdir: bir şeyi bir kez alıp yakında bir kopyasını tutarsınız ki bir sonraki istek daha hızlı olsun. Her seferinde ağı dolaşmak (veya yavaş bir diske/sunucuya gitmek) yerine yerel kopyayı yeniden kullanırsınız.

Xerox PARC'ta bu önem taşıdı çünkü ağlı iş istasyonları ve paylaşılan servisler “tekrar sunucuya sor” alışkanlığını pahalı kılıyordu. Önbellekleme uzaktaki kaynakları çoğu zaman hızlıymış gibi hissettirdi.

Temel gerilim: hız vs. tazelik

Yakalanan sorun tazelik. Bir önbellek yanlış olabilir.

Paylaşılan bir belgeyi hayal edin: çalıştığınız istasyon belgeyi açmak için önbelleğe alır. Bir meslektaşınız aynı belgeyi düzenleyip kaydederse, önbelleğiniz habersiz kalırsa eski içeriği görmeye devam edebilirsiniz—ya da daha kötüsü, bayat bir kopyayı düzenleyip yeni çalışmayı üzerine yazabilirsiniz.

Dolayısıyla her önbellekleme tasarımı bir takas:

• Performans: daha az ağ turu, daha hızlı yanıtlar
• Tutarlılık: bayat veriden ve sürpriz davranışlardan kaçınma

Yaygın teknikler (yüksek seviyede)

Ekipler genellikle bu takası birkaç geniş araçla yönetir:

• TTL'ler: önbelleğe alınan veri belirli bir sürede sona erer, yenileme zorunlu olur.
• Invalidasyonlar: veri değiştiğinde sistem önbellekleri düşürmeye veya güncellemeye çalışır.
• Kiralama (leases): bir önbelleğe, kısa süreliğine geçerli olma hakkı verilir; süresi dolduğunda yenilemek gerekir.

Bugün bunun nerede görünüyor

Modern sistemlerde aynı desen her yerde: CDN'ler web içeriğini kullanıcılara yakın önbellekler, tarayıcılar ve mobil uygulamalar varlıkları ve API yanıtlarını önbelleğe alır, ve veritabanı önbellek katmanları (Redis veya Memcached gibi) birincil depolardaki yükü azaltır.

Ders halen geçerli: önbellekleme genellikle en ucuz performans kazancıdır—ama ürününüz için “yeterince taze”nin ne olduğunu açıkça belirlemediğiniz sürece işe yaramaz.

Güvenlik ve Yetenekler: Pratik Erişim Kontrolü

Ölçekli güvenlik sadece “sen kimsin?” sorusu değildir—aynı zamanda “şimdi bu belirli kaynakla ne yapmana izin var?” sorusudur. Lampson ve Xerox PARC geleneği bunun için çok pratik bir fikri öne sürdü: capabilities (yetenekler/jetonlar).

Capabilities sade dille

Bir capability erişim veren kırılamaz bir jetondur—bir dosya, yazıcı, posta kutusu veya servis işlemi gibi bir şeye erişim hakkı verir. Jetona sahipseniz izin verilen işlemi yapabilirsiniz; yoksa yapamazsınız.

Anahtar nokta kırılamaz olmasıdır: sistem geçerli bir jetonu tahmin ederek üretmeyi hesaplama veya yapı olarak imkansız kılar.

Bunu bir otel anahtarı kartına benzetin: sadece odanızı (ve yalnızca konaklamanız boyunca) açar, el yazısıyla yazılmış “girebilirsin” notu gibi değil.

Kimlik + ACL kontrollerinden farkı

Birçok sistem kimlik tabanlı güvenliğe dayanır: kullanıcı olarak kimliğinizi doğrularsınız ve her erişim kaynak üzerindeki bir ACL (Erişim Kontrol Listesi) ile kontrol edilir—hangi kullanıcı/grup ne yapabilir listesi.

ACL'ler sezgiseldir ama dağıtık sistemlerde hantallaşabilir:

• Her servis kimliğinizi güvenilir şekilde bilmek zorundadır.
• Her kaynak izin listelerini saklamalı ve sürdürmelidir.
• Yetki devretme (“bu işin 10 dakika boyunca bir dosyayı okumasına izin ver”) genellikle özel durum mantığına dönüşür.

Capabilities varsayılanı tersine çevirir. Merkezi bir otoriteye tekrar tekrar sormak yerine, zaten hakkı kodlayan bir jeton sunarsınız.

Dağıtık sistemler neden önemser

Dağıtık sistemler işi makineler arasında sürekli geçirir: bir ön uç bir arka uca çağırır; bir zamanlayıcı bir işi bir çalışana verir; bir servis başka bir servisi tetikler. Her adımda yeteri kadar izni taşımak gerekir.

Capabilities bunu doğal hale getirir: bir istekle birlikte bir jeton geçirirsiniz ve alan makine onu doğrulayabilir—her seferinde güveni yeniden icat etmek zorunda kalmaz.

İyi yapıldığında bu kazara aşırı izin vermeyi azaltır ve bir şey ters gittiğinde zarar alanı sınırlar.

Bugün muhtemelen kullandıklarınızın benzerleri

Capabilities şu formlarda görünür:

• İmzalı jetonlar (ör. JWT'ler) belirli iddialara sahip olduğunu kanıtlar.
• Kapsamlı kimlik bilgileri (OAuth erişim tokenları, bulut “oturum tokenları”) süresi dolan ve eylemleri sınırlayan kimliklerdir.
• En az ayrıcalıklı servis kimlikleri (workload identity, servis hesapları) kimlik bilgilerini dar kapsamlı yapar.

Ders basittir: izinleri devretme, kapsam ve sona erme etrafında tasarlayın; sadece uzun ömürlü kimlikler etrafında değil.

Hata Normaldir: Kısmi Kesintilere Göre Tasarım

Dağıtık sistemler tek, temiz bir şekilde “bozulmaz.” Dağıtık, dağınık şekilde başarısız olur: bir makine işin ortasında çöker, bir anahtar yeniden başlatılır, bir ağ bağlantısı paketleri düşürür veya bir güç olayı bir rafı etkiler ama diğerlerini etkilemez.

Kullanıcı perspektifinden hizmet “ayakta”dır, ama bir kısmı erişilemez.

Açık bir hata modeli ile başlayın

Pratik bir hata modeli serttir:

• Süreçler çöker ve bellek içi durum kaybolur.
• Makineler aniden yeniden başlatılabilir.
• Ağlar bölünebilir (iki grup konuşamaz), yavaşlayabilir veya mesajları yeniden sıralayıp geciktirebilir.
• Zaman belirsizdir: bir istek yavaş olabilir, kaybolmuş olmayabilir.

Bunu kabul ettiğinizde hataları “köşe durumu” olarak değil normal kontrol akışı olarak işlemeye başlarsınız.

Klasik cevaplar: zaman aşımları, retry'ler, backoff, failover

Çoğu sistem küçük bir hareket setine dayanır.

Zaman aşımları çağıranların sonsuza dek beklemesini engeller. Anahtar, zaman aşımlarını gerçek gecikme verilerine göre seçmektir, tahmine göre değil.

Retry'ler geçici hatalardan kurtarabilir ama bir kesinti sırasında yükü de çoğaltabilir. Bu yüzden üstel backoff (her retry arasında biraz daha uzun bekleme) ve jitter (rastgelelik) önemlidir: senkronize retry fırtınalarını önler.

Failover (yedek örneğe geçiş) bir bileşen gerçekten down olduğunda yardımcı olur, ama yalnızca sistem arızayı güvenli ve hızlı şekilde algılayabiliyorsa işe yarar.

“En az bir kere” vs “tam olarak bir kere”, sade dille

Bir isteği yeniden denerseniz, onu birden fazla kez çalıştırabilirsiniz. Buna en az bir kere teslim denir: sistem işi bırakmamak için çok çabalar, ama çoğaltmalar olabilir.

Tam olarak bir kere işlemin yalnızca bir defa gerçekleştiği sözü verir. Ağ bölünmeleri gibi durumlarda bunu sağlamak zordur.

Birçok ekip bunun yerine işlemleri idempotent yapar (tekrar edilmesi güvenli), böylece en az bir kere teslim kabul edilebilir olur.

Ölçün ve hatayı test edin—varsaymayın

En güvenilir ekipler staging'de (ve bazen üretimde) hatalar enjekte eder ve ne olduğunu izler: örnekleri öldürür, ağ yollarını bloklar, bağımlılıkları yavaşlatır ve alarmları, retry'leri ve kullanıcı etkisini doğrular.

Kesintileri tasarımınızı iyileştiren deneyler olarak görün, olmaması gereken sürprizler değil.

Modern İşletim Sistemi Tasarım Dersleri: Arayüzler, İzolasyon ve Sadelik

İşletim sistemleri köpeğin yıllarında yaşar: her yeni özellik etkileşimlerin sayısını katlar ve bu da hataların saklandığı yerdir.

Lampson’ın okulu—Xerox PARC'ta şekillenen—işletim sistemi yapısını bir ölçeklendirme stratejisi olarak ele alır. Çekirdek dağınıksa, üstüne inşa edilen her şey o dağınıklığı miras alır.

Küçük ilkelere dayalı büyük sistemler

Tekrarlayan PARC dersi çekirdek (veya “güvenilen çekirdek”) dar ve basit, bileşenlendirilebilir ilkelere sahip olmalıdır. Onlarca özel durumu çekirdeğe gömmek yerine, açıklaması kolay ve yanlış kullanılması zor birkaç mekanizma tanımlayın.

Sınırlar açık olduğunda—bir bileşen ne vaat ediyor, ne varsayabiliyor—implementasyonları değiştirebilir, parçaları izole test edebilir ve istemeden bağımlılığı önleyebilirsiniz.

İzolasyon bir özellik, eklenti değil

İzolasyon zararın yayılma alanını sınırlar. Bellek koruması, süreç ayrımı veya kaynaklara en az ayrıcalıklı erişim olsun, izolasyon “her yerdeki bir hata her şeyi kırar” yerine “hata sınırlıdır” yapar.

Bu düşünce aynı zamanda capability benzeri tasarımlara yönlendirir: koda yalnızca ihtiyaç duyduğu yetkiyi verin ve erişimi zımni bırakmayın.

Performans: yaygın durumu optimize edin

Pragmatizm performansta da kendini gösterir: yaygın işlemler için hızlı yollar oluşturun ve güvenlik veya açıklık getirmeyen yüklerden kaçının.

Amaç her şeyi mikro-optimize etmek değil—sık görülen durumun hızlı hissettirilmesi, doğruluğu korurken.

Bunun modern platformlarla eşleşmesi

Aynı fikirleri bugün kernel'larda, dil çalışma zamanlarında ve konteyner platformlarında görebilirsiniz: küçük güvenilen taban, iyi tanımlanmış API'ler ve ekiplerin hızlı göndermesini sağlayıp hata modlarını paylaşmamasına izin veren izolasyon sınırları (süreçler, sandboxlar, namespace'ler).

Ayrıntılar değişti; tasarım alışkanlıkları hâlâ kazançlı.

Bugün Uygulayacaklarınız: Takımlar için Pratik Kontrol Listesi

PARC'ın büyük başarısı tek bir icat değil—insanların gerçekten kullanabileceği ağlı sistemler inşa etme konusunda tutarlı bir yoldu. İsimler değişti ama temel problemler (gecikme, hatalar, güven, sahiplik) değişmedi.

Klasikleri modern yapı taşlarına çevirin

Tasarımı gözden geçirirken yardımcı olacak kısa bir “zihin sözlüğü”:

• RPC → API'ler (REST/gRPC/GraphQL): teli saklayın, ama zaman aşımlarını, retry'leri ve idempotentliği açık tutun.
• Adlandırma & dizinler → DNS + servis keşfi: “nerede?” ilk sınıf meseptir.
• Önbellekleme → CDN'ler + yerel önbellekler + edge depolama: hız kolay; doğruluk zordur.
• Capabilities → token/anahtar/kapsamlar (OAuth kapsamları, macaroons, imzalı URL'ler): özel haklar verin, geniş erişim değil.
• Monolit değil servisler → net sözleşmeli modüler sistemler: ayrım ancak sahiplik ve arayüzler net olduğunda faydalıdır.

Pratik mimari kontrol listesi

Bir sistemi ölçek açısından değerlendirirken kullanın:

1. Servis sınırları ve sahipler kim? Bir bileşenin hesabı yoksa bozulur.
2. İstemciler servisi nasıl buluyor? Keşif, sürümleme ve rollout stratejisini erken tanımlayın.
3. Hata planı nedir? Zaman aşımları, retry'ler, devre kesiciler ve “azalmış mod”un nasıl göründüğünü karar verin.
4. Durum nerede, nasıl korunuyor? Yetkili kaynakları, replikasyon kurallarını ve yedekleme/geri yüklemeyi belirleyin.
5. Nerede önbellek var ve ne bayat olabilir? Tutarlılık beklentilerini açıkça yazın.
6. İzin modeli nedir? En az ayrıcalıklı tokenlar ve kısa ömürlü kimlik bilgilerini tercih edin.
7. Nasıl gözlemleyeceğiz? Loglar, metrikler, izler ve kullanıcı deneyimine bağlı net SLO'lar.

Temelleri atlamadan daha hızlı inşa etme notu

Modern bir büküm, ekiplerin dağıtık mimarileri ne kadar hızlı prototipleyebildiğidir. Koder.ai gibi araçlar (sohbetten kod üreten platformlar), “ilk çalışan sistem” fazını hızlandırabilir—ön yüzde React, arka uçta Go + PostgreSQL ve mobilde Flutter—ve yine de kaynak kodunu dışa aktararak ciddi üretim kod tabanına dönüştürebilirsiniz.

Yine de Lampson döneminin dersi geçerlidir: hız kazançlıdır ama arayüzleri net tutmuyorsanız, hata davranışını (zaman aşımları, retry'ler, idempotentlik) açıkça belirtmiyorsanız ve adlandırma, önbellekleme, izinleri birinci sınıf tasarım kararları olarak ele almıyorsanız, er ya da geç sorun çıkar.

Kopyalayın, uyarlayın ve kaçının

Disiplini kopyalayın: basit arayüzler, açık sözleşmeler ve kısmi arızalar için tasarım. Mekanizmaları uyarlayın: bugün yönetilen keşif, API gateway'ler ve bulut IAM kullanacaksınız—özelleştirilmiş dizinlere ve el yapımı kimlik çözümlerine gerek yok.

Kaçının: aşırı merkezileştirme (herkesin bağımlı olduğu bir “tanrı servisi”) ve belirsiz sahiplik (sahibi olmayan paylaşılan bileşenler).

Araçlar değişecek—yeni çalışma zamanları, yeni bulutlar, yeni protokoller—ama kısıtlar aynı kalır: ağlar arızalanır, gecikme vardır ve sistemler yalnızca insanlar tarafından işletilebilir hale geldiğinde ölçeklenir.