M365Con 2027 – konferensi online gratis · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

IOPS vs. Throughput: Memilih Metrik Performa yang Tepat untuk Database Anda

By · · Updated

Ketika arsitek dan administrator database merancang infrastruktur berperforma tinggi untuk beban kerja berat seperti SQL Server, mereka sering dihadapkan pada rentetan akronim teknis dan spesifikasi penyimpanan. Di antara yang paling krusial, namun sering disalahpahami, adalah IOPS dan throughput. Salah memilih metrik saat menyediakan penyimpanan dapat menyebabkan kueri lambat, sistem yang tersend

Automatically translated with AI from the original post. Read the English original

Cover: Azure Elastic SAN — Simply Explained

Ketika arsitek dan administrator database merancang infrastruktur berperforma tinggi untuk beban kerja berat seperti SQL Server, mereka sering dihadapkan pada rentetan akronim teknis dan spesifikasi penyimpanan. Di antara metrik yang paling krusial, namun sering disalahpahami, adalah IOPS dan throughput. Memilih metrik yang keliru saat menyediakan penyimpanan dapat menyebabkan kueri lambat, sistem yang tersendat, dan anggaran yang terbuang. Memahami bagaimana database Anda sebenarnya membaca dan menulis data adalah langkah pertama untuk membangun arsitektur yang tangguh.

Dalam artikel ini, kita akan menguraikan perbedaan mendasar antara IOPS dan throughput, membahas penerapannya pada beban kerja database yang intensif, meninjau hambatan arsitektur yang umum seperti batas mesin virtual, dan menjelaskan bagaimana model penyimpanan bersama mengubah situasi bagi lingkungan cloud modern.

Pengantar Metrik Performa Database

Performa penyimpanan tidak bisa diukur dengan satu standar untuk semua. Ketika Anda melihat penyimpanan cloud atau perangkat SAN tradisional, vendor akan menyebutkan angka-angka mengesankan tentang seberapa cepat data dapat dipindahkan dan berapa banyak operasi yang dapat diproses sebuah disk. Namun, mesin database berperilaku sangat berbeda dibandingkan layanan streaming video atau server file berskala besar. Jika server video perlu mengalirkan aliran data besar yang berkesinambungan melalui sebuah saluran, database menghabiskan waktunya untuk mencari baris tertentu, memperbarui log transaksi, dan menyimpan halaman di memori.

Agar lingkungan Anda tidak goyah di bawah tekanan, Anda harus terlebih dahulu memahami karakter berbeda dari beban kerja Anda. Langkah ini dimulai dengan pembahasan mendalam tentang dua pilar performa penyimpanan: Input/Output Operations Per Second (IOPS) dan Megabytes per Second (Throughput).

Mendefinisikan IOPS: Mengapa Database Mengandalkan Pembacaan dan Penulisan Kecil

IOPS adalah singkatan dari Input and Output Operations Per Second. Ini adalah ukuran berapa banyak permintaan penyimpanan individual yang dapat ditangani sebuah perangkat dalam satu detik. Untuk platform database intensif seperti SQL Server, IOPS biasanya menjadi metrik yang paling utama.

Database bersifat transaksional secara alami. Ketika pengguna masuk ke sebuah aplikasi, database biasanya tidak membaca atau menulis file berukuran besar bergigabyte sekaligus. Sebaliknya, database melakukan ribuan operasi kecil dan terarah. Database mungkin membaca halaman data 8KB untuk mengambil profil pengguna, menulis beberapa ratus byte ke log transaksi, atau memperbarui indeks. Karena operasi-operasi ini sangat kecil, kemampuan subsistem penyimpanan dalam memproses volume perintah individual yang tinggi, yaitu kapasitas IOPS-nya, menjadi penggerak utama performa. Jika database Anda membutuhkan 10.000 IOPS untuk mengimbangi transaksi pengguna, tetapi disk penyimpanan Anda hanya mampu memberikan 3.000, kueri Anda akan menumpuk dalam antrean, kunci (lock) akan saling berantai, dan waktu respons aplikasi akan anjlok.

Mendefinisikan Throughput: Kapan Bandwidth Paling Berpengaruh

Jika IOPS mengukur *jumlah* operasi, throughput mengukur *volume* data yang dipindahkan dalam periode tertentu, biasanya dinyatakan dalam megabyte per detik (MB/s). Anggaplah IOPS sebagai jumlah mobil yang melintas di jalan raya, dan throughput sebagai total beban muatan yang mereka bawa.

Ada skenario ketika throughput jauh lebih penting daripada IOPS. Pertimbangkan rutinitas backup database harian, impor data warehouse berskala besar, atau kueri analitik yang memindai jutaan baris dalam sebuah tabel. Tugas-tugas ini tidak terlalu peduli berapa banyak permintaan individual yang diproses per detik; yang mereka pedulikan adalah seberapa cepat aliran data berat yang berkesinambungan dapat dimasukkan atau diekspor. Jika Anda mencoba menjalankan migrasi data besar pada penyimpanan yang memiliki IOPS tinggi tetapi batas throughput rendah, Anda akan mendapati migrasi memakan waktu berjam-jam lebih lama dari perkiraan karena saluran data tidak cukup lebar.

Memetakan Beban Kerja Aplikasi ke Konfigurasi Penyimpanan

Setiap aplikasi di perusahaan Anda memiliki karakter penyimpanan yang unik. Keberhasilan dalam merancang lingkungan Anda bergantung pada pemetaan pola baca dan tulis yang spesifik tersebut ke konfigurasi penyimpanan yang tepat. Misalnya, database pemrosesan transaksi (OLTP) membutuhkan kemampuan IOPS tinggi untuk menangani permintaan pengguna yang bersamaan tanpa lonjakan latensi. Sebaliknya, data lake atau server pelaporan mungkin membutuhkan throughput tinggi untuk mengolah kueri analitik.

Tantangannya muncul ketika sebuah lingkungan menjalankan beberapa beban kerja dengan pola yang saling bertentangan. Database SQL bisa mencapai puncak beban saat pelaporan keuangan akhir bulan, server pelaporan bisa melonjak setiap pagi pukul 08.00, dan sistem backup bisa membanjiri jaringan dengan lalu lintas data semalaman. Secara historis, administrator akan menyediakan disk terpisah untuk setiap puncak beban tersebut, yang berujung pada over-provisioning besar-besaran dan sumber daya yang menganggur.

Hambatan Mesin Virtual: Lebih dari Sekadar Disk

Meskipun Anda menghitung kebutuhan IOPS dan throughput database secara cermat lalu menyediakan disk tercepat yang tersedia, Anda tetap bisa menghadapi batas performa yang serius. Penyebabnya sering kali bukan media penyimpanannya sendiri, melainkan mesin virtual tempat disk tersebut terpasang.

Misalnya, mesin virtual Azure menerapkan batas ketat untuk total IOPS dan throughput disk, bergantung pada ukuran dan tier VM yang Anda pilih. Anda bisa memasang disk kelas enterprise yang sangat cepat ke ukuran VM yang sederhana, tetapi VM tersebut akan membatasi lalu lintas penyimpanan pada ambang maksimumnya sendiri. Sistem penyimpanan mungkin mampu menghasilkan 20.000 IOPS, tetapi jika jalur mesin virtual hanya membatasi hingga 10.000 IOPS, maka angka itulah batasnya. Selalu audit spesifikasi disk dan ukuran komputasi Anda untuk memastikan jalur di antara keduanya cukup lebar untuk menangani beban puncak Anda.

Bagaimana Shared Storage Pool Mengubah Perencanaan Performa

Untuk memutus siklus penyediaan disk yang terisolasi dan berukuran terlalu besar untuk setiap beban kerja, arsitektur cloud modern beralih ke shared storage pool, yang mengingatkan pada Storage Area Network (SAN) tradisional. Alih-alih mengurung performa di dalam wadah terpisah yang kaku, model bersama menggabungkan kapasitas dan IOPS ke dalam satu kumpulan.

Dalam lingkungan yang memanfaatkan sumber daya gabungan, metrik performa meningkat seiring kapasitas. Misalnya, di Azure Elastic SAN, setiap 1 TiB kapasitas dasar berkontribusi pada jumlah performa tertentu, seperti 5.000 IOPS dan throughput 200 MB per detik, ke sebuah pool pusat. Pool bersama ini memungkinkan volume yang berbeda mengambil dari satu anggaran performa yang sama. Jika database keuangan Anda membutuhkan lonjakan IOPS selama siklus pelaporan yang padat sementara sistem gudang data Anda sedang sepi, sumber daya tersebut dapat menyesuaikan diri secara dinamis untuk mendukung beban kerja yang aktif.

Menghindari Titik Hambatan: Menyeimbangkan Beban Puncak dan Batas Bersama

Meskipun shared storage pool menawarkan fleksibilitas dan penghematan biaya yang luar biasa, pool ini bukan solusi ajaib untuk performa tanpa batas. Menggabungkan sumber daya berarti Anda bergantung pada kemungkinan statistik bahwa tidak setiap database akan mencapai permintaan puncaknya pada milidetik yang sama.

Jika beberapa beban kerja intensif melonjak bersamaan dan total permintaannya melampaui batas pool bersama, throttling akan terjadi. Throttling menimbulkan latensi, memperlambat query, dan dapat memicu timeout aplikasi yang berantai. Database administrator dan perencana infrastruktur harus menganalisis metrik historis secara cermat, memahami jumlah penggunaan bersamaan pada puncaknya, serta memastikan shared storage pool diukur dengan ruang cadangan yang cukup untuk menyerap beban puncak yang tumpang tindih tanpa kesulitan berarti.

Kesimpulan: Memilih Metrik yang Tepat untuk Database Anda

Menguasai keseimbangan antara IOPS dan throughput sangat penting bagi siapa pun yang mengelola beban kerja database intensif di cloud. Dengan mendiagnosis secara akurat apakah aplikasi Anda kekurangan operasi kecil yang cepat atau bandwidth data yang besar, Anda dapat menghindari hambatan performa yang mahal. Selain itu, mengadopsi paradigma penyimpanan modern seperti shared pool dapat meningkatkan efisiensi secara signifikan, memastikan infrastruktur Anda berskala secara cerdas seiring pertumbuhan bisnis. Untuk mempelajari lebih dalam bagaimana arsitektur penyimpanan cloud modern mengatasi tantangan skala dan performa ini, pastikan Anda menonton episode podcast terkait: Azure Elastic SAN — Simply Explained.

Entities in this article

IOPS Virtual machine Azure Elastic SAN Caching Throttling

Related articles

RSS