Bilgi çağında otomasyon devrimi

Sanayi devrimi başladığında üretim ağırlıklı olarak el emeğine dayanmaktaydı. Önce değişik tipteki motorların icat edilmesi, sonrasında bu motorların yardımı ile üretimin maliyetinin büyük oranda düşmesi ile dünyada sosyal, kültürel, siyasi ve ekonomik alanda büyük değişimler meydana geldi. Bu değişimlerin somut halini fabrikalarda gördük. Fabrikaya giren hammadde makinalar yardımı ile ürüne dönüşüyordu. Yirminci yüzyıl boyunca fabrikalardaki bu süreçlerde insan emeği karşılığı ödenen ücretin toplam maliyet içindeki payı otomasyon ile her geçen sene biraz daha azaldı. Artık içeceklerimiz kocaman fabrikalarda otomasyonun verdiği olanaklarla birkaç kişi tarafından üretiliyor. Arabalar robotlar tarafından monte edilip üretim hattında ilerliyorlar.
 Bütün bu değişimin benzerinin bilgi çağında da yaşandığını görmekteyiz. 1950 li yıllardan itibaren motorlara benzer şekilde ortaya çıkan bilgisayarlar, bilgi üretimi alanında insan emeğinin her geçen yıl daha da azaldığını gördüğümüz bir sürecin içerisinde ilerliyor. Bilgi devriminin somut hali olan Bilgi Teknolojileri veya Bilişim Şirketlerinin, veriyi hammadde olarak aldığı ve bilgisayarlar yardımı ile ürüne dönüştürdüğü bir dönemin içerisindeyiz. Veriyi işleyen teknoloji şirketlerinin artan rekabet ile maliyetleri azaltmak, yeni ürünler çıkartmak için sanayi devrimindeki sürece benzer olarak otomasyona daha fazla yer verdiğini de görmekteyiz.

Bizde durum

 İşte tam bu noktada, yazılım dünyasının sanal robotları olan schedulerların tarih sahnesinde gittikçe daha ön plana çıkmaya başlamaları bir tesadüf değil şüphesiz. Bunu 2008 de görüp yerli bir scheduler yapma fikrini hayata geçirmeye giriştiğimizde, Bilişim dünyamızdan birçok arkadaşımız “Windows un scheduler ı var, Unix de de cron var ne gerek var scheduler yazmaya” gibi yorumlarda bulunmuşlardı. 2008 de kurduğumuz Likya şirketinde, Tlos ismini verdiğimiz scheduler ın üretilme hikayesi bu şekilde başladı. Önce basit bir ETL sürecini yöneten komut satırından çalışan bir scheduler ile başlayan çalışmalarımız, Java tabanlı bir ürün olarak yıllar içinde gelişti. Windows ve Unix ortamlarında bağımlılıkları olan işleri çalıştırabilen ve yönetmek için web ara yüzü olan bir ürüne dönüştü. Bu ürün Türkiye de bazı şirketlere satıldı ve yıllar boyunca kullanıldı. Bu süreçte, 2010 yılı civarında işleri yönetmenin tek bir makinada yapılmasının kısıtları ve çalıştırılacak işlerin sayısının sürekli artmasını da göz önüne alarak Dağıtık İş Yükü Otomasyonu ile ilgili bir proje başlattık. Projede değişik aşamalarda görev alan yaklaşık on kişilik bir ekiple toplamda iki yıl kadar süren bir geliştirme sürecine girdik. Bu süreçte, Türkiye de uluslararası çapta rekabet gücü olan bir yazılım geliştirmenin ne kadar zor bir iş olduğunu ve devletten özel sektöre kadar bir yelpazede yönetenlerin söyledikleri ile gerçekte yaptıklarının ne kadar farklı olduğunu fiili olarak yaşadık. Sonuçta ürünün ilk versiyonunu bitirdik ama biz de kaynaklarımızı tüketmiştik. Finansal olarak destek arayışlarımız sonuçsuz kaldı. Bizim de şirket olarak bazı hatalarımız oldu ama böyle iddialı bir ürün için hata yapmadan da ilerlemenin olanaksız olduğunu zaman geçince insan daha iyi anlıyor. Sonuçta iyi işler çıkaran bu ekip dağıldı ve kendi başının çaresine bakmak durumunda kaldı.

Dünyada durum

Tabii bu süreçte bir scheduler ın çok detaylı mimarisi ve çalışma sistemi için tamamen kendi ürettiğimiz bir yapı kurduğumuz için çok ciddi bir know-how oluşturduk. Bu açıdan yıllarını veri işleme ve veri madenciliği ile uğraşarak geçiren bir kişi olarak, büyük veri adı altında veri işleme konusunda yapılanları incelediğimde, Hadoop un ve benzer frameworklerin gerçekte çok özel işler çalıştırmak için geliştirilmiş birer scheduler olduklarını görmem fazla vaktimi almadı. İşin teknik detayını bilenler zaten farkındalar. Ben burada farkında olmayanlar için teknolojiyi takip etmek ile kullanmak arasındaki farkı anlamalarını umarak biraz detay vermek istiyorum.
İşlerin bilgisayarlarda otomatik olarak çalıştırılması için kullanılan sistemlere eski tabiri ile scheduler denmektedir. Buna yeni terimlerle iş yükü otomasyonu (workload automation) denmesinin sebebi, yeni nesil scheduler ların iş yükünü kaynakların verimli olarak kullanılması açısından akıllı bir şekilde dağıtabilmeleridir.
Dünyada schedulerlar startejik ürün olarak görülmektedir. Bu nedenle her gelişmiş ülkenin kendi scheduler ı vardır dersek yanlış yapmayız. Bunun sebebi büyük şirketlerin scheduler olmadan günlük operasyonlarını yürütemeyecekleri gerçeğidir. Bunun istisnası yoktur. Bu nedenle umarım ileride bu konuda ülkemizde de bazı adımlar atılır.

Büyük veri işlemede otomasyon

Daha önceleri veri işlemede özellikle veri tabalarında kullanılan ETL süreçleri ön planda olduğundan, scheduler lar ticari hayatta ağırlıklı olarak veri ambarları, veri tabanlarının işletilmesi ile, birazda sistem güncellemeleri gibi kullanımları ile gündemdeydi. Büyük veri işlemede Hadoop un ve problem çözme tarzı dağıtık mimari üzerinde çalışan Map-Reduce (MR) un ön plana çıkması ile bu gündem oldukça değişti.

Hadoop ile veri işlemede otomasyon

Hadoop un v1 olarak bildiğimiz eski versiyonunda işlerin yönetimi yani çalışmaya başlaması, bağımlılıklarının kontrolü, hatalı bitmesi durumunda ne yapılacağı gibi detaylar ile işlere kaynak ataması yapılması yani workload management aynı yapı içinde yapılmaya çalışılıyordu. Hatta workload management ikinci plandaydı denebilir.
Hadoop un v2 yani yeni versiyonunda temel değişiklik bu iki yapının birbirinden ayrılmasıdır. Bunun yazılım mimarisi açısından anlamı şu; mimariye işlerin kaynak yönetimini yapan bir katman eklenmiş oldu. Bu katman bir işin cluster da hangi node üzerinde çalıştırılacağına karar veren mekanizmayı barındırıyor. Bunun için bütün kaynaklardan sürekli bir şekilde kaynak kullanımı ile ilgili veri alması ve bunları değerlendirmesi gerekiyor. Yani, CPU, Harddisk, RAM kullanımı gibi bilgileri istenen periyotlarla almak ve gerçek zamanlı olarak bu verileri değerlendirmek için bir yapı gerekiyor ve özellikle işlerle ilgili SLA (Service Level Aggrement) lerin bu noktada dikkate alınması gerekiyor. Yani basitçe, önceliği olan bir işe öncelik verilmeli, ya da en az 1GB bellek isteyen bir işi bunun altında memory si olan bir kaynağa yönlendirmemeli vb. Bu katmanı yöneten yazılıma Hadoop eko sisteminde YARN ismi verildi. Diğer bir katman ise MR işlerinin çalıştırıldığı katman.

Kaynak yönetimi

Bu basit gibi görünen değişikliğin önemli kazanımları oldu. Kaynak yönetimi yapan başka bir yazılımı YARN ın yerine koyma fırsatı çıktı. Bunun bildiğimiz iki örneği Kaliforniya Üniversitesi, Berkeley'de geliştirilen sonrasında Twitter ın kullanma kararı alarak geliştirmesine destek verdiği açık kaynak dünyasının yeni sayılabilecek yıldızlarından Mesos ve Google da Borg ismi verilen cluster yönetim sisteminin açık kaynak versiyonu olan Kubernetes tir. Google, Borg u uzun zaman kullandığı ve yeni ihtiyaçlar ortaya çıktığı için "yeni nesil Borg" diye nitelenen Omega ismi verilen yazılım üzerinde çalışmaktadır. Bu ürünler tamamen kaynak yönetimi ve işlere kaynak ataması yapılması, yoksa kaynak yaratma gibi konulara odaklanırken, bunların üzerinde uygun API ile çalıştırılan her bir uygulama, MR, Spark, Storm vb. kendi schduling ini yapmakta özgür kaldı. Bu şekilde örneğin, Twitter bütün sistemlerini kendi ihtiyaçları doğrultusunda geliştirdiği ve açık kaynak kodlu ürettiği Aurora Scheduler ile yönetmektedir.

Buluttan iş yapmak

Bilgi devrimi çağında otomasyon ile maliyetlerin düşürülmesi için güncel en önemli araç cluster ve kaynak yönetimi yapan yazılımlardır. Yapılacak işleri uygun kaynaklara atama problemi, kaynağın ne olduğu sorusu ile yakından ilişkilidir. Bunu kısaca tanımlayalım. Kaynak bir iş yapmak için kullandığımız her şeydir. Konumuz açısından baktığımızda iş yapmak bir yazılım parçasının, kodun çalıştırılması olduğu için bunun gerçekleştirilmesi için normalde olması gereken, bir makine yani donanımdır ve onun üzerindeki işletim sistemi ve gereken diğer uygulamalardır. Ama sanal makinalar devrinde bu iş, gerektiği zaman bir sanal makine açmak ve işi burada çalıştırıp kapatmak şekline dönüşmüştür. Dolayısı ile cluster yönetimi ve kaynak kullanımı bu işlerden de sorumludur. “Buluttan iş yapmak” deyimi bunu ifade etmektedir esasen. Kullanılan web servislerinin dahil olmak üzere bir çok servisin, bu şekilde gerektiği kadar node üzerinde çalıştırılarak kullanıldığını biliyoruz.

Minumum maliyet

Son birkaç yıldır, bu kurgunun yani her bir iş için bir sanal makine açmanın kaynak israfı olduğunu ve tasarruf noktası olduğunu düşünenler, iki çözüm üzerinde yoğunlaştılar. Bunların birincisi, sanal makinanın kırpılmış bir halini kullanmaktır. Kullanıcı ile güvenli bir bağlantı, örneğin SSH, üzerinden etkileşebileceği bir imkan verip kullanıcı ara yüzünü tamamen kaldırmak gibi. Bunun bir örneği Vagrant dır. İkinci bir çözüm, eski bir çözümü yeni bir problem için kullanmak fikrinden çıkmıştır. Uygulama geliştiricilerin yakından bildiği container ları kullanmak. Bu şekilde her bir iş için bir container kullanılarak kaynak kullanımı minimize edilmiş olmaktadır. Bu çözümün önde gelen ismi Docker dır. Yani bir işi sanal bir makine yaratarak değil de, uygun container ile çalıştırmak. Bunu uzun zamandır yaptığını açıklayan Google, 2014 de bir haftada 2 milyar container ı operasyonları için çalıştırdığını açıklamıştır. Şu andaki sıkıntı container dünyasının ortak bir standardı olmamasıdır ve bunun için Google firması desteği ile Linux Foundation tarafından Cloud Native Computing Foundation kurulmuştur. Standartların oluşması ile bulut üzerinde iş yapan firmaların iş yapma şeklinde köklü değişiklikler ortaya çıkacağı beklenebilir.

Akıl akıldan üstündür

Son olarak bu katmanın kazandırdığı diğer bir özellikten bahsederek bu yazıyı bitirelim. Normalde tek bir dağıtık uygulama çalıştırmaya izin veren cluster kullanımı yerine, birden fazla dağıtık uygulamanın bir cluster da çalışabilmesinin önü açılmıştır. Bunun şu anda öncü firmalarından Mesosphere ın servis olarak sattığı, Mesos üzerinde bu tür bir hizmettir.

Sonuç

Bu şekilde otomasyonun giderek daha fazla kullanılması, ürün ve hizmetlerin daha ucuza üretilmesini sağlarken, rekabette öne çıkmanın önemli araçlarından biri olmuştur. Ülkemizde scheduler ın bir ürün olarak ne işe yaradığını bilmeyen bir çok BT çalışanı olduğunu ve bir scheduler kullanmadan operasyonlarını yürüten firmalar olduğunu düşünürsek bu gelişmelerin neresinde olduğumuzu maalesef görmüş oluyoruz.