Yazılım & Uygulama
Sonsuz Veriye Tek Bakış: Hepsiburada'nın İzleme Devrimi
Hepsiburada gibi devasa bir e-ticaret platformu için milyonlarca sunucu ve hizmeti tek bir yerden yönetmek büyük bir zorluktur.
Hexcore
4 dk
Veri Ağına Aktar
Hepsiburada, Türkiye'nin önde gelen e-ticaret platformlarından biri olarak milyonlarca kullanıcıya kesintisiz hizmet veriyor. Bu ölçekteki bir işletme için sistemin sorunsuz çalışması sadece iyi yazılmış kodlardan ibaret değildir; her anın, en ince detayına kadar gözlemlenebilir olması gerekir.
Platformun kritik durumunu yöneten RabbitMQ, Consul ve Kafka gibi temel servisler ile OpenSearch ve Elasticsearch kümesi dahil yüzlerce bileşen aktif durumda. Bu hizmetleri barındıran 2000’den fazla Ubuntu sunucusu ve üzerinde çalışan 500’ün üzerindeki Kubernetes kümesini Cluster API (CAPI/CAPO) yönetiyor. Ancak bu muazzam ölçekte izleme, başlı başına ciddi bir mühendislik problemidir.
Hata oluştuğunda neyin bozulduğunu, nerede ve ne zaman olduğunu hızla tespit edebilmek, hatta bir aksaklığın yaşanmasını beklemek yerine önceden tahmin etmek doğrudan kullanıcı deneyimini ve iş sürekliliğini etkiliyor. Platformun artan büyümesiyle birlikte mevcut izleme altyapısının artık bu sorumluluğu taşıyamayacağını fark eden mühendisler radikal bir dönüşüm kararı aldı.
VictoriaMetrics'e geçmeden önce karşılaşılan dört temel sorun, sadece teknik zorluklar değil, aynı zamanda operasyonel riskleri ve iş maliyetlerini temsil ediyordu. İlk ve en büyük engel veri saklama süresi ile maliyetiydi.
Her bir hizmet grubu için ayrı Prometheus ve Grafana istifleri kurulmuştu; her Kafka ana makinesinin kendine ait izleme sistemi vardı. Bu da 14 günlük sabit bir süreyle sınırlı kalıyordu çünkü daha fazla veri tutmak, disk depolama maliyetlerini kontrolsüzce artırıyordu.
Makinelerdeki bellek sızıntısını takip etmek veya geçmiş dönemlere ait trafiği analiz etmek için bu verilere ihtiyaç duyuluyordu; ancak sistem, en çok gerektiğinde veriyi sunamıyordu. Veriler parçalanmış ve bütün bir hikaye anlatmak imkansızdı.
İkinci büyük problem merkezi izleme eksikliğiydi. 2000’den fazla sunucu ve yüzlerce küme varken tüm platform sağlığını tek bir ekranda görecek bir merkezin olmaması, arıza tespitini zorlaştırıyordu. Örneğin, Kafka'daki ani bir artışın Elasticsearch gecikmesiyle bağlantılı olup olmadığını anlamak için birden fazla Grafana paneli arasında zihinsel olarak geçiş yapmak gerekiyordu.
Üçüncü ve en kritik sorun ise merkezi uyarı (alert) mekanizması eksikliğidir. Tüm sunucularda geçerli olan bir disk kullanım uyarısı oluşturmak, her ayrı Prometheus örneğine tek tek gitmek ve manuel değişiklikler yapmak anlamına geliyordu. Her küçük güncelleme onlarca farklı noktaya dokunmayı gerektiriyordu; bu da hatalı uyarıların veya gözden kaçan kritik olayların yaşanmasını beraberinde getiriyordu.
Hepsiburada, önceden izleme ihtiyaçlarını Thanos gibi çözümlerle hafifletmiş olsa da ölçek büyüdükçe yeni problemler ortaya çıktı. Veri hacmi arttıkça Compactor (sıkıştırıcı) bile istikrarlı çalışmıyor ve sürekli operasyonel yük oluşturuyordu. S3 nesne depolama alanından geniş zaman aralıkları sorgulamak ise son derece yavaştı.
Geliştiriciler, haftalar öncesine ait veriyi görebilecekleri Grafana panellerinden uzaklaşmaya başladı; bu, bir izleme sisteminden beklenen tam tersi durumdu. Bu karmaşıklık ve sürekli bakım gerektiren çoklu bileşen yapıları (Sidecar, Store Gateway, Querier vb.), mühendislerin platform geliştirmek yerine sadece kendi izleme altyapısını korumaya odaklanmasına neden olan büyük bir zaman kaybına yol açtı.
Hepsiburada'nın tercih ettiği VictoriaMetrics, Prometheus ile tam uyumlu yüksek performanslı bir seri zaman veritabanıdır ve doğuştan küme desteği sunar. Bu çözümün benimsenmesinin ardındaki temel nedenler oldukça netti.
İlk etapta en çok dikkat çeken nokta üstün sıkıştırma verimliliği oldu. Aynı miktardaki veri, VictoriaMetrics içinde çok daha az yer kaplıyor; bu da depolama maliyetlerini doğrudan düşürüyor ve büyüme için bir engel olmaktan çıkarıyor. Bu sayede artık uzun süreli veri saklama zorunluluğu üzerindeki finansal kısıtlamalar ortadan kalktı.
İkinci kritik özellik, sorgu hızının yerel diskten faydalanmasıdır. Veri, genel nesne depolama alanları yerine doğrudan lokal PVC'ler üzerinde tutulur ve bu sayede sorgular S3’e ağ üzerinden gidip gelmesine gerek kalmaz; veri diskten anında okunur. Bu durum, aylara yayılan dönemleri içeren geniş aralık sorgularının bile saniyeler içinde sonuç vermesini sağlıyor.
Tasarımı da oldukça sade tutulmuştur. vminsert, vmselect ve vmstorage olmak üzere üç temel bölümden oluşması, gereksiz yan hizmetler (sidecar) veya sıkıştırıcılar kullanma ihtiyacını ortadan kaldırır; bu da sistemin daha az hata noktasına sahip ve bakımı çok daha kolay olması anlamına gelir.
Apple, macOS 27.0.1 Golden Gate, macOS Tahoe 26.7.1 ve macOS Sequoia 15.8.1 güncellemelerini yayınladı.
Henüz yorum yapılmamış. İlk yorumu sen yap!
E-posta adresiniz yayımlanmayacaktır. Gerekli alanlar (*) ile işaretlenmiştir.
