Sayın Valimin bilgisayarında sunucu çalıştırmak

22/02/2019

Merhabalar,

Docker ve microservis’i duymayanımız kalmadı artık sanırım. Haklarında bir sürü abimiz/arkadaşımız yazdı çizdi. Allah onlardan razı olsun. Amin. Ben size bu yazımda bu iki muhteşem kelimenin bana düşündürdüğü bir mimariden, uygulanma biçiminden bahsedeceğim.

Docker ve microservisl’er hala çok aşina gelmiyorsa docker hakkındaki yazımı okumanızı tavsiye ederim.

Hiçbirimiz programlama kariyerine direk Google da bulut mimarinin içinde başlamadık. Adım adım geldik bu hale. Hala da adım adım gelişiyoruz. Bu süreç gösteriyor ki hiç bir şey laf olsun diye tasarlanmıyor. THY kodu canlıya çıkarana kadar, laf olsun diye 20 tane katmandan geçirmiyor. UAT ortamı laf olsun diye açılmadı.

Mimariler de laf olsun diye tasarlanmıyor. Kesinlikle bir problemi çözüyor yada kolaylaştırıyor. Bazen farkında olmadan o çözümü kullanıyoruz aslında. Yada üretiyoruz. Biz spagetti kod ile site tasarlarken de kullanıyorduk mesela MVC ‘yi. Farkında olmadan. Dosya adımız routing di, haberler dosyasının ilk satırlarında veriyi çekiyorduk modelimiz buydu. Sonraki satırlarda veriyi anlamlandırıyor şekillendiriyorduk aslında controller yaptığımızın farkında olmadan. Sonra bazı işlemlerimi kolaylaştırsın diye kütüphane dosyamızı yazmıştık hepimiz, helper’ımızdı. En son satırlarda da verimizi html kodu içine gömüyorduk (view). 25. işimizden sonra adım adım sınıflara bölmeye başladık “Base” projemizi. Farkında olmadan codeigniter (vs.)yaptık hepimiz. Bir sürü codeigniter vardı farklı farklı adamların geliştirdiği. Sonra en iyi codeigniterlar markalaştı. Biz de baktık bu hakikaten bazı noktalarda daha iyi, standarda uyduk onu kullandık.

Bugün bahsedeceğim konu da bundan farklı değil. Ama önce biraz temel şeylerden bahsetmek istiyorum. Önce uygulamayı geliştirirken dikkat etmemiz gerektiğini düşündüğüm hususları yazıp sonra bizi bir çok kahırdan kurtaracak yapıya geçeceğim.

Hepimiz fark ettik ki; uygulama geliştirmek kadar ölçeklemek de önemli. Örneğin kendiniz bir “e-devlet” yazdınız, her şey mükemmel çalışıyor ama uygulama paralel çalıştırılamadığı için en çok 500 eş zamanlı kullanıcıya hizmet verebiliyor. Oldu mu şimdi?

Ölçeklenebilirliği de tasarım esnasında planlamalısınız. Monolith uygulamalar yazıyor olsanız bile sistemi olabildiğince “stateless” yapmalısınız. Bir yolunu bulmalısınız. Sessionları db de tutabilirsiniz mesela, yada oluşturması maliyetli dataları cache sunucunuzda. Uygulama sunucusu üzerinde hiçbir özel data kalmamalı. Kalmamalı ki; gerekirse siz onun aynısından bi tane daha ayağa kaldırıp yanına farklı bir IP ile koyabilesiniz. Bu şekilde gelen isteklerin yarısına birisi cevap versin yarısına diğeri. Uygulama sunucumuz üzerinde özel data kalır ise ne olur? Örneğin 2 adet sunucunuz var. Kullanıcı ilk geldiğinde load balancer onu 1. sunucuya yönlendirdi ve orada login oldu diyelim. Session bilgisi 1. sunucuda tutuluyor. Sonra kullanıcı profilim sayfasına tıkladı. Yani yeni bir sayfa istedi. Bu sefer load balancer onu 2. sunucuya yönlendirdi. 2. sunucu baktı ki adamın session bilgisi geçersiz. Çünkü onun session id’si 1. sunucu için anlamlı. 2. sunucu onu tekrar login sayfasına yönlendirir. Bu gibi senaryoların yaşanmamasını istiyorsak uygulama sunucusu stateless yani durumsuz olmalı. Daha detaylı bilgi için şurada güzel bir video var. Bir zamanlar biz de uygulamamızı aşağıdaki gibi bölüp durumsuz parçalar haline getirmiştik.

İkinci kısım ve yukarıda adı geçen ikinci teknoloji mikroservisler. Mümkünse uygulamanızı küçük servisler halinde yazın. Bunu niye böyle söylediğimi yazının sonunda anlaşılacak. Şöyle düşünün; elinizde Kütahya İl Özel İdaresi adında bir uygulama var. Bu uygulama içerisinde 12 tane müdürlük var. Siz bu uygulamayı durumsuz olarak tasarladınız. Bir yoğunluk olduğu an rahatlıkla ölçekleme yapabileceksiniz. Oldu da bir zaman geldi emlak müdürlüğü gerçekten çok fazla istek almaya başladı. Sonra siz bunu gördünüz ve hemen yanına bir Kütahya İl Özel İdaresi daha kondurdunuz. 12 Müdürlüğüyle yüzlerce personeliyle tüm uygulamayı kopyaladınız. Dış kapıdaki güvenliklere de dediniz ki dışarıdan gelen kişilerin yarısını 1. binaya yarısını 2. binaya gönder. Süper. Beklenilen oldu. Artık her iki binadaki emlak müdürlükleri de normal yoğunlukta çalışıyor. Ama farkında olmadan birşey yaptınız. Birinci binada insan kaynakları müdürlüğü çok yoğun değildi. Hatta belki de boş oturuyordu. Siz bunu da kopyaladınız. Her müdürlük en iyi ihtimalle bir miktar ram demek, başlama ve kontrol esnasında işlemci demek. Ayrıca bu iki Kütahya İl Özel idaresi de aynı veri tabanına bağlı. Veri tabanı ölçeklenmedi.

Artık bir çok teknoloji bir noktaya kadar doydu. Sadece çözüyor olmak yetmiyor. İnsanlar verimli çözümler için kafa patlatıyor. Hem üretim endüstrisi hem yazılım endüstrisi.

Son olarak da docker swarmdan bahsedip bunların hepsini toplayacağım. Docker 2013 de duyurulduktan yaklaşık 1.5 sene sonra -yani 2014 ün sonunda- 55 milyon $ yatırım aldı. Tabiri caizse adamlar parayı harcayacak yer bulamadılar. Swarm da docker ‘ın sonradan bu paralarla satın aldığı teknolojilerden birisi. Özetle önce bir makine grubu oluşturup containerlerinizi bu grupdaki çeşitli makinelerde sizin istekleriniz doğrultusunda çalıştırıyor/yönetiyor.

Peki gelelim bu yazının da konusu olan esas meseleye. Bunları birleştirirsek ne olur? Biz bunları birleştirdik.

250 adet personelimiz, bir o kadar da bilgisayarımız var. Bu bilgisayarlar genelde 08:00–17:00 arası açık duruyorlar ve çok da yoğun değiller. En yoğun olduğu zamanlarda bile minimum 2–3 GB boş ram ve %30 işlemci kaynağı var. Ne tesadüftür ki bizim bilgi sistemimizin de en yoğun olduğu zamanlar bu saatler arası.

Biz bir docker cluster oluşturduk. Bu kümede; sunucular üzerinde çalışan ve yaklaşık 250 personelimizin bilgisayarında çalışan sanal makineler var. Sanal makinelerde docker kurulu ve kümeye katılmış durumda. Sunucu üzerinde çalışan docker node ‘ler yönetici diğerleri worker. Kullanıcı bilgisayarlarındaki sanal makineleri VirtualBox ile çalıştırıyoruz. Makine açıldığında otomatik olarak komut satırından gui siz olarak başlatıldığı için kullanıcılar farkında bile değiller. Ayrıca işlemci ve ram kullanımları, kullanıcıyı taciz etmeyecek seviyede sınırlandırıldığı için onlara bir zararı olmadığı da söylenebilir.

Burada akıllara şu gelebilir: kullanıcı bilgisayarında çalıştırdığınız için kullanıcılar bilgisayarda çalışan servisleri yada dosyaları görebilir mi? Yada ağ iletişimini dinleyebilir mi? İkisinin cevabı da hayır. Çünkü orada çalışan izole bir işletim sistemi var. Kullanıcı adı ve şifresi gizli hiçbir şekilde login olamayacağı için bir bilgi sahibi olamaz. Ağ tarfiğini de swarm planlıyor. Bazı portları kapatıyor, bazı servisler custom portlar üzerinden sanal ağlar ile haberleşiyor. Kaldı ki ağ trafiğini bir şekilde dinlese bile servisler arası haberleşme şifrelenmiş olarak tasarlanabilir.

Bu kümeyi kullanarak servislerimizi koşturuyoruz. Sistem yoğun olan servisleri otomatik olarak 2, 3, 5… gerektiği kadar ölçekliyor. Bu bize 0 TL maliyet ile yüzlerce çekirdek ve yüzlerce GB ram sunuyor. Bu kadar kaynağı bize Sayın İsmet GÜRAL “içimden geldi, devletimize hibe ettim” dese, ücretsiz sağlamış olsa bile elektrik gideri olacaktı. Yani şu haliyle hibe sunuculardan bile daha makul.

Bu mimaride dikkat edilmesi gereken iki noktadan bahsedebilirim. Birincisi ağ altyapınız yeteri kadar iyi olmalı. Çünkü dağıtık çalışan servisler özellikle uygulamanın yoğun kullanıldığı anlarda ciddi bir trafik yapacaktır. İkincisi ise çok sağlam bir ağ storage sahibi olmalısınız. Buda ayrıca artı olarak ağ yükü getirecektir. Mümkünse o da dağıtık çalışan bir sistem olsun (ceph yada glusterFS’e bakılabilir). Sanal sunucularınız üzerinde dosya tutmayacağınız için tüm istemcilere vereceğiniz hizmetinizin hızı son kullanıcıyı direk olarak etkileyecektir.

Aslında bu haliyle docker mantığına tamamen aykırı olduğunun farkındayız. Container ‘ın amacı aradaki fazla işletim sistemini kaldırmaktı. Ama biz kullanıcı bilgisayarlarına fazladan sanal işletim sistemleri kurarak hibrit bir çözüm uyguladık. Burada docker ‘ı öngörülen amacının dışında kullanıyor olmamız; bunun uzun vadede bizi sunucu odalarından kurtaracak bir çözüm olduğunu ve mevcut durumda 250 adet bilgisayarı daha verimli kullanıyor olduğumuz gerçeğini değiştirmez!

Bu gavurlar senelerdir kaynaklarımızı zombi bilgisayar olarak kullanmadılar mı? Yada tarayıcımızda bitcoin üretmeye çalışmadılar mı? Biz aynı mantığı hayırlı işler için kullanıyoruz.

Bunu, sadece bizim değil bir çok kamu kurumunun hatta üniversitelerin ihtiyacını karşılayacak bir çözüm olarak görüyoruz. Örneğin üniversitelerin öğrenci bilgi sistemleri bu mimaride çalışacak şekilde geliştirilmiş olsa. Kampüste yüzlerce personel bilgisayarı var her gün açık olan. Bu kaynak öğrencilerin ders kayıt zamanlarında sorunsuzca işlerini halletmesini sağlayabilir. ÖSYM sonuç açıklayacağı gün bunu kullanabilir. Özellikle peryodik olarak sadece belirli günlerde yoğunlaşan sistemlerde daha verimli olacağını düşünüyorum. Sevgiyle kalın…

He unutmadan. Başlık tamamen temsilidir. Özel bilgisayarlar kapsam dışı :)