Mikroservis Mimari ile Geliştirilmiş bir Uygulamanın
Mevcut Çoklu Uygulama Portföyüne Entegre Edilmesi
Ümit Kanoğlu1[0000-0001-8245-1355] , Ali İmre1[0000-0001-9477-0660] ve Oumout Chouseinoglou2[0000-0002-8513-351X]
1 Türk Telekom, Ankara, Türkiye
{umit.kanoglu, ali.imre}@turktelekom.com.tr 2 Endüstri Mühendisliği, Hacettepe Üniversitesi, Ankara, Türkiye
uhus@hacettepe.edu.tr
Özet. Servis kalitesinin her zaman en üst seviyede olması gereken kurumlarda
bilişim sistemleri yeterli erişilebilirlik olgunluğunu 7/24 sergilemeli, erişilebilirlik seviyesinin yanında fonksiyonel ve regülatif anlamda da sürekli güncel kalmaları gerekmektedir. Her ne kadar bu güncellemeler sürüm planlama süreçleri işletilerek yönetilse de, genellikle monolitik mimari üzerine inşa edilmiş mevcut uygulamaların devreye alımı sonrasında canlı sistemlerde servis kesintileri görülebilmektedir. Bu çalışmada Türk Telekom’un kesintisiz devreye alımları sağlamak için iç müşterinin kullanımına sunduğu ve ilk defa mikroservis mimarinin yanı sıra davranış güdümlü geliştirme yönteminin de kullanıldığı bir projenin kurum envanterine ve mevcut süreçlere entegrasyonu özetlenmiştir.
Anahtar Kelimeler: Mikroservis, Davranış Güdümlü Geliştirme, Konteyner,
Konteyner Orkestrasyonu, Sürekli Entegrasyon, Sürekli Devreye Alım.
Integration of an Application Developed on Microservice
Architecture to the Existing Multiapplication Portfolio
Ümit Kanoğlu1[0000-0001-8245-1355] , Ali İmre1[0000-0001-9477-0660] and Oumout Chouseinoglou2[0000-0002-8513-351X]
1 Türk Telekom, Ankara, Turkey
{umit.kanoglu, ali.imre}@turktelekom.com.tr 2 Department of Industrial Engineering, Hacettepe University, Ankara, Turkey
uhus@hacettepe.edu.tr
Abstract. Companies, where the service level is required to be at the highest
level at all times, must have information systems that not only display an adequate level of access maturity continuously but also are up-to-date both in functional and regulative terms. Even though these updates are managed by
version planning processes, service loses on live systems may occur, especially in legacy applications built on top of monolithic architectures. In this study, a project presented by Türk Telekom to its internal customers, enabling continuous deployment by using for the first time a microservice architecture and behavior driven development, is summarized together with the details of integrating it into the corporate application inventory and existing corporate processes.
Keywords: Microservice, Behavior Driven Development, Container, Container
Orchestration, Continuous Integration, Continuous Deployment.
1
Giriş
Türk Telekom’un [1] abonelerine ve iç müşterilerine kesintisiz hizmet sağlamak amacıyla oluşturduğu yazılım uygulama portföyünün tamamına yakını monolitik mimari ile geliştirilmiş uygulamalardan oluşmaktadır. Monolitik mimari ile geliştirilmiş ve iş süreçleri içerisinde birbirlerine bağımlılıkları yüksek olan kurum uygulamalarının güncellenmesinde, yazılım geliştirme ve operasyonel süreçlerde farklı türde işletim zorlukları ile karşılaşılmaktadır. Bunlar; en küçük kod değişikliğinde tüm kod bloğunun tekrar derlenmesi, devreye alım işlemi esnasında canlı ortam üzerinde çalışan ilgili uygulama sunucularının kapatılması ve uygulamaların devreye alınmasının zaman ve erişilebilirlik anlamında hizmet kayıplarına neden olmasıdır.
Son yıllarda ticari rekabetin artmasıyla kesintisiz ve sık devreye alım yetenekleri önem kazanmış, monolitik mimariye alternatif olarak sürekli entegrasyon (Continuous Integration-CI), sürekli devreye alım (Continuous Deployment-CD) ve mikroservis mimari (Microservices Architecture-MSA) gibi yaklaşımların üzerinde daha fazla durulması gerekliliği ortaya çıkmıştır [2]. Mikroservis, genellikle tek bir işlemi yapan birbirinden bağımsız olarak kendi sürecinde çalışan iş (kod) paketleri üzerine kurgulanmış mimari bir yaklaşımdır [3]. Mikroservisler iş yetenekleri doğrultusunda birbirilerinden etkilenmeden devreye alımı sağlayacak bir şekilde tasarlanmaktadır [3,4] ve birbirleri arasında senkron veya asenkron iletişim kurabilirler. Mikroservisler uygulama sunucularında konteynerler üzerinde konumlandırılır ve genellikle dağıtık olarak yönetilir. Konteyner, bir uygulamanın kodunun yanı sıra bağımlılık ve yapılandırmalarını tutarlı ve verimli bir şekilde paketleyen sanallaştırma tekniği olup, yazılımı çalıştırmak için gereken kütüphaneler ve konfigürasyonları paketlemeye imkân tanır [5]. Konteynerler, MSA üzerinde yazılım geliştirme, sunma ve sürdürme için kullanılmaktadır. Konteyner yönetimi, çoklu kümeler (cluster) içindeki mikroservisler üzerine kurulmuş ayrı ayrı konteynerlerin yönetilmesi veya programlanması için otomatik bir işlemdir [4]. Bu çalışma kapsamında incelenen projede kullanılan bir diğer yazılım geliştirme yaklaşımı da davranış güdümlü geliştirme (Behavior Driven Development-BDD) olup, temel amacı müşterinin talep ettiği ürünün ya da fonksiyonun kullanım senaryosu olarak belirlediği davranışları üzerinden geliştirme aşamalarında ilerleme sağlamaktır [6]. Bu yöntemde müşteri kabul kriterleri ön planda olup kabul kriterlerinden kaynak koda giden süreç için belli araçlar kullanılarak test merkezli geliştirme yapılmaktadır. Bu kavramların yanında CI, kod üzerinde yapılan her değişikliğin ardından, tüm sistemin çalışır durumda olduğunu,
yapılan değişikliğin sistemin bazı bölümlerinde kırılmalara yol açmadığını tespit etmek için kullanılan yöntem olup CD ise, başarılı olan bir kod derleme işleminin uygulama sunucusu ya da sunucularına otomatik olarak yaygınlaştırılmasıdır [7].
Service Level Agreement (SLA) projesi, Türk Telekom’da MSA, CI ve CD yaklaşımlarının kurum içi uygulanabilirliğine yönelik bilincin arttırılması, aynı zamanda bahsi geçen yaklaşımların kurum içinde uygulanma aşamalarında karşılaşılan zorlukların ve öğrenilmiş derslerin değerlendirilmesi açısından pilot bir proje olarak devreye alınmıştır. Bu deneyim bildirisinin geri kalan kısmında, Bölüm 2’de proje deneyimi, Bölüm 3’te öğrenilmiş dersler ve Bölüm 4’te çalışmadan tecrübe edilmiş sonuçlar verilmektedir.
2
Proje Deneyimi
SLA yönetimi uygulamasının MSA’ye uygun geliştirilmesi bu çalışmada bir vaka olarak ele alınmış olup, proje sürecinde elde edilmiş olan öğrenme çıktıları bu çalışmanın odak noktasını oluşturmaktadır. SLA uygulamasının kapsamı ses, Internet ve veri ürünleri ile ilgili tek bir uygulama üzerinden satış ve müşteri şikâyet süreçlerinin SLA takibinin yapılmasıdır. Müşteriye bir ürün satıldığı zaman, müşteriye verilen taahhütler hem ürünün tesis ve şikâyet süreci ile hem de ürünün kullanılabilirliği ile ilgilidir. Uygulamanın geliştirilmesi ve bir pilot hizmet için devreye alım süreci 01.11.2017 ile 01.10.2018 arasında gerçekleşmiştir. İlk fazda uygulamanın temel fonksiyonlarının geliştirilmesi planlanmış, uygulama kuruma entegre edildikten sonra satılan tüm hizmetler fazlara ayrılarak uygulama kapsamına alınması hedeflenmiştir. Proje ilk fazı Java ile MongoDB ve Oracle veritabanları üzerinde geliştirilmiştir, geliştirme eforu 2.200 kişi/gün olup yaklaşık 600.000 satır koddan oluşmaktadır. Kurum bünyesinde, telekom sektörü standartlarını belirten TMForum’a [8] göre oluşturulmuş bir uygulama portföyü bulunmakta ve uygulamalar müşteri, sipariş, problem, envanter gibi alanlara ayrıştırılarak geliştirilmektedir. Yeni bir uygulamanın mevcut uygulamalarla entegre şekilde çalışması gerektiğinden, mevcut uygulamalarla entegrasyon etkisi oluşmakta ve geliştirme yapılması gereken uygulama sayısı artmaktadır.
2.1 Uygulanan Mikroservis Mimari (MSA)
Uygulama, MSA’e uygun olarak geliştirilmiş olup, Şekil 1’de gösterildiği gibi entegrasyon, ölçme, hesaplama, doğrulama, raporlama ve grafik görseller gibi SLA yönetiminin alt süreçleri mantıksal olarak ayrıştırılarak mikroservisler oluşturulmuştur. Burada oklar takip edilmekte olan genel iş süreci akışını gösternmektedir. Kurumda yazılım geliştirme süreçlerinde tecrübe edilen temel problemlerden biri uygulamanın mevcut uygulamalarla entegre edilmesidir. MSA ile uygulamanın entegrasyon noktası ayrı bir mikroservis olarak yazılarak geliştirme sürecinde entegrasyonda yaşanan zorluk ve aksamalar uygulamanın temel fonksiyonlarından soyut yönetilebilmiştir. MSA’da, mikroservisler kod düzeyinden veritabanı seviyesine kadar birbirinden soyut şekilde oluşturulmalıdır. Fakat pratikte bunu kısıtlayan etkenler olabilir. Şekil 2’de verildiği üzere, geliştirilen uygulama için tüm mikroservisler ayrı ayrı kodlanmış ama
veri bütünlüğü önemli olduğu için veritabanı seviyesinde fonksiyonel olarak mikroservis ayrımına gidilmemiştir. Mikroservislerin kendi içerisindeki entegrasyonu Kafka1 ile sağlanmıştır. Fonksiyonel açıdan tek veritabanı olup, uygulama tanım ve parametreleri için ayrı veritabanı oluşturulmuştur, MSA ile CI ve CD süreçleri desteklenmiştir. Her bir mikroservis için ayrı yönetilen geliştirme ve teslimatlar CI ile yönetilerek, DevOps yaklaşıma uygun bir süreç işletilmiştir. Mikroservisler, Docker2 konteyner yapıdaki sunucular üzerinde Kubernetes3 ile orkestra edilmiştir.
Şekil 1. MSA Tasarımı
Şekil 2. SLA Uygulamasının MSA’i
1 https://kafka.apache.org/
2 https://www.docker.com/ 3 https://kubernetes.io/
2.2 Uygulanan Davranış Güdümlü Geliştirme (BDD), Sürekli Entegrasyon (CI) ve Sürekli Devreye Alma (CD)
Uygulama 22 mikroservisten oluşturulmuştur. Tablo 1’de verilen bu mikroservislerden 12 tanesi için BDD aracı ile yaklaşık 500 adet test senaryosunun otomatik koşulması bir saat sürmekte, zamanlanarak otomatik koşulabilmekte ve sonuçları e-posta ile iletilmektedir. BDD aracı olarak Cucumber4 kullanılmış, Web servis ve fonksiyonel mikroservislerin davranışlarını %100 kapsayacak şekilde otomatik testler oluşturulmuştur. Dolayısıyla, mikroservislerde değişiklik olduğunda CI ile otomatik olarak canlı ortamda güncellenebilmektedir. “Happy path” olarak kapsanan mikroservisler hata olma olasılığı düşük olanlardır. Otomatik test kapsamına alınmayan 10 mikroservis ise kullanıcı arayüzü ve raporlamalar ile ilgili olanlardır.
Mikroservis yaklaşımda, CI ve CD araçları ile uçtan uca, kaynak kod seviyesinden canlı ortama yüklemeye kadar tüm süreçlerin otomasyon dâhilinde yapılması hedeflenmektedir. Uygulama için CI ve CD süreçlerinde Artifactory5, Jenkins6, Docker ve Kubernetes araçları kullanılmış, geliştirme ortamından canlı ortama kadar olan tüm akış otomasyon dâhilinde yönetilmiştir. %100 otomatik test kapsaması sağlanan mikroservisler için kaynak kod Jenkins ile otomatik derlenmekte, devreye alım paketi oluşturulmakta, paket Kubernetes aracılığı ile Docker konteynerlere kesinti yaşanmadan orkestra edilerek aktarılabilmektedir. Manuel test edilen mikroservisler için de test sonrası istenildiğinde ve kesintisiz olarak devreye alma yapılabilmektedir.
Tablo 1. Mikroservisler ve otomatik test kapsama oranları.
Mikroservis Mikroservis Tanımı Otomatik Test Kapsama Oranı (%)
performance-ws Gerçekleşme verisi alma 100
sla-validator Veri doğrulama 100
enricher Veri zenginleştirme 100
sla-caching-service Cache veri okuma 100
metric measurement Metrik ölçme 100
slo-calculator Süre hesaplama 100
scheduler-service Zamanlama 100
process-executor Süreç çalıştırma 100
penalty-calculation Ceza ücreti hesaplama 100
sls-exp-calculator SLS hesaplama 100
notification-ws SLA tanımı alma happy path ≃ 50 notification-service SLA tanım yönetme happy path ≃ 50 10 adet mikroservis Arayüz, tanımlama, raporlama, uygulama yönetimi 0
4 https://cucumber.io/
5 https://jfrog.com/artifactory/ 6 https://jenkins.io/
3
Öğrenilmiş Dersler
MSA’de teorik olarak mikroservisler kod düzeyinden veritabanı seviyesine kadar birbirinden soyut şekilde oluşturulmalıdır. Proje dâhilinde geliştirici sayısı, veri büyüklüğü ve bütünlüğü, çok fazla kod tabanı (codebase) olmasının getirdiği hata ayıklama zorlukları gibi faktörler mikroservis sayısını belirlemede etkili olmuştur. Operasyon açısından, mevcut sunucu ve insan kaynakları kapasitesi de dikkate alınmıştır. MSA’de her bir mikroservis için ayrı veritabanı oluşturulması önerilse de, uygulama özelinde veri bütünlüğü önemlidir. Bu yüzden fonksiyonel veriler ortak veritabanı üzerinde tutulmuş olup, temel tanım ve uygulama parametreleri ayrı veritabanındadır. Fonksiyonel veriler için MongoDB kullanılmış, temel tanım ve parametreler için Oracle tercih edilmiştir. Uygulama devreye alındıktan sonra entegrasyonda değişiklik olmadan yapılan güncellemelerin diğer uygulamalarla bağımlı şekilde yapılma zorunluluğu ortadan kalkmıştır. Ayrıca her mikroservis kendi içerisinde güncellenip bağımsız olarak devreye alınabilmektedir. Bu şekilde hem uygulamanın kendi içerisinde hem de diğer uygulamalarla bağımlılık açısından elde edilen esneklik ile planlama ve devreye alım kolaylığı sağlanmaktadır. Ayrıca konteyner yapı ile yatay genişleme kolaylıkla sağlanabilmektedir. Birden fazla mikroservisi kapsayan kullanım durumlarını bütünleşik test edebilmek zorlayıcı bir durum olup, bunun için BDD araçları büyük kolaylık sağlamıştır. BDD aracı sayesinde sağlanan test otomasyonu ile %5’inin manuel olarak koşulması bir hafta süren testler, bir saatte ve istenildiği zaman otomatik olarak koşulabilen duruma gelmiştir. Bu, geliştirme sonrası devreye alım sürecinin kısalması açısından büyük bir kazanımdır. Fakat yapılan her geliştirme için otomatik test senaryolarında oluşabilecek güncelleme, kazanımın yanında önemsiz olsa da ek efor oluşturabilmektedir. Arayüz ile alakalı mikroservislerde, test senaryosu hazırlamak zaman açısından yüksek maliyetli olduğu için, test otomasyonu yapılmamıştır. Operasyon açısından MSA’de bir uygulamayı izlemenin daha zor olduğu görülmüş, bunun için özel izleme araçlarına ve daha nitelikli çalışanlara ihtiyaç duyulmuştur. MSA’de uygulama geliştirme ve operasyon altyapısı oluşturmanın monolitik mimariye göre daha zor olduğu ama teknolojilerle uyum sağlandıktan sonra uygulama yaşatma sürecinin daha kolay olduğu görülmüştür.
4
Sonuç
Bu çalışmada MSA ile geliştirilen bir uygulamanın monolitik uygulamalara entegre edilerek, tasarım ve devreye alma süreci anlatılmıştır. Geliştirme aşamasında fonksiyonel olarak ayrıştırılarak modellenen mikroservisler ile birbirinden bağımsız olarak sağlanan geliştirme ve devreye alma esnekliği CD ve CI araçları ile desteklenmiştir. Vaka çalışmasında kullanılan SLA uygulamasının, kurumdaki diğer uygulamalarla çok fazla entegrasyonu mevcut olup, bu entegrasyonların ayrı mikroservis olarak geliştirilmesi uygulamanın kendi içerisinde olan güncellemelerinin esnek devreye alınabilmesini sağlamıştır. Test otomasyonu açısından %100 kapsama sağlanan mikroservisler geliştirme sonrası insan faktörü olmadan yaygınlaştırılabilmiştir. Bundan sonraki süreçte kurum içerisindeki diğer
uygulamaların MSA’e dönüştürülmesi hedeflenmektedir. MSA’in TMForum [8] gibi çerçeveler üzerinde de önemli değişiklik etkisi oluşturacağı düşünülmektedir.
Kaynakça
1. Türk Telekom Yatırımcı İlişkileri, http://www.ttyatirimciiliskileri.com.tr/tr-tr/turk-telekom-grubu/grup-sirketleri/sayfalar/turk-telekom.aspx
2. Fowler, M.: MonolithFirst, https://martinfowler.com/bliki/MonolithFirst.html.
3. Lewis, J., Fowler, M.: Microservices. https://martinfowler.com/articles/microservices.html. 4. Söylemez, M., Tarhan, A.: Mikroservis Mimarisi ve Mimari Faktörleri Üzerine Endüstriyel
Bir İnceleme, 12. Ulusal Yazılım Mühendisliği Sempozyumu, İstanbul, (2018).
5. Aytekin, A. I., Macit, Y.: GelİŞlet (DevOps) Yaklaşımında Konteyner Dönüşümü Deneyimi, 12. Ulusal Yazılım Mühendisliği Sempozyumu, İstanbul, (2018).
6. Çıtlık, A., Bağcı, V.H., Turgut, U.O., Güngör, T.: “Bankacılık Alanında Doğal Dil İşleme Destekli Davranış Güdümlü Geliştirme”, 8. Ulusal Yazılım Mühendisliği Sempozyumu, Güzelyurt KKTC, (2014).
7. Continuous integration | ThoughtWorks, https://thoughtworks.com/continuous-integration 8. Frameworx homepage 2019 - TM Forum, http://tmforum.org/tm-forum-frameworx-2/
