Günümüzde web tabanlı uygulamalar oldukça popüler ve artık sadece web tabanlı bir uygulama ürün yada hizmet olarak büyük şirketler bulunmaktadır. Bunların en gözdeleri ; twitter, facebook, instagram, linkedin vb... saymakla bitmez. Anlık olarak binlerce/onbinlerce kullanıcıya hizmet veren bu uygulamaların mimarileri nasıldır.. Aslında sırf bu soruyu baz alarak hali hazırda bir web uygulaması mevcut, sadece bu sorunun cevabını veren ve benimde hatırladıkça ziyaret ettiğim bir web-sitesi : highscalibility.com Ölçeklenebilirlik alanında bolca yazı bulacağınız bu sitede, benim bu güzel konum için güzel çok örnekler mevcut. Zamanında merak edip, araştırıp bu sitede bulduğum ünlü bir web uygulamasının sistem dizaynını paylaşayım ve neden bir web uygulamasının bu denli ihtiyaçlara sahip olması gerektiğinin cevabını yada bir web-sitesi olarak gördüğünüz bir sitenin aslında koca bir dünya ve bu dünya içinde gereksinimlere dayalı olarak nasıl süreçlerden geçtiği ve karşılaştıkları ihtiyaç/sorunlara nasıl çözüm ürettiklerinide basitçe anlamış olacağız. İlk incelediğim sistem mimarisi tumblr olduğu için ; eski bir gönül bağlılığı olsa gerek ki, hiç üye olmasam bile, ilk olmanın aşkı ile onu paylaşayacağım. Tüm referansım, highscalibility sitesidir. İstatistikleri Günde 500 milyon sayfa gösterimi Ayda 15B+ sayfa gösterimi Çalışan sayısı : 20 mühendis Saniyede 40k (ortalama 40bin) istek Günde 1+ TB data Hadoop cluster : Hadoop dağıtık dosyalama sistemidir. Günde bir kaç TB'dan fazla data MySQL/HBase/Redis/Memcache gibi hafıza yada RDBMS sistemlerinde barındırılması Aylık 30% artış 1000 'e yakın hardware sistemleri Günlük 50GB veri transferi. Günlük takibpçilerin güncellemeleri ile oluşan veri akışının boyutu : 2.7TB. Böyle istatistiklere sahip bir siteniz olsa Artık ne yaparsınız bilmem, google, facebook, twitter'ı düşünemiyorum bile Yazılım Alt Yapısı OS X , Linux yayındaki alt yapı Apache PHP, Scala, Ruby -> 2 adet fonksiyonel dil... bir adet betimleyici.. dikkat! Redis, HBase, MySQL - >Documented ve RDBMS Varnish, HA-Proxy, nginx, - > Load balancer ve istek dağıtıcılar, gelen istekleri karşılayanlar.. Memcache, Gearman, Kafka, Kestrel, Finagle - > Cache serverları Thrift, HTTP Func - a secure, scriptable remote control framework and API Git, Capistrano, Puppet, Jenkins - > Çevik yazılım geliştirme ve konfigürasyon araçları, Cont' Integration Donanım Alt Yapısı 500 web servers 200 database servers 47 pools 30 shards (verilerin farklı farklı makinelere dağıtılması : mesela bir tablonuz var 50 milyar veri var burda belirli noktalardaki verilere hızlı erişmek için mesela 10 parçaya bölünüp, 5 milyar lık tablolara ayrışması gibi) 30 memcache servers - > Cache sunucuları 22 redis servers - > Cache 15 varnish servers -> Cache 25 haproxy nodes -> isteklerin proxy lerle yönlendirilmesi 8 nginx - > load balancer (oldukça hafif 14 job queue servers - > Mesajlaşma sistemleri Yazının devamında eski Tumblr mimarisinin, yeni Tumblr mimarisine geçişi ve bu geçişlerin sebepleri ve teknik açıdan neden fonksiyonel dillere yöneldiğinin sebeplerini yazıyor. Üstün körü şunu söyleyebilirim. Bir sayfada yapılan değişikliğin diğer takipçi sayfalarındada güncellenmesi demek binlerce takipçisi olan bir kişinin bir diğer değişikliğinin binlerce veri güncellenmesi ve bunun her kullanıcı için tutarlı olması anlamına geliyor. Birde buna bölgesel olarak değişen saat faktörü ve bölgesel olarak değişen diğer etmenleride düşündüğümüzde aslında küçük bir güncellemedende öte bir şey olduğunun farkındalığı oluşuyor. Mesela teknik açıdan fonksiyonel dillere neden ihtiyaç duyup geçmelerinin en temel sebeplerinden biri de anlık olarak değişen bu verinin hem tutarlı, hem hızlı hemde ölçeklenebilir olması gerek burada fonksiyonel dillerin ne kadar yeteneğe sahip olduğunu ve yüksek ölçekli uygulamalarda işin mantıksal boyutundan öte basit bir database^e gönderilen update değilde tüm kullanıcılar için uygulamanın yenilenmesi demek olduğunu görebiliyorsunuz. Fonksiyonel dillerde en güzel özellik bir fonksiyonun diğer bir fonksiyon için bir değer olarak geçebilmesi ile verilen akışının ne denli rahat olduğu, fazla kurallara bağlı olmadan bir işlem yapıp sonucu beklemekten öte, bir işi kendi akışına bırakmak gibidir. Fonksiyonel dillerdeki buradaki örnekte (Scala , Ruby), siz bir metoda yada fonksiyonal fonksiyon gönderip, fonksiyon alaibliyorsunuz, fonksiyonu parametre olarak gönderip, fonksiyon dönebiliyorsunuz, yada fonksiyona ile parametrik geri bildirimler alabiliyorsunuz. Bu fonksiyonel dillerin güçlü tarafları ve yapacağınız iş içinde fonksiyonel bir dilmi yoksa nesne yönelimli C++, java gibi bir imperative dilmi kullanmanız gerektiğinizin kararını vermenizi sağlar. Elimizdeki örnekte ise fonksiyonelite, hız, ölçeklenebilirlik her daim sonuçsal odaklanmanın önüne geçiyor ve bize aslında neden fonksiyonel bir dil gerektiğininde cevabı oluyor. Bir diğer teknik kavram ise fonksiyonel diller için state kavramının olmaması, bu durum kavramı neden bu örneğimizde bu kadar önem atfetmiyor.. Sebebi siz bir kullanıcı olarak profilinizde güncelleme yaptınız, bunu takipçilerinizde kısa bir zaman dilimi içinde bunu görmesi yada diğer bir şekilde profillerine yansıması gerek.. Klasik bir yaklaşımla nesne yönelimli programlama dillerinde bunun için bir değişkende bu değişen değeri tutup, teker teker diğer kullanıcılar için istekler yaratmanız gerekmektedir. Buda senkronizasyonu sağlamak için state'in yani durumun sabit kalıp, tüm bu güncelleme işleminin bitmesini beklemek oluyor.. Buda zaman ve kaynak tüketimini göz önüne aldığınızda, yukarıdaki gibi istatistikleri olan bir uygulama için uzun bir zaman dilimi ve kaynakların sömürülmesi demek hatta farklı bir kullanıcı bu işlemi eş zamanlı yaptığında ve bunu binlerce kullanıcının yaptığını düşündüğünüzde olası bir kaos yaşarsınız.. Bu kaostan kaçmak ve değişeni tutmak yerine, bırakıp kendi işini yapması ve anlık güncellemelerdede değişmesi istenilen bir davranış olacaktır. en güzel örnek herkesin bildiği fonksiyonel bir dil olan java script'teki async callback'ler olabilir. Sevgilerle, Turgay Can Dip Not : fonksiyonel programlamaya sadece ilgim olduğu için fazla karlayamadım ve hakimliğim yok gibi sadece bloglardan ve takip ettiğim kişilerin yazılarından oluşan kulak dolgunluğu bilgidir. Arada belki yanlış/yanıltıcı aktarımlar yapmış olabilirim. Lütfen uyarın düzeltelim, ben bir yanlışımı düzeltmiş olurum ve bir bilgi kazanırım içerikte daha doğru oluşmuş olur. Referans : Kaynak Merak edenler için : Google Mimarisi LinkedIn Mimarisi Salesforce Mimarisi YouTube Mimarisi Nitfy Mimarisi Instagram Mimarisi Twitter'ın Milyarca Veriyi ve TB'larca veriyle nasıl