Slack, hücresel mimariye geçti

• Slack, son 1,5 yılda yedekliliği artırmak ve site arızalarının etkisini sınırlamak için tekil yapıdan hücre tabanlı bir yapıya (Cellular Architecture) geçti
• Bu geçiş, Haziran 2021'deki bir ağ kesintisinin Slack müşterilerinde hizmet bozulmasına yol açmasının ardından Slack hizmetinin dayanıklılığını artırma ihtiyacıyla yönlendirildi
• Hücresel yapı, her hizmetin kullanılabilirlik bölgesi (AZ) başına bir sanal hizmet olarak çalışmasını sağlayarak bir AZ'deki arızanın diğer AZ'leri etkilememesini sağlıyor
• Ayrıca sorunlu AZ'deki trafiği boşaltma (drain) özelliğini de içeriyor; bu sayede söz konusu AZ sistemin geri kalanından etkili biçimde izole ediliyor
• Boşaltma mekanizması; hızlı, hatasız, kademeli ve boşaltılan AZ'nin kaynaklarından bağımsız olacak şekilde tasarlandı
• Hücresel yapıya geçiş, hizmetlerin yalnızca kendi AZ'leri içinde trafik alıp göndermesini sağlayan siloing adlı bir stratejiyi de içeriyor. Bu, tek bir AZ içindeki tüm arızaların sınırlandırılmasına yardımcı oluyor
• Trafik taşıma mekanizmasının uygulanması, kullanıcı sorgularını çekirdek hizmetlere yönlendiren sisteme odaklandı
• Yeni yapı, AZ boşaltmayı desteklemek için Envoy'un weighted clusters özelliği ile RTDS üzerinden dinamik ağırlık atamasından yararlanıyor
• Bu geçiş, Slack'in çalışma biçimini ve hizmetlerini kurma şeklini değiştirdi; trafik yönetimi ve arıza azaltımı için güçlü yeni araçlar sundu
• Gelecekteki blog yazılarında teknik uygulama ayrıntıları daha derinlemesine ele alınacak ve yeni yapının Slack'in operasyonlarını nasıl etkilediği tartışılacak

[GN⁺]

Hacker News görüşleri

• Slack’in hücresel mimariye geçişi, kendine özgü operasyon ve izleme yaklaşımı nedeniyle ilgi çekti.
• Şirketin stratejisi, istekleri tek bir AWS availability zone (AZ) içinde çözmek, operasyonları basitleştirmek ve izlemeyi kolaylaştırmak.
• Bu yaklaşım, kümeler arasındaki metrikleri karşılaştırarak tek bir kümedeki olayların kolayca tespit edilmesini ve hafifletilmesini sağlıyor.
• Ancak bu strateji, çoğu hizmetin birden fazla kümede çalışmasını gerektirdiği için compute, cache vb. alanlarda fazlalık yaratıyor.
• Bazı kullanıcılar, hizmet arka ucuna yüzlerce RPC fan-out yapabilen Slack’in API istek sisteminin verimliliğini sorguluyor.
• AWS availability zone yakınlığını kullanmak ile üst düzey yönlendirme noktasında devre dışı kalan bir AZ’yi basitçe devreden çıkarmak arasındaki fark üzerine bir tartışma var.
• AWS USE1 içinde her şeyi çalıştırmanın getirdiği fazlalık konusunda endişeler dile getirildi; USE1 ile ilgili sorunlar birden fazla hizmeti etkileyebilir.
• Bu mimaride kullanıcı verilerinin nasıl ele alındığı, özellikle de AZ çarpanı söz konusu olduğunda, soru işaretleri doğurdu.
• Bazı kullanıcılar, geçmişte üzerinde çalıştıkları benzer mimarileri, örneğin Metal Cell adlı dağıtık işletim sistemini hatırlıyor.
• Yeni kullanıcı istekleri gelmese bile, çok kaynak tüketen işlerin ayrılmış bir AZ’de süresiz olarak çalışmaya devam etme ihtimaliyle ilgili sorunlar tartışılıyor.
• Kullanıcılar, Slack’in şu anda hangi programlama diliyle yazıldığını merak ediyor ve hâlâ Hack/PHP olup olmadığını soruyor.
• Bazı kullanıcılar Slack’in performansıyla ilgili hayal kırıklığını dile getiriyor ve onu Discord gibi diğer sohbet uygulamalarıyla kıyaslandığında olumsuz buluyor.