Lakukan Pengujian Kekacauan di Cluster Amazon Aurora Anda

“Semuanya gagal sepanjang waktu” Werner Vogels, AWS CTO

Pada tahun 2010, Netflix memperkenalkan alat yang disebut “Chaos Monkey”, yang digunakan untuk memperkenalkan kesalahan dalam lingkungan produksi. Chaos Monkey menyebabkan lahirnya rekayasa Chaos di mana tim menguji aplikasi langsung mereka dengan sengaja menyuntikkan kesalahan. Pengamatan kemudian digunakan untuk mengambil tindakan korektif dan meningkatkan ketahanan aplikasi.

Di blog ini, Anda akan mempelajari tentang kemampuan injeksi kesalahan yang tersedia di Amazon Aurora untuk mensimulasikan berbagai kesalahan database.

Eksperimen Kekacauan

Eksperimen Chaos terdiri dari:

• Memahami dasar aplikasi: Perilaku kondisi mapan aplikasi
• Merancang percobaan: Tanyakan “Apa yang bisa salah?” untuk mengidentifikasi skenario kegagalan
• Jalankan eksperimen: Perkenalkan kesalahan di lingkungan aplikasi
• Perhatikan dan koreksi: Mendesain ulang aplikasi atau infrastruktur untuk toleransi kesalahan

Eksperimen kekacauan memerlukan simulasi kesalahan di seluruh komponen aplikasi yang terdistribusi. Amazon Aurora menyediakan serangkaian kemampuan simulasi kesalahan yang dapat digunakan oleh tim untuk melakukan eksperimen chaos terhadap aplikasi mereka.

Injeksi kesalahan Amazon Aurora

Amazon Aurora adalah layanan database terkelola sepenuhnya yang kompatibel dengan MySQL dan PostgreSQL. Aurora sangat toleran terhadap kesalahan karena arsitektur penyimpanan yang direplikasi enam arah. Untuk menguji ketahanan aplikasi yang dibangun dengan Aurora, pengembang dapat memanfaatkan fitur injeksi kesalahan asli untuk merancang eksperimen chaos. Hasil eksperimen memberikan pemahaman yang lebih baik tentang radius ledakan, kedalaman pemantauan yang diperlukan, dan kebutuhan untuk mengevaluasi buku pedoman respons peristiwa.

Di bagian ini, kami akan menjelaskan berbagai skenario injeksi kesalahan yang dapat Anda gunakan untuk merancang eksperimen Anda sendiri. Kami akan menunjukkan cara melakukan eksperimen dan menggunakan hasilnya. Ini akan membuat aplikasi Anda lebih tangguh dan siap untuk acara yang sebenarnya.

Perhatikan bahwa ketersediaan fitur injeksi kesalahan tergantung pada versi MySQL dan PostgreSQL.

Gambar 1. Ikhtisar injeksi kesalahan

1. Menguji sebuah instance crash

Cluster Aurora dapat memiliki satu replika utama dan hingga 15 replika baca. Jika instance utama gagal, salah satu replika menjadi yang utama. Aplikasi harus dirancang untuk pulih dari kegagalan instans ini sesegera mungkin agar berdampak minimal pada pengalaman pengguna akhir.

Injeksi kesalahan kerusakan instans mensimulasikan kegagalan instans/pengirim/node di kluster database Aurora. Injeksi kesalahan dapat dilakukan pada primer atau replika dengan menjalankan API terhadap instance target.

Contoh: Aurora PostgreSQL misalnya simulasi kerusakan

Kueri berikut akan mensimulasikan crash instance database:

SELECT aurora_inject_crash ('instance' );

Karena ini adalah simulasi, ini tidak mengarah ke failover ke replika. Sebagai alternatif untuk menggunakan API ini, Anda dapat melakukan failover aktual dengan menggunakan AWS Management Console atau AWS CLI.

Tim harus mengamati perubahan perilaku aplikasi untuk memahami dampak kegagalan instans. Mengambil tindakan korektif untuk mengurangi dampak kegagalan tersebut pada aplikasi.

Waktu pemulihan yang lama pada aplikasi akan mengharuskan tim untuk mengurangi waktu aktif (TTL) Layanan Nama Domain (DNS) untuk koneksi DB. Sebagai praktik terbaik umum, cluster Aurora Database harus memiliki setidaknya satu replika.

2. Menguji kegagalan replika

Aurora mengelola replikasi asinkron antara node cluster dalam sebuah cluster. Jeda replikasi tipikal adalah di bawah 100 milidetik. Kelambatan jaringan atau masalah pada node dapat menyebabkan peningkatan jeda replikasi antara penulis dan node replika.

Injeksi kesalahan kegagalan replika memungkinkan Anda untuk mensimulasikan kegagalan replikasi di satu atau beberapa replika. Perhatikan bahwa jenis injeksi kesalahan ini hanya berlaku untuk klaster DB yang memiliki setidaknya satu replika baca.

Kegagalan replika memanifestasikan dirinya sebagai data basi yang dibaca oleh aplikasi yang terhubung ke replika. Dampak fungsional spesifik pada aplikasi tergantung pada sensitivitas terhadap kesegaran data. Perhatikan bahwa mekanisme injeksi kesalahan ini tidak berlaku untuk mekanisme yang didukung replikasi asli di database PostgreSQL dan MySQL.

Contoh: Aurora PostgreSQL untuk kegagalan replika

Pernyataan berikut akan mensimulasikan 100% kegagalan replika bernama ‘my-replica’ selama 20 detik.

SELECT aurora_inject_replica_failure(100, 20, ‘my-replica’)

Tim harus mengamati perilaku aplikasi dari perspektif sensitivitas data. Jika kelambatan yang diamati tidak dapat diterima, tim harus mengevaluasi tindakan korektif seperti penskalaan vertikal instance database dan optimisasi kueri. Sebagai praktik terbaik, tim harus memantau jeda replikasi dan mengambil tindakan proaktif untuk mengatasinya.

3. Menguji kegagalan disk

Volume penyimpanan Aurora terdiri dari enam salinan data di tiga Availability Zone (lihat diagram sebelumnya). Aurora memiliki kemampuan yang melekat untuk memperbaiki dirinya sendiri untuk kegagalan dalam komponen penyimpanan. Keandalan yang tinggi ini dicapai melalui model kuorum. Bacaan hanya membutuhkan 3/6 node dan menulis membutuhkan 4/6 node untuk tersedia. Namun, mungkin masih ada dampak sementara pada aplikasi tergantung pada seberapa luas masalah tersebut.

Kemampuan injeksi kegagalan disk memungkinkan Anda untuk mensimulasikan kegagalan node penyimpanan dan kegagalan sebagian disk. Tingkat keparahan kegagalan dapat diatur sebagai nilai persentase. Simulasi berlanjut hanya untuk jumlah waktu yang ditentukan. Tidak ada dampak pada data aktual pada node penyimpanan dan disk.

Contoh: Aurora PostgreSQL untuk simulasi kegagalan disk

Anda mungkin mendapatkan jumlah disk (untuk indeks) di cluster Anda menggunakan kueri:

SELECT disks FROM aurora_show_volume_status()

Query berikut akan mensimulasikan 75% kegagalan pada disk dengan indeks 15. Simulasi akan berakhir dalam 20 detik.

SELECT aurora_inject_disk_failure(75, 15, true, 20)

Aplikasi mungkin mengalami kegagalan sementara karena injeksi kesalahan ini dan harus dapat memulihkannya dengan baik. Jika waktu pemulihan lebih tinggi dari ambang batas, atau aplikasi mengalami kegagalan total, tim dapat mendesain ulang aplikasi mereka.

4. Kesalahan kemacetan disk Disk

Kemacetan disk biasanya terjadi karena lalu lintas I/O yang padat terhadap perangkat penyimpanan. Dampaknya dapat berkisar dari kinerja aplikasi yang menurun, hingga kegagalan aplikasi yang lengkap.

Aurora menyediakan kemampuan untuk mensimulasikan kemacetan disk tanpa beban SQL sintetis terhadap database. Dengan mekanisme injeksi kesalahan ini, Anda dapat memperoleh pemahaman yang lebih baik tentang karakteristik kinerja aplikasi di bawah lonjakan I/O yang berat.

Contoh: Aurora PostgreSQL untuk simulasi kemacetan disk

Anda mungkin mendapatkan jumlah disk (untuk indeks) di cluster Anda menggunakan kueri:

SELECT disks FROM aurora_show_volume_status()

Kueri berikut akan mensimulasikan kegagalan disk 100% selama 20 detik. Kegagalan akan disimulasikan pada disk dengan indeks 15. Delay yang disimulasikan antara 30 dan 40 milidetik.

SELECT aurora_inject_disk_congestion(100, 15, true, 20, 30, 40)

Jika perilaku yang diamati tidak dapat diterima, maka tim harus hati-hati mempertimbangkan karakteristik beban aplikasi mereka. Bergantung pada pengamatan, tindakan korektif dapat mencakup pengoptimalan kueri, pengindeksan, penskalaan vertikal instans database, dan menambahkan lebih banyak replika.

Kesimpulan

Eksperimen chaos melibatkan penyuntikan kesalahan dalam lingkungan produksi dan kemudian mengamati perilaku aplikasi. Hasil eksperimen membantu tim mengidentifikasi kelemahan aplikasi dan mengevaluasi proses respons peristiwa. Amazon Aurora secara asli menyediakan kemampuan injeksi kesalahan yang dapat digunakan oleh tim untuk melakukan eksperimen chaos untuk skenario kegagalan database. Aurora dapat digunakan untuk mensimulasikan kegagalan instans, kegagalan replikasi, kegagalan disk, dan kemacetan disk. Cobalah kemampuan ini di Aurora untuk membuat aplikasi Anda lebih kuat dan tahan dari kegagalan database.