Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Skenario penggunaan umum
**Topics**
+ [Skalabilitas aplikasi](#rds-proxy-best-practices.application-scalability)
+ [Ketersediaan tinggi](#rds-proxy-best-practices.high-availability)
+ [Menggunakan beberapa proxy dengan satu target](#rds-proxy-best-practices.multiple-proxies)
## Skalabilitas aplikasi
### Penanganan koneksi dalam aplikasi tanpa server dan berbasis peristiwa
Aplikasi tanpa server dan berbasis peristiwa, seperti API dan layanan web yang didukung oleh AWS Lambda, harus sering mendukung sejumlah besar permintaan klien berumur pendek. Pola penggunaan ini dapat menyebabkan churn koneksi di sisi database tanpa kemungkinan untuk mengimplementasikan penyatuan koneksi di sisi aplikasi. Kinerja database dapat menjadi terdegradasi karena jumlah koneksi bersamaan saja, atau database mungkin melebihi batas koneksi yang mengarah ke kesalahan yang dihadapi klien.
Dalam skenario ini, RDS Proxy dapat membawa manfaat berikut:
1. Ini menurunkan biaya membangun koneksi dari database ke proxy, dan menyediakan penyatuan koneksi dan multiplexing untuk menerjemahkan sejumlah besar koneksi klien ke jumlah koneksi basis data back-end yang jauh lebih kecil. Ini membantu mengurangi overhead koneksi dan pertentangan database, terutama di mesin database seperti PostgreSQL di mana biaya membangun dan memelihara koneksi relatif tinggi.
1. Itu dapat menangani lonjakan koneksi dengan lebih anggun. Misalnya, ketika database melebihi batas koneksinya, ia segera mengembalikan kesalahan ke klien. Ketika RDS Proxy perlu meminjam koneksi dari pool tetapi pool sudah berkapasitas, proxy dapat menunggu koneksi tersedia. Kemampuan ini dapat meningkatkan pengalaman klien dengan mengubah kesalahan keras menjadi sedikit peningkatan latensi kueri.
1. Dengan ukuran kumpulan koneksi yang dapat dikonfigurasi, Anda juga dapat menggunakan RDS Proxy sebagai mekanisme throttling atau load shedding. Jika jumlah koneksi melebihi batas yang Anda tentukan, RDS Proxy menunggu koneksi tersedia dalam batas waktu yang dapat dikonfigurasi. Ini dapat berguna dalam kasus di mana database melayani beberapa beban kerja, dan Anda ingin membatasi jumlah tekanan yang dapat dibuat oleh beban kerja tertentu pada database.
### Penanganan koneksi dalam aplikasi terdistribusi berbasis kontainer
Arsitektur aplikasi terdistribusi berbasis kontainer mungkin ratusan atau bahkan ribuan kontainer, masing-masing menjalankan salinan kode aplikasi. Bahkan jika kontainer individu mampu menyatukan koneksi, kumpulan tersebut khusus wadah dan karenanya sangat kecil. Jumlah kontainer yang dikalikan dengan ukuran setiap kolam mini kontainer berpotensi melebihi batas koneksi pada basis data Amazon RDS atau Aurora Anda.
Dalam situasi ini, kemampuan RDS Proxy untuk melakukan penyatuan koneksi (menggunakan kembali koneksi) dan multiplexing (melayani banyak klien menggunakan satu koneksi back-end) adalah yang paling berharga. Anda masih dapat menggunakan penyatuan koneksi di dalam setiap kontainer untuk mengurangi churn antara utas aplikasi dan Proxy RDS, tetapi proxy dapat membantu menurunkan jumlah koneksi database back-end ke tingkat yang dapat dikelola.
### Meningkatkan pemanfaatan replika baca
Read-heavy database mungkin memerlukan beberapa replika baca untuk mendukung lalu lintas hanya-baca. Aplikasi dapat menggunakan logika mereka sendiri untuk memilih replika mana yang akan dihubungkan atau, lebih umum, mereka menggunakan mekanisme DNS-based round-robin seperti titik akhir pembaca cluster Aurora. Namun, DNS-based pendekatan dapat menyebabkan pemanfaatan replika yang tidak merata sebagai akibat dari caching DNS. Misalnya, klien dapat “menyematkan” diri mereka sendiri ke replika tertentu, mereka bisa gagal mengenali replika baru yang ditambahkan ke cluster, atau mereka mungkin mencoba menghubungkan ke replika yang sudah tidak ada lagi.
Saat Anda menggunakan titik akhir read-only Proxy RDS, proxy akan merutekan koneksi klien antara semua replika yang tersedia menggunakan logika “koneksi yang paling tidak menonjol”. RDS Proxy tidak memuat keseimbangan lalu lintas berdasarkan metrik database seperti pemanfaatan CPU, tetapi mencoba untuk menyamakan jumlah koneksi klien pada setiap replika, ditimbang oleh batas koneksi database. Misalnya, jika Anda memiliki tiga replika Aurora yang berjalan dengan `max_connections` pengaturan 500, 500, dan 1000 (masing-masing), proxy mencoba mengirim kira-kira dua kali jumlah koneksi ke replika ketiga dibandingkan dengan dua lainnya.
Anda dapat menggunakan titik akhir pembaca Proxy RDS dengan cluster Aurora atau penerapan klaster Amazon RDS Multi-AZ DB dengan dua standby yang dapat dibaca. Titik akhir pembaca proxy tidak didukung untuk penerapan instans Amazon RDS DB dengan replika baca.
### Meningkatkan efisiensi koneksi
Saat memperkenalkan proxy antara aplikasi klien dan database, tujuan Anda biasanya untuk meningkatkan efisiensi penanganan koneksi sambil juga mempertimbangkan biaya latensi dari hop jaringan tambahan melalui proxy. Lapisan perantara tambahan dapat tampak berlawanan dengan intuisi untuk meningkatkan efisiensi koneksi karena koneksi apa pun yang akan dibuka langsung terhadap database sekarang dibuka terhadap proxy. Langkah-langkah jabat tangan protokol sama dalam kedua kasus, jadi jika Anda masih menghabiskan sumber daya untuk jabat tangan koneksi, mungkin tidak jelas dari mana peningkatan efisiensi berasal.
Proxy tidak selalu membuat koneksi lebih murah untuk dibuat. Sebaliknya, ia memindahkan sebagian besar beban penanganan jabat tangan dari lapisan database ke lapisan proxy. Ketika Anda membayar sumber daya database, Anda ingin sumber daya tersebut dihabiskan untuk pekerjaan database dan bukan pada overhead tambahan. Hal ini menjadi sangat penting ketika menggunakan koneksi terenkripsi: meskipun overhead transmisi data terenkripsi melalui koneksi yang ada tidak signifikan, overhead awal pengaturan koneksi terenkripsi sangat besar. Dalam lingkungan yang berputar melalui ratusan atau ribuan koneksi per detik, upaya ekstra itu dapat dengan cepat bertambah. Anda mungkin tidak ingin menghabiskan waktu CPU itu pada sumber daya database (relatif mahal) dan sebagai gantinya menurunkannya ke lapisan proxy (relatif murah).
Mengenai latensi yang diperkenalkan oleh hop jaringan tambahan, sejauh mana hal itu penting tergantung pada seberapa “cerewet” aplikasi Anda dan berapa banyak pernyataan yang dijalankan per setiap “percakapan” dengan database. Di RDS Proxy, Anda biasanya mengamati latensi tambahan dalam milidetik satu digit rendah, tetapi itu tidak akan selalu menyebabkan dampak yang terlihat pada aplikasi Anda. Contoh:
+ Beban kerja di mana waktu eksekusi kueri berada dalam urutan puluhan atau ratusan milidetik (atau lebih) tidak mungkin memperhatikan overhead proxy karena ini adalah sebagian kecil dari total waktu kueri.
+ Aplikasi yang menjalankan kueri milidetik atau sub-milidetik satu digit dapat melihat perbedaan karena overhead kueri (satu hop jaringan tambahan per kueri) cukup besar dibandingkan dengan waktu eksekusi kueri. Ini mungkin tidak menjadi masalah jika sesi klien hanya melibatkan beberapa kueri, sehingga overhead kumulatif masih kecil.
Jika latensi tambahan dalam situasi Anda terlihat dan tidak diinginkan, Anda harus menimbangnya dengan manfaat lain menggunakan proxy (penyatuan, multiplexing, penanganan failover).
## Ketersediaan tinggi
Multi-AZ database yang berjalan di Amazon RDS dan Aurora (tidak termasuk Aurora DSQL) menggunakan mekanisme failover untuk memulihkan ketersediaan jika terjadi masalah dengan instance database utama. Failover juga digunakan sebagai bagian dari alur kerja operasional, seperti penskalaan komputasi untuk instance utama. Failover melibatkan perubahan DNS yang memindahkan titik akhir basis data primer (read/write-capable) dari instance utama sebelumnya ke yang baru dipromosikan. Perubahan DNS ini harus diamati dan dikenali oleh aplikasi klien, sehingga klien dapat mengikuti primer tanpa penundaan.
Beberapa aplikasi dapat berjuang dengan pengakuan perubahan DNS yang tepat waktu sebagai akibat dari cache DNS di sistem operasi atau di tingkat aplikasi. Meskipun merupakan praktik terbaik untuk mengatasi masalah caching DNS di tingkat aplikasi, itu tidak selalu layak karena kompleksitas aplikasi atau biaya untuk memperkenalkan perubahan.
Dalam skenario ini, RDS Proxy adalah cara yang efektif untuk menghindari penundaan DNS-related failover. Titik read/write akhir dan titik akhir hanya-baca opsional yang disediakan oleh RDS Proxy adalah “stabil” dalam arti bahwa alamat IP di belakang titik akhir tersebut tidak berubah ketika instance database bertukar peran mereka. RDS Proxy terus melacak topologi database back-end dan mengabstraksi perubahan peran instance dari klien.
Ada cara alternatif untuk menangani masalah caching DNS, seperti dengan menggunakan driver canggih yang secara langsung mampu mendeteksi topologi database tanpa bergantung pada DNS. Namun, mungkin lebih mudah untuk menyebarkan proxy tunggal di depan database daripada memperkenalkan perubahan kode dan driver baru di tingkat aplikasi.
### Baca ketersediaan
Selain meningkatkan pengalaman klien selama kegagalan database, RDS Proxy juga membantu ketersediaan aplikasi jika terjadi masalah replika baca. Ia melakukannya dengan dua cara:
1. Jika replika baca menjadi tidak tersedia, tetapi ada replika lain yang tersedia di cluster, proxy dapat merutekan koneksi baru ke replika yang tersedia. Klien tidak perlu khawatir tentang penundaan propagasi DNS atau caching DNS.
1. Untuk koneksi klien yang sudah ada yang multipleks, proxy dapat mengirim kueri berikutnya dari koneksi tersebut ke replika lain yang tersedia. Dalam situasi ini, klien mungkin bahkan tidak menyadari bahwa replika back-end mengalami masalah. Saat menggunakan teknik ini, RDS Proxy memastikan bahwa replika baru tidak berada di belakang yang sebelumnya dalam hal kelambatan replikasi. Dengan begitu, kueri berikutnya yang dikirim oleh klien tidak akan melihat data yang dapat dianggap basi.
## Menggunakan beberapa proxy dengan satu target
Sebagai praktik terbaik, gunakan satu Proxy RDS per target database seperti instans Amazon RDS atau cluster Aurora. Ini bekerja dengan baik di sebagian besar skenario, ini membuat konfigurasi tetap sederhana, dan itu membuat pengalaman klien lebih dapat diprediksi. Sebagai perbandingan, menggunakan beberapa proxy mengharuskan Anda untuk menyelaraskan konfigurasi dengan hati-hati di semua proxy untuk menghindari perilaku yang tidak terduga. Misalnya, Anda harus memastikan bahwa ukuran gabungan dari semua kumpulan proxy tidak melebihi batas koneksi target database tunggal.
Anda mungkin masih mengeksplorasi gagasan menggunakan beberapa proxy dalam situasi tertentu. Bagian berikut membahas skenario yang paling umum dan menguraikan pro dan kontra dari proxy tunggal versus pendekatan multi-proxy.
### Ketersediaan proxy
Infrastruktur Proxy RDS sangat tersedia dan digunakan di beberapa Availability Zone (AZ) berdasarkan desain. Kapasitas proxy didistribusikan di banyak node dengan pemantauan kesehatan berkelanjutan, dan secara otomatis disesuaikan berdasarkan ukuran instans yang disediakan atau pengaturan ACU maksimum Tanpa Server v2 database Anda. Sebagai hasil dari Multi-AZ desain terdistribusi proxy, Anda tidak perlu menjalankan beberapa proxy di depan klaster Amazon RDS atau Aurora Anda untuk tujuan ketersediaan tinggi.
Faktanya, menggunakan beberapa proxy di depan satu target database berarti bahwa tumpukan aplikasi sekarang bertanggung jawab untuk mendeteksi dan bereaksi terhadap masalah alih-alih mengandalkan mekanisme kuat yang dibangun ke dalam proxy. Akibatnya, menggunakan beberapa proxy untuk alasan ketersediaan tinggi sangat tidak disarankan karena kemungkinan akan menimbulkan lebih banyak masalah daripada yang dapat dipecahkan.
### Menangani beberapa kumpulan klien
Setiap proxy menyediakan satu read/write titik akhir dan (opsional) titik akhir tambahan read/write atau hanya-baca. Ketika satu proxy digunakan untuk menangani beberapa grup klien atau beberapa beban kerja, beban kerja tersebut berpotensi mengganggu. Misalnya, satu beban kerja dapat memonopoli kumpulan koneksi ke titik di mana tidak ada cukup koneksi bebas yang tersisa untuk menangani beban kerja lainnya. Menggunakan proxy terpisah untuk mengisolasi beban kerja bisa menjadi solusi yang menarik, tetapi Anda dapat mempertimbangkan opsi lain terlebih dahulu:
+ Basis data itu sendiri mungkin memberikan alternatif yang lebih sederhana untuk menjalankan beberapa proxy. Misalnya, jika masalah disebabkan oleh pengguna tertentu yang memonopoli kumpulan, Anda dapat menggunakan sistem izin database untuk membatasi jumlah koneksi bersamaan yang diizinkan untuk dibuka oleh pengguna tersebut.
+ Demikian pula, batas waktu kueri tingkat database dan batas waktu idle dapat mengatasi masalah dengan koneksi yatim piatu atau kueri runaway.
+ Jika masalah disebabkan oleh kueri atau durasi transaksi atau konsumsi sumber daya per kueri daripada jumlah koneksi bersamaan, menggunakan proxy tambahan tidak akan membantu karena proxy tidak memberlakukan batasan pada kueri atau bobot transaksi. Jika masalah tidak dapat diatasi di sumbernya, Anda dapat menggunakan penjadwal peristiwa database untuk menjalankan kode yang mendeteksi dan menghentikan aktivitas klien berdasarkan kondisi arbitrer alih-alih memindahkan klien bermasalah tersebut ke proxy terpisah.
Jika Anda memutuskan untuk menggunakan beberapa proxy di depan target yang sama, pastikan bahwa ukuran total semua kumpulan koneksi tidak melebihi kemampuan database target. Misalnya, jumlah `MaxConnectionsPercent` seluruh proxy harus kurang dari 100, jika tidak proxy dapat mencoba untuk membuka lebih banyak koneksi daripada database dikonfigurasi untuk menangani.
Setiap proxy ditagih secara terpisah, dan tingkat penagihan tergantung pada ukuran sumber daya database yang mendasarinya dan bukan aktivitas beban kerja. Pertimbangkan biaya menjalankan beberapa proxy versus biaya penerapan solusi alternatif, jika ada.
### Mengontrol kolam baca dan tulis secara mandiri
Setiap proxy menyediakan satu read/write titik akhir dan (opsional) titik akhir tambahan read/write atau hanya-baca, tetapi batas dan batas waktu dikonfigurasi untuk seluruh target proxy dan tidak secara individual untuk setiap titik akhir proxy.
Misalnya, Anda mungkin memiliki klaster Aurora yang menangani sejumlah besar kueri hanya-baca menggunakan beberapa replika baca dan titik akhir pembaca proxy, tetapi Anda ingin membatasi jumlah read/write koneksi untuk mengurangi tekanan sumber daya pada penulis tunggal. Karena `MaxConnectionsPercent` pengaturan ditentukan untuk seluruh target proxy (cluster), Anda tidak dapat membatasi jumlah koneksi terhadap read/write titik akhir tanpa juga memengaruhi batas titik akhir hanya-baca.
Ada beberapa cara untuk mendekati tantangan ini:
Anda dapat meluncurkan replika baca tambahan di cluster dan secara proporsional mengurangi pengaturan proxy. `MaxConnectionsPercent` Ini mempertahankan ukuran total kumpulan koneksi hanya-baca sekaligus mengurangi jumlah maksimum koneksi yang diizinkan pada penulis. Namun, ini juga meningkatkan biaya cluster dan semakin kurang efektif semakin banyak replika yang Anda miliki.
Anda dapat menggunakan grup parameter tingkat instance untuk mengonfigurasi batas koneksi database (seperti di `max_connections` Aurora MySQL atau PostgreSQL) untuk replika baca secara terpisah dari penulis. Namun, Anda harus menghindari penggunaan konfigurasi parameter asimetris karena replika dapat dipromosikan ke peran penulis selama failover, sehingga diferensiasi parameter awal tidak akan permanen. Anda mungkin berpikir untuk mengubah pengaturan prioritas failover tingkat instance untuk memengaruhi replika mana yang dipilih untuk promosi selama failover, dan menggunakannya sebagai mekanisme pengecualian failover lunak yang membuat konfigurasi asimetris lebih dapat diprediksi. Namun, prioritas failover hanya berfungsi sebagai petunjuk dan bukan jaminan kuat perilaku failover. Multi-instance Oleh karena itu, konfigurasi dengan pengaturan asimetris tidak disarankan karena memerlukan pemantauan berkelanjutan dan dapat menghasilkan perilaku yang tidak terduga jika failover mendarat pada instance yang tidak Anda sukai.
Dalam skenario ini, menggunakan beberapa proxy bisa menjadi cara terbersih untuk mengelola kumpulan baca dan tulis secara terpisah. Anda dapat membuat dua proxy untuk target database tunggal, lalu mengonfigurasi aplikasi untuk menggunakan titik akhir penulis dari proxy pertama dan titik akhir hanya-baca dari proxy kedua. Satu proxy hanya menangani beban kerja tulis, proxy lainnya hanya menangani beban kerja baca, dan `MaxConnectionsPercent` (serta pengaturan lainnya) dapat dikonfigurasi secara independen untuk setiap proxy. Solusi ini melibatkan biaya tambahan untuk menjalankan proxy kedua, tetapi lebih sederhana dan lebih dapat diprediksi daripada alternatif sebelumnya.