İş Yükünden Compute Baseline’ına

Ön koşul: bir iş hizmetinin uygulama, platform, compute, network ve storage bağımlılıklarını çıkarabilmeli; KNOWN, ASSUMED, UNKNOWN ve TBD kayıtlarını kullanabilmelisin. Bu dersin sonunda “iki yeni sunucu” talebini iş yükü ve karar ölçütlerine çevirebilecek; latency, throughput, eşzamanlılık ve tamamlanma süresini birbirinden ayırabilecek; CPU yüzdesi ile kaynak baskısını aynı şey saymadan kanıt isteyebilecek; zaman eşlemeli bir compute baseline hazırlayabileceksin. Yaklaşık 26 dakika anlatı ve örnek, 16 dakika Arven çalışması, 10 dakika bilgi kontrolleridir. Ürün modeli, işlemci ailesi ve kesin BoM seçimi bu dersin kapsamı değildir.

Compute discovery envanterle başlasa da envanterde bitmez. “Kaç sunucu var, kaç çekirdek kullanılıyor?” mevcut yapıyı gösterir; hangi işin ne hızda tamamlanması gerektiğini açıklamaz. Aynı 16 çekirdek, tek iş parçacıklı bir lisans servisi, yüzlerce eşzamanlı web isteği, gece çalışan batch, sanal masaüstü veya analitik sorgu için farklı sonuç üretir. Pre-Sales önce korunacak iş sonucunu, sonra bunu üreten iş yüklerini ve ölçülebilir hizmet hedeflerini açar. İş yükü bir uygulama adından daha ayrıntılı tanımlanır. İş birimi, işlem veya görev; aktif kullanıcı ve eşzamanlılık; istek/işlem hacmi; veri seti ve working set; okuma-yazma örüntüsü; kritik zaman penceresi; büyüme olayı; bağımlı servisler; planlı işler ve kabul eşiği birlikte kaydedilir. ERP tek iş yükü değildir: çevrimiçi sipariş, ay sonu kapanış, raporlama, entegrasyon ve yedekleme aynı platformu farklı zamanlarda zorlayabilir. Compute kararı da tek boyutlu değildir. Bir kullanıcı isteğinin yanıt süresi latency hedefidir; saatte tamamlanan sipariş veya batch sayısı throughput hedefidir; ay sonu kapanışının bitiş saati elapsed-time hedefidir. Eşzamanlı kullanıcı sayısı yükün büyüklüğünü etkiler fakat tek başına CPU talebine dönüşmez. Aynı kullanıcı sayısı farklı sorgu, cache, veri ve bekleme davranışı üretebilir. Kabul ölçütü, iş yükü, zaman ve percentile gibi bağlam taşımadan “hızlı” veya “yüzde 30 daha iyi” denemez.

Bir metrik; ad, birim, kapsam, zaman aralığı, toplama sıklığı, aggregation, kaynak, sahip ve semantik taşıdığında karar kanıtına dönüşür. “CPU yüzde 80” kaydında host mu VM mi, tek çekirdek mi bütün sistem mi, anlık mı beş dakikalık ortalama mı, user/system/iowait dağılımı ne, olay anındaki iş hacmi kaç bilinmiyorsa yorum zayıftır. Yüzde değerinin paydasını da doğrula: sanal makineye verilen vCPU, fiziksel host kapasitesi ve cgroup limiti farklı paydalardır. Ölçümleri aynı zaman çizgisine getir. Uygulama p50/p95/p99 latency, transaction rate ve hata oranı; işletim sistemi CPU kullanımı, run queue, context switch, memory pressure, paging ve swap; platform vCPU ready/steal veya limit baskısı; storage latency ve IOPS; network gecikmesi, throughput ve retransmission; batch başlangıç-bitiş zamanı ortak pencereye bağlanır. Her teknoloji aynı metriği sunmayabilir. Amaç araç listesini tamamlamak değil, kullanıcı etkisi yükseldiğinde hangi kaynakta bekleme veya doygunluk oluştuğunu sınamaktır. Ortalama tepeyi gizleyebilir, tek tepe de olağan kapasiteyi temsil etmeyebilir. Normal gün, iş açısından kritik tepe, bakım/failover durumu ve büyüme senaryosu ayrı görünür. Percentile, dağılımdaki kuyruk etkisini gösterir; yine de örnek sayısı, pencere ve müşteri kabulü olmadan sihirli eşik değildir. Zaman dilimi, saat senkronizasyonu ve ölçüm boşlukları özellikle farklı sistemlerin kayıtlarını eşlerken belirtilir. Baseline üretim sistemine aşırı yük bindirmemelidir. Yeni profiler, benchmark veya agent kullanılacaksa değişiklik süreci, veri hassasiyeti, overhead, süre ve geri alma yöntemi doğrulanır. Mevcut gözlem verisi önce kullanılır; eksik kanıt için kontrollü test planlanır.

Kullanım, bir kaynağın meşgul olduğu oranı gösterebilir; darboğaz ise iş sonucunu sınırlayan kaynak veya bağımlılıktır. Yüksek kullanım verimli çalışma da olabilir. Düşük CPU ise boş kapasite kadar bellek, I/O, lock, ağ veya dış servis beklemesi anlamına gelebilir. Bu yüzden “yüksekse büyüt, düşükse küçült” kuralı güvenilir değildir. Talep, hizmet sonucu ve bekleme kanıtı birlikte okunur. Linux Pressure Stall Information, CPU, memory ve I/O kıtlığı nedeniyle görevlerin ne kadar süre ilerleyemediğini ölçer. `some`, en az bazı görevlerin stall olduğu zamanı; `full`, ilgili kaynakta tüm non-idle görevlerin aynı anda stall olduğu zamanı gösterir. Bu değerler CPU kullanımının alternatifi değil, kaynak çekişmesinin iş üzerindeki zaman maliyetine ek bir mercektir. Run queue, scheduler latency, IPC, cache miss, local/remote memory bandwidth ve uygulama profili gerektiğinde uzman incelemesine girer. Red Hat’ın araç seti topolojiyi `lscpu` ve `numactl`, NUMA dağılımını `numastat`, cache ve bellek bant genişliğini uygun sistemlerde `pqos`, affinity’yi `taskset` gibi araçlarla incelemeyi destekler. Araç çıktısı otomatik reçete değildir. Topoloji, socket, core, hardware thread, cache, memory node ve I/O yerelliğini gösterir; sonraki derslerde bunların iş yüküyle nasıl eşleştiği ayrıntılanacaktır. Darboğaz kanıtı kontrollü değişiklikle güçlenir. İş hacmini sabit tutup vCPU limitini kaldırmak, uygun ortamda thread veya memory placement değiştirmek ya da sorgu planını düzeltmek sonuç metriğini değiştiriyor mu? Aynı anda birçok değişkeni değiştirmek nedenselliği zayıflatır. Üretimde deneme yapmadan önce risk, geri dönüş ve gözlem yöntemi tanımlanır. Ölçüm bir kök neden iddiasını desteklemiyorsa UNKNOWN kalır.

Arven, ERP ve bayi sipariş portalı için iki yeni fiziksel sunucu ister. Mevcut cluster dört hosttur. Aylık raporda ortalama CPU yüzde 41, bellek yüzde 68 görünür. Satış notunda “ay sonu çok yavaş” ve “gelecek yıl kullanıcı yüzde 25 artacak” yazılıdır. Bu veriler teklif için yeterli değildir: host ile VM kapsamı, yoğun pencere, aggregation, iş hacmi, vCPU ready/steal, memory pressure, storage ve uygulama latency bilinmez. İlk karar yeni model seçmek değil, yenilemenin hangi iş yükü sonucunu ve hangi risk sınırını karşılayacağıdır. ERP çevrimiçi işlem, ay sonu batch, raporlama ve entegrasyon; portal ise istek hacmi ve kampanya tepesine ayrılır. Her biri için normal/tepe hacim, p95 yanıt veya tamamlanma süresi, hata, CPU zamanı, run queue, working set, pressure, disk ve ağ beklemesi aynı pencerede istenir. Lisanslanan çekirdek ve desteklenen topoloji kısıtları doğrulanana kadar kesin çekirdek sayısı UNKNOWN kalır. Bakım ve arıza durumu ayrı senaryodur. Dört host bugün ortalamayı taşısa bile bir host bakımdayken yoğun yük için yeterli boşluk olmayabilir. Tersine, ortalama kullanıma yüzde 25 kullanıcı artışı eklemek de doğru değildir; kullanıcı, işlem hacmi ve CPU talebi doğrusal büyümeyebilir. Büyüme sürücüsü kullanıcı, işlem, veri, yeni özellik ve çalışma penceresi bazında modellenir. Arven baseline’ı tek sayı değil, ölçülebilir senaryo seti olur.