Pertimbangan aplikasi dan beban kerja

Multi-tenant dan lingkungan multi-pengguna

Ketika datang ke skalabilitas dan meningkatkan manajemen koneksi, manfaat menggunakan RDS Proxy bergantung pada kemampuannya untuk melakukan penyatuan koneksi dan, pada tingkat yang jauh lebih besar, multiplexing koneksi. Penggabungan koneksi mengurangi overhead yang terkait dengan membuka dan menutup koneksi. Multiplexing koneksi memungkinkan proxy untuk menggunakan kembali koneksi database back-end setelah transaksi. Untuk informasi selengkapnya, lihat Konsep dan terminologi Proksi RDS.

Ketika koneksi tidak dapat dimultipleks, proxy akan kembali ke perilaku yang disebut pin koneksi. Pinning adalah situasi di mana klien dipaksa untuk menggunakan koneksi proxy dasar yang sama untuk seluruh sesinya. Koneksi proxy dicadangkan untuk satu klien itu, jadi tidak tersedia untuk digunakan kembali oleh klien lain. Dengan kata lain, pinning menciptakan asosiasi 1:1 eksklusif antara koneksi client-proxy dan koneksi proxy-database. Menghindari penyematan penting dalam semua skenario di mana RDS Proxy digunakan terutama untuk alasan skalabilitas dan efisiensi. Untuk perilaku penyematan terbaru, lihat Menghindari menyematkan Proxy RDS.

Sebagai aturan umum, koneksi dapat dimultipleks ketika mereka memiliki keadaan yang identik. Koneksi tidak dapat dimultipleks saat berisi informasi status khusus sesi khusus. Salah satu aspek yang mendefinisikan status sesi adalah nama pengguna database yang terkait dengan koneksi. Saat Anda terhubung ke proxy sebagai “User_a”, proxy perlu membuka koneksi database back-end sebagai “User_a” juga. Proxy berpotensi mengumpulkan dan menggunakan kembali koneksi back-end ini untuk klien lain yang masuk sebagai “User_a”, tetapi tidak untuk klien yang menggunakan nama pengguna yang berbeda.

Perilaku ini dapat secara signifikan mengurangi efisiensi pengumpulan dan multiplexing di lingkungan multi-pengguna dengan sejumlah besar akun database unik. Hal ini terutama berlaku dalam arsitektur yang menggunakan tingkat database atau multi-tenancy tingkat skema. Jika database berisi seribu skema (satu per penyewa) dan setiap penyewa terhubung ke database dengan nama pengguna yang berbeda, kumpulan koneksi menjadi terfragmentasi menjadi kumpulan mikro khusus pengguna, mengurangi efisiensi keseluruhan.

Selain itu, aspek-aspek khusus untuk mesin database mungkin lebih mempengaruhi efisiensi penyatuan dan kemampuan proxy untuk koneksi multipleks:

1. Di Amazon RDS dan Aurora PostgreSQL, multi-tenancy sering diimplementasikan dengan menggunakan satu database per penyewa. Namun, di PostgreSQL, koneksi bersifat khusus basis data: koneksi yang dibuka terhadap satu database tidak dapat mengakses data dari database lain. Oleh karena itu, multi-tenancy tingkat database mengurangi efisiensi penyatuan dan multiplexing di tingkat proxy. Pertimbangan ini juga berlaku jika beban kerja menggunakan multi-tenancy tingkat skema dan sesi klien menggunakan kustom. search_path Namun, jika semua sesi menggunakan jalur pencarian default dan merujuk ke tabel menggunakan nama yang sepenuhnya memenuhi syarat (schema_name.table_name), sesi tersebut dapat dimultipleks.

2. Di Amazon RDS dan Aurora MySQL, istilah “database” dan “skema” adalah sinonim. Multi-tenancy sering diimplementasikan dengan menggunakan satu skema per penyewa, yang di MySQL sama dengan satu database per penyewa. Koneksi dibuka terhadap server MySQL secara keseluruhan dan tidak terikat pada skema. Jika aplikasi menggunakan multi-tenancy tingkat skema, multiplexing koneksi masih dimungkinkan untuk klien yang menggunakan nama pengguna database yang sama, bahkan jika koneksi tersebut perlu mengakses data dalam skema yang berbeda. Multiplexing akan paling efektif jika pemisahan penyewa dilakukan pada tingkat aplikasi alih-alih menggunakan akun database yang berbeda untuk setiap penyewa.

Dalam lingkungan multi-skema, efisiensi multiplexing tergantung pada bagaimana Anda merujuk ke nama tabel:

• Untuk klien yang memilih skema saat ini menggunakan variabel sesi (SET search_path ...di PostgreSQL dan di MySQL) USE schema; dan kemudian menggunakan nama tabel yang tidak memenuhi syarat dalam kueri (SELECT ... FROM table_nameseperti), multiplexing koneksi hanya berfungsi antara klien menggunakan skema yang sama atau jalur pencarian yang sama.

• Untuk klien yang tidak memodifikasi status sesi untuk menentukan skema saat ini, tetapi menggunakan nama tabel yang sepenuhnya memenuhi syarat dalam pernyataan SQL (sepertiSELECT ... FROM schema_name.table_name), multiplexing juga tidak dibatasi.

Database yang melayani beberapa aplikasi atau tumpukan perangkat lunak

Seperti yang dibahas di bagian sebelumnya, karakteristik status koneksi tertentu tidak menyebabkan penyematan, tetapi masih mengurangi kemampuan proxy untuk menggunakan kembali koneksi antara klien yang berbeda. Saat digunakan dengan target MySQL, Proxy RDS melacak sejumlah pernyataan dan variabel sesi yang mengonfigurasi status sesi, seperti set karakter, zona waktu, dan pengaturan pemeriksaan. Ketika klien menggunakan pernyataan atau variabel yang dilacak untuk mengonfigurasi pengaturan sesi, koneksi proxy hanya dapat digunakan kembali untuk klien lain yang memiliki nilai yang sama untuk pengaturan tersebut.

Akibatnya, perilaku aplikasi dan driver tertentu dapat mengurangi kemampuan Anda untuk menggunakan kembali koneksi di dalam proxy. Misalnya, Anda mungkin mengizinkan aplikasi yang berbeda untuk terhubung ke database menggunakan nama pengguna yang sama, dengan asumsi bahwa proxy dapat menggunakan kembali dan koneksi multipleks antara aplikasi tersebut. Namun, jika satu aplikasi bootstraps koneksi dengan zona waktu A (SET time_zone = ?) dan aplikasi lain menggunakan zona waktu B, koneksi dapat digunakan kembali dalam aplikasi tetapi tidak di antara aplikasi. Hal ini menyebabkan fragmentasi kumpulan koneksi, yang secara negatif mempengaruhi efektivitas penyatuan dan multiplexing.

Untuk informasi selengkapnya, lihat Apa yang dilacak Proksi RDS untuk basis data RDS for MariaDB dan RDS for MySQL. Pelacakan status sesi saat ini tidak didukung untuk target database selain MySQL.

Lihat Pedoman konfigurasi pedoman konfigurasi dan praktik terbaik untuk mengelola status sesi untuk menghindari penyematan koneksi.

Menggunakan penyatuan tingkat aplikasi dan driver tingkat lanjut dengan RDS Proxy

RDS Proxy membantu meningkatkan skalabilitas dan efisiensi koneksi dalam situasi di mana aplikasi itu sendiri tidak menggunakan penyatuan koneksi. Pada saat yang sama, banyak driver dan kerangka kerja menyertakan fitur penyatuan. Anda mungkin juga menggunakan pembungkus atau driver lanjutan yang mengimplementasikan beberapa fitur proxy di tingkat driver.

Menggunakan penyatuan tingkat aplikasi dan peningkatan penanganan koneksi lainnya tidak secara inheren bertentangan dengan penggunaan RDS Proxy, dan tidak meniadakan manfaatnya. Misalnya, Anda mungkin menggunakan penyatuan koneksi di wadah aplikasi Anda, tetapi jumlah kontainer cukup besar sehingga Anda masih kehabisan batas koneksi database tanpa menggunakan proxy. Saat menggunakan RDS Proxy dengan kumpulan tingkat aplikasi dan fitur terkait koneksi lainnya, tinjau dan pahami alasan adanya fitur penanganan koneksi lanjutan di tingkat aplikasi. Tentukan fitur mana yang layak disimpan (atau tidak berbahaya), dan mana yang dapat tumpang tindih atau mengganggu perilaku proxy. Contoh:

1. Fitur penyatuan yang dibangun ke dalam driver dan kerangka kerja dapat berguna bahkan jika mereka tampak tumpang tindih dengan fungsionalitas Proxy RDS. Jika kumpulan tingkat aplikasi meningkatkan efisiensi koneksi lokal di atas manfaat yang diberikan oleh proxy, Anda dapat menyimpannya.

2. Fitur yang terkait dengan penanganan failover dapat mengganggu logika Proxy RDS atau meningkatkan kompleksitas tumpukan secara keseluruhan tanpa memberikan manfaat. Misalnya, jika aplikasi Anda secara aktif melacak topologi cluster Aurora Anda untuk menghindari penundaan DNS-related failover, aplikasi tidak perlu lagi melakukannya dengan RDS Proxy. Menjaga logika pelacakan topologi ini dapat menyebabkan perilaku yang tidak diinginkan, seperti thread aplikasi yang melewati proxy dan menghubungkan langsung ke instance database individual. Dalam skenario ini, Anda dapat menonaktifkan logika pelacakan tingkat aplikasi dan membiarkan RDS Proxy mengabstraksikan topologi cluster untuk Anda.

3. Pustaka penyatuan koneksi mungkin menggunakan fitur manajemen status yang tampaknya bermanfaat secara teori, tetapi mengganggu perilaku proxy. Salah satu contohnya adalah pustaka PostgreSQL yang memanggil kueri untuk mengatur ulang status koneksi antar DISCARD ALL pinjam. Tampaknya mengatur ulang koneksi akan membantu penyatuan dan multiplexing, tetapi itu mengganggu manajemen status sesi internal Amazon RDS Proxy. Saat menggunakanDISCARD, proxy menyematkan koneksi klien Anda saat rilis, mengurangi efisiensi multiplexing.

Untuk komponen penanganan koneksi tingkat aplikasi yang Anda simpan, pastikan konfigurasinya tidak mengganggu logika penanganan koneksi yang digunakan oleh Amazon RDS Proxy. Contoh:

• Sejajarkan ukuran kolam di semua lapisan tumpukan. Jika kumpulan tingkat aplikasi terlalu besar (atau kumpulan proxy Anda berukuran kecil), aplikasi dapat mencoba membuka koneksi yang tidak dikonfigurasi untuk ditangani oleh proxy. Koneksi tersebut dapat mengalami penundaan terbaik dan kesalahan penolakan paling buruk.

• Sejajarkan pengaturan batas waktu untuk mengurangi churn dan menghindari kebingungan seputar perilaku koneksi. Jika kumpulan aplikasi membuat koneksi tetap hidup selama 300 detik, tetapi proxy dikonfigurasi untuk menutup koneksi setelah 60 detik, aplikasi akan melihat penutupan koneksi prematur alih-alih perilaku yang diharapkan.

Beberapa keputusan arsitektur dan pilihan konfigurasi ini mungkin memerlukan pengujian dan eksperimen. Tidak selalu mungkin untuk memprediksi perilaku aplikasi secara tepat di lingkungan dengan beberapa lapisan pengumpulan dan manajemen koneksi.

Lihat Pedoman konfigurasi untuk pedoman konfigurasi umum.