Merencanakan penyebaran Azure Database for PostgreSQL untuk performa operasional

Komputasi cloud secara dramatis membentuk ulang lanskap hosting database. Ini memberi tim akses ke skalabilitas, ketahanan, jangkauan global, dan kemampuan yang sebelumnya tidak dapat dipertahankan. Alih-alih menanggung biaya dan overhead yang cukup besar dengan merencanakan beban kerja terbesar yang mungkin (dan membawa biaya itu sejak hari pertama), tim sekarang dapat mengoptimalkan skala yang tepat sesuai kebutuhan mereka saat mereka membutuhkannya, dan menyesuaikan saat tuntutan mereka berubah.

Introduction

Fleksibilitas untuk memilih keseimbangan sumber daya yang sesuai sangat berharga untuk penyebaran database PostgreSQL. Beban kerja database PostgreSQL mungkin dimulai dari yang kecil, tumbuh dengan cepat, melonjak secara musiman, bergeser dari dominan pembacaan ke dominan penulisan, atau berevolusi dari beban kerja transaksional menjadi sistem operasional dan analitik hybrid secara waktu nyata. Azure Database for PostgreSQL memastikan solusi Anda mencapai target Anda dengan menawarkan berbagai pilihan di seluruh komputasi, penyimpanan, ketersediaan, replikasi, keamanan, pencadangan, dan manajemen operasional.

Tetapi dengan semua kekuatan ini datang tanggung jawab, terutama ketika merencanakan penyebaran Anda. Untuk mencapai performa terbaik, keputusan penyebaran Anda harus sesuai dengan persyaratan beban kerja Anda secara keseluruhan.

Penyebaran Azure Database for PostgreSQL yang sukses bukan hanya pertanyaan untuk memilih "inti dan memori terbanyak yang kita butuhkan." Sebaliknya, performa operasional maksimum berasal dari memahami perilaku aplikasi Anda, perilaku klien, komputasi, penyimpanan, dan karakteristik pertumbuhan database, dan bagaimana semua ini bersinggungan dan berinteraksi.

Arsitektur terbaik adalah salah satu di mana potongan-potongan ini sengaja diselaraskan.

Perencanaan performa cloud adalah tanggung jawab bersama

Salah satu manfaat utama pindah ke platform cloud tepercaya adalah model tanggung jawab bersama. Microsoft menyediakan infrastruktur global, layanan terkelola, inovasi perangkat keras, keandalan, keamanan, dan rekayasa operasional. Tim Anda menghadirkan keahlian konteks aplikasi tertentu: kekritisan bisnis, perilaku beban kerja, desain model data, profil lalu lintas jaringan, harapan pertumbuhan, tujuan pemulihan, dan persyaratan pengalaman pengguna akhir.

Hasil terkuat muncul ketika kedua kekuatan ini terpadu.

Azure menyediakan infrastruktur Postgres yang sangat dapat diskalakan, tetapi tim Anda harus membawa wawasan ke bidang-bidang ini:

Berapa banyak pengguna bersamaan yang diharapkan selama periode normal dan puncak?
Apakah operasi yang paling penting memiliki beban baca tinggi, beban tulis tinggi, atau campuran?
Apakah lonjakan permintaan terjadi selama akhir bulan, akhir kuartal, hari libur, peluncuran, atau jendela pelaporan?
Seberapa cepat himpunan data tumbuh?
Operasi mana yang sensitif terhadap latensi?
Kueri atau pekerjaan mana yang dapat mentolerir runtime yang lebih lama?
Apakah beban kerja terutama OLTP, OLAP, atau hibrid?
Apakah klien terletak di dekat wilayah database, didistribusikan secara global, atau terkonsentrasi dalam satu geografi?

Ambil detail ini sebelum penyebaran, bukan setelah insiden produksi. Penyebaran cloud mempermudah penskalan, tetapi desain yang berkinerja tertinggi dan paling hemat biaya masih dimulai dengan pengumpulan persyaratan yang solid dan perencanaan yang baik dan benar. Dalam kebanyakan kasus, pertanyaan-pertanyaan ini dapat disaring ke hubungan di seluruh koneksi bersamaan, IOPS maksimum, dan throughput yang diperlukan.

Performa memiliki beberapa lapisan

Performa database jarang ditentukan oleh satu pengaturan. Pengalaman penyebaran yang berhasil bergantung pada beberapa lapisan yang bekerja sama:

Performa lapisan aplikasi.
Lapisan ini mencakup kode aplikasi, pola kueri, cakupan indeks, penggunaan pemicu, pemartisian data, penanganan koneksi, penembolokan, logika coba lagi, pengumpulan, perilaku ORM, desain transaksi, dan perilaku pekerjaan latar belakang.
Performa lapisan klien dan jaringan.
Lapisan ini mencakup tempat klien berada, bagaimana mereka terhubung, apakah permintaan melintasi wilayah dan zona ketersediaan, latensi jaringan, overhead TLS, churn koneksi, dan apakah aplikasi menggunakan pengelompokan koneksi secara efisien.
Performa database platform.
Lapisan ini mencakup konfigurasi penyebaran Postgres, ukuran komputasi, memori, CPU, jenis penyimpanan, ukuran penyimpanan, IOPS penyimpanan, throughput penyimpanan, ketersediaan tinggi, replika, dan operasi pemeliharaan.

Artikel ini berfokus terutama pada lapisan ketiga: merencanakan penyebaran database Azure Postgres sehingga pilihan komputasi dan penyimpanan mendukung profil performa yang diperlukan.

Azure Database for PostgreSQL menawarkan fleksibilitas, tetapi perencanaan sangat penting

Azure Database for PostgreSQL Flexible Server menyediakan berbagai opsi penyebaran, termasuk:

Area implementasi	Pilihan yang tersedia
Compute	Tingkat komputasi, pembuatan komputer virtual (VM), konfigurasi Tujuan Umum, dan konfigurasi Memori yang Dioptimalkan.
Storage	Azure SSD Premium v1, Premium SSD v2, skala penyimpanan, konfigurasi IOPS, dan konfigurasi throughput.
Availability	Ketersediaan tinggi, pencadangan dan pemulihan, serta pencadangan geo-redundan dalam konfigurasi yang didukung.
Replikasi	Replika baca dan replika geografis.
Keamanan	Kunci yang dikelola pelanggan dan integrasi keamanan perusahaan.

Fleksibilitas ini sangat kuat karena beban kerja yang berbeda membutuhkan kemampuan yang berbeda. Sistem transaksi yang berorientasi penulisan tidak memerlukan profil yang sama seperti sistem yang berorientasi pelaporan. Aplikasi SaaS global tidak memerlukan desain yang sama dengan aplikasi regional internal. Database yang tumbuh 5% per tahun tidak memerlukan rencana penyimpanan yang sama dengan yang tumbuh 200% setiap bulan.

Tujuan perencanaan adalah untuk mengidentifikasi kebutuhan profil performa beban kerja Anda, lalu menerapkan pilihan yang tepat di seluruh opsi komputasi dan penyimpanan untuk memberikan solusi menyeluruh Anda dengan sukses.

Mulai dengan profil beban kerja

Sebelum memilih komputasi atau penyimpanan, tentukan beban kerja. Dimensi perencanaan yang berguna meliputi:

Area perencanaan	Pertanyaan yang harus dijawab
Geografi	Di mana pengguna, aplikasi, replika, dan integrasi berada?
Concurrency	Berapa banyak koneksi simultan dan kueri aktif yang diharapkan?
Ukuran data	Berapa ukuran database saat ini, dan berapa tingkat pertumbuhan yang diharapkan?
Laju perubahan	Seberapa cepat data tumbuh dari bulan ke bulan? Berapa banyak log write-ahead (WAL) yang dihasilkan?
Tipe beban kerja	Apakah sistem OLTP, OLAP, reporting-heavy, batch-heavy, atau hybrid?
Campuran baca/tulis	Berapa persentase operasi yang dibaca dan ditulis?
Perilaku Maksimal	Apakah ada siklus bisnis yang dapat diprediksi, puncak musiman, atau jendela waktu pemrosesan batch?
Sensitivitas keterlambatan	Transaksi mana yang berhadapan langsung dengan pengguna dan penting terhadap latensi?
Kebutuhan throughput	Apakah ada pemindaian data besar, ekspor, impor, atau proses ekstraksi, transformasi, dan pemuatan (ETL)?
Ekspektasi penskalaan	Apakah beban kerja memerlukan ledakan sementara atau performa yang lebih tinggi berkelanjutan?

Tujuannya bukan untuk memprediksi masa depan dengan sempurna. Tujuannya adalah untuk menghindari merancang secara membabi buta.

Memahami tiga konsep performa penyimpanan inti

Azure perencanaan performa penyimpanan biasanya turun ke tiga konsep terkait tetapi berbeda: IOPS, throughput, dan latensi. Faktor-faktor ini adalah kunci untuk perencanaan performa aplikasi.

IOPS

IOPS berarti operasi input/output per detik. Ini mengukur berapa banyak operasi baca atau tulis yang dapat dikirim database ke penyimpanan setiap detik.

IOPS sangat penting untuk beban kerja OLTP. Sistem ini sering melakukan banyak bacaan dan tulisan kecil dan acak, seperti sisipan, pembaruan, pencarian indeks, pembacaan titik, dan transaksi pendek. Beban kerja transaksional dengan ribuan pengguna bersamaan mungkin memerlukan IOPS tinggi meskipun setiap operasi individu kecil.

Skenario Sensitif IOPS umum meliputi:

Pemrosesan pesanan volume tinggi
Pembaruan profil pengguna
Sistem inventarisasi
Pemrosesan data peristiwa
Sistem pembayaran atau penagihan
Aplikasi SaaS dengan tingkat konkuren yang tinggi

Daya Tampung

Throughput, kadang-kadang disebut bandwidth, mengukur berapa banyak data yang dapat dibaca dari atau ditulis ke penyimpanan dari waktu ke waktu. Hal ini dinyatakan dalam MB/s.

Throughput penting ketika operasi memindahkan data dalam jumlah besar. Kueri analitis, pencadangan, pemulihan, pekerjaan batch, pembuatan indeks, pemindaian tabel, dan alur kerja ETL mungkin memerlukan throughput tinggi meskipun tidak memerlukan IOPS tertinggi.

Skenario umum yang sensitif terhadap throughput meliputi:

Pelaporan kueri pada tabel besar
Impor atau ekspor massal
Pemindaian gaya gudang data
Operasi pencadangan dan pemulihan
Pembuatan indeks besar atau operasi pembangunan ulang
Pemrosesan batch

Latensi

Latensi adalah waktu yang diperlukan untuk menyelesaikan satu permintaan I/O. Latensi rendah sangat penting untuk operasi database yang menghadap pengguna, terutama di mana banyak operasi kecil ditautkan bersama dalam transaksi.

Sistem dapat memiliki IOPS teoritis tinggi tetapi masih terasa lambat jika latensi tinggi. Untuk beban kerja Postgres, latensi penyimpanan dapat secara langsung memengaruhi waktu respons kueri, perilaku penerapan transaksi, perilaku titik pemeriksaan, dan respons aplikasi secara keseluruhan.

Nota

Disk Premium SSD v1 dirancang untuk latensi milidetik dalam satu digit untuk hampir semua operasi I/O, dan terutama, caching disk dapat lebih mengurangi latensi baca untuk konfigurasi disk di bawah 4 TB. Premium SSD v2 dan Ultra Disk menawarkan latensi submilidetik.

IOPS, throughput, dan latensi harus dipertimbangkan bersama

IOPS dan throughput saling berhubungan. Beban kerja yang mengeluarkan beberapa operasi kecil 8-KiB mungkin mendorong IOPS tinggi tanpa throughput tinggi. Beban kerja yang melakukan operasi berukuran beberapa MB yang besar dapat mendorong throughput tinggi dengan IOPS yang lebih rendah.

Cara sederhana untuk memikirkannya:

IOPS x Ukuran I/O = Throughput

Untuk Postgres, implikasi praktisnya adalah bahwa perencanaan penyimpanan beban kerja harus didasarkan pada perilaku beban kerja yang diamati atau diperkirakan, bukan ukuran database saja. Contohnya:

Sistem OLTP konkurensi tinggi mungkin membutuhkan lebih banyak IOPS dan latensi yang lebih rendah.
Sistem yang berat pada pelaporan mungkin membutuhkan lebih banyak throughput.
Sistem hibrid mungkin membutuhkan keduanya, terutama selama siklus puncak.
Sistem OLTP konkurensi tinggi mungkin membutuhkan lebih banyak IOPS dan latensi yang lebih rendah.
Sistem yang banyak pelaporan mungkin membutuhkan lebih banyak throughput.
Sistem hibrid mungkin membutuhkan keduanya, terutama selama siklus puncak.

Pilihan penyebaran Anda secara langsung memengaruhi performa penyimpanan

Kesalahan umum adalah mengatur penyimpanan Anda untuk nomor performa target tanpa sepenuhnya mempertimbangkan apakah SKU komputasi yang Anda pilih dapat mendorong tingkat performa yang sama.

Kinerja penyimpanan Azure memiliki beberapa pertimbangan. Detail ini meliputi:

Set kemampuan komputasi (IOPS komputasi maksimum dan batas throughput).
Pembuatan penyimpanan (SSD v1, SSD v2, Ultra Disk).
Ukuran disk penyimpanan (disk SSD v1 di bawah 4.096 GB termasuk caching host, yang memungkinkan lonjakan IOPS di atas batas dasar standar).
Kapasitas IOPS penyimpanan.
Kapasitas throughput penyimpanan.

Dalam istilah praktis: batas maksimal performa efektif Anda adalah batas relevan terendah Anda dalam rantai proses.

Jika konfigurasi penyimpanan dapat menyediakan 80.000 IOPS tetapi SKU komputasi hanya dapat menangani 20.000 IOPS, maka penyebaran tidak memberikan 80.000 IOPS. Sebaliknya, jika generasi VM mendukung IOPS tinggi tetapi tingkat penyimpanan yang dipilih dibatasi lebih rendah, tingkat penyimpanan menjadi batasnya.

Perencanaan komputasi dan penyimpanan harus terjadi bersama-sama.

SSD premium v1: performa dasar yang kuat serta karakteristik caching penting

Premium SSD v1 adalah pilihan umum untuk beban kerja Azure Postgres di produksi yang membutuhkan performa yang konsisten dan telah disediakan. Penyimpanan Azure Postgres SSD v1 mendukung kapasitas hingga 32 TB, 20,000 IOPS, dan throughput 900 MB/s.

Premium SSD v1 berfungsi dengan baik untuk beban kerja yang mendapat manfaat dari caching host. Azure Postgres mendukung caching host untuk ukuran disk SSD v1 yang kurang dari 4.096 GB. Setiap disk yang disediakan hingga 4.095 GB dapat memperoleh manfaat dari caching host. Setelah penyimpanan disediakan pada 4,096 GB atau lebih tinggi, cache host tidak didukung. Batas itu penting. Untuk penyebaran Premium SSD v1 di bawah 4 TB, cache dapat meningkatkan performa baca dan mengurangi latensi baca. Penembolokan ini menciptakan efisiensi biaya terhadap kinerja yang sangat baik untuk beban kerja yang berfokus pada pembacaan atau campuran yang berada di bawah ambang batas penembolokan.

Mengapa batas 4-TB penting

Ketika penyebaran Premium SSD v1 tumbuh melampaui rentang yang didukung caching, profil performa dapat berubah:

Bacaan tidak lagi mendapat manfaat dari cache host.
Operasi baca lebih banyak berasal langsung dari disk dasar.
Pembacaan diperhitungkan terhadap batas IOPS dan throughput disk.
Beban kerja baca yang sensitif terhadap latensi mungkin mengalami perilaku yang berbeda.
Konfigurasi yang sebelumnya efisien mungkin memerlukan lebih banyak IOPS yang disediakan, lebih banyak throughput, penskalaan komputasi, penyetelan kueri, atau opsi penyimpanan yang berbeda.

Melewati 4 TB tidak buruk, tetapi Anda harus merencanakan.

Jika Anda mengharapkan database tumbuh melebihi 4 TB, pertimbangkan status masa depan selama desain arsitektur. Desain yang memiliki kinerja baik pada 2 TB dengan penyimpanan sementara mungkin memerlukan rencana kinerja yang berbeda pada 5 TB tanpa penyimpanan sementara.

Burst membantu menangani lonjakan, tetapi tidak menggantikan kapasitas berkesinambungan.

Alokasi penyimpanan Azure Postgres Premium SSD v1 di bawah 4-TB mendukung lonjakan caching host, yang dapat membantu dalam skenario seperti:

Aktivitas startup
Pekerjaan batch pendek
Lonjakan lalu lintas
Pemrosesan akhir bulan
Lonjakan beban kerja sementara

Meskipun bursting berguna, gunakan dengan hati-hati. Bursting dapat menyerap lonjakan sementara, tetapi seharusnya bukan dasar untuk permintaan beban kerja berkelanjutan. Jika beban kerja sering berjalan di atas garis besar, lebih baik menyediakan tingkat performa yang lebih tinggi, menyesuaikan pengaturan performa penyimpanan, menskalakan komputasi, atau mendesain ulang pola beban kerja.

Pertanyaan perencanaan yang baik adalah: Apakah ini lonjakan sementara, atau apakah ini normal baru?

Lonjakan sementara mungkin merupakan kandidat yang baik untuk peledakan. Tangani permintaan berkelanjutan dengan perencanaan kapasitas yang disederhanakan.

Premium SSD v2 memisahkan kapasitas, IOPS, dan throughput

SSD premium v2 mengubah model perencanaan dengan memisahkan ukuran disk, IOPS, dan throughput. Azure Database for PostgreSQL server fleksibel mendukung Premium SSD v2.

Kapasitas dari 32 GB hingga 64 TB.
Hingga 80.000 IOPS.
Throughput hingga 1,200 MB/dtk
Penyesuaian kapasitas secara granular dalam satuan 1 GB.
Konfigurasi IOPS dan throughput yang fleksibel.
Latensi yang lebih rendah daripada Premium SSD v1.
Tidak ada cache host.

Perubahan ini adalah pergeseran besar. Dengan Premium SSD v1, performa lebih erat terkait dengan ukuran disk. Dengan Premium SSD v2, Anda dapat mengonfigurasi performa lebih langsung di sekitar kebutuhan beban kerja.

Misalnya, database yang berat transaksi mungkin memerlukan IOPS tinggi tanpa memerlukan penyimpanan dalam jumlah besar. Azure Postgres menyediakan IOPS dan throughput dasar tanpa biaya tambahan, dengan IOPS dan throughput tambahan yang tersedia untuk biaya tambahan. Premium SSD v2 menawarkan:

Disk hingga 399 GB menerima batas dasar 3.000 IOPS dan 125 MB/dtk.
Disk 400 GB atau lebih besar menerima dasar 12.000 IOPS dan 500 MB/s.
Disk dapat mencapai hingga 80.000 IOPS saat berukuran hingga setidaknya 160 GB ruang yang tersedia.
Throughput dapat meningkat hingga 1.200 MB/dtk.

Premium SSD v2 sering kali menarik ketika Anda membutuhkan kontrol yang lebih tepat atas biaya dan performa. Alih-alih menskalakan kapasitas penyimpanan hanya untuk meningkatkan performa, Anda dapat mengalokasikan performa dengan lebih terencana.

Ultra Disk (Pratinjau): kelas performa disk Azure kelas atas

Ultra Disk adalah opsi disk berkinerja tertinggi. Azure Ultra Disk menawarkan tingkat performa hingga:

400.000 IOPS
Throughput 10.000 MB/dtk
Kapasitas 64 TB
Target desain latensi submillisecond
Kapasitas, IOPS, dan throughput yang dapat dikonfigurasi secara independen

Penyimpanan Ultra Disk dirancang untuk menggerakkan beban kerja intensif IO untuk database tingkat atas, SAP Hana, dan sistem yang berat transaksi. Penawaran penyimpanan baru ini memberikan performa terbaik untuk beban kerja misi penting Anda. Namun, tim Anda harus mempertimbangkan beberapa kemampuan penyebaran utama, pembatasan ketersediaan regional, dan opsi konfigurasi saat merencanakan penyebaran:

Pertumbuhan otomatis penyimpanan tidak didukung untuk server yang menggunakan Ultra Disk
Enkripsi data dengan kunci yang dikelola pelanggan tidak didukung untuk server dengan Ultra Disk
Disk Ultra tidak mendukung caching disk

Penting untuk memahami kemampuan Disk Ultra sebagai bagian dari lanskap performa penyimpanan Azure yang lebih luas. Namun, Anda harus memvalidasi ketersediaan dan dukungan layanan untuk beban kerja Azure Postgres spesifik Anda. Tanyakan kepada perwakilan Microsoft Anda apakah fitur Pratinjau Disk Ultra tersedia untuk penyebaran layanan Azure Postgres Anda.

Inti praktis: Ultra Disk mewakili tingkat tertinggi dari performa penyimpanan Azure, tetapi desain Postgres end-to-end Anda harus menyertakan kombinasi dukungan yang sebanding untuk compute SKU yang dipilih, serta pilihan wilayah dan tingkat rilis.

Masalah pembuatan VM: Langit-langit penyimpanan komputasi V5 dan V6 berbeda

Generasi komputasi dapat secara signifikan memengaruhi performa penyimpanan. Saat Anda menjelajahi performa penyimpanan Azure di level tertinggi, hindari kesalahpahaman bahwa "komputasi besar" secara otomatis berarti "kapasitas penyimpanan maksimum." Anda harus memvalidasi SKU komputasi yang dipilih dengan menyesuaikan tingkat penyimpanan yang dimaksud. Mari kita ilustrasikan titik ini dengan mempertimbangkan dua generasi komputasi berukuran serupa, Ddsv5 dan Ddsv6:

Seri Ddsv5 mendukung Premium Storage (dengan caching), Premium SSD v2, dan Ultra Disk di tingkat famili VM. Namun, batas total penyimpanan jarak jauh VM masih menentukan batas maksimum yang dapat dicapai oleh VM tersebut. Ddsv5-series menyediakan performa penyimpanan berkisar hingga 80.000 IOPS dan 2.600 MB/dtk.

Seri Ddsv6 ini menyediakan kapasitas penyimpanan yang lebih tinggi, mencapai hingga 400.000 IOPS dan 12.000 MB/s. Komputasi seri V6 juga menawarkan skalabilitas yang lebih tinggi daripada generasi sebelumnya, dengan hingga 192 vCPU dan memori 768-GiB.

Perubahan generasi itu penting untuk desain Postgres berkinerja tinggi. Jika arsitektur target Anda memerlukan performa penyimpanan yang tinggi, memilih pembuatan komputasi dengan langit-langit penyimpanan agregat yang lebih rendah dapat mencegah penyebaran menggunakan kemampuan penyimpanan penuh.

Contoh: mengapa perataan ujung ke ujung itu penting

Pertimbangkan beban kerja PostgreSQL dengan target penyimpanan aspirasional 400.000 IOPS.

Pada lapisan disk, Azure Ultra Disk mendukung hingga 400.000 IOPS per disk. Premium SSD v2 mendukung hingga 80.000 IOPS per disk, dan desain agregat yang lebih tinggi mungkin memerlukan beberapa disk atau abstraksi tingkat platform tergantung pada dukungan layanan.

Tetapi kemampuan penyimpanan saja tidak cukup.

Konfigurasi seri V5 mungkin memiliki langit-langit penyimpanan yang lebih rendah dari target. Seperti yang disebutkan sebelumnya, SKU seri V5 mendukung hingga 260.000 IOPS untuk throughput disk jarak jauh SSD Premium. Dalam hal ini, memilih lapisan komputasi seri V5 untuk target ini menjadi faktor pembatasan sebelum target IOPS 400.000 tercapai.

Sebaliknya, dokumentasi seri Ddsv6 menawarkan hingga 400.000 IOPS dan 12.000 MB/detik. Itu membuat seri V6 dan generasi yang lebih baru secara strategis penting untuk desain yang perlu menyelaraskan komputasi dan penyimpanan di sekitar kelas performa penyimpanan tertinggi.

Pelajarannya sederhana: performa database maksimum adalah properti end-to-end, bukan properti khusus penyimpanan.

Merencanakan siklus bisnis, bukan hanya status stabil

Banyak sistem tidak memiliki satu profil performa. Mereka memiliki beberapa:


Lalu lintas hari kerja normal.	Jam kerja puncak.
Pemrosesan akhir bulan atau akhir triwulan.	Permintaan liburan atau musiman.
Peristiwa peluncuran produk.	Jendela pelaporan
Jendela pemeliharaan.	Azure Batch periode penyerapan.
Skenario pencadangan dan pemulihan.	Peristiwa pemulihan bencana.

Database yang didesain untuk pemanfaatan rata-rata mungkin akan kesulitan pada saat-saat yang paling penting. Sebaliknya, database yang ukurannya ditetapkan secara permanen untuk puncak penggunaan sebulan sekali mungkin akan terlalu mahal tanpa alasan.

fleksibilitas Azure memungkinkan tim membuat pilihan yang lebih bernuansa. Contohnya:

Gunakan Premium SSD v2 untuk menyesuaikan IOPS dan throughput seiring berkembangnya kebutuhan beban kerja.
Gunakan replika baca untuk mengurangi beban kerja yang berat dalam membaca jika sesuai.
Menskalakan komputasi untuk periode puncak yang diketahui.
Menyetel kueri, indeks, dan pengumpulan koneksi sebelum menskalakan infrastruktur.
Gunakan pengamatan untuk mengidentifikasi apakah hambatan adalah CPU, memori, IOPS, throughput, ketidakcocokan kunci, tekanan koneksi, atau desain kueri.

Implementasi terbaik tidak selalu merupakan implementasi terbesar. Ini adalah desain yang cocok dengan beban kerja dan dapat berkembang dengan aman.

Pengamatan adalah bagian dari arsitektur

Perencanaan performa tidak boleh berhenti pada penyebaran. Beban kerja Postgres berubah dari waktu ke waktu. Data tumbuh, pergeseran pola kueri, peluncuran fitur baru, perubahan lalu lintas pelanggan, dan pekerjaan operasional terakumulasi.

Area pemantauan	Sinyal untuk ditinjau
Compute	Pemanfaatan CPU dan tekanan memori.
Connections	Koneksi aktif, koneksi diam, dan perilaku kumpulan koneksi.
Queries	Durasi kueri, perubahan rencana kueri, dan penggunaan indeks.
Storage	Persentase penyimpanan, latensi baca, latensi tulis, pemanfaatan IOPS, dan statistik throughput.
Maintenance	Pembengkakan tabel, pembengkakan indeks, karakteristik WAL, jadwal pencadangan, dan jadwal pemeliharaan.
Replikasi	Lag replika, jika relevan.

Azure Database for PostgreSQL dokumentasi menyoroti pemantauan konsumsi I/O melalui portal Azure atau metrik Azure CLI, termasuk batas penyimpanan, persentase penyimpanan, penyimpanan yang digunakan, dan persentase I/O.

Metrik ini membantu menjawab pertanyaan operasional yang paling penting: lapisan mana yang benar-benar membatasi performa?

Tanpa pengamatan, tim mungkin menskalakan hal yang salah. Permasalahan rencana kueri mungkin terlihat seperti masalah penyimpanan. Badai koneksi mungkin terlihat seperti tekanan CPU. Indeks yang hilang mungkin terlihat seperti IOPS yang tidak mencukup. Masalah penempatan klien regional mungkin terlihat seperti latensi database.

Pemantauan membantu tim membuat perubahan yang ditargetkan alih-alih tebakan mahal.

Daftar periksa perencanaan praktis

Sebelum memilih konfigurasi Azure Database untuk PostgreSQL produksi, kumpulkan informasi berikut.

Category	Input perencanaan
Tipe beban kerja	OLTP, OLAP, hibrid, pelaporan, batch, dan penyerapan.
Campuran baca/tulis	Persentase membaca, menulis, I/O acak, dan I/O berurutan.
Performa saat ini	IOPS dasar, throughput, latensi, CPU, memori, dan koneksi.
Performa puncak	Persentil ke-90 dan persyaratan beban kerja persentil ke-99.
Ukuran data	Ukuran saat ini, pertumbuhan yang diharapkan, penggunaan objek besar, dan pertumbuhan indeks.
Tingkat pertumbuhan	Proyeksi penyimpanan bulan ke bulan dan tahun ke tahun.
Concurrency	Sesi aktif, sesi diam, dan perilaku kumpulan koneksi.
Siklus bisnis	Puncak harian, mingguan, bulanan, musiman, dan terkait peluncuran.
Availability	Ketersediaan tinggi, replika, pemulihan bencana, pencadangan, pengembalian, tujuan titik pemulihan (RPO), dan tujuan waktu pemulihan (RTO).
Pilihan penyimpanan	SSD Premium, SSD Premium v2, wilayah yang didukung, dan fitur yang didukung.
Dampak caching	Apakah caching host Premium SSD v1 berlaku untuk kapasitas di bawah 4 TB.
Pembuatan komputasi	Apakah SKU yang dipilih dapat mendorong IOPS dan throughput yang diperlukan.
Model penskalakan	Penskalaan manual, penskalaan terjadwal, penyesuaian kinerja, dan replika.
Keterukuran	Metrik, notifikasi, wawasan kueri, dan proses peninjauan beban kerja.

Prinsip desain yang direkomendasikan

Gunakan prinsip-prinsip berikut saat merencanakan penyebaran Postgres Azure untuk performa operasional.

Ukuran untuk bentuk beban kerja, bukan hanya ukuran data.
Database 500 GB dapat membutuhkan lebih banyak IOPS daripada database 5 TB jika sangat transaksi dan sensitif terhadap latensi. Ukuran penting, tetapi perilaku beban kerja lebih penting.
Validasi komputasi dan penyimpanan bersama-sama.
Jangan pilih penyimpanan hanya berdasarkan batas disk. Pastikan bahwa SKU komputasi yang dipilih dapat mendorong IOPS dan throughput yang diperlukan.
Perlakukan batas cache SSD Premium 4-TB sebagai langkah penting dalam desain.
Penyebaran SSD premium di bawah 4 TB dapat memanfaatkan cache host. Pada 4.096 GB ke atas, penembolokan host tidak didukung. Jika pertumbuhan akan melewati ambang batas itu, rencanakan model performa masa depan lebih awal.
Pertimbangkan Premium SSD v2 untuk penyetelan performa yang fleksibel.
Premium SSD v2 memungkinkan kontrol kapasitas, IOPS, dan throughput yang lebih terperinci. Ini bisa sangat cocok ketika kebutuhan performa tidak cocok langsung dengan ukuran disk yang sudah ditentukan.
Gunakan bursting untuk ledakan, bukan permintaan berkelanjutan.
Bursting dapat membantu dengan lonjakan sesaat, tetapi bursting yang sering atau berkelanjutan biasanya berarti konfigurasi dasar perlu ditinjau kembali.
Cocokkan generasi dengan ambisi.
Untuk tujuan performa kelas atas, generasi komputasi yang lebih baru seperti seri v6 dapat mengekspos batas penyimpanan jarak jauh agregat yang lebih tinggi daripada generasi tujuan umum sebelumnya. Jika targetnya adalah arsitektur kelas 400.000-IOPS, pilih generasi komputasi yang sesuai.
Mengukur sebelum dan sesudah perubahan.
Penskalaan lebih mudah di cloud, tetapi pengukuranlah yang membuat penskalaan efektif. Tangkap metrik garis besar, puncak, dan pasca-perubahan sehingga keputusan performa berbasis bukti.

Tolok ukur dunia nyata: membandingkan konfigurasi penyimpanan di bawah beban

Prinsip-prinsip yang diuraikan dalam artikel ini tidak teoritis. Untuk menunjukkan bagaimana komputasi, penyimpanan, dan beban kerja berinteraksi dalam praktiknya, bagian ini meringkas pgbench tolok ukur yang membandingkan konfigurasi penyimpanan dan tingkat komputasi dalam kondisi terkontrol dan terukur.

Penyiapan dan metodologi tolok ukur

Tolok ukur menggunakan pgbench, alat tolok ukur PostgreSQL standar, untuk mensimulasikan beban kerja transaksional di lima konfigurasi penyimpanan dan komputasi yang berbeda. Pengujian dimulai dengan 500 koneksi bersamaan dan meningkat hingga 750 koneksi bersamaan setelah periode awal pengujian, mempertahankan beban koneksi yang lebih tinggi ini untuk sisa waktu pengujian. Pola peningkatan ini mensimulasikan berapa banyak aplikasi nyata yang meningkatkan beban dari waktu ke waktu saat lalu lintas tumbuh, dan mengukur bagaimana database merespons lonjakan awal dan konkurensi tinggi berkelanjutan.

Semua tolok ukur berjalan di Azure Database for PostgreSQL Server Fleksibel di wilayah yang sama, dalam zona ketersediaan yang sama, menggunakan database pengujian dan profil beban kerja yang sama. Dengan mengisolasi penyimpanan dan komputasi sebagai variabel, Anda memastikan bahwa perbedaan performa mencerminkan kemampuan platform aktual daripada variasi jaringan, aplikasi, atau beban kerja.

Detail Konfigurasi

Uji lima konfigurasi yang berbeda, bervariasi tingkat penyimpanan dan ukuran komputasi untuk mengilustrasikan konsep perencanaan utama.

Konfigurasi	SKU Komputasi	vCores	Memory	IOPS maks komputasi	Jenis penyimpanan	Capacity	IOPS	Daya Tampung
Konfigurasi 1	Standard_D16ds_v5	16	64 GB	25.600 (40.000 lonjakan)	SSD Premium (P50)	4.095 GB	7,500	250 MB/detik
Konfigurasi 2	Standard_D16ds_v5	16	64 GB	25.600 (40.000 ledakkan)	SSD Premium (P50)	4.096 GB	7,500	250 MB/detik
Konfigurasi 3	Standard_D16ds_v5	16	64 GB	25.600 (40.000 lonjakan)	SSD Premium (P80)	32 Terabyte	20,000	900 MB/detik
Konfigurasi 4	Standard_D16ds_v5	16	64 GB	25.600 (40.000 ledakkan)	Premium SSD v2	4.095 GB	40,000	1,200 MB per detik
Konfigurasi 5	Standard_D32ds_v5	32	128 GB	51.200	Premium SSD v2	4.095 GB	60,000	1,200 MB per detik

Pengamatan utama dari desain konfigurasi:

Konfigurasi 1 vs. Konfigurasi 2: Konfigurasi ini hanya berbeda dalam ukuran penyimpanan, 4.095 GB versus 4.096 GB. Perbandingan ini menguji batas pengemparan host untuk disk Premium SSD v1.
Konfigurasi 2 vs. Konfigurasi 3: Kedua konfigurasi menggunakan SSD v1, tetapi Konfigurasi 3 menskalakan ke kapasitas 32 TB untuk membuka IOPS dan throughput yang lebih tinggi.
Konfigurasi 3 vs. Konfigurasi 4: Kedua konfigurasi menggunakan komputasi yang sama, tetapi Konfigurasi 4 menunjukkan Premium SSD v2 dengan IOPS dan throughput fleksibel yang independen dari kapasitas.
Konfigurasi 4 vs. Konfigurasi 5: Konfigurasi 5 menggandakan SKU komputasi untuk menunjukkan bagaimana komputasi tingkat yang lebih tinggi membuka lebih banyak ruang performa penyimpanan.

Hasil performa

Konfigurasi 1: 4,095-GB Premium SSD v1 dengan penyimpanan sementara host

Konfigurasi 1 menggunakan Premium SSD v1 berukuran 4.095 GB, yang mendapatkan manfaat dari caching host pada Premium SSD v1. Selama beban kerja, konfigurasi ini berkelanjutan:

IOPS Maksimal: 24.773, dibatasi oleh 7.500 IOPS yang dipasang pada Premium SSD v1, dengan caching meningkatkan kinerja efektif.
IOPS baca maks: 21.330, mendapat manfaat dari cache host untuk operasi baca-berat.
IOPS penulisan maks: 7.610.

Penembolokan host menyediakan peningkatan baca, sehingga IOPS efektif secara sementara dapat melebihi batas provisi IOPS disk 7.500 dan mencapai batas kemampuan penyimpanan komputasi.

Konfigurasi 2: 4.096-GB Premium SSD v1 tanpa penembolokan host

Konfigurasi 2 menggunakan ukuran Premium SSD v1 4.096 GB, yang melewati batas penggunaan cache dan kehilangan manfaat cache dari host. Dampaknya terlihat:

IOPS Maksimum: IOPS efektif yang lebih rendah dibandingkan dengan Konfigurasi 1 karena kehilangan cache.
IOPS baca maks: Berkurang secara signifikan tanpa cache host.
IOPS tulis maks: 7.610, tidak berubah.

Konfigurasi ini menunjukkan kepentingan praktis dari batas caching 4 TB. Menyeberang dari 4.095 GB menjadi 4.096 GB mengubah profil performa dengan menghapus pembacaan yang di-cache. Untuk database yang berkembang mendekati ambang batas ini, rencanakan sebelumnya.

Konfigurasi 3: 32-TB Premium SSD v1 dengan IOPS yang lebih tinggi

Konfigurasi 3 mengatasi batas atas IOPS dan throughput SSD Premium v1 dengan meningkatkan kapasitas hingga 32 TB. Konfigurasi ini berhasil mencapai:

IOPS maks: 20.000.
IOPS baca maks: Sekitar 12.000.
IOPS tulis maks: Sekitar 5.000.

Meningkatkan kapasitas mendasar penyimpanan Premium SSD v1 meningkatkan IOPS dan throughput. Anda masih dapat mencapai batas atas rentang penyimpanan komputasi untuk beban kerja intensif.

Konfigurasi 4: SSD premium v2 dengan 40.000 IOPS

Konfigurasi 4 menunjukkan konfigurasi performa fleksibel Premium SSD v2, menyediakan 40.000 IOPS dan throughput 1.200-MB/dtk pada kapasitas 4.095 GB:

IOPS maks: Pemanfaatan efektif yang lebih tinggi karena latensi Premium SSD v2 dan kemampuan throughput.
IOPS baca maks: Peningkatan performa dibandingkan dengan konfigurasi Premium SSD v1.
IOPS tulis maks: Kapasitas tulis berkelanjutan yang lebih tinggi.

Premium SSD v2 memungkinkan penyediaan IOPS tinggi tanpa memerlukan kapasitas penyimpanan yang besar, sehingga efisien untuk beban kerja yang berat transaksi.

Konfigurasi 5: SSD premium v2 dengan 60.000 IOPS pada komputasi D32ds_v5

Konfigurasi 5 menskalakan performa penyimpanan, pada 60.000 IOPS, dan komputasi, dengan Standard_D32ds_v5 dan 32 vCore. Konfigurasi ini menunjukkan prinsip perataan ujung-ke-ujung:

IOPS maks: Secara signifikan lebih tinggi dari semua konfigurasi sebelumnya.
IOPS baca maks: Peningkatan signifikan dengan kapasitas komputasi tambahan.
IOPS tulis maks: Kapasitas tulis yang lebih tinggi berkelanjutan.

Dengan menyelaraskan komputasi dan penyimpanan ke tingkat performa yang lebih tinggi, konfigurasi ini mencapai throughput terbaik dan tekanan CPU terendah. Langit-langit penyimpanan yang lebih tinggi dari D32ds_v5 memungkinkan disk 60.000-IOPS Premium SSD v2 dapat digunakan secara lebih optimal.

Pelajaran dari tolok ukur

Kelima konfigurasi ini menggambarkan prinsip-prinsip utama dari artikel ini:

Batas cache 4 TB penting.
Konfigurasi 1 vs. Konfigurasi 2 menunjukkan bahwa caching host memberikan amplifikasi performa baca yang terukur di bawah 4 TB, sementara melampaui 4 TB akan menghapus manfaat tersebut.
Kapasitas bukan performa.
Konfigurasi 3 menyediakan 32 TB tetapi tidak memberikan IOPS tertinggi. Kapasitas penyimpanan saja tidak menentukan throughput transaksi.
Premium SSD v2 menyediakan penyetelan performa yang fleksibel.
Konfigurasi empat menunjukkan IOPS tinggi pada kapasitas sederhana, memvalidasi model terpisah yang dimungkinkan oleh Premium SSD v2.
Komputasi dan penyimpanan harus diselaraskan.
Config lima menunjukkan bahwa memaksimalkan performa penyimpanan memerlukan kapasitas komputasi yang memadai. Batas kapasitas penyimpanan D32ds_v5 yang lebih tinggi diperlukan untuk sepenuhnya menggunakan kapasitas 60.000-IOPS.

Hasil tolok ukur memvalidasi prinsip inti: performa maksimum adalah properti end-to-end. Tidak ada lapisan tunggal, seperti penyimpanan, komputasi, atau jaringan, yang menentukan hasilnya. Keberhasilan memerlukan keselarasan yang disengaja di semua lapisan, validasi terukur, dan pengamatan berkelanjutan seiring berkembangnya beban kerja.

Kesimpulan

Azure Postgres menyediakan platform yang kuat dan fleksibel untuk membangun solusi database modern yang dihosting cloud. Rekayasa menyeluruh di Azure Compute, penyimpanan, jaringan, ketersediaan tinggi, replikasi, keamanan, dan observabilitas memungkinkan beberapa arsitektur Postgres yang paling tangguh dan berperforma tinggi yang tersedia.

Performa maksimum tidak terjadi secara tidak sengaja.

Performa operasional maksimum memerlukan pemahaman aplikasi, klien, beban kerja, profil pertumbuhan data, campuran baca/tulis, dan siklus bisnis yang membentuk permintaan. Ini juga memerlukan penyelarasan pilihan komputasi dan penyimpanan sehingga target IOPS, throughput, dan latensi dicapai secara end-to-end.

Premium SSD v1 dapat memberikan kinerja yang konsisten dan kuat, terutama ketika penyimpanan sementara host diterapkan untuk data di bawah batas 4 TB. Premium SSD v2 menambahkan konfigurasi performa yang lebih fleksibel dengan memisahkan kapasitas, IOPS, dan throughput. Ultra Disk mewakili kelas performa disk terkelola Azure tertinggi, sementara generasi komputasi yang lebih baru menyediakan langit-langit penyimpanan jarak jauh agregat yang jauh lebih tinggi untuk arsitektur kelas atas.

Penyebaran Postgres Azure terbaik menggabungkan kemampuan platform dengan perencanaan yang disarankan, pemantauan berkelanjutan, dan kepemilikan operasional yang jelas. Dengan persyaratan yang tepat dan arsitektur yang tepat, tim dapat memberikan pengalaman Postgres kelas dunia yang memberikan performa puncak.

Azure Premium Storage: desain untuk performa tinggi
Azure disk bursting
Ukuran VM seri Ddv5 dan Ddsv5
Ukuran VM seri Ddsv6
Opsi penyimpanan Premium SSD di Azure Database for PostgreSQL
Pilihan opsi penyimpanan Premium SSD v2 di Azure Database for PostgreSQL
Tipe disk yang dikelola Azure
Memantau metrik di Azure Database for PostgreSQL

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-05-08