Akış mimarileri: Örnek olay incelemesi
Akış mimarilerinin nasıl değişip geliştiğini gördüğümüze göre şimdi tek bir belirli çerçeve olarak Apache Samza’ya göz atalım.
Apache Samza
Samza projesi, LinkedIn’de dağıtılmış akış işleme çerçevesi olarak geliştirilmiştir. Bu proje, durum bilgisi olan veya durum bilgisi olmayan işleme temelinde iletilerin giriş akışını, değiştirilmiş bir çıkış akışına dönüştürür. Samza, düşük gecikme süreli dağıtılmış bir mesajlaşma sistemi olan Kafka (daha önce ele alınmıştır) ile birlikte geliştirilmiştir. Samza, bu Kafka iletilerinin gerçek zamanlı işlenmesine olanak sağlamıştır.
Samza üç katmana ayrılır:
- Bölümlenmiş, çoğaltılmış ve dayanıklı akışlar sağlayan bir akış katmanı
- Küme üzerinde görevleri zamanlayan ve koordine eden bir yürütme katmanı
- Giriş akışını dönüştürüp yeni bir çıkış akışı oluşturan, veritabanlarını değiştiren, olayları tetikleyen ve genellikle giriş iletilerine tepki veren bir işleme katmanı
Şekil 9: Samza uygulamasının üç katmanı
Akış ve yürütme katmanları takılabilir. Varsayılan bir uygulama, akış ileti aracısı olarak Kafka’yı kullanır. Giriş ve çıkış akışları, düğümler arasında bölümlenebilen sabit ileti dizileridir. Bir bölüm içinde iletiler genel olarak sıralanır ve akış içindeki ofset tarafından benzersiz şekilde tanımlanabilir. Varsayılan yürütme katmanı, YARN’ı kullanır ancak kullanılabilecek başka bir genel kaynak yöneticisi de Mesos’dur. YARN kullanılması, Samza uygulamasının hataya dayanıklılık sağlamasını, dağıtımı kolaylaştırmasını ve yerleşik günlük kaydı ve kaynak yalıtımı özelliklerini kullanmasını kolaylaştırır. HDFS ile YARN kullanılması, Samza’nın veri yerelliğinden yararlanmasına da olanak sağlar.
Samza ayrıca tek bir işte bir veya birden çok görev yürütmek için JVM’leri çalıştıran tek çekirdekli kapsayıcıları işlemek için cgroups’u da kullanır. Cgroups, bir işlem koleksiyonunun CPU, bellek ve dosya sistemi üzerinde bir kolektif sınırının olmasını sağlayan Linux çekirdeği özelliğidir. Herhangi bir anda bir kapsayıcı içindeki yalnızca tek bir görevin yürütüldüğü dikkate alındığında, Samza’da her bir kapsayıcı, bir ileti işlenirken tek bir iş parçacığı olarak mantıksal şekilde yürütülür. İşlem, Samza API’si kullanılarak yazılan özel kod tarafından gerçekleştirilir.
Daha fazla paralellik elde etmek için Samza daha fazla kapsayıcı üretir. Bu nedenle geliştiricilerin, iş kodu içinde çoklu iş parçacığı kullanımından yararlanması önerilmez. Samza, iletişim ve işleme için dahili olarak birden çok iş parçacığı kullanır; ancak tek bir iş parçacığı, ileti G/Ç’sini, denetim noktası oluşturmayı, pencerelemeyi ve ölçümlerin temizlenmesini işleyen bir olay döngüsü olarak çalıştırılır.
Şekil 10: Samza işinde giriş ve çıkış akışları
Samza istemcileri, Samza işlerini YARN’da başlatır. Samza’nın YARN Kaynak Yöneticisi (RM) ile kaynaklar için anlaşma yapan kendi Uygulama Ana Kaydı vardır. YARN Kaynak Yöneticisi, bir Samza uygulamasına kaynaklar ayırmak için çeşitli Düğüm Yöneticileri ile konuşur. YARN, Samza StreamTask API’sini uygulayan özel kodu çalıştıran SamzaContainers (Görev Çalıştırıcıları) üretir. Bunlar genellikle veri yerelliğini en üst düzeye çıkarmak için Kafka aracıları için kapsayıcılarla birlikte bulunur.
Şekil 11: Samza işi, bir kapsayıcı içinde gruplanabilen görevlere ayrılmıştır. Her kapsayıcı için yalnızca bir iş parçacığı bulunduğundan, herhangi bir anda yalnızca bir görev etkindir.
Samza, performans iyileştirmeleri için yatay ölçeklendirmeyi kullanır. Bir iş içindeki görev sayısı artırılarak bu gerçekleştirilir. Her görev, işin giriş akışlarındaki tek bir bölümde çalışır. Bu nedenle, daha fazla paralel görev çalıştırabilmek için bir akışın daha çok sayıda bölüme ayrılması gerekir. Kafka ile ilgili önceki bir konuda bu açıklanmıştır. Her bir giriş konusu için, her bir bölüme yönelik başlatılmış en az bir StreamTask örneği vardır. Her bir akış görevi, tek bir bölümü bağımsız olarak işler.
Şekil 12: Samza uygulamaları yalıtılmış kapsayıcılarda YARN üzerinde çalışır
Elbette yukarıda gösterilen akış örneği, gelen bir akışı çıkışa dönüştürür. Herhangi bir giriş iletisinde gerçekleştirilen hesaplamanın diğer tüm iletilerden bağımsız olduğu birçok akış işleme uygulaması vardır. Örnekler arasında, basit zamana dayalı değişiklikler veya kuralları temel alan veri filtreleme yer alır.
Ancak akış işleme için daha ilginç olan kullanım örneklerinde, birden çok akışın bağlanması, ileti toplamanın gerçekleştirilmesi veya bir veri zaman penceresine göre karar alınması gerekir. Bu senaryoların tümünde durum bilgilerinin depolanması gerekir. Samza, KeyValueStore soyutlamasını kullanarak dayanıklılık uygular. Her bir StreamTask örneği, durum bilgilerini aynı makinedeki ayrı bir ekli veri deposunda depolar. Varsayılan olarak Samza, düşük gecikme süresi ve yüksek aktarım hızı sağlayan ve yazma açısından iyileştirilmiş olan RocksDB’yi kullanır. Ekli bir veritabanı kullanıldığında, verileri sorgulamak için pahalı ağ çağrılarını kullanma yükü azalır.
Şekil 13: Ekli veri deposu kullanarak görevin yerel durumunun dayanıklılığını sağlama
Bu uygulama, uzak bir veritabanının parçalanması ve her bir parçanın benzersiz bir veri bölümüyle birlikte konumlandırılması olarak düşünülebilir. Hataların durum bilgisi kaybına yol açmamasını sağlamak için yerel bir veritabanı üzerinde yapılan tüm değişiklikler, ayrı bir değişiklik günlüğü akışı kullanılarak yayınlanır; bu ayrı bir Kafka konusu olarak sunulmaktadır. Değişiklik günlüğündeki veri miktarını azaltmak için ayrı bir arka plan işlemi, günlük sıkıştırma işlemi çalıştırır.
Şekil 14: Her yerel eklenmiş veritabanı bir değişiklik günlüğü çıkış akışına yazar
Bu nedenle, kendi veritabanı olan yeni bir kapsayıcı başlatılıp başka bir paralel değişiklik günlüğü akışına yazılarak kolayca görevlerin kapsamı genişletilebilir. Herhangi bir hata olması durumunda, başarısız olan bölümün çıkış değişiklik günlüğünden kullanım gerçekleştirilerek yeni bir kapsayıcı başlatılabilir ve tutarlı bir duruma geri yüklenebilir.
Şekil 15: Samza'da hata kurtarma