Bu yazıyı uzun zamandır üzerine düşündüğümüz ve bulduğumuz bir çözüm üzerine ele alıyorum. Bu yazımızın temel amacı PEAKUP Azure Services paketini neden geliştirdiğimizle doğrudan alakalıdır. Ek olarak doğru kullanım noktasında, ölçeklendirme ile ilgili problemlerin Azure üzerinde aslında çok az maliyetler ile nasıl çözülebildiğini göstermektir. Bu yazının kapsamı ve faydası, birden fazla veritabanı yönetimi, Azure SQL Sunucu üzerinde veritabanlarının bakımını ve performansını arttırmak üzeredir.
Yazının girişinde bahsettiğimiz paketi geliştirirken Azure üzerinde deneyimlediğimiz bir ilginç şeyse, REST üzerinden iletilen tüm Scale Up/Down taleplerinin portal.azure.com üzerinden yapılan taleplerden belkide iki katı kadar kısa bir sürede gerçekleşmesiydi!
Vaka
PEAKUP’ın Velocity ürünü içerisinde yer alan bazı müşterilerimizin kayıtları yüz binleri bazıları da milyonları bulabiliyor. İlerleyen zamanlarda yüz milyonlara hatta milyarlara kadar ulaşacağından eminim. Bu nedenle gerekli bakım stratejilerini daha baştan, en doğru ve pratik şekilde kurgulamak son derece değerli! Ürün içerisinde tek bir veritabanı içerisinde Multi Tenant bir yapı uygularken aynı zamanda KVKK gereği bulut kaynakları kullanmayan müşterilerimiz için yerel sunucu desteği sunuyoruz ya da müşterilerimizin kendilerine ait Azure kaynakları içerisinde tuttukları veritabanlarını da kullanabiliyoruz. Yani bir veritabanı üzerinde birden fazla Multi Tenant yapının yanında birden fazla veritabanı üzerinde de yine birden fazla Multi Tenant bir mimariden bahsediyoruz.
Velocity platformunun her zaman erişime açık olması, her zaman yüksek ve ayrıca aynı performansta olması ürün için ortaya koyduğumuz en önemli prensiplerden yalnızca bir kaçı arasında yer alıyor. Genel olarak kullanım, iş dünyasına hitap ettiği içini iş günleri ve çalışma saatleri içerisinde çok yüksek olsa da mavi yakanın ağırlıklı olduğu ve 24 saat operasyonun devam ettiği müşterilerimizde gece kullanımı da oldukça yüksek oluyor. Bu nedenle bakım süreçlerinin kullanımın görece daha az az saatlerde olduğu zamanlarda olsa da kesinlikle platformu durdurmaması ya da herhangi bir yavaşlığa, kesintiye sebep olmaması gerekiyor. Söz konusu yedi gün yirmi dört saat devam eden bir operasyon olduğunda sürekli erişebilirlik taviz verilebilecek bir konu opsiyonundan çıkıyor.
Sürekli büyüyen veritabanlarında, veritabanının sürekli, doğru ve düzgün bir şekilde yedeklenmesi, verilerin sürekli olarak sıralı bir şekilde depolandığını kontrol etmek veritabanı ölçeklendirme konusundaki en kritik operasyonlardan birisidir. Yedekleme safhası Azure tarafından otomatik olarak yönetildiği için bu yük üzerinizden kalksa da Index’lerin bakımları, Partition’ların gerekli zamanlarda tekrar yapılandırılmaları gibi konular veritabanı üzerinde ciddi anlamda yük yaratan operasyonların başında gelir. Azure SQL içerisinde sorguların performanslarını takip etmek, yavaş sorguları tespit edip bunlar için aksiyon almak “Database recommendations” bölümündeki tavsiyeler eşliğinde kolayca yapılsa da, bakım süreçlerinde bu aksiyonları almaya başladığınızda veritabanı performansıyla ilgili ciddi sorunlar sizleri bekliyor. Üstelik bu problem, On Premise olarak çalışan SQL sunucuları için oldukça güç! İşte bunun için doğru zamanda, doğru miktarda kaynak kullanımı son derece kritik rol oynuyor.
Veritabanın sahip olduğu sunucu tipi(enterprise, developer, express vb.) bir çok geliştirici tarafından çok önem arz etmese de söz konusu bakım olduğunda böylesi kriterlerin değeri ortaya çıkıyor. Zira SQL Server Enterprise içerisinde Index bakımları Online olarak yapılabilirken, system içerisinde herhangi bir duraksama söz konusu olmaktan çıkıyor. Ancak veritabanının kullandığı kaynaklar ve bakımların süresiyle ilgili problemler, problem olmaya devam ediyor. Şu da unutulmamalıdır ki veritabanı üzerinde yapılan her Index, her Partition operasyonu performasın artacağı garantisini vermez… Zira diskin büyümesine haliyle SQL Server tarafından belleğe alınan verinin daha da büyük hale gelmesiyle kaynak kullanımı bir yerden sonra yetersiz oluyor. Özellikle söz gelimi olarak 1, 2, 4 ve 14 hafta olacak şekilde bir Retention Policy, veritabanı üzerinde her zaman yükün artacağını bunun yanı sıra bakım konularının kritik seviyesini en üst seviyeye çekiyor.
Bakım süreçlerinin en hızlı şekilde yapılması hem kullanıcı memnuniyeti, hem ölçeğin sürekli olarak arttırılabilir noktada olması hem de itibar açısından son derece önemli bir hale geliyor. İşte bu nedenle Azure üzerinde kaynakları ihtiyacınız olduğu anda dilediğiniz kadar arttırabilmek ya da azaltabilmek (Scale Up/Scale Down) son derece kilit bir rol oynuyor. Üstelik sadece süreç olarak değil maliyet olarak da!
İhtiyacımız olan senaryo, bakım süresi öncesinde kullandığımız veritabanı planını bir ya da iki üst seviyedeki kaynak oranında arttırmak ve bakım sonrasında eski kaynaklara geri dönebilmek… Böylece arttırılan kaynakların bir kısımı bakım kalan kısmı da platformun düzenli bir şekilde devam etmesi için hazır olarak bekliyor!
Üstelik bu operasyon sırasında, hiçbir bakım işleminin zaman aşımına uğramaması ve bakım sürecini en baştan tekrar başlatmamak ya da veritabanının kilitlenmesi gibi çok büyük riskleri ortadan kaldırmak… Böylece veritabanı üzerindeki maliyete sadece saatlik fiyatlar ile katlanırken, belkide 3-4 saat kadar sürecek bir operasyonu dakikalar içerisinde tamamlayabilmek!
Söz konusu problemlerin bir de, birden fazla sunucunun ya da birden fazla veritabanının olduğu noktalarda problem daha da karmaşıklaşıyor. Zira bir veritabanı ile ilgili böyle bir işlemi haftada bir, elle yapmak çok ciddi vakit almaz ya da kendi içerisinde büyük riskler barındırmaz. Ancak birden fazla sunucu, birden fazla veritabanı ve tüm bunların yanında bakımın yapılma sıklığını düşündüğümüz zaman süreci otomatize etmek artık zorunlu hale geliyor.
Yakın zamanda, PEAKUP olarak sahip olduğumuz bu çözümü Azure’ın REST API istekleriyle çözülebileceğini zaten tahmin ediyorduk. Ancak programatik olarak olması, ilgili sorunu olası bir durumda diğer ürünlerimizde ve hizmetlerimizde kullanabileceğimiz şekilde çözülmesi bizim için en önemli noktalardan birisiydi. Bu nedenle PEAKUP Azure Services çözümünü ele aldık. İlgili kaynak kod içerisinde, yalnızca SQL ile ilgili sorunları değil ek olarak, Web Application konusunda da benzer problemleri keşfedebileceğiniz çözümleri de bulabilirsiniz.
