Penskalaan Otomatis dengan Amazon Aurora Tanpa Server

Amazon Aurora Tanpa Server menyediakan basis data relasional sesuai permintaan, dapat diskalakan secara otomatis, sangat tersedia, yang hanya menagih Anda saat sedang digunakan. Ini memberikan opsi yang relatif sederhana dan hemat biaya untuk beban kerja yang jarang, terputus-putus, atau tidak terduga. Apa yang memungkinkannya adalah aplikasi ini otomatis memulai, menskalakan kapasitas komputasi agar sesuai dengan penggunaan aplikasi Anda, dan kemudian dimatikan saat tidak lagi dibutuhkan.

Diagram berikut menunjukkan arsitektur tingkat tinggi Aurora Tanpa Server.

Dengan Aurora Tanpa Server, Anda mendapatkan satu titik akhir (sebagai lawan dari dua titik akhir untuk DB standar yang disediakan Aurora). Ini pada dasarnya adalah catatan DNS yang terdiri dari armada proxy yang berada di atas instance database. Dari titik server MySQL, artinya koneksi selalu datang dari armada proxy.

Penskalaan Otomatis Tanpa Server Aurora

Aurora Tanpa Server saat ini hanya tersedia untuk MySQL 5.6. Anda pada dasarnya harus mengatur unit kapasitas minimum dan maksimum untuk cluster DB. Setiap unit kapasitas setara dengan konfigurasi komputasi dan memori tertentu. Aurora Tanpa Server mengurangi sumber daya untuk klaster DB saat beban kerjanya di bawah ambang batas ini. Aurora Tanpa Server dapat mengurangi kapasitas hingga minimum atau meningkatkan kapasitas hingga unit kapasitas maksimum.

Kluster akan otomatis ditingkatkan skalanya jika salah satu dari kondisi berikut terpenuhi:

• Utilisasi CPU di atas 70% ATAU
• Lebih dari 90% koneksi sedang digunakan

Kluster akan turun secara otomatis jika kedua kondisi berikut terpenuhi:

• Penggunaan CPU turun di bawah 30% DAN
• Kurang dari 40% koneksi yang digunakan.

Beberapa hal penting yang perlu diketahui tentang aliran penskalaan otomatis Aurora:

• Ini hanya akan ditingkatkan jika mendeteksi masalah kinerja yang dapat diselesaikan dengan meningkatkannya.
• Setelah scaling up, periode cooldown untuk scaling down adalah 15 menit.
• Setelah scaling down, periode cooldown untuk scaling down berikutnya adalah 310 detik.
• Ini diskalakan ke kapasitas nol saat tidak ada koneksi selama 5 menit.

Secara default, Aurora Tanpa Server melakukan penskalaan otomatis dengan mulus, tanpa memutus koneksi database aktif apa pun ke server. Ia mampu menentukan titik penskalaan (titik waktu di mana database dapat dengan aman memulai operasi penskalaan). Namun, dalam kondisi berikut, Aurora Tanpa Server mungkin tidak dapat menemukan titik penskalaan:

• Kueri atau transaksi yang berjalan lama sedang berlangsung.
• Tabel atau kunci tabel sementara sedang digunakan.

Jika salah satu dari kasus di atas terjadi, Aurora Tanpa Server terus mencoba menemukan titik penskalaan sehingga dapat memulai operasi penskalaan (kecuali "Force Scaling" diaktifkan). Ia melakukan ini selama menentukan bahwa cluster DB harus diskalakan.

Mengamati Perilaku Penskalaan Otomatis Aurora

Perhatikan bahwa di Aurora Tanpa Server, hanya sejumlah kecil parameter yang dapat diubah dan max_connections bukan salah satunya. Untuk semua parameter konfigurasi lainnya, cluster Aurora MySQL Serverless menggunakan nilai default. Untuk max_connections, dikontrol secara dinamis oleh Aurora Tanpa Server menggunakan rumus berikut: 

max_connections =TERBESAR({log(DBInstanceClassMemory/805306368)*45},{log(DBInstanceClassMemory/8187281408)*1000})

Di mana, log adalah log₂ (log base-2) dan "DBInstanceClassMemory" adalah jumlah byte memori yang dialokasikan ke kelas instans DB yang terkait dengan instans DB saat ini, dikurangi memori yang digunakan oleh proses Amazon RDS yang mengelola instans. Cukup sulit untuk menentukan nilai yang akan digunakan Aurora, jadi sebaiknya lakukan beberapa tes untuk memahami bagaimana nilai ini diskalakan.

Berikut adalah ringkasan penerapan Aurora Tanpa Server kami untuk pengujian ini:

Untuk contoh ini saya telah memilih minimal 1 unit kapasitas Aurora yang setara dengan RAM 2GB hingga maksimal 256 unit kapasitas dengan RAM 488GB.

Pengujian dilakukan menggunakan sysbench, hanya dengan mengirimkan beberapa utas hingga mencapai batas koneksi database MySQL. Upaya pertama kami untuk mengirimkan 128 koneksi database simultan sekaligus langsung gagal:

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=128 \
--delete_inserts=5 \
--time=360 \
--max-requests=0 \
--db-driver=mysql \
--db-ps-mode=disable \
--mysql-host=${_HOST} \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=password \
--tables=20 \
--table-size=100000 \
run

Perintah di atas segera mengembalikan kesalahan 'Terlalu banyak koneksi':

FATAL: unable to connect to MySQL server on host 'aurora-sysbench.cluster-cdw9q2wnb00s.ap-southeast-1.rds.amazonaws.com', port 3306, aborting...
FATAL: error 1040: Too many connections

Saat melihat pengaturan max_connection, kami mendapatkan yang berikut:

mysql> SELECT @@hostname, @@max_connections;
+----------------+-------------------+
| @@hostname     | @@max_connections |
+----------------+-------------------+
| ip-10-2-56-105 |                90 |
+----------------+-------------------+

Ternyata, nilai awal max_connections untuk instans Aurora kami dengan satu kapasitas DB (RAM 2GB) adalah 90. Ini sebenarnya jauh lebih rendah dari nilai yang kami antisipasi jika dihitung menggunakan rumus yang disediakan untuk memperkirakan nilai max_connections:

mysql> SELECT GREATEST({log2(2147483648/805306368)*45},{log2(2147483648/8187281408)*1000});
+------------------------------------------------------------------------------+
| GREATEST({log2(2147483648/805306368)*45},{log2(2147483648/8187281408)*1000}) |
+------------------------------------------------------------------------------+
|                                                                     262.2951 |
+------------------------------------------------------------------------------+

Ini berarti DBInstanceClassMemory tidak sama dengan memori sebenarnya untuk instans Aurora. Itu harus jauh lebih rendah. Menurut utas diskusi ini, nilai variabel disesuaikan untuk memperhitungkan memori yang sudah digunakan untuk layanan OS dan daemon manajemen RDS.

Namun demikian, mengubah nilai max_connections default menjadi sesuatu yang lebih tinggi juga tidak akan membantu kami karena nilai ini dikontrol secara dinamis oleh klaster Aurora Tanpa Server. Jadi, kami harus mengurangi nilai utas awal sysbench menjadi 84 karena utas internal Aurora sudah mencadangkan sekitar 4 hingga 5 koneksi melalui 'rdsadmin'@'localhost'. Selain itu, kami juga memerlukan koneksi ekstra untuk tujuan pengelolaan dan pemantauan kami.

Jadi kami menjalankan perintah berikut sebagai gantinya (dengan --threads=84):

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=84 \
--delete_inserts=5 \
--time=600 \
--max-requests=0 \
--db-driver=mysql \
--db-ps-mode=disable \
--mysql-host=${_HOST} \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=password \
--tables=20 \
--table-size=100000 \
run

Setelah tes di atas selesai dalam 10 menit (--time=600), kami menjalankan perintah yang sama lagi dan saat ini, beberapa variabel dan status penting telah berubah seperti yang ditunjukkan di bawah ini:

mysql> SELECT @@hostname AS hostname, @@max_connections AS max_connections, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+--------------+-----------------+-------------------+--------+
| hostname     | max_connections | threads_connected | uptime |
+--------------+-----------------+-------------------+--------+
| ip-10-2-34-7 |             180 | 179               | 157    |
+--------------+-----------------+-------------------+--------+

Perhatikan bahwa max_connections sekarang telah berlipat ganda hingga 180, dengan nama host yang berbeda dan waktu aktif yang kecil seperti server baru saja dimulai. Dari sudut pandang aplikasi, sepertinya "instance database yang lebih besar" telah mengambil alih titik akhir dan dikonfigurasi dengan variabel max_connections yang berbeda. Melihat peristiwa Aurora, berikut yang terjadi:

Wed, 04 Sep 2019 08:50:56 GMT The DB cluster has scaled from 1 capacity unit to 2 capacity units.

Kemudian, kami menjalankan perintah sysbench yang sama, membuat 84 koneksi lain ke titik akhir database. Setelah stress test yang dihasilkan selesai, server secara otomatis meningkatkan kapasitas hingga 4 DB, seperti yang ditunjukkan di bawah ini:

mysql> SELECT @@hostname AS hostname, @@max_connections AS max_connections, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+---------------+-----------------+-------------------+--------+
| hostname      | max_connections | threads_connected | uptime |
+---------------+-----------------+-------------------+--------+
| ip-10-2-12-75 |             270 | 6                 | 300    |
+---------------+-----------------+-------------------+--------+

Anda dapat mengetahuinya dengan melihat hostname, max_connection, dan nilai uptime yang berbeda jika dibandingkan dengan yang sebelumnya. Instance lain yang lebih besar telah "mengambil alih" peran dari instance sebelumnya, di mana kapasitas DB sama dengan 2. Titik penskalaan sebenarnya adalah ketika beban server menurun dan hampir menyentuh lantai. Dalam pengujian kami, jika kami menjaga koneksi tetap penuh dan beban basis data tinggi secara konsisten, penskalaan otomatis tidak akan terjadi.

Dengan melihat kedua tangkapan layar di bawah, kami dapat mengetahui bahwa penskalaan hanya terjadi ketika Sysbench kami telah menyelesaikan uji stresnya selama 600 detik karena itu adalah titik teraman untuk melakukan penskalaan otomatis.

Saat melihat peristiwa Aurora, peristiwa berikut terjadi:

Wed, 04 Sep 2019 16:25:00 GMT Scaling DB cluster from 4 capacity units to 2 capacity units for this reason: Autoscaling.
Wed, 04 Sep 2019 16:25:05 GMT The DB cluster has scaled from 4 capacity units to 2 capacity units.

Akhirnya, kami membuat lebih banyak koneksi hingga hampir 270 dan menunggu hingga selesai, untuk masuk ke kapasitas 8 DB:

mysql> SELECT @@hostname as hostname, @@max_connections AS max_connections, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+---------------+-----------------+-------------------+--------+
| hostname      | max_connections | threads_connected | uptime |
+---------------+-----------------+-------------------+--------+
| ip-10-2-72-12 |            1000 | 144               | 230    |
+---------------+-----------------+-------------------+--------+

Dalam instance 8 unit kapasitas, nilai MySQL max_connections sekarang adalah 1000. Kami mengulangi langkah serupa dengan memaksimalkan koneksi database dan hingga batas 256 unit kapasitas. Tabel berikut merangkum keseluruhan unit kapasitas DB versus nilai max_connections dalam pengujian kami hingga kapasitas DB maksimum:

Penskalaan Paksa

Seperti disebutkan di atas, Aurora Tanpa Server hanya akan melakukan penskalaan otomatis jika aman untuk melakukannya. Namun, pengguna memiliki opsi untuk memaksa penskalaan kapasitas DB agar segera terjadi dengan mencentang kotak Paksa penskalaan di bawah opsi 'Konfigurasi penskalaan tambahan':

Saat penskalaan paksa diaktifkan, penskalaan terjadi segera setelah batas waktu habis dicapai yaitu 300 detik. Perilaku ini dapat menyebabkan gangguan database dari aplikasi Anda di mana koneksi aktif ke database mungkin terputus. Kami mengamati kesalahan berikut ketika penskalaan otomatis paksa terjadi setelah mencapai batas waktu:

FATAL: mysql_drv_query() returned error 1105 (The last transaction was aborted due to an unknown error. Please retry.) for query 'SELECT c FROM sbtest19 WHERE id=52824'
FATAL: `thread_run' function failed: /usr/share/sysbench/oltp_common.lua:419: SQL error, errno = 1105, state = 'HY000': The last transaction was aborted due to an unknown error. Please retry.

Hal di atas hanya berarti, alih-alih menemukan waktu yang tepat untuk meningkatkan skala, Aurora Tanpa Server memaksa penggantian instans dilakukan segera setelah mencapai batas waktu, yang menyebabkan transaksi dibatalkan dan mundur. Mencoba kembali kueri yang dibatalkan untuk kedua kalinya kemungkinan akan menyelesaikan masalah. Konfigurasi ini dapat digunakan jika aplikasi Anda tahan terhadap penurunan koneksi.

Ringkasan

Penskalaan otomatis Amazon Aurora Tanpa Server adalah solusi penskalaan vertikal, di mana instans yang lebih kuat mengambil alih instans yang lebih rendah, memanfaatkan teknologi penyimpanan bersama Aurora yang mendasarinya secara efisien. Secara default, operasi penskalaan otomatis dilakukan dengan mulus, di mana Aurora menemukan titik penskalaan yang aman untuk melakukan peralihan instans. Seseorang memiliki opsi untuk memaksa penskalaan otomatis dengan risiko koneksi database aktif terputus.