Ağ Yazılım Mimarisi – Ortaya Çıkan Kavramlar ve Yaklaşımlar

Bulutta Yerel Uygulama

Bu, uygulamanızın her biri bağımlılıkları olan mikro hizmetler olarak ayrılması, belirli bir kapsayıcı düzenleme sisteminde çalışan kapsayıcılar içinde paketlenmesi için bir yaklaşımdır. Ayrıntılı olarak, dikkate alınması gereken farklı hususlar vardır:

• Mikro hizmet: Uygulamanız artık bir hizmet koleksiyonunun (mimari açıdan mikro hizmetler olan) işbirliği ile oluşturulmuştur. Ekibinizin içinde hizmetlerin tanımlanması, bunları uygulama stratejisi, bunların nereye dağıtılacağı hakkında tartışmalar olacaktır. Tasarım aşamasında baştan aklınıza gelebilecek bazı sorular, “hey, bu bir hizmet olabilir, ancak işlevi artık basit olduğu için, onu XYZ hizmetiyle bir araya getirip daha sonra ayırabilir miyiz?” Veya ” tüm hizmetler için aynı veritabanını kullanıyoruz veya her birinin kendi veritabanına sahip olmalıyız? “veya” günlüklere ne dersiniz, tüm günlükleri DB’mize mi kaydetmeliyiz yoksa yalnızca ABC sistemine aktarmalı mıyız? ” (genellikle bu, diğer ekibin, örneğin sorunu izlemek, uygulamanızın iyi kodlanmış olup olmadığını, tek hata mı yoksa veya birden fazla hata olup olmadığını değerlendirmek için yönettiği sistemdir) vb. Bu arada, mikro hizmetten bahsederken, API’lerden bahsetmemiz gerekiyor, örneğin API’lerin formatı, kimlik doğrulama, API sürümü.

• İzleme (telemetri ve raporlama): Bir hizmet hatası, tüm uygulamanızı çökertebilir. İnanması zor ama son kullanıcılarınızdan gelen tüm talepler için giriş noktası olan ağ geçidi çalışmıyorsa? 🙂 Sistemimizde herhangi bir anormal şey olup olmadığını bize bildiren bir hizmete ihtiyacımız var. Aklınızdaki ilk şey günlüğe kaydetmektir. Elbette günlük verilerine dayanan, Fluentd, LogStash, Kafka’dan (evet, Apache Kafka) CloudWatch, Prometheus ve Grafana’ya kadar başka kullanabileceğimiz araçlar da var. Bahsedilen tüm araçlarla birlikte Kubernetes üzerinde bir mikro hizmet olarak bir “Merhaba Dünya” örneği dağıtabilirseniz, artık işin üstesinden gelebilirsiniz.

• Esneklik: Kaos Mühendisliği ve Kaos Maymunu hakkında bir şeyler duydunuz mu? Bir hizmetin ne zaman / nasıl / nerede başarısız olabileceğini bilmek imkansız olsa da bununla başa çıkabilmek mümkün. Nasıl mı ? tüm hizmetler, diğer hizmetlerden gelen girdilerinin beklediği gibi değilse, örneğin; yanlış format, gecikme ve istek zaman aşımı gibi durumlarla başa çıkabilmeye esneklik diyoruz.

Ağ Otomasyonu

Diyelim ki şu anda iyi çalışan bir ağınız var. Zamanın birinde bazı sorunlar yaşanabilir. Dolayısıyla, ağ otomasyonu, ağınızın gelecekte siz dokunmadan stabil çalışmasını sağlayan bir işlemdir. Ağ Otomasyonu uygulamasının tüm yönlerini aşağıdaki gibi özetlemek gerekirse:

• Amaca Dayalı Ağ Oluşturma: Mimar bakış açısından, düşük seviyeli ağ cihazlarının komutları hakkında hiçbir fikriniz yoksa, IBN devreye girer. Ayrıntılı olarak anlatmak gerekirse, yalnızca ne istediğinizi (amacınızı) söylemeniz gerekir ve bunu gerçekleştirecek bazı araçlar yardımınıza koşacaktır. Bu araçlar ile doğru planlar yapıp, ağ aygıtlarınızında syntax kapasitesine yardımcı olmalıdır.

• API ve Veri Modeli: Mühendis perspektifinden, ilki size amacınızı belirlemek ve belirlediğiniz amaçtan beklediğinizi almak için bir araç sağlarken. İkincisi amacınızın sonucunu temsil ettiğiniz yoldur. Başka bir deyişle, ağ cihazlarını anlamanız ve API’ler aracılığıyla kendinizi cihazlar tarafından anlaşılabilir kılmanız gerekir, yani REST, RESTCONF, NETCONF ve veri modelleri.

• Ağ İzleme: Ağınızda yanlış bir şey olup olmadığını nasıl bileceğiniz sorusuna cevap vermek içindir. SNMP (IP ağı için) kullanarak bir ağı izleyebilmeniz gerekir. Aynı görevi yapan çeşitli özel protokoller olduğunu unutmayın. Sadece IP ağları değil, aynı zamanda optik ağların izlenmesine de ihtiyaç vardır.

• Veri Analitiği: Analiz oluşturma süreci için yararlı girdileri ayırt etmek ve toplanan verileri analiz edebilmek. İşte bu verileri elde etmek için Elastic Stack (ElasticSearch, Kibana, LogStash) araçları kadrajımıza giriyor 🙂

• Otomasyon Frameworkleri: Ansible, en popüler altyapı otomasyon frameworküdür. Ayrıca Chef, Puppet, SaltStack gibi diğer araçları da kullanabilirsiniz.

• Native Bulut: Ağ Otomasyonu sürecini kesintisiz bir hale getirmek için ve ağı daha üst düzey mecralara taşımak için native ortama çekmemiz gerekir. Bunun için Ağ hizmetleri bulut tabanlı bir yaklaşımla dağıtmak, hem güvenlik hem de kesintisiz bir hizmet için hayati önem taşımaktadır.

Sunucusuz Mimari

Diyelim ki A1 (MySQL sunucusu), A2 (yük dengeleyici), A3 (güvenlik duvarı), A4 (HTTP sunucusu) gibi farklı özelliklerden oluşan bir A (web sitesi) uygulamanız var, hepsini aynı şekilde birbirine bağlı halde yayınlamamız gerekiyor. Fiziksel sunucunuzda (fiziksel, sanal, kapsayıcı, her neyse) veya bulut tabanlı dağıtılmış bir şekilde uygulamanızı haberleştirebilirsiniz. Bunun size maliyeti yüksek olacaktır fakat güvenlik ve performans açısından uygulamanızın daha kararlı bir şekilde çalışmasını ve hizmet vermesini sağlayacaktır.

Sunucusuz işleminizi biraz daha ayrıntılı bir şekilde açacak olursak:

• Olaya Dayalı Hesaplama, Hizmet Olarak İşlev Sunma: Bu işlev de Mikro hizmet mimarisinin temel felsefesini kullanırsınız. Başka bir deyişle başkalarının kullanması için çeşitli işlevlere sahip bir sistem üzerine inşa edilmiş bir sistemdir.

Kafamız biraz karıştı gibi hemen sizlere yukarıda bahsettiklerimi, şekiller ile açıklayayım:

Servis Ağı

Mikro hizmet mimarisinde, hizmetlerin sayısı arttıkça, bir bileşik uygulamanın, hizmet sağlığının izlenmesi, arızaların ele alınması, kimlik doğrulama işlemleri ve daha fazlası için aralarındaki karmaşık etkileşimlerle haberleşmesi gerekir. Hizmet ağı, hizmetler arası iletişimi yöneten bir uygulama altyapısı katmanına sahip olmak için bir çözüm olarak gelir; örneğin, bu katman, uygulamanızın veya mikro hizmetin kendileri yerine sistem durumunu izleyebilirler.

Bir hizmet ağı uygulamak için hizmetlerinizin yanında bir proxy dağıtabilirsiniz. Bu aynı zamanda sepet modeli olarak da bilinir. Envoy ve Istio, bu amaç için en popüler 2 platformdur.