View a markdown version of this page

Kinerja khusus instans dan pemantauan sumber daya - Amazon Aurora
IkhtisarDasar-dasar arsitektur instanceMemantau performa instansPemantauan dan pemecahan masalah routerPemantauan dan pemecahan masalah shardBatasan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Kinerja khusus instans dan pemantauan sumber daya

Pemantauan pada tingkat instans adalah kunci untuk memahami kemiringan koneksi, kemiringan beban kerja dan kemiringan data, serta kapan harus menambahkan router atau pecahan terpisah untuk meningkatkan throughput yang lebih tinggi dengan latensi yang dipertahankan.

Ikhtisar

Saat aplikasi Anda mengeluarkan kueri, permintaan tersebut melintasi sistem terdistribusi yang canggih sebelum mengembalikan hasil. SELECTPernyataan yang tampaknya sederhana mungkin menyentuh beberapa instance database, masing-masing memainkan peran yang berbeda dalam memproses permintaan Anda. Memahami perjalanan ini—dan contoh yang mendayanginya—mengubah cara Anda merancang aplikasi, menafsirkan data pemantauan, dan mendiagnosis masalah kinerja.

Panduan ini memberikan wawasan teknis yang mendalam tentang arsitektur instance:

  • Penyegaran Arsitektur Tanpa Batas, router, dan pecahan

  • Kapan dan bagaimana menskalakan setiap jenis instans untuk memenuhi persyaratan kinerja dan kapasitas Anda

  • Cara memantau, memecahkan masalah, dan mengoptimalkan kinerja tingkat instans

  • Praktik terbaik untuk desain aplikasi yang memanfaatkan arsitektur terdistribusi secara efektif

Dasar-dasar arsitektur instance

mencapai skalabilitas horizontal melalui pemisahan fungsional di dua jenis instance khusus:

  • Instans router menyediakan lapisan orkestrasi—mereka menerima koneksi klien, menganalisis kueri, mengoordinasikan operasi terdistribusi, dan hasil agregat. Router bersifat stateless, artinya mereka tidak menyimpan data dan dapat ditambahkan atau dihapus tanpa migrasi data.

  • Instance shard menyediakan data dan lapisan komputasi—mereka menyimpan data tabel, mengeksekusi kueri terhadap data lokal, dan menangani transaksi. Pecahan bersifat stateful, masing-masing memiliki subset tertentu dari data Anda yang ditentukan oleh hashing yang konsisten.

Pemisahan ini memungkinkan untuk menskalakan penanganan koneksi, koordinasi kueri, dan penyimpanan data secara independen berdasarkan karakteristik beban kerja Anda.

Perbandingan router dan shard

Karakteristik Instans Router Contoh Shard
Peran Utama Koordinasi dan distribusi kueri Penyimpanan data dan eksekusi kueri
Status Stateless (tidak ada penyimpanan data) Stateful (memiliki data)
Skalabilitas Tambah/hapus secara instan Membutuhkan penyeimbangan kembali data
Fokus Sumber Daya CPU untuk koordinasi; memori sedang CPU untuk kueri; memori tinggi untuk cache
Pemicu Penskalaan Jumlah koneksi tinggi, tingkat txn terdistribusi CPU tinggi, volume data, throughput kueri

Memantau performa instans

Memahami kinerja tingkat instans sangat penting untuk beroperasi secara efektif. Pemantauan khusus instans mengungkapkan pola distribusi yang memengaruhi kinerja: kemiringan koneksi, kemiringan beban kerja, dan kemiringan data.

Mendeteksi kemiringan

Dalam penerapan yang ideal, beban kerja dan sumber daya didistribusikan secara merata di seluruh instance. Dalam praktiknya, aplikasi sering mengalami distribusi yang tidak merata yang memusatkan beban pada instance tertentu.

Tiga jenis kemiringan untuk dipantau:

  • Connection miring: Distribusi koneksi klien yang tidak merata di seluruh router

  • Kemiringan beban kerja: Beban kueri yang tidak merata di seluruh pecahan karena tombol hot shard

  • Kemiringan data: Volume data tidak merata di seluruh pecahan karena frekuensi kunci pecahan

Distribusi beban Wawasan Database

Cara tercepat untuk menilai kesehatan tingkat instans adalah tampilan Distribusi Beban Wawasan Database, yang memberikan visibilitas langsung tentang bagaimana Sesi Aktif didistribusikan di seluruh instans.

Untuk mengakses Distribusi Beban:

  1. Arahkan ke Konsol RDS → Cluster Tanpa Batas Anda

  2. Pilih tab “Performance Insights”

  3. Klik bagian “Distribusi Beban”

Pola sehat: Beban didistribusikan secara relatif merata di seluruh instance

  • Router mungkin menunjukkan AAS sedikit lebih tinggi daripada pecahan (overhead koordinasi)

  • Nilai Shard AAS dalam 20% satu sama lain menunjukkan keseimbangan yang baik

Mengenai pola: Konsentrasi yang signifikan pada contoh tertentu

  • Satu router dengan> 70% beban router → Koneksi miring

  • Satu pecahan dengan> 50% beban pecahan → Beban kerja atau kemiringan data

  • Varians besar antara pecahan → Selidiki distribusi kunci pecahan

CloudWatch metrik

Untuk analisis lebih dalam di luar Database Insights, CloudWatch sediakan metrik spesifik instance yang mengungkapkan pola pemanfaatan sumber daya.

ServerlessDatabaseCapacityMetrik dengan dimensi DBShardGroupInstance menunjukkan konsumsi ACU per instance, memberikan pandangan paling langsung tentang pemanfaatan sumber daya.

Kapan harus menyelidiki:

  • Varians ACU router > 30% → Konsentrasi beban kerja miring atau cross-shard koneksi

  • Varians ACU Shard > 40% → Kemiringan data atau beban kerja

  • Setiap contoh secara konsisten pada ACU maks → Kendala kapasitas

Pemantauan dan pemecahan masalah router

Router dapat mengalami masalah kinerja dari dua penyebab utama: distribusi koneksi yang tidak merata dan konsentrasi beban kerja cross-shard.

Sesi yang didistribusikan tidak merata

Gejala: Satu router menangani bagian koneksi yang tidak proporsional

Akar penyebab: Caching DNS menyebabkan beberapa permintaan koneksi diselesaikan ke titik akhir router yang sama.

Paling umum selama:

  • Benchmarking dengan alat seperti pgbench

  • Inisialisasi kumpulan koneksi (banyak koneksi dibangun dengan cepat)

  • Server aplikasi dimulai ulang

Obat:

  • Pastikan untuk menggunakan titik akhir Limitless yang ditentukan di konsol

  • Penyeimbangan manual: ekstrak titik akhir router dan hubungkan aplikasi yang berbeda ke router yang berbeda

  • Untuk aplikasi libpq gunakan fitur LOADBALANCEHOSTS

  • Untuk aplikasi JDBC gunakan Plugin koneksi Limitless

  • Gunakan NLB untuk mengelola sesi dan distribusi

Pemantauan dan pemecahan masalah shard

Pecahan mengalami masalah kinerja dari tiga penyebab utama: kendala sumber daya, kemiringan data, dan kemiringan beban kerja.

Pemanfaatan sumber daya shard

Pecahan dengan kunci pecahan populer akan memiliki lebih banyak data dan beban kerja yang lebih tinggi. Ini bermanifestasi sebagai pemanfaatan sumber daya, yaitu instance akan mengkonsumsi lebih banyak ACUs.

Strategi remediasi:

  1. Menilai ulang pemilihan kunci pecahan: Tinjau kardinalitas kunci pecahan dan pola akses. Pertimbangkan kunci pecahan komposit untuk distribusi yang lebih baik.

  2. Pisahkan pecahan: Mendistribusikan beban di lebih banyak contoh pecahan

Kapan harus membagi pecahan:

  • Pecahan tunggal secara konsisten pada > 80% maks ACU

  • Throughput kueri dibatasi oleh kapasitas pecahan tunggal

Volume data pecahan

Gunakan fungsi SQL untuk menanyakan volume data:


SELECT subcluster_id, subcluster_type, pg_size_pretty(db_size) 
FROM rds_aurora.limitless_stat_database_size('postgres_limitless') 
ORDER BY 1;

Untuk melihat data per-tabel dan per-shard:


SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public', 'table_name');

Menyelesaikan pemanfaatan yang tidak merata

Ketika beban kerja atau kemiringan data berkonsentrasi pada pecahan tertentu, pecahan pemisahan mendistribusikan kembali beban di lebih banyak instance.

Pertimbangan penting:

  • Kunci pecahan mana yang harus dipindahkan tidak dapat dikontrol

  • Tidak ada cara untuk membatalkan split tanpa memulihkan ke snapshot manual yang diambil sebelum pemisahan

  • Semua instance, termasuk pecahan baru, mengkonsumsi ACU minimum instance saat idle

Pecahan pemisahan memungkinkan penskalaan lebih lanjut, dan pemisahan pecahan berturut-turut adalah jalur menuju throughput yang lebih tinggi dan penskalaan lebih lanjut, sambil mempertahankan latensi rendah.

Batasan

Waspadai kendala operasional ini:

Keterbatasan router:

  • Router tidak dapat dihapus - Setelah ditambahkan, router tetap berada di cluster

  • Rencanakan penambahan router dengan hati-hati untuk menghindari biaya dasar yang tidak perlu

Batasan pecahan:

  • Pecahan tidak dapat digabungkan - Shard split adalah operasi satu arah

  • Hanya opsi pemulihan: Pulihkan dari snapshot yang diambil sebelum dibagi

Strategi mitigasi:

  • Mulailah dengan jumlah instans minimum yang layak

  • Tambahkan kapasitas secara bertahap sesuai kebutuhan

  • Ambil snapshot sebelum perubahan topologi besar

  • Pantau biaya dasar saat cluster tumbuh