APM Nedir?

PERFORM Akademi’de başladığımız ve yazı dizilerimizin ilki olan APM’i Yazılım Performans Mühendisliği bağlantılı olarak mercek altına almak istiyoruz.

Amacımız, uygulama performansı konusunda tutkulu olan ve her gün onu geliştirmek için çalışan, bu işe gönül vermiş bizim gibi insanlar için bir referans belge sağlamaktır. Performansla ilgili pek çok belge dağınık olarak varken, günlük performans modeli, süreçleri ve yönetimi için kesin bir referans kaynağın bulunmadığını gördük. Bilgileri arayabileceğiniz ve sorunlarınızın yanıtlarını hızlı bir şekilde bulabileceğiniz bu referansı sizlere sunmakla birlikte, APM’nin ne olduğunu ve bunu yazılım geliştirme- test- üretim ortamları ve yazılım sistemleri kalite süreç bağlantılı nasıl kullanabileceğinizi açıklamak istiyoruz.

Performans, iş faaliyetlerini desteklemek için uygulamaları kullanan herkes için her geçen gün artan önem taşıyan bir konudur. Günümüzde mühendisler, mimarlar ve aslında biraz da kullanıcılar, karmaşık uygulama hizmetlerinin sorunsuz bir şekilde çalışmasını ve sorunların hızlı ve asgari çabayla çözülmesini sağlamak zorundadır. Perform olarak uygulama performans yönetimi (APM) çözümlerini ve süreçlerini kullanan ve uygulayan BT uygulayıcılarıyla bire bir dirsek teması çalıştık, çok kafa yorduk ve çok farklı ortamlarda çok farklı senaryolar ile karşı karşıya kaldık. Akademin diğer bir amacı da 2010 yılından bu yana edindiğimiz tecrübeleri sizlerle paylaşarak ve her yeni gün karşılaştığımız olayları da burada belgelemektir.

Bununla birlikte, APM konusunu olabildiğince belgelerken, performans konusunda dilimize yerleşmiş olan İngilizce terimlerin Türkçe karşılıklarını vererek konuyla ilgili Türkçe bir kaynak da oluşturmak istiyoruz.

Her yazımınızda;

1. Sözlük : Konu içinde geçen ve genel sözlüğe kaynak oluşturacak
2. Kaynakça : Referansların belirtilmesi
3. Kavramlar : Bahsi geçen ve detaylarını daha sonra ele alacağımız konulara ilişkin kavramların numaralandırılmasını da (Mavi sayılar ile tanımlanacaktır)

sunuyor olacağız.

APM

• Application Performance Monitoring- Uygulama Performans İzleme
• Application Performance Management- Uygulama Performans Yönetimi

Olarak tanımlanır ve her iki tanım da geçerli olduğu gibi kullanıldıkları yerlere göre farklılık gösterirler. Yazılım mühendisliğinde fonksiyonel olmayan gereksinim bileşenlerinden biri olan “Performans” ve onunla ilişkili olan kavram da uygulama performansıdır.

Çok uzun ve farklı tanımlar yapılabilir fakat en yalın haliyle APM:

• Uygulama Performans İzleme / Application Performance Monitoring

Sistem bileşenlerinin (Uygulama, Veri tabanı, Network, Sunucu vb.) ve son kullanıcı deneyimlerinin ölçülerek, farklı ölçütlerin, farklı veri tiplerine göre toplanarak saklanması (Süre, adet, yüzde vb.), raporlanması, uyarı verdirilmesi, eğilimlerin anlaşılması ve analiz edilmesine “Uygulama Performans İzleme”, [1]

• Uygulama Performans Yönetimi / Application Performance Management

Toplanan ve özelleştirilen ölçütler üzerinden, kurumun kendine özgü bir performans modeli ve bu model ile performans süreçleri oluşturması, “Uygulama Performans Yönetimi” denilmektedir.[2]

Yazılım Performans Mühendisliği / Software Performance Engineering:

Yazılım Performans Mühendisliği, en basit haliyle, donanım olanaklarından daha iyi yararlanarak yazılımın verimini ve hızını arttırmaktadır. Üretim ortamına geçmeden önce, geliştirim ve test süreçlerinde elde edilen performans ölçüt ve analizleri, yazılımın, daha hızlı algoritmalar kullanması ve daha az veri yoğun kodlama yapmasını, üretim ortamına geçtikten sonra ise bir performans süreci içinde yazılım sisteminin eniyilemesini sağlar.[3]

Açıklamalardan da anlaşılacağı gibi “APM” kısaltmasında ilk harf olan “A” harfi artık geçerliliğini yitirerek başka anlamlara evrilmiş, son harf olan “M” harfi ise iki farklı anlamda genişleyerek hayat bulmuş, ortadaki “P” harfi yani “Performans” ise gerek yazı dizimizin gerekse temsil ettiği kavramın ana bileşenini oluşturmuştur.

Peki o zaman APM’i APM kavramı olarak kullanmak doğru mudur? Bu açıdan bakıldığında pek de doğru değildir ve zaten APM kavramı da artık farklı bir felsefeye doğru yönelmiştir.

M:Monitoring mi yoksa Management mi?

Monitoring kelimesi APM tanımındaki yerine sığamaz olmuş, bu olgu artık bir izleme değil, Bilgi Teknolojileri Operasyon Yönetimi alanında “IT Operations Management (ITOM)” bir model ve süreç olarak yerini almaya başlamıştır. Dijital dünya artık “olursa iyi olur” gibi disiplin dışı yaklaşımların var olmasına izin vermeyen bir dünyadır. Günümüzün karmaşık kurumsal üretim ortamlarının yönetilmesi zorlaştıkça, ITOM’un daha akıllı, daha güçlü, daha çevik yönetim model ve süreçleri ile APM’in gücünü kullanması günümüzde artık neredeyse bir zorunluluktur.

Fakat aslında önemli nokta; “Monitoring mi yoksa Management mi” konusunda hangi kelimeyi seçmemiz gerektiği değil, kurumların “Performansa” yaklaşım ve uyguladıklarıyla, içinde bulundukları farkındalık / olgunluk seviyeleridir.

Bilgi Teknolojilerinin sahip olduğu birçok ana ve alt disiplini içinde, APM’in de bir olgunluk modeli vardır. Dolayısıyla “Monitoring mi yoksa Management mi” sorusunun yanıtı “Monitoring” veya “Management” olarak bir tercih değil, kurumdan kuruma değişen ve kurumların uyguladıkları süreçlerin sonucudur. İleriki konularda APM’in olgunluk seviyelerini detaylı olarak inceleyeceğiz.

Fakat çok temel olarak; kurumların belli bir olgunluğa kadar “Monitoring” belli bir olgunluktan sonra da “Management” seviyesinde olduklarını rahatlıkla söyleyebiliriz.

A:Application

APM’deki “A” kelimesi kendi başına uygun fakat yukarıda ifade edildiği üzere bu geniş felsefenin ilk harfini temsil etmeye artık uygun değildir.

Uygulamaların bir kara kutudan farksız olduğu dönemlerde aşağıda tanımladığımız üç ana ölçüt ve türevleri neredeyse sahip olunan yegâne ölçütlerdi ve APM’deki “A” harfini hem temsil ediyor hem de karşılığını hak ederek veriyordu. (1.Nesil / Geleneksel APM uygulamaları) [4]

1. Yanıt Süresi (Response Time)
2. Hata Adedi / Oranı (Failure Count / Rate)
3. İşlem Yoğunluğu-Trafik (Throughput)

Günümüzün yazılım sistemleri (“uygulama” kelimesi özellikle kullanılmamış olup, uygulamalar veri tabanı, ağ, dış çağrılar vb. gibi çok ve karmaşık bir yapı içinde çalışıyor olup tekil değil çoğul bir bütünün içinde hizmet verdiğinden “uygulama” değil “sistem” kelimesi kullanılmıştır) kaynakları tüketen canavarlar olabilir.

Hangi ortam ve tür için yazılım geliştirirseniz geliştirin yazılım sisteminiz birden fazla bileşen ile etkileşimde olacaktır. Sistemler genel olarak iki ana bileşenden oluşur. Asıl fırtına ise bu iki ana bileşenin kendi içinde ve karşılıklı etkileşimleri sonucunda ortaya çıkar.

1-Ön yüz (Front End)

2-Arka Uç (Back End)

Bu ana bileşenleri biraz daha detaylandırdığımızda büyük karmaşıklığın biraz daha farkına varıyor oluruz.

1. 1-Ön yüz (Front End)

• Yazılımın kendisine ait Js, Css ve Görsel kütüphane
• CDN
• Yazılımın kendisine ait olmayan 3. taraf bileşenler (Js, Css, Görsel kütüphane)

1. Arka Uç (Back End)

• Sunucular
• Uygulamalar
• Veri tabanı

Bu karmaşık sistemlerin her katmanı kendi eşik seviyelerinde gereken performansı sağlaması gerekir ve sistemin en güçlü noktası sistemin en zayıf bileşenin performansı ile doğrudan ilişkilidir.

Ve bu performans; yazılım geliştirme, test ve üretim ortamlarında gerçek zamanlı ölçülmeli, modellenmeli ve bir süreç disiplini içinde, ön yüzde başlatılan işlemleri uçtan uca gerçek zamanlı analiz ederek, sistemin hızını, darboğazları, işlem trafiğini, hataları ve kesintileri anlık olarak sunarak yönetilmelidir.

Aslında uygulama performansı yönetimi; kullanılabilirlik ve kullanıcı deneyimini yönetme sanatıdır.

Uygulamaların tekil olarak çalıştığı istemci-sunucu mimarisinden, Iaas, Paas ve SaaS gibi yeni yazılım mimarilerine, mikro hizmetlerin ve işlevlerin yaygın kullanımı, Agile ve DevOps gibi yeni yazılım geliştirme uygulamaları nedeniyle yazılım geliştiricileri için giderek daha karmaşık, dağıtılmış ve sonrasında bulut tabanlı esnek uygulamalara dönüştükçe, uygulama performans yönetimi de buna uygun olarak gelişmiştir.

Doğal olarak artık APM’in sadece bir ölçüt toplama değil, yazılım sistemlerinin ne zaman normal ve ne zaman anormal davrandıklarını belirleyebilecek yönetimden ve sorunların kök nedeninin hızlı bir şekilde tanımlanmasından bahsetmekteyiz.

Günümüz yazılım mimarileri karmaşıktır ve bağımlılıktaki hacim hiçbir insanın anlayamayacağı bir ölçeğe ulaşmıştır. Bulut, konteyner, mikro servisler derken milyarlarca bağımlılıktan konuşuyor olabiliriz.

Peki ama büyüklüğün ne kadarına en büyüğü denir?

Aslında, ne kadar ölçek konuştuğumuzu ifade etmek çok zordur. “Çevreleri çok büyük, 50.000 ana bilgisayara kadar” diyebiliriz, ancak yalnızca ana bilgisayarlar veya bu ana bilgisayarda çalışan yazılımların bağımlılıkları karmaşıklığı temsil etmiyor. Yurt dışında katıldığımız bir panelde bir müşterinin sorun başına 235 milyar bağımlılığın analiz edildiğini paylaştı. Bu bilgiler hiçbir insanın takip edeceği ve raporlayacağı türden bilgiler değildir ve burada artık kavram değişikliğine gidilmiştir.

APM’in genişleyen bu sorumluluk alanları dolayısıyla Gartner APM’i 3 ana kategoride tanımlamıştır. (2020 yılı raporu)

Gartner’e göre APM’in üç ana fonksiyonel boyutu:

1. Dijital deneyim izleme / Digital experience monitoring (DEM)
2. Uygulama bulma, izleme ve tanılama / Application discovery, tracing and diagnostics (ADTD)
3. Uygulamalar ve BT operasyonları için yapay zekâ / Artificial intelligence for IT operations (AIOps) for applications (AIOps)

Gartner’ın tanımlamalarının yanı sıra artık günümüz kurumsal üretim ortamlarının salt uygulamadan ibaret olmadığı ve şartların çok değiştiği çok nettir. Uygulamanın yanına başka önemli oyuncularda dahil olmuştur.

Bunu biraz daha genişletecek ve genel olarak ifade edecek olursak:

1. Uygulama Performansı

Mikroservisler

Cloud (Bulut)

Hibrid Cloud (Karma/Kısmi Bulut)

Veri tabanı (SQL / NoSQL)

1. Dijital Deneyim

Web, Mobil, IOT

Gerçek Kullanıcı İzleme (Real User Monitoring)

Sentetik (Synthetic)

Oturum Kaydı (Session Replay)

1. Yapay Zekâ Operasyonları (AI — Operations)

Orkestrasyon (Orchestration)

Kök Neden Belirleme (Precise Root Cause)

Topoloji ve Bağımlılıklar (Topology — Dependencies)

1. Altyapı İzleme (Infrastructure Monitoring)

Sunucular (Hosts)

Sanal Makinalar (Virtual Machines)

Konteynerler (Containers)

Olaylar ve Günlükler (Events — Logs)

Ağ ve Ağ Cihazları (Network- Network Devices)

1. Dijital İş Analizi (Digital Business Analytics)

Dönüşümler (Conversions)

Hemen Çıkma Analizi (Bounce Rate Analysis)

Müşteri Analizi (Customer Analysis)

Bölgesel Analiz (Regional Analysis)

Bu durumda “A”nın yerini artık daha geniş bir kavrama sahip olan “D” (Digital) kelimesi almış olmaktadır.

DPM (Digital Performance Management)

DPM’in de çok kısa tanımını yapacak olursak; web veya mobil uygulamalarının kullanıcılara sunduğu uygulama performansının ve müşteri deneyiminin sunulanın en iyisi olma durumudur.

Organizasyonların dijital ve rekabetçi bir çağda büyümek ve pazar lideri olmak için yapmaları gereken sadece uygulamaları değil dijital bileşenlerin tümünün bir uyum içinde yönetildiğinden emin olmaları gerekmektedir.

Değişim beraberinde birçok konu, birden fazla eşzamanlı ve olumlu veya olumsuz örtüşen çalışmaları da beraberinde getirir. BT projelerinin başarısız olmasına ne neden olur? Giderek artan karmaşıklık, birden fazla paydaş, belirsiz vizyon, odaklanamama ve beceri eksikliği ilk aşamada belirtilecek sadece birkaç noktadır.

Yazılım sistemlerinin uçtan uca yapılandırılması, konteyner tabanlı çözümlere yeni yatırımlar ya da dijital dönüşümün bir parçası olarak bulut tabanlı teknolojilerin yanı sıra geleneksel veri merkezi dağıtımlarına yapılan mevcut yatırımlarla Dijital Performans Yönetiminin (DPM) başlıca esaslarıdır.

Ancak DPM’nin felsefesini tam olarak anlamak için, bunun sadece bir araçtan daha fazlası olduğunu özümsemeliyiz. Bir kuruluşun, yatırım ve buna bağlı olarak geri dönüş gelirlerini, başarılı bir şekilde üst düzeye çıkarmak için “bilginin bilimsel olarak araştırılması ve edinilmesi” girişimleri destekleyecek kültüre, insanlara ve sürece odaklanması zorunludur. Çünkü bilgi güçtür ve bu kültürü merkezine koymamış / koyamamış kurumların ne olduğunun farkına bile varamadan bu yeni çağın sahnesinden kaybolacakları aşikardır.

Bir sonraki yazımızda “Uygulama Performans İzleme / Application Performance Monitoring” ve “Uygulama Performans Yönetimi / Application Performance Management” konularının derinlere inip, kavramlarını inceleyeceğiz.

Sözlük

1. Response Time

• Yanıt Süresi:

Bu ölçüt bazen “Tepki Süresi” olarak da isimlendiriliyor. “Response” kelimesinin Türkçe karşılıklarından olan “Tepki” ile “Yanıt” arasında ince bir ayrım vardır.

Yanıt Süresi, bir işlemin çalışmaya başlayıp tamamlaması için geçen süredir.

Örnek: Bir web isteğinin uygulama sunucularına, veri tabanına ve dış servislere giderek elde ettiği yanıt verisini, isteğin geldiği yere geri döndürme süresi.

Tepki Süresi:

1. Bir işlemin çalışmaya başlamak için beklediği süre.

Örnek: Bir SQL cümleciğinin çalışması için önce bir bağlantı alması gerekir (Get Connection). Bu bağlantıyı aldıktan sonra SQL cümlesi çalışır.

• Get Connection à Tepki Süresi
• SQL Execution à SQL Çalışma Süresi

Yanıt Süresi = a + b

1. Bir işlemin çalışmaya başlamasıyla, henüz işlemin tümü bitirilmeden üretilen ilk anlamlı verinin hizmete sunulması arasında geçen süre.

Örnek: Time to first byte (TTFB)- İlk bayta kadar geçen süre

Bir istemci tarafından başlatılan (web veya mobil) bir isteğin, istemciye geri dönen yanıttaki ilk bayta kadar geçen süre.

1. Failure Count / Rate

• Hata Adedi / Oranı

1. Throughput

• Birim zamanda işlem göre istek sayısı.

Bu ölçüt işlem yoğunluğunu belirtmek için kullanılır.

• Örnek: Login sayfası 1,500 / dakika demek Login işleminin 1 dakika içinde 1,500 kez işlem gördüğü demektir.

1. Arka-Uç / Back End:

• Bir bilgisayar sisteminde son kullanıcının doğrudan kullanamadığı ve/veya kolayca erişemediği, ancak bir yazılım veya bilgisayar tarafından kullanılan kısmı.

1. Ön-yüz / Front End:

• Bir bilgisayar sisteminde kullanıcının doğrudan gördüğü ve kullandığı görsel kısım.

1. Dijital deneyim izleme / Digital experience monitoring (DEM)

• Kurumsal uygulama ve hizmetlerin etkileşime girmesiyle, insan ve makinenin deneyim ve davranışlarını inceleyen, analiz eden ve bunların eniyilemesini tavsiye eden bir kullanılabilirlik ve performans izleme disiplini.

1. Uygulama bulma, izleme ve tanılama / Application discovery, tracing and diagnostics (ADTD)

• Yazılım sistemlerinin bütününde, uygulamaların otomatik olarak bulunması ve tanınması (hangi dilde ve sürümde yazıldığı anlama, kullandığı bileşenleri algılama vb.), ve hangi bileşenlerle etkileşimde olduğunun analiz edilmesi ve ilişkilendirilmesi.

1. Uygulamalar ve BT operasyonları için yapay zekâ / Artificial intelligence for IT operations (AIOps) for applications (AIOps)

• Uygulamalar ve BT operasyonlarındaki yoğun hareketli, karmaşık, dağıtılmış uygulama ve donanım ortamlarının hacim, hız ve bilgi çeşitliliğinin trilyonlarca verinin anında anlamlandırılması ve bunun otomatik hale getirilmesi.

Kaynakça

• https://www.dynatrace.com/platform/application-performance-management/
• https://en.wikipedia.org/wiki/Time_to_first_byte
• https://en.wikipedia.org/wiki/Application_performance_management
• https://en.wikipedia.org/wiki/Performance_engineering
• https://streamhpc.com/knowledge/what-is/performance-engineering/
• https://smartbear.com/learn/performance-monitoring/what-is-application-performance-management/
• https://www.dynatrace.com/news/blog/ai-driven-digital-performance-management/
• https://www.dynatrace.com/news/blog/how-to-accelerate-technology-adoption-with-digital-performance-management/

Kavramlar

Bu yazımız içinde geçen, daha sonraki yazılarımızda detaylı olarak anlatılacak ve kendisi başlı başına bir ana konu olan kavramlar listesi.

[1] Uygulama Performans İzleme / Application Performance Monitoring

[2] Uygulama Performans Yönetimi / Application Performance Management

[3] Yazılım Performans mühendisliği / Software Performance Engineering

[4] APM Tarihçesi