Joe Armstrong’ın Erlang yaklaşımının eşzamanlılık, supervision ve “let it crash” zihniyetiyle nasıl güvenilir platformlar sağladığını keşfedin—gerçek zamanlı hizmetlerde bugün de kullanılan fikirler.
Joe Armstrong sadece Erlang’in yaratılmasına yardımcı olmadı—onun en açık, en ikna edici anlatıcısı oldu. Konuşmaları, makaleleri ve pragmatik bakış açısıyla basit bir fikri popüler hale getirdi: yazılımın ayakta kalmasını istiyorsanız, hataları önlemek yerine hata için tasarlarsınız.
Bu yazı, Erlang zihniyetinin bir rehber turu ve neden hâlâ güvenilir gerçek zamanlı platformlar (sohbet sistemleri, çağrı yönlendirme, canlı bildirimler, çok oyunculu koordinasyon ve parçaları bozulsa bile hızlı ve tutarlı yanıt vermesi gereken altyapı gibi) inşa ederken önemli olduğu üzerine odaklanacak.
Gerçek zamanlı her zaman “mikrosaniyeler” veya “kesin zaman sınırları” demek değildir. Birçok üründe şu anlama gelir:
Erlang, bu beklentelerin tartışılmadığı telekom sistemleri için inşa edildi—ve bu baskı en etkili fikirlerini şekillendirdi.
Sözdizimine dalmak yerine, Erlang’i ünlü yapan ve modern sistem tasarımında tekrar eden kavramlara odaklanacağız:
Yol boyunca bu fikirleri aktör modeli ve mesajlaşma ile ilişkilendireceğiz, supervision ağaçlarını ve OTP’yi anlaşılır terimlerle açıklayacağız ve BEAM VM’in bütün yaklaşımı pratik hale getirdiğini göstereceğiz.
Erlang kullanmasanız bile (ve asla kullanmayacaksanız bile), Armstrong’un çerçevesi, gerçek dünya karıştığında bile yanıt veren ve erişilebilir kalan sistemler kurmak için güçlü bir kontrol listesi sunar.
Telekom anahtarları ve çağrı yönlendirme platformları, birçok web sitesinin “bakım için kapatma” yapabildiği şekilde kapatılamaz. Çağrıları, faturalama olaylarını ve sinyal trafiğini 7/24 işlemeye devam etmeleri beklenir—çoğu zaman erişilebilirlik ve öngörülebilir yanıt süreleri için sıkı gereksinimlerle.
Erlang, 1980’lerin sonlarında Ericsson içinde bu gerçeklikleri sadece özel donanımla değil, yazılımla karşılamak amacıyla başladı. Joe Armstrong ve meslektaşları zerafeti kendi başına aramıyorlardı; sürekli yük, kısmi arızalar ve gerçek dünya koşullarında operatörlerin güvenebileceği sistemler inşa etmeye çalışıyorlardı.
Düşüncedeki ana kayma, güvenilirliğin “asla başarısız olmamak” anlamına gelmediğidir. Büyük, uzun çalışan sistemlerde bir şeyler başarısız olur: bir süreç beklenmedik girişle karşılaşır, bir düğüm yeniden başlatılır, bir ağ bağlantısı kesilip geri gelir veya bir bağımlılık takılır.
Bu yüzden hedef şöyle olur:
Bu zihniyet, supervision ağaçları ve “bırak çöksün” fikirlerini makul kılar: arıza normal bir olay olarak tasarlanır, istisnai bir felaket olarak değil.
Hikâyeyi tek bir vizyonerin atılımı olarak anlatmak cazip gelebilir. Daha kullanışlı olan görüş daha basittir: telekom kısıtları farklı bir takas setini zorunlu kıldı. Erlang, hizmetleri çalışır tutmak için pratik araçlar olan eşzamanlılık, izolasyon ve kurtarmayı önceliklendirdi.
Bu problem-odaklı çerçeve, Erlang derslerinin bugün de iyi aktarılıyor olmasının nedenidir—her yerde çalışma süresi ve hızlı kurtarma, mükemmel önleme önünde daha önemli olduğunda işe yarar.
Erlang’de temel fikir, “aynı anda birçok şey yapmak”ın sonradan eklenen özel bir özellik değil—sistemi yapılandırmanın normal yolu olduğudur.
Erlang’de işler birçok küçük “süreç”e bölünür. Bunları bir işi yapan küçük işçiler olarak düşünün: bir telefon çağrısını yönetmek, bir sohbet oturumunu takip etmek, bir cihazı izlemek, bir ödemeyi yeniden denemek veya bir kuyruğu izlemek.
Bunlar hafiftir; yani büyük donanım gerektirmeden çok sayıda süreç çalıştırabilirsiniz. Bir tane ağır işçinin her şeyi idare etmeye çalışması yerine, hızlı başlayıp durabilen ve kolayca değiştirilebilen odaklanmış bir işçi kalabalığı elde edersiniz.
Birçok sistem tek bir büyük program gibi tasarlanır; parçalar sıkı bağlıdır. Böyle bir sistem ciddi bir hatayla, bellek sorunuyla veya engellenen bir işlemle karşılaştığında, başarısızlık dışarıya yayılabilir—bir sigortayı atlatıp tüm binayı karartmaya benzer.
Erlang tersini zorlar: sorumlulukları izole edin. Bir küçük işçi yanlış davranırsa, alakasız işleri kapatmadan o işçiyi düşürüp yerine yenisini koyabilirsiniz.
Bu işçiler nasıl koordine olur? Birbirlerinin iç durumuna karışmazlar. Mesaj gönderirler—dağınık bir beyaz tahtayı paylaşmaktan çok, not gönderme gibidir.
Bir işçi, “Yeni bir istek var,” “Bu kullanıcı bağlantısını kesti,” veya “5 saniye sonra tekrar dene” diyebilir. Alan işçi notu okur ve ne yapacağına karar verir.
Temel fayda, kapsama: işçiler izole ve mesajlaştıkları için arızalar tüm sisteme yayılma olasılığı daha düşüktür.
Erlang’in “aktör modeli”ni anlamanın basit yolu, sistemi birçok küçük, bağımsız işçiden oluşan bir yapı olarak hayal etmektir.
Bir aktör, kendi özel durumu ve bir posta kutusuyla birlikte öz‑içerikli bir birimdir. Üç temel işlem yapar:
Hepsi bu. Gizli paylaşılan değişken yok; bir aktör diğerinin belleğine erişemez. Bir aktörün bir başkasından bir şeye ihtiyacı varsa, mesaj gönderir ve sorar.
Birden çok iş parçacığı aynı veriyi paylaştığında yarış koşulları ortaya çıkabilir: iki şey neredeyse aynı anda aynı değeri değiştirir ve sonuç zamana bağlı olur. Bu tür hatalar aralıklı olur ve yeniden üretmesi zordur.
Mesajlaşma ile her aktör kendi verisinin sahibidir. Diğerleri doğrudan değiştiremez. Bu, eşzamanlı erişimden kaynaklanan sorunları büyük ölçüde azaltır.
Mesajlar “bedava gelmez.” Bir aktör, mesajları işleyebileceğinden daha hızlı mesaj alıyorsa posta kutusu büyür. Bu back-pressure’dır: sistem dolaylı olarak size “bu kısım aşırı yüklü” diyor.
Pratikte, posta kutusu boyutlarını izlersiniz ve yükü azaltma, toplama, örnekleme veya işleri daha fazla işçiye yönlendirme gibi sınırlar kurarsınız; kuyrukların sonsuza dek büyümesine izin vermezsiniz.
Bir sohbet uygulamasını hayal edin. Her kullanıcı, bildirimleri iletmekten sorumlu bir aktöre sahip olabilir. Bir kullanıcı çevrimdışı olduğunda mesajlar gelmeye devam eder—böylece posta kutusu büyür. İyi tasarlanmış bir sistem kuyruk sınırı koyabilir, kritik olmayan bildirimleri düşürebilir veya sindirim moduna geçebilir; tek yavaş kullanıcı tüm servisi bozmasın diye.
Erlang, pratik bir güvenilirlik yaklaşımını popülerleştirdi: bölümler başarısız olacakmış gibi varsayın ve sonra ne olacağını tasarlayın.
Her çöküşü engellemeye çalışmak yerine, hata izolasyonu, hızlı tespit ve otomatik kurtarma üzerinde durur; bu, sohbet, çağrı yönlendirme, bildirimler ve koordinasyon servisleri gibi gerçek zamanlı platformlarla iyi eşleşir.
Bu bağlamda “gerçek zamanlı” genellikle yumuşak gerçek zamanlı demektir:
Mikrosaniye garantilerinden çok, duraksamalardan, çöküş spiralinden ve kademeli kesintilerden kaçınmak önemlidir.
Erlang tarzı tasarımda eşzamanlılık-temel olarak çok sayıda küçük, izole işçi olarak sistemi yapılandırmak demektir; büyük, sıkı bağlı bileşenler yerine her işçi dar bir sorumluluk üstlenir (oturum, cihaz, çağrı, yeniden deneme döngüsü gibi).
Hafif süreçler, büyük sayılarda oluşturabileceğiniz küçük, bağımsız işçilerdir.
Pratik faydaları:
Mesajlaşma, ortak paylaşılan durum yerine mesaj gönderme yoluyla koordinasyondur.
Her işçi kendi iç durumunun sahibidir; başkaları doğrudan değiştiremez. Bu, yarış koşulları gibi eşzamanlılık hatalarının büyük bir kısmını azaltır.
Back-pressure, bir işçinin işleyebileceğinden daha hızlı mesaj alması ve posta kutusunun (queue) büyümesidir.
Bununla başa çıkmanın pratik yolları:
“Let it crash” demek, bir işçi geçersiz veya beklenmeyen bir duruma geldiğinde hızla başarısız olması ve sürünen bir halde devam etmemesi gerektiğidir.
Kurtarma yapı (supervision) tarafından ele alınır; bu basit, okunabilir kod yolları ve öngörülebilir kurtarma sağlar—tabii yeniden başlatmalar güvenli ve hızlıysa.
Supervision tree, süpervizörlerin işçileri izlediği ve tanımlı kurallara göre yeniden başlattığı bir hiyerarşidir.
Ad‑hoc kurtarma yerine merkezi bir yerden karar verirsiniz:
OTP, Erlang sistemlerini uzun süre çalıştırılabilir kılan standart desenler (behaviours) ve sözleşmeler setidir.
Yaygın yapı taşları:
gen_server: durum tutan uzun ömürlü işçisupervisor: başarısız işçileri yeniden başlatma politikalarıapplication: bir servisin nasıl başlatılıp durdurulduğunu ve sürüme nasıl sığdığını tanımlamaAvantajı, proje başına yeni bir çark icat etmek yerine paylaşılan ve anlaşılmış yaşam döngülerine sahip olmaktır.
Aynı prensipleri diğer yığınlarda da uygulayabilirsiniz: hatayı ve kurtarmayı birinci sınıf kabul edin.
Örnekler:
Daha fazla için yazıda , uygulama detaylarında ve değerlendirme için metinlerini not edin.