Veritabanları için Kapasite Planlaması

Not: Bu gönderi, Julia Evans'ın kapasite planlamasıyla ilgili son gönderisinden esinlenmiştir.

RDBMS

İlk olarak, bazı temel kurallar belirleyelim. Evet… bu gönderi, MySQL'i aynı anda tek bir yazarla ve 2 veya daha fazla okuma kopyasıyla kullananlarımız için hazırlanmıştır. Burada bahsedeceğim şeylerin çoğu, çok yazarlı kümelenmiş veri depoları için farklı şekilde uygulanır veya hiç uygulanmaz, ancak bunlar kendi tavizleri ve uyarıları ile birlikte gelir. Yani… kilometreniz kesinlikle değişecektir.

Bununla birlikte, bu blog gönderisi, kendi kendine barındırılan fiziksel ana bilgisayarları kullanmanıza veya sihir benzeri ayrılmış örnekleri ve neredeyse anında sağlamayı kullanabileceğiniz AWS'de olmanıza bakılmaksızın UYGULANACAKTIR. “Bulutta” olmak, altyapınızın yeteneklerini ve sınırlarını bilmenizi engellemez ve ekibinize ve müşterilerinize karşı bu sorumluluktan sizi kurtarmaz.

parçalama

Daha önceki yazılarımdan birinde bununla ilgili büyük vuruşları zaten ele aldım, çoğunlukla orada işlevsel veya yatay parçalamanın faydalarına odaklandım. Evet, bu mutlak bir ön koşuldur, çünkü veritabanı katmanına erişmek için kullandığınız şey, ne kadar esneklik ölçeklendirmeniz gerektiğine karar verir.

Yepyeni bir şirketseniz, 1. günde işlevsel parçalamaya ihtiyacınız olmayabilir, ancak büyümeyi umuyorsanız (ve yaptığınızdan şüpheleniyorum), bölünmenize izin vermeyecek açık kaynaklı bir ORM ile kendinizi kutulamayın. verilerinizi işlevsel bir temelde. Şirketinizi tüm ilişkisel verilerinizle tek bir şemada başlatmazsanız da bonus puanlar.

Okuma ve yazma işlemlerini bölme yeteneği

Bu, yapabilmeniz gereken, ancak kesin bir kural olarak zorunlu olarak uygulamanız gerekmeyen bir şeydir. Bir yazmanın çok kısa bir süre sonra okunması gereken ve gecikme/nihai tutarlılık gibi şeylere toleransın düşük olduğu kullanım durumları olacaktır. Bunların olması sorun değil, ancak aynı uygulamalarda, daha uzun bir nihai tutarlılık zamanını tolere edebilen okumalar için senaryolarınız da olacak. Bu tür okumalar yüksek hacimli olduğunda, gerçekten gerekmiyorsa, bu cildin tek yazarınıza gitmesini gerçekten istiyor musunuz? Kendinize bir iyilik yapın ve büyüme günlerinizde kodunuzda okuma veya yazma IP kullanımını kontrol edebileceğinizden emin olun.

Şimdi gerçek kapasite planlamasının düşünce sürecine gelelim… Bir veritabanı kümesi yetişmiyor, ne yapmalıyım?

Sistem darboğazını belirleyin

• Yazma veya okuma konusunda darboğaz mı yaşıyorsunuz?
• Sorun yüksek CPU olarak mı gösteriliyor?
• IO kapasitesi olarak mı sergileniyor?
• Net bir okuma sorgusu suçlusu olmadan kopyalarda gecikme büyüyor mu?
• Kilitler mi?
• Hangisi olduğunu nereden bileyim?

Bunların her biri kendi başına bir gönderi olabilir. Yapmaya çalıştığım nokta, hangi parçanın darboğaz olduğunu bulabilmek için sisteminize ve DB'ye özgü metriklere aşina olmanız gerektiğidir.

Bir temele ihtiyacınız var

Her zaman en az birkaç hafta önce görselleştirebileceğiniz temel sistem ölçümlerine sahip olduğunuzdan emin olun. Birçok araç bunu sağlar (Cacti, Munin, Graphite…vs). En çok hangi sistem metriğine bağlı olduğunuzu öğrendikten sonra, temel ve tepe değerleri belirlemeniz gerekir. Aksi takdirde, mevcut sorununuzun yeni bir uygulama kaynaklı hata mı yoksa gerçek büyüme mi olduğunu belirlemek, istediğinizden çok daha fazla hataya açık olacaktır.

Bununla birlikte, temel sunucu ölçümleri yalnızca bir yere kadar gidebilir - bir noktada bağlam tabanlı ölçümlere de ihtiyacınız olduğunu göreceksiniz. Sorgu performansı ve uygulama tarafında algılanan performans, uygulamanın sorgulara yanıt süresi olarak ne gördüğünü size söyleyecektir. Bu bağlamda yoğun izleme yapmak için birçok araç vardır. Bazıları Anemometer gibi açık kaynak ve Vivid Cortex gibi ticari araçlardır (Bunları SendGrid'de kullanıyoruz. Bakın burada bunun hakkında konuşalım.) Sadece bu metrikleri uygulama perspektifinden takip etmek ve onları statsd metrikleri olarak atmak bile iyi bir ilk adım olacaktır. Ancak, uygulamanızın algıladığı şeyin müşterilerinizin algıladığı şey olduğu gerçeğine erkenden alışmalısınız. Ve önce bilmenin bir yolunu bulmalısın.

İşletmenizin trafik modellerini öğrenin

Belirli hafta içi günlerde (örneğin pazarlama) aşırı zirvelere duyarlı bir işletme misiniz? Trafiğinizi oyun oynamak gibi üçe veya dört katına çıkaran düzenli lansmanlarınız var mı? Bu tür sorular, ne kadar ayrılmış boşluk bırakmanız gerektiğini veya esnek büyümeye yatırım yapmanız gerekip gerekmediğini belirleyecektir.

Kullanımdaki kapasiteye göre ham trafik sayılarının oranını belirleyin

Bu sadece, “Kod optimizasyonu yapmasaydık, kaç e-posta/satış/çevrimiçi kullanıcı/her neyse” sorusunun cevabı şu anda elimizdeki veritabanı örnekleriyle hizmet verebilir miyiz?

İdeal olarak, bu, bir yıllık büyümeyi planlamaya yönelik matematiği basit bir matematik denklemi yapan belirli bir değerdir. Ancak hayat asla ideal değildir ve bu değer mevsime veya yeni bir büyük müşteriye kaydolmak gibi tamamen dışsal mutlu faktörlere bağlı olarak değişecektir. Erken başlangıçlarda bu sayı daha hızlı hareket eden bir hedeftir, ancak şirket ilk günlerden daha öngörülebilir iş büyüme modelleriyle daha yerleşik işlere geçerken istikrar kazanmalıdır.

Gerçekten daha fazla makine almam gerekiyor mu?

Bunun gerçekten kapasite olup olmadığını belirlemenin bir yolunu bulmanız gerekiyor; daha fazla eşzamanlı yazma yükünü desteklemek için yazmaları bölmem veya daha fazla okuma kopyası eklemem gerekiyor. kod tabanlı performans darboğazı (yakın zamanda yapılan bir dağıtımdan gelen bu yeni sorgu, sonuçlarının gerçekten daha ucuz bir şeyde önbelleğe alınmasını sağlayabilir ve veritabanını o kadar fazla geçemez).

Bunu nasıl yaptın? Sorgularınıza aşina olmanız gerekir. Bunun için ilk adım, innotop, yavaş günlük ve Percona Toolkit'in pt-sorgu özetinin bir birleşimidir. Veritabanı günlüklerini merkezi bir konuma göndererek ve özet bölümünü otomatikleştirerek bunu otomatikleştirebilirsiniz.

Ancak bu aynı zamanda resmin tamamı değildir, eşiklerini çok fazla düşürürseniz yavaş günlükler performans açısından yoğundur. Daha az seçici örnekleme ile yaşayabiliyorsanız, uygulama ile veri deposu arasındaki tüm konuşmaları algılamanız gerekecektir. Açık kaynaklı arazide tcpdump kadar basit gidebilir veya Datadog, New Relic veya VividCortex gibi barındırılan ürünleri kullanabilirsiniz.

Arama yap

Kapasite planlaması, %90 bilim ve %10 sanat olabilir, ancak bu %10, resmin mümkün olduğu kadar büyük bir kısmı için çabalamamamız gerektiği anlamına gelmemelidir. Mühendisler olarak bazen eksik %10'u sabitleyebiliriz ve işi yaparsak, %90'ın yığınımızın sağlığı, zamanımızı optimize etme performansımızı ve planlama kapasitemizi daha verimli kullanma konusunda bizi çok daha iyi bir fikre götürebileceğini fark edemeyiz. dikkatli bir şekilde artar ve bu da nihayetinde ürünlerimiz için çok daha iyi bir yatırım getirisi sağlar.