Strava altyapısına teknik bir bakış

Güzel bir hafta sonu, güneşli ve keyifli. Giderek ısınan havaların ayrıca keyfini çıkaran büyük bir kitle var etrafımızda; bisiklet severler. Bu hafta masaya yatırdığım teknolojiler bütünü uygulama,  bisiklet ve koşu tutkunlarının yakından tanıdığı,  tanıyanların da “Yapmış adamlar!” dediği uygulama Strava.

Uygulama altyapısı hakkında Online ortamlardan edindiğim bilgiler ile yapıda kullanılan teknolojilere kısa bir bakış ve bakış sonrası, bu yapıda aktif kullanılan Apache Mesos‘un nasıl kullanıldığı, Mesos ve Docker‘ın nasıl yük altında uyum içinde çalıştırıldığını ve Mesos Framework’lerinden özellikle de Mesosphere Marathon‘un kullanımı hakkında yine çeşitli kaynaklardan derlediğim bilgilerle ve naçizane kendi Apache Mesos ve Marathon framework bilgilerimle de kısa yorumlar ekleyerek bir şeyler karalamak istiyorum. Daha sonra konuyu biraz Strava Infra’sından kopararak Apache Mesos ve onun namıdiğer “container uygarlığı“na doğru hararetlendirmek istiyorum. Makale yine biraz uzayacak gibi görünse de tadında bırakmaya çalışacağım, en azından öyle umuyorum(!) Ben de “medium.com” gibi makalenin en başına “13 min read” koymayı isterdim ama inanın kestiremiyorum süreyi. 🙂 Araya uygulama mimarilerinden örnekler ve bir takım gerekli/gereksiz bilgiyi de eklemek istediğimi düşünürsek bence siz gidip kendinize büyük boy bir kahve alıp makaleye öyle başlayın. Yol uzun görünüyor yine. Makale yine spontane bir şekilde ortaya çıkacak, o yüzden mini bir indeks veya bir “tl;dr” geçmeyi çok tercih etmedim.

Daha önce incelediğim Spotify mimarisi gibi bu incelemede yine (fark edeceğiniz gibi) bir yazılımcı yaklaşımı şeklinde değil de “sistem-network, dağıtık altyapılar üzerine araştırmalar yapıp, bilgilenmeye çalışan ve bu bilgilerini notlayan bir IT çalışanı perspektifi” ile ele alınacak.

Strava yapısındaki Apache Mesos, Docker ve servisler konusuna yoğunlaşmadan önce bu yapıda hangi teknolojiler kullanılıyor önce bir göz atalım; özellikle de yine olmazsa olmaz yük yönetimi, veri tabanı, hangi bulut teknolojilerini/servislerini kullandığı, geliştirme araçları hakkında bulabildiğimiz bilgileri sıralayalım.  Öncelikle, bu bilgileri toparladığım kaynaklar; firmada çalışan mühendislerin çeşitli Online ortamlarda, bloglarda yaptıkları paylaşımlarından hatta sitenin iş ilanlarında geçen “Requirements” bölümlerinden(!) ve şirketin kendi “Engineering” blogundan yaptığım alıntılardan oluşuyor.  Özellikle de Reddit paylaşımları bu konuda kotarılmayı gerçekten hak ediyor. Genelde aktardığım bilgilerin büyük çoğunluğu kendi yorumlarımı ekleyerek yaptığım ve yazının sonunda kaynak gösterdiğim makalelerdir. İlgili kaynakları yazının sonunda bulabilirsiniz. Ve, son not olarak, bilgilerin hepsi Public ortamlardan elde edilmiş ve  genelde kaynak gösterilmeye özen gösterilmiştir. Herhangi bir illegal bir kaynak durumu mevcut değildir.

Motivasyon,

Bir süredir hakkında araştırmalar yaptığım Apache Mesos mimarisi hakkında öğrendiğim şeyleri buradan aktarmak, bilgi ve fikirlerimi aktarırken kendi kendime yaptığım sessiz beyin fırtınalarına yenilerini eklemek, Docker ekosisteminin en ağır toplarından Apache Mesos’a derinlemesine bakış atarken onun gerçek dünyadaki sayısız implementasyonlarından birisi olan Strava mimarisine atıfta bulunarak hem öğrendiklerimi pekiştirmek, paylaşmak, bilgilere yenilerini eklemek için birkaç saatimi feda etmek gayet mantıklı geliyor. 🙂

Haydi başlayalım,

Kahvemizden bir yudum alıp Strava’yı biraz tanıyalım. Mottosu “Sporcuların sosyal ağı” olan, bu söylemde de oldukça başarılı olduğu görülen, sporcunun tüm aktivitesini,  geçtiği rotaları GPS yardımı ile takip eden, loglayan ve daha sonra da raporlayan bir uygulama. Koşu, bisiklet, triatlon sporlarını yapan amatör/profesyonel bütün sporcuların ortak buluşma ve sosyalleşme ortamıdır. Bana göre, Strava da diğer başarılı girişimler gibi doğru kitleyi hedeflemiş ve o kitlenin gereksinimleri üzerine şekillenmiş bir uygulama. Şirketin “Hakkında” sayfasındaki bir cümle inanılmaz hoşuma gitti; “If you’re striving to improve, no matter your goals or ability, you’re one of us.” Bence genel motto bu olmalı. Aşırı teşvik edici çünkü.

Monolitikten mimariden iş birliği yapan dağıtık servis mimarisine,

Tanım çok mu sıkıcı geldi? Haydi biraz sayısal verilere göz atalım;  Strava Web sitesi ve çeşitli platformlar üzerinde koşan mobil uygulamaları her gün milyonlarca kullanıcıya, aktivitelerinde kullanılmak üzere harita görüntüleri, rotalar ve çeşitli coğrafi içerikler sunuyor.  Bu milyonlarca kullanıcıya her gün binlercesi bu servislerden yararlanmak için eklenir. Strava’ya bağlı 13.800’den fazla ürün Strava API üzerinden Strava sunucuları ile iletişim kurarak bu sunucular üzerinde her 24 saatlik periyot içinde 10.000.000’dan fazla request oluşturur. Devasa rakamlar! Peki bu ürünler neler? Bu ürünler Strava’nın sunduğu servislere API’lar ile haberleşerek kullanıcılara farklı deneyimler sağlar. Bu uygulamalara şu ve bu linklerden göz atabilirsiniz. Bu anlamda Strava tam bir GIS cenneti bana kalırsa. Sözün özü; Strava sunduğu servisleri geliştiricilerin erişimine açarak onların da bu servislere özgü ürünler üretmesini ve yazılımlar geliştirmesini sağlamış. Var olan sunucu yükü yetmezmiş gibi üzerine bu servisleri kullanan uygulamların ürettiği request’ler de eklenmiş. Bakalım bu devasa trafik ve kullanıcı yükü ve bu yükün yönetimi hakkında neler yapılmış.

 

Son birkaç yıldır Strava’da mevcut Server-Side geliştirme yapısı monolitik mimari üzerine yapılanmış Ruby on Rails uygulamadan Scala, Ruby ve golang ile geliştirilmiş  Servis Odaklı Mimari’ye (Service oriented architecture) geçiş yapılmış. Bugün Strava onlarca mühendisin Deploy edip yönettiği yüzün üzerinde servis ile hizmet veriyor. Mühendisler yeni servisleri hızlıca ve sorunsuz olarak Deploy edebiliyorlar. Servis Deploy süreleri dramatik bir şekilde düşmüş durumda. Yaklaşık 30 saniyenin altında bir sürede yedekli ve güvenilir bir yolla servis Deploy edilebiliyor. Servisler rahatça izlenebiliyor ve Log kayıtları tutulabiliyor.

Commits to our monolithic rails app

Yukarıdaki grafikte Strava’nın Monolitik Rails uygulaması halindeyken yapılan commit sayılarının yıllara göre oranı görülmekte. Commit’ler giderek azalmakta, neden acaba? Hemen bakalım,

Total private repositories at Strava

Monolitik uygulamaya yapılan Commitlerin giderecek azalmasının nedeni Mikroservis odaklı mimariye geçiş nedeni ile artan servislere ait Private Repository’ler. Geçişle birlikte servisler ve Repository’ler artmış.

 

Burada biraz soluklanalım ve uygulama mimarilerine bir göz atalım

Bu kısımda biraz Strava odaklı bilgilendirmeden uzaklaşıp, mimarileri detaylandırmaya çalışacağım. Konu biraz dağılabilir ama daha sonra tekrar ara verdiğimiz noktaya geri döneceğiz.

Monolitik Mimari (Monolithic Architecture) ve Mikroservis Mimari (Microservice Architecture ) hakkında biraz konuyu detaylayalım.

Bu iki kavramı açıklarken ortak olarak kullanacağımız bir senaryomuz olsun, bu senaryoda bir server-side kurumsal uygulama geliştirdiğinizi düşünün. Uygulamamıza, masaüstü ve mobil browser’lar dahil olmak üzere çeşitli client ortamlarından erişilmek istenmekte. Uygulama aynı zamanda 3. partiler için de bir API sağlamakta. Uygulama, diğer uygulamalarla web servisleri veya Message Broker‘lar kanalı ile haberleşebilmeli. Uygulama, HTTP istek ve mesajlarını bir iş mantığında işleyebilmeli. Örneğin; veri tabanına erişim, diğer sistemlerle mesaj değişim, HTML/JSON/XML formatında cevap döndürme vs. Fark edeceğiniz gibi uygulamanın çeşitli işlev alanlarına karşılık gelen mantıksal bileşenler mevcut. Tıpkı modern uygulamaların yapısında olduğu gibi. Tamam da, bütün bu yapıyı, mantığı içerecek nasıl bir Deployment mimarisi düzenlenmeli?

Bu yapıda üstesinden gelmemiz gereken adımları inceleyelim,

  • Uygulama üzerinde çalışan büyük bir ekibimiz var ve yeni takım üyesi çok hızlı bir şekilde ortama ayak uydurup hızlıca üretken bir şekilde çalışabilmeli
  • Tasarlanacak uygulama mimarisi kolay, anlaşılabilir ve değiştirilebilir olabilmeli
  • Uygulamanın “Continuous Deployment” süreci sorunsuz bir şekilde yapılmalı.
  • Uygulamanın birçok kopyası birçok farklı sunucuda çalışabilmeli, Scalability, yani ölçekleme ve Availability, yani yüksek erişebilirlik, servisin her durumda ayakta kalması durumu sağlanabilmeli.
  • Uygulama geliştirirken, gelişmekte olan yeni teknolojilere hızlıca adapte olunabilmeli (Framework‘ler, yeni ortaya çıkan modern programlama dilleri gibi.)

 

Monolitik Mimari

Böyle bir senaryoyu Monolitik Mimari (Monolithic Architecture) ile hayata geçirdiğimizi düşünelim.

Uygulamamız muhtemelen bir single Java WAR dosyası veya tek klasör altına hiyerarşik düzenlenmiş Rails veya NodeJS kodlarından oluşabilir.  Örneğin bir alışveriş sitesi geliştirdiğinizi düşünün. Müşterilerden sipariş aldığınız, stokları doğruladığınız, kredi kartı ödeme kabul ettiğiniz ve kargo/sipariş takip hizmetlerini de verebileceğiniz bir site.

DecomposingApplications.011

Image Source: http://microservices.io/patterns/monolithic.html

War dosyamızı hızlıca incelersek, Kullanıcı arabirimi, Kredi kartı ödemelerini kontrol ettiğimiz, siparişleri aldığımız bileşen, stok ve envanter kontrol bileşeni ve kargolama süreçlerini içeren bölüm. Yukarıdaki mimari monolitik olarak deploy edilmiş bir uygulamadır. Uygulamanın Java Web uygulamasıdır ve Tomcat  uygulama sunucusu ile çalışır. Scale ve Availability işlemleri için bu uygulamanın birden çok kopyasını farklı birçok sunucuda çalıştırabilir. Ancak bu durumda en önde istekleri karşılayacak bir Load Balancer uygulaması gereklidir. Bu arada Load Balancer deployment işlemleri için ayrı bir makale yazmayı düşünüyorum.

Monolitik Mimari geleneksel mimari adı ile de anılmakta. Böyle bir mimariyi geliştirmek, test etmek, deploy etmek ve Scale etmek genel anlamda kolay olmakta.

Strava’nın de ilk zamanlar böyle bir mimaride hizmet vermeye çalıştığını ve daha sonra Mikroservis Mimarisine geçtiğini yazmıştım. Bu mimarinin birçok kolaylığı olmasına rağmen alabildiğine de zorlukları mevcut;  uygulamanın code-base dediğimiz temeli oluşturan kodların devasa büyüklüklere ulaşması ve bu kod yığınlarının ekibe yeni katılan birisi için zor anlaşılması. IDE‘lerin bu bu kod yığınlarını işlerken kasım kasım kasılması ve geliştirme ortamlarının yavaşlığı, aşırı büyüyen uygulama boyutu yüzünden uygulamanın zor ayağa kalkması, bunun çok vakit alması, deployment işlemlerinin zorluğu gibi.Bu yüzden bir yerden sonra şirket Mikroservis mimarisine geçiş kararı almış. Scale etmek güzel bir çözüm ama bir yerden sonra o da çözüm olmaktan çıkıyor. Çoğu Cloud Provider yük artışlarında dinamik olarak uygulamayı Scale edebiliyor ama diğer taraftan artan data volume bu mimaride Scale edilemiyor. Üretilen her instance kopya uygulama dataya erişim sağlar ve Cache mimarisinin verimsiz çalışmasına neden olur. En büyük sıkıntılardan biri de uygulamanın her komponenti’nin CPU/IO/RAM gereksinimi farklıdır. Monolitik mimaride bu komponentler bağımsız olarak Scale edilemez.

 

Mikroservis Mimarisi

Strava’nın neden Mikroservis Mimarisine geçiş yaptığını inceleyelim. Az önce bahsettiğim senaryonun ile geliştirildiğini düşünün. Şekle bakalım,

Microservice_Architecture

Image Source: http://microservices.io/patterns/microservices.html

Sunulan her fonksiyon ve hizmet için ayrı bir servis geliştirilir. Bu servisler birbirleri sürekli haberleşir. İşler küçük parçalara bölünerek yapılır. Dağıtık bir yapıdır. Her servis birbiri ile HTTP/REST gibi senkron protokollerle veya AMQP gibi asenkron protokollerle iletişim kurar. En önemli özellik, servisler birbirlerinden bağımsız bir şekilde geliştirilebilir, deploy edilebilir, konuşlandırılabilir. Her servis kendi veri tabanına sahip olabilir.

Mikroservis mimarisinin artı ve eksilerinden de bahsettikten sonra Strava Infra’sındaki yolculuğumuza devam edelim.

Mikroservis mimarisinde her servis görece olarak daha küçüktür. Böylece, geliştiriciler kodu daha iyi anlayabilir, IDE daha hızlı çalışır ve geliştirici daha üretkendir. Uygulama daha hızlı ayağa kalkar ve deploy edilir. Her servis bağımsız geliştirilebilir. Diğer servislerden bağımsız bir şekilde ilgili servisin yeni versiyonu sıklıkla deploy edilebilir. Uygulamanın gelişirilmesi daha kolay ölçeklenebilir. Geliştirme takımları daha verimli organize edilebilir. Her takıma ilgili servisin sorumluluğu verilebilir. Takım sadece kendi servisini bağımsız bir şekilde geliştirebilir, deploy edebilir ve hatta scale bile edebilir.

Mikroservis mimarisinde önemli kriterlerden birisi de hata izolasyonudur. Bu şu demek; örneğin servislerden birinde bir memory leak yani yanlış bir hafıza yönetimi mevcut. RAM’in tıkanmasına neden oluyor. Böyle bir durum monolitik yapıda olsaydı bütün hizmetleri etkileyen ve servisin tamamının kesintisiyle sonuçlanacak bir durum ortaya çıkardı. Mikroservis mimarisinde sadece ilgili servis Down olacak ve verilen diğer servisler çalışmaya devam edecekti.

Mikroservis mimarisinde ziyadesi ile önemli bir konu da, “long-term technology stack” dediğimiz durumu elimine etmesi. Bunu da örnekleyerek konuyu tekrar Strava yapısında kaldığımız yerden devam ettirelim. Çünkü biz oldukça bir koptuk sanki durumdan. 🙂

Mikroservis yapısı geliştiriciye yeni teknolojileri deneme fikri sunar. Her servis farklı teknoloji ile geliştirilebilir. Geliştirici, servisi hangi teknoloji ile geliştirmek istiyorsa, servise hangi teknoloji daha uygunsa yola onunla devam edilebilir.

Peki bu yapının eksileri yok mu? Elbette var, ama bu konuda daha fazla detay almak için şu link gayet açıklayıcı.

Geliştirme araçları ve Cloud ortamı

Strava’nın çoğu Infra’sı AWS üzerinde. Gündemi takip edenler hatırlayacaktır, geçenlerde ciddi bir AWS outage durumu oldu. Hizmet kesintisi yaşayan uygulamalardan birisiydi Strava.

str

iOS geliştirme tarafında önce çıkan araçlar CocoaTouchxcodebuild fastlane ve CocoaPods

CocoaPods, Ruby ile oluşturulmuş, Swift ve Objective-C için bir dependency (bağımlılık) yöneticisi. İçinde otuz bin üzeri kütüphaneye sahip ve 1.9 milyon uygulamada kullanılmış. Arkasında ciddi bir destekçi kitlesi mevcut. CocoaTouch ise iOS üzerinde çalıştırılabilir uygulama inşa etmek için kullanılan bir Framework. CocoaTouch iOS üzerinde bulunan soyut bir katmandır da diyebiliriz. Bu Framework bir dizi grafik kontrol elemanları içerir. Objective-C dilinde yazılmış. fastlane  ise iOS ve Android geliştiricileri için birçok can sıkıcı işi otomatize bir şekilde hallediyor. Özellikle de uygulama Release  işlemleri sırasında ortaya çıkan bir çok görevin üstesinden geliyor; örneğin ekran görüntüsü oluşturma, kod imzalama, uygulama Release etme gibi.

Scala, Java, Ruby, Ruby on Rails ve özellikle Python ise diğer geliştirme araçları. İlişkisel veri depoları MySQL ve PostgreSQL‘in yanında NoSQL veri depoları da kullanılmakta; Redis ve Cassandra. Redis; açık kaynaklı bir in-memory key-value veri deposu. Veri tabanı ve ön bellek olarak kullanılmakta. Çoğu zaman Redis bir cache mekanizması olarak karşımıza çıksa da aslında Cache’den daha fazlası. Redis key=value şeklinde veri saklar. Bir Cache’in aksine Redis bu key ve value’ler üzerinde çalışmanıza olanak sağlar.

Test işlemleri için; XCTest ve JUnit kullanılıyor. Kif for iOS, Espresso, Robolectric for Android diğer test araçları.

Bitrise ve Jenkins,  Continuous Integration ve Continuous Delivery araçları olarak firma içinde DevOps kültürüne hizmet etmekte. Proje geliştirme yaklaşımı olarak da Agile ön planda.

 

Apache Mesos

Strava, Apache Mesos ve Docker‘ı etkin olarak kullanan girişimlerden. Mesos’a geçiş aslında öyle kolay olmamış. Hatta karar vermek bile kolay olmamış. Mesos’un sahip olduğu bir çok somut konsept ve sağlayacağı fayda küçük bir işletme için fazla gelebilir diye düşünmüşler öncesinde. Ama şu an Mesos gerçek anlamda Strava’da Production ortamında kullanılmakta.

Apache Mesos ile birlikte kullanılan Framework’ler ise şöyle;

  • Marathon, “Long-running” dediğimiz görevleri koşturmak için kullanılır.
  • Storm, gerçek zamanlı bir akış hesaplama Framework’ü
  • Spark, dağıtık olarak çalışabilen bir data işleme Framework’ü.

Strava mühendisleri Long-Running işlemler için önce Aurora seçilmiş ama mevcut ihtiyaçlar için oldukça karmaşık gelmiş. Daha sonra Marathon’da karar kılmışlar. Bence iyi de yapmışlar. Birazdan detaylı bir şekilde Marathon’a değineceğim.

Strava neden Mesos, Marathon ve Docker’a ihtiyaç duydu?

Aslında servisleri Mesos ile deploy etmek çok gerekli bir durum değildi diyor Drew Robb ve devam ediyor, “Ama şöyle de bir gerçek var, sağladığı faydalar yadsınamaz.” En azından Mesos Servis odaklı mimaride çoğu sorunu elimine ediyor.

Peki nedir bu faydalar?

Strava‘nın Mesos öncesi yapılanmasında  servisin deploy edilmesi çok can sıkıcı ve istenenden uzak bir haldeymiş. Çok uzun ayağa kaldırma süreçleri, adımların manuel bir şekilde kontolü işleri oldukça yavaşlatıyormuş.  Her yeni mühendisin kendi sorumluluğundaki bir servisi geliştirmesi ve dokümante etmesi oldukça zormuş. Genelde bu işlemler şu adımlarla ilerliyormuş;

  • Bir Debian (.deb) paketinin build edilmesi
  • Bu paketin Apt server’a Pusj edilmesi (1 dk)
  • Apt sunucunun paketi hazır hale getirmesi (5 dk)
  • Build işlemleri
    • Yeni bir AWS instance’ın boot olmasının beklenmesi (1-2 dk.)
    • Instance üzerinde Puppet çalıştırılması ve .deb paketinin kurulumu (2-5 dk)
    • Instance’ın bir AMI imajına dönüştürülmesi (2-3 dk)
  • Yeni AMI imajını kullanan bir instance’ın boot olması işlemi (1-2 dk)
  • Eski AWS instance’ının kaldırılması

Her single manuel deploy işlemi bu şekilde toplamda yaklaşık 30 dakika kadar sürüyor ve herhangi bir aksaklık yaşanmadığı sürece tabii.

Hızlı Deploy çevrimi Servis odaklı mimari için kritik bir bileşendir. Çok fazla servis demek çok fazla Deployment anlamına geliyor ve deployment süreleri için hiç kimse vakit kaybetmemeli.

Haydi bir şeyleri otomatize edelim,

Strava’da Mesos/Marathon/Docker ile oluşturula deployment ortamı şu şekilde;

  • Docker image lokalde veya CI yardımı ile  Build sonrası hızlıca Push edilir. (< 1dk)
  • Marathon ile bu image deploy edilir. (~1 dk-) Rolling Restart‘lar ile birlikte.

Genel olarak basit bir servisin deploy edilmesi ideal koşullar altında 20 saniye kadar sürmekte Strava’da. Eskiden yaşanan manuel takip edilen adımlar artık yerini otomatize bir Pipeline‘a bırakmış durumda.

Birden çok servisin hızlı bir şekilde deploy edilmesine olanak sağlayan Mesos ve Marathon aynı zamanda yazılımın test ve optimizasyon maliyelerini de düşürmekte. Geliştiriciler tek bir değişiklikte bile kolayca deploy işlemini yapabilir böyle hataların kaynağına daha hızlı bir şekilde ulaşabilirler.

Docker ile daha kolay build işlemleri,

Docker’ın Strava’da kullanılması ile muazzam faydalara ulaşılmış. Öncesinde build işlemleri gerçek AWS instance’lar üzerinde zahmetli bir şekilde yapılırken artık geliştiriciler kendi lokal ortamlarında bu işlemleri kolayca yapabilmekteler. Lokal ile production ortamını arasındaki fark çok az.

Servisler her zaman temiz Docker image dosyaları ile restart edilir. Bir servis yeniden başladığında herhangi bir veri kaybı endişesi duyulmaz. Merkezi olarak olan biten her durumun kaydı loglanır.

Altyapının basitliği,

Strava’da bütün Mesos görevleri aynı konfigürasyonlara sahip sunucu havuzu üzerinde koşmakta. Daha önce altyapının AWS üzerinde olduğundan bahsetmiştik. AWS instance’ların seçimi faturaları ödemek kadar kolay. Öncesinde, her servis için ayrı özelliklerde AWS instance ihtiyacı mevutmuş, bu sunucuları planlamak, ihtiyacın ne olduğuna karar vermek çok zaman alıyormuş. Ama artık Mesos ile tek tip sunucular üzerinde koşan farklı servisler var.

Mesos ile elde edilen faydalardan biri de kaynak verimliliği. Strava’da bir çok servisin çalışması için çok az kaynak yeterli gelmekte ama bununla birlikte en önemli durum ise yüksek erişilebilirlik. Kesintinin olmaması durumu. Örneğin Strava Authorization servisi her web isteğinde erişilebilir durumda olmalıdır. Bu servise gelen istek sayısı yaklaşık 1000 QPS kadardır. Bu servis sadece 1 Core CPU tüketmektedir. Böylesine kritik bir servisi Strava mühendisleri Mesos/Marathon ile 3 ayrı instance olarak Scale etmiş. Her instance ayrı Mesos Agent üzerinde çalıştırmışlar. Hem yedeklilik durumu hem de tek bir full CPU core yerine yükün dağıtılması sağlanmış.

 

Peki  nedir Apache Mesos? Genel bir bakış atalım,

mesos-logo

 

Apache Mesos aslında soyut bir katmandır. Linux Kernel ile aynı kurallarla çalışır. Bir cluster manager yazılımıdır. Cluster haldeki sunucular üzerinde kaynak yönetimi yapar. Cluster’lar üzerinde dağıtık uygulamalar ve Mesos için  yazılmış Framework’leri çalıştırır.  Çalışma mantığı Linux kernel ile aynıdır. Linux Kernel donanım katmanında tek bir sunucuyu kontrol ederken Mesos ise Cluster’a üye olan yüzlerce sunucuyu kullanabilir. Bütün bir data center’ın tek bir kaynak havuzuymuş gibi kullanılmasına olanak sağlar.

Şu görsel ile durumu biraz daha pekiştirebilirsiniz.

mesos22

Konuyu biraz derinleştirelim ve Kernel mantığını biraz daha detaylayalım,

Evet, Mesos dağıtık bir Kernel’dır. Mesos Kernel Cluster’a üye olan bütün sunucular üzerinde çalışır ve bu sunucular üzerinde kaynak yönetimi ve scheduling işlemlerini yönetir. Teknik olarak 10.000 node üzerinde Scale testi yapılmış ve sağlamlığı doğrulanmıştır. Native olarak Docker Container desteği vardır. CPU/RAM/DISK/PORT/GPU ve modüller için sağlam bir izolasyon sunar. HTTP API sunarak Cluster üzerinde  yen dağıtık uygulamalar geliştirmeye zemin sağlar. Web üzerinden UI sağlayarak Cluster durumunu izleyebilir, çalışan Container’ları monitör edebilir.

 

Mimariyi parçalara ayırıp inceleyelim,

Apache Mesos’un mimarisi bir çok bileşenden oluşan “fine-grained” yani diğer bir deyişle “Modülerize bir mimari.  Mimari de 3 ana component bulunmakta.

  1. Mesos Master
  2. Mesos Slave
  3. Framework

mesosmasterquorum-al-150324-w1024_1x

Image Source: https://www.antonlindstrom.com/2015/03/29/introduction-to-apache-mesos.html

 

Master’lar ve Slave’ler.

Bu bileşenler test amaçlı tek bir sunucu üzerinde de çalıştırılabilir. Ama önerilen En az 3 ayrı sunucuya Mesos Master ve Framework‘lerin kurulumu. Geride kalan n tane sunucuyu ise Slave yani köle modda çalıştırmak.

Mesos Master: Mimarinin tam ortasında bulunan master,  Slave ‘leri yani köle sunucuları yönetir ve koordine eder. Mesos Master makine üzerinde  Apache Mesos, Marathon  (veya farklı bir framework) ve Apache ZooKeeper  çalışır.

High Availability için Master sayısını arttırabiliriz ancak mimaride aynı anda sadece tek bir master aktif rol alır.  Master’lar arasındaki bu koordinasyonu Zookeeper yapar. Master problem yaşayınca Zookeper, Quorum algoritmasını kullanarak lideri yani hizmet verecek yeni master’ı seçer.

Her yerde karşımıza çıkan Zookeeper burada da aktif bir oyuncu,

Zookeeper: Bir Apache projesi. Distributed edilmiş sistemler arasındaki koordinasyonu yönetmeye yarıyor. Resmi tanımı biraz ilginç, distribute edilmiş, yani cluster’a  yayılmış uygulamalar için bir distribute koordinasyon servisi. Mimarimizde Mesos master’ların yönetiminden sorumlu. (Belki bir gün onun kendi mimarisi ile ilgili bir makale yazabilirim. Çünkü koordinasyon gerektiren çoğu açık kaynak dağıtık yazılımın arkasında Zookeeper mevcut.)

Master, Slave node’lar ile birlikte çalışır ve her bir slave node üzerinde bulunan raporlanmış “available” yani boştaki kaynak bilgisini toplar. Her slave node güncel bir şekilde üzerindeki boştaki kaynağı Master’a rapor eder.  Master ise bu boştaki kaynak bilgilerini Framework ile paylaşır. Framework ise bu kaynakları, üzerinde çalışan uygulamanın ihtiyaçlarına göre ya kabul eder, ya da red eder. Kaynaklar Framework tarafından her kabul edilişinde Mesos Master  simultane bir şekilde hem kaynak paylaşımı, hem de slave’ler üzerindeki Task Scheduling işlemlerini koordine eder.

Mesos Slave: Mesos mimarisinin temel komponentlerinden bir diğeri de Slave node’lardır. Üzerinde proseslerin çalıştırılır.  Slave’ler boştaki sistem kaynaklarını sürekli olarak Master’a sürekli raporlarlar.  Gerçekte bir daemon’dur. Slave node’lar fiziksel veya virtual olabilirler.

Mesos Frameworks: Apache Mesos yapısı üzerine geliştirilmiş distributed uygulamalardır. Bir framework  Mesos Master’ın sunduğu “Offer”ların yani boş Slave sistem kaynaklarının schedule edilmesinden sorumludur.  Bu kaynakları ihtiyaca göre ya kabul eder ya da red eder.  Frameworkler aynı zamanda Slave’ler üzerinde task ve komut çalıştırmaktan da sorumludur.

Bilinen en yaygın Mesos Framework’leri:  Apache Spark, Mesosphere Marathon, Apache Hadoop, Apache Storm, Elasticsearch, Cassandra ‘dır. Diğer Framework listesine bu linkten ulaşabilirsiniz.

Mesos Framework yapı olarak 2 ana komponentten oluşur.  Bir “Scheduler” ve bir de “Executor”.

Framework Scheduler: Mesos Master tarafından gönderilen boştaki Slave sistem kaynaklarının kaydını tutar.  Master tarafından gönderilen tüm Offer bilgileri burada tutulur.

Framework Executor: Slave node üzerinde bulunan bir daemon’dur.  Framework’ün atayacağı taskleri çalıştırır.

 

Peki,  cluster ortamında iş akışı nasıl sağlanır, hemen bakalım,

Yukarıdaki mimariyi anlatan görseldeki iş akışı adım adım şu şekilde gerçekleşir.

  • “Mesos Slave 1”  üzerindeki mevcut boşta duran kaynak miktarlarını Mesos Master’a raporlar.  Hey, Master!”4GB Ram, 4 CPU is free!”
  • Mesos Master aldığı bilgileri Mesos Framework’e kabul edilmesi veya red edilmesi için sunar. Bu işleme “Offer” denir.
  • Eğer Framework bu Offer’ı kabul ederse,  Mesos Master’a, Mesos Cluster üzerinde çalıştırılmak istenen task listelerini yollar.
  • Task listeleri  Mesos Master tarafından acilen üzerinde Framework Executor çalıştıran Slave Node’lara çalıştırılmak üzere gönderilir.  Slave’ler task süreçleri ve  kalan kaynak bilgilerini sürekli Master’a raporlar.

Biliyorum, artık sıkıldınız. Ama son olarak Marathon’dan bahsetmeden olmaz. Marathon önemli bir Framework ve anlatılmalı. Son olarak Marathon’u anlatıp, bir de Strava’nın neden Mesos ve Marathon ikilisine ihtiyaç duyduğunu ve bu ikilinin yapıdaki görevinin neler olduğunu anlatıp yazıyı sonlandırayım.

 

Marathon Framework’ü tanımlayalım,

Mesosphere Marathon‘un ne işe yaradığından bahsetmeden önce ufak bir Linux bilgisi verelim;  İlk şekle bakacak olursak, klasik bir UNIX/LINUX mimarisi en kaba tabiri ile Kernel, Init System, ve en tepede de Application‘lardan oluşur.

marathon-init

Kernel sistemin çekirdeğidir. Cpu kontrolü, yazılımların donanımlarla  iletişimi,  I/O kontrolü vs. core işlemleri yapar.

 

Init, her şeyin bağladığı yer!

Init, bütün süreçlerin anasıdır diyebiliriz. Sistem boot olduğunda ilk ayağa kalkan Process’in adı init’dir. PID numarası her zaman 1’dir.  Sistemdeki tüm süreç veya prosesler direkt veya endirekt init ile ilişkilidir. Systemd Linux’un yeni nesil sistem ve servis yöneticisidir.  Upstart ise Init sistemin ubuntu versiyonudur. Bu da sistem ve servislerden sorumludur.Uygulamalar ise Init sistemin üzerinde çalışır.  Init sistemler uygulamalar için servis ve proses yönetimi yaparlar.

Şimdi de Mesos-Marathon yapısına bakalım,

mesos-stack.png

Görüleceği üzere, INIT katmanının yerini Marathon almış durumda. Her Linux sistemde bir kernel olduğu aşikar, Apache Mesos’un dağıtık bir sistemler için bir  kernel katmanı  olduğundan bahsetmiştik.  Marathon ise Mesos üzerindeki bi dağıtık bir init veya upstart sistem gibi çalışır. Bu şu anlama gelir; onlarca node’luk clusterlar üzerindeki Mesos kerneli üzerinde herhangi bir Linux uygulamasını -hiçbir modifikasyona gerek kalmadan- çalıştırabilir. Mesosphere Marathon, bize üzerinde uygulama çalıştırabilmek, durdurabilmek veya scale edebilmek için bir REST API sunar.

Son sözler,

Haydi durumu biraz toparlayalım, Apache Mesos ile Data center boyunca bütün sunucular tek bir sunucuymuş gibi bir davranış gösterir. Geliştirilen yazılımlar tek bilgisayar odaklı değil Mesos’un üzerine yayıldığı cluster katmanı üzerinde dağıtık bir şekilde çalışır. Twitter ve Paypal başta olmak üzere sayısız firmada ciddi yükler altında çalışmaktadır.

mesos-use

Marathon ise Mesos üzerinde koşan bir Framework. Amacı ise yönetim işlerini basitleştirmek, yazılım ve donanım tabanlı hataları tolere edip HA yani High Availability sağlamak,  cluster kaynaklarının (RAM/CPU/HDD/Port) daha verimli kullanılmasını sağlamak ve tüm bunları yönetirken de geliştiricilere API sunarak bu yapıya farklı ortamlardan direkt erişim sağlayıp amaca göre Cluster kaynaklarını kullandırmak.

Her ne kadar yazıyı kısa tutmaya çalışsam da laf lafı açtı sanırım yine. 🙂 Sabrınız ve anlayışınız için teşekkürler.

 

Hakan ORCAN

 

 

Kaynaklar:

http://labs.strava.com/blog/mesos/

https://www.mulesoft.com/resources/api/microservices-vs-monolithic

http://blog.strava.com/powered-by-strava-apps-12402/?__prclt=JgX6PhCn

http://microservices.io/patterns/microservices.html

http://microservices.io/patterns/monolithic.html

https://www.agilealliance.org/glossary/continuous-deployment/

http://www.esri.com/what-is-gis

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s