Perencanaan Kapasitas untuk Database

Catatan: Postingan ini terinspirasi dari postingan terbaru Julia Evans tentang perencanaan kapasitas.

RDBMS

Pertama, mari kita buat beberapa aturan dasar. Ya…postingan ini ditujukan bagi kita yang menggunakan MySQL dengan satu penulis sekaligus dan 2 atau lebih replika baca. Banyak dari apa yang akan saya bicarakan di sini berlaku secara berbeda, atau tidak sama sekali, untuk penyimpanan data berkerumun multi-penulis, meskipun itu juga datang dengan serangkaian kompromi dan peringatan mereka sendiri. Jadi… jarak tempuh Anda pasti akan bervariasi.

Namun, entri blog ini AKAN berlaku terlepas dari apakah Anda menggunakan host fisik yang dihosting sendiri atau berada di AWS tempat Anda dapat menggunakan instans cadangan seperti ajaib dan penyediaan hampir instan. Berada di "awan" tidak akan menghalangi Anda untuk mengetahui kemampuan dan batasan infrastruktur Anda dan itu tidak akan membebaskan Anda dari tanggung jawab tersebut terhadap tim dan pelanggan Anda.

pecahan

Saya telah membahas goresan besar ini di salah satu posting saya sebelumnya, saya sebagian besar fokus di sana pada manfaat sharding fungsional atau horizontal. Ya, itu adalah prasyarat mutlak, karena apa yang Anda gunakan untuk mengakses lapisan basis data AKAN menentukan seberapa besar fleksibilitas yang harus Anda skalakan.

Jika Anda adalah perusahaan baru, Anda mungkin tidak memerlukan sharding fungsional pada hari 1 tetapi, jika Anda berharap (dan saya kira Anda melakukannya) untuk tumbuh, jangan memasukkan diri Anda ke dalam ORM open source yang tidak memungkinkan Anda untuk berpisah data Anda secara fungsional di telepon. Poin bonus jika Anda juga tidak memulai perusahaan dengan semua data relasional Anda dalam satu skema.

Kemampuan untuk membagi membaca dan menulis

Ini adalah sesuatu yang Anda harus bisa lakukan, tetapi tidak harus ditegakkan sebagai aturan baku. Akan ada kasus penggunaan di mana penulisan perlu dibaca segera setelahnya dan di mana toleransi untuk hal-hal seperti lag/konsistensi akhirnya rendah. Itu boleh untuk dimiliki, tetapi dalam aplikasi yang sama, Anda juga akan memiliki skenario untuk pembacaan yang dapat mentolerir rentang waktu yang lebih lama dari konsistensi akhirnya. Ketika bacaan seperti itu dalam volume tinggi, apakah Anda benar-benar ingin volume itu masuk ke penulis tunggal Anda jika tidak benar-benar harus? Bantulah diri Anda sendiri, dan pastikan segera di hari-hari pertumbuhan Anda bahwa Anda dapat mengontrol penggunaan IP baca atau tulis dalam kode Anda.

Sekarang ke proses pemikiran perencanaan kapasitas aktual…Sebuah cluster database tidak mengikuti, apa yang harus saya lakukan?

Tentukan hambatan sistem

• Apakah Anda mengalami hambatan dalam menulis atau membaca?
• Apakah masalah menunjukkan CPU yang tinggi?
• Apakah itu menunjukkan sebagai kapasitas IO?
• Apakah ada kelambatan pada replika tanpa penyebab kueri baca yang jelas?
• Apakah itu kunci?
• Bagaimana saya tahu yang mana itu?

Masing-masing dapat menjadi posting dengan sendirinya. Poin yang saya coba sampaikan adalah Anda harus terbiasa dengan sistem Anda dan metrik spesifik DB untuk dapat mengetahui bagian mana yang menjadi hambatan.

Anda membutuhkan dasar

Selalu pastikan Anda memiliki metrik sistem dasar yang tersedia untuk divisualisasikan setidaknya beberapa minggu yang lalu. Banyak alat yang menyediakan ini (Cacti, Munin, Graphite…dll). Setelah Anda mengetahui metrik sistem apa yang sebagian besar terikat dengan Anda, Anda perlu menetapkan nilai dasar dan nilai puncak. Jika tidak, menentukan apakah masalah Anda saat ini adalah bug yang bersumber dari aplikasi baru vs. pertumbuhan nyata akan lebih rawan kesalahan daripada yang Anda inginkan.

Namun, metrik server dasar hanya dapat berjalan sejauh ini–pada titik tertentu Anda akan menemukan bahwa Anda juga memerlukan metrik berbasis konteks. Kinerja kueri dan kinerja yang dirasakan sisi aplikasi akan memberi tahu Anda apa yang dilihat aplikasi sebagai waktu respons terhadap kueri. Ada banyak alat untuk melakukan pelacakan berat konteks ini. Beberapa open source seperti Anemometer dan alat komersial seperti Vivid Cortex (Kami menggunakan ini di SendGrid. Lihat kami membicarakannya di sini.) Bahkan hanya melacak metrik ini dari perspektif aplikasi dan melemparkannya sebagai metrik statsd akan menjadi langkah pertama yang baik. Namun, sejak awal Anda harus terbiasa dengan kenyataan bahwa apa yang dirasakan oleh aplikasi Anda adalah apa yang dirasakan oleh pelanggan Anda. Dan Anda harus menemukan cara untuk mengetahuinya terlebih dahulu.

Pelajari pola lalu lintas bisnis Anda

Apakah Anda bisnis yang rentan terhadap puncak ekstrem di hari kerja tertentu (misalnya pemasaran)? Apakah Anda memiliki peluncuran reguler yang melipatgandakan atau melipatgandakan lalu lintas Anda seperti bermain game? Pertanyaan-pertanyaan semacam ini akan mendorong seberapa banyak ruang kepala cadangan yang harus Anda simpan atau apakah Anda perlu berinvestasi dalam pertumbuhan elastis.

Tentukan rasio jumlah lalu lintas mentah dalam kaitannya dengan kapasitas yang digunakan

Ini hanyalah jawaban untuk, “Jika kami tidak melakukan pengoptimalan kode, berapa banyak email/penjualan/pengguna online/apa pun” yang dapat kami layani dengan instans database yang kami miliki saat ini?

Idealnya, ini adalah nilai khusus yang membuat matematika menuju perencanaan pertumbuhan satu tahun persamaan matematika sederhana. Tetapi hidup tidak pernah ideal dan nilai ini akan bervariasi tergantung pada musim atau faktor-faktor bahagia yang sepenuhnya eksternal seperti mendaftar pelanggan utama baru. Pada startup awal, jumlah ini adalah target yang bergerak lebih cepat tetapi harus stabil karena transisi perusahaan dari hari-hari awal ke bisnis yang lebih mapan dengan pola pertumbuhan bisnis yang lebih dapat diprediksi.

Apakah saya benar-benar perlu membeli lebih banyak mesin?

Anda perlu menemukan cara untuk menentukan apakah ini benar-benar kapasitas–saya perlu membagi penulisan untuk mendukung lebih banyak beban tulis bersamaan atau menambahkan lebih banyak replika baca–vs. kemacetan kinerja berbasis kode (kueri baru ini dari penerapan baru-baru ini benar-benar dapat membuat hasilnya di-cache dalam sesuatu yang lebih murah dan tidak mengalahkan database sebanyak itu).

Bagaimana kamu melakukannya? Anda harus terbiasa dengan pertanyaan Anda. Langkah awal untuk itu adalah kombinasi dari innotop, log lambat, dan pt-query-digest dari Percona Toolkit. Anda dapat mengotomatiskan ini dengan mengirimkan log DB ke lokasi pusat dan mengotomatiskan bagian intisari.

Tapi itu juga bukan gambaran keseluruhannya, log lambat adalah kinerja intensif jika Anda menurunkan ambang batasnya terlalu banyak. Jika Anda dapat hidup dengan pengambilan sampel yang kurang selektif, Anda perlu mendeteksi seluruh percakapan antara aplikasi dan penyimpanan data. Di lahan open source Anda dapat menggunakan tcpdump atau Anda dapat menggunakan produk yang dihosting seperti Datadog, New Relic, atau VividCortex.

Menelpon

Perencanaan kapasitas dapat berupa 90% sains dan 10% seni, tetapi 10% itu tidak berarti bahwa kita tidak boleh berusaha keras untuk mendapatkan gambaran sebanyak yang kita bisa. Sebagai insinyur, terkadang kita dapat terpaku pada 10% yang hilang dan tidak menyadari bahwa jika kita melakukan pekerjaan, 90% itu dapat membawa kita jauh ke dalam gagasan yang lebih baik tentang kesehatan tumpukan kita, penggunaan waktu kita yang lebih efisien, mengoptimalkan kinerja, dan kapasitas perencanaan meningkat dengan hati-hati yang pada akhirnya menghasilkan pengembalian investasi yang jauh lebih baik untuk produk kami.