Joe Armstrong ve Erlang: Güvenilir Platformlar İçin "Bırak Çöksün"

Bu Yazı Neleri Kapsıyor (ve Neden Hâlâ Önemli)

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.

Düz dille “gerçek zamanlı”

Gerçek zamanlı her zaman “mikrosaniyeler” veya “kesin zaman sınırları” demek değildir. Birçok üründe şu anlama gelir:

• kullanıcıların hissedeceği kadar hızlı yanıtlar (garip duraklamalar yok)
• yük altındayken öngörülebilir davranış (yavaşlayabilir ama kontrolden çıkmamalı)
• kısmi arızalar sırasında hizmet devamlılığı (kötü bir bileşen her şeyi götürmemeli)

Erlang, bu beklentelerin tartışılmadığı telekom sistemleri için inşa edildi—ve bu baskı en etkili fikirlerini şekillendirdi.

Odaklanacağımız üç temel direk

Sözdizimine dalmak yerine, Erlang’i ünlü yapan ve modern sistem tasarımında tekrar eden kavramlara odaklanacağız:

1. Varsayılan olarak eşzamanlılık: yazılımı birkaç büyük parçadan ziyade birçok küçük, izole işçiden inşa edin.
2. Hata toleransı tasarım hedefi olarak: hataların, zaman aşimlarının ve çökmelerin olacağını varsayın—ve bundan sonra ne olacağını planlayın.
3. “Bırak çöksün”: her kod satırını aşırı savunmak yerine; hızlı başarısız olmayı ve yapıyla (kahramanlığa gerek kalmadan) temiz kurtarmayı tercih edin.

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.

Joe Armstrong’un Motivasyonu: Ayakta Kalan Sistemler İnşa Etmek

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ı.

Pratikte “güvenilir” ne demekti

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:

• parçalar yanlış davransa bile kullanıcıya hizmet vermeye devam etmek
• arızaları hızlıca tespit etmek
• insan müdahalesini minimuma indirerek otomatik kurtarma sağlamak
• bir hatanın her şeyi götürmesini engellemek

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.

Daha az mit, daha çok problem çözme

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.

Varsayılan Olarak Eşzamanlılık: Çok Sayıda Küçük İşçi

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.

Hafif süreçler, basitçe açıklandı

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.

“Tek büyük program” neden farklı şekilde çöker

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.

Mesajlaşma: “not gönderme” gibi

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.

Aktör Modeli ve Mesajlaşma (Jargondan Uzak)

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.

Aktörler: sadece mesaj göndererek konuşan küçük işçiler

Bir aktör, kendi özel durumu ve bir posta kutusuyla birlikte öz‑içerikli bir birimdir. Üç temel işlem yapar:

• posta kutusundan (sırayla) mesaj alır
• kendi iç durumunu günceller
• diğer aktörlere mesaj gönderir

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.

Paylaşılan durumdan kaçınmak hangi hata kategorilerini kaldırır

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.

Back-pressure, kahve dükkânındaki kuyruk gibi anlatımı

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.

Somut bir örnek: sohbet bildirimleri

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.