Membangunkan Database Tanpa Koneksi Mati

Aplikasi yang dipublikasikan di Mythex, dan database-nya, masuk ke mode tidur saat tidak ada yang memakainya. Saat sebuah aplikasi bangun, ia bisa menahan permintaan pertamanya selama 10 hingga 12 detik, karena ia mencoba memakai ulang koneksi database yang sudah mati selama semuanya tidur. Sekarang kami memberi aplikasi Spring Boot pengaturan database yang aman setelah tidur, dan memberi tahu agen untuk membangun aplikasi dari stack apa pun dengan cara yang sama. Di platform hosting, permintaan pertama setelah bangun turun dari 12,7 detik menjadi 2,3 detik.

Mengapa aplikasi dan database tidur

Aplikasi Mythex yang dipublikasikan berjalan di mesin yang ditangguhkan setelah beberapa menit tidak aktif, dan database-nya adalah Postgres serverless yang tidur setelah lima menit tidak aktif dan bangun pada permintaan berikutnya. Itulah yang membuat aplikasi yang sepi tetap murah: Anda ditagih untuk apa yang benar-benar dipakai database, dan aplikasi yang tidur tidak mengeluarkan biaya compute. Kami menulis tentang sisi penagihannya di menagih database berdasarkan apa yang benar-benar mereka pakai.

Masalahnya, keduanya tidur secara terpisah, dan mereka tidak sepakat tentang apa itu koneksi.

Gejalanya: kunjungan pertama yang lambat

Sebagian besar aplikasi server menyimpan connection pool: sejumlah kecil koneksi database yang tetap terbuka dan siap, sehingga setiap permintaan tidak perlu membayar biaya membuka koneksi baru. Itu desain yang tepat untuk aplikasi yang selalu aktif.

Begini yang terjadi saat tidur:

1. Aplikasi berjalan, dengan beberapa koneksi menganggur di pool-nya.
2. Tidak ada yang berkunjung. Mesin aplikasi ditangguhkan, dibekukan dengan pool-nya yang masih utuh.
3. Database tidur dan menjatuhkan ujung koneksinya.
4. Seorang pengunjung datang. Aplikasi bangun persis seperti sebelumnya, masih memegang koneksi yang tidak lagi dikenal database.
5. Pool memberikan salah satu koneksi itu. Aplikasi harus mengetahui bahwa koneksi itu mati, dengan mencobanya dan menunggu, sebelum menyerah padanya.

Dalam aplikasi Spring Boot, memvalidasi koneksi mati itu memblokir permintaan pertama selama sekitar 10 detik sebelum akhirnya gagal dengan “Connection is not available”. Bagi pengunjung, situs itu seolah menggantung, lalu mungkin menampilkan error.

Mengapa aplikasi Spring yang paling terdampak

Spring Boot adalah framework Java yang populer, dan ia memakai pool koneksi bernama HikariCP secara default. Spring bisa mengonfigurasi pool itu dari pengaturan, termasuk berapa banyak koneksi menganggur yang disimpan.

Tetapi Mythex memberi setiap aplikasi database-nya sebagai satu DATABASE_URL dengan format postgresql://user:pass@host/db. Spring tidak bisa membaca format itu secara langsung. Jadi aplikasi Spring yang dibangun di Mythex membuat pool-nya sendiri dalam kode dengan mengurai URL tersebut, dan pool yang dibuat dengan tangan mengabaikan semua pengaturan spring.datasource.* milik Spring. Bahkan jika seseorang tahu pengaturan pool yang benar, tidak ada tempat agar pengaturan itu berlaku.

Perbaikan bagian 1: pengaturan yang bisa dipakai Spring

Ketika sebuah proyek memiliki database, sekarang kami juga memberinya variabel lingkungan yang dibaca Spring secara native:

• SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME, dan SPRING_DATASOURCE_PASSWORD, dikonversi dari DATABASE_URL (dengan SSL diwajibkan kecuali URL menyatakan lain).
• Pengaturan pool yang bertahan setelah tidur:

Dengan tidak ada koneksi menganggur yang disimpan, aplikasi yang bangun membuka satu koneksi baru alih-alih menelusuri koneksi mati yang banyak.

Dengan variabel ini tersedia, Spring mengonfigurasi pool-nya sendiri, dan pengaturannya berlaku. Apa pun yang sudah diatur sendiri oleh proyek selalu menang; kami hanya mengisi yang belum ada. Aplikasi yang bukan Spring mengabaikan variabel ini.

Detail yang hampir membuatnya tidak berfungsi

Spring memetakan variabel lingkungan ke pengaturannya dengan aturan yang mudah keliru. Pengaturan minimum-idle harus ditulis sebagai SPRING_DATASOURCE_HIKARI_MINIMUMIDLE: tanda hubung dibuang, kata-kata disambung. Menulisnya sebagai SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE, yang terlihat lebih alami, dipetakan ke pengaturan lain yang tidak ada (minimum.idle) dan diabaikan tanpa suara.

Ini jenis kesalahan yang lolos dari setiap tinjauan dan tidak berbuat apa-apa di produksi. Maka sebuah tes memeriksa keduanya: bahwa nilainya diatur, dan bahwa tidak ada variabel yang memakai bentuk yang dipisahkan garis bawah.

Perbaikan bagian 2: setiap stack lainnya

Spring bukan satu-satunya framework dengan pool, dan kami tidak bisa mengonfigurasi setiap library di setiap bahasa sebelumnya. Maka agen Mythex, AI yang menulis aplikasi Anda, sekarang mendapat instruksi tetap untuk stack apa pun: aplikasi dan database yang dipublikasikan tidur saat tidak aktif, sehingga koneksi yang dibiarkan terbuka bisa sudah mati pada permintaan berikutnya. Agen harus:

• tidak menyimpan koneksi database menganggur yang terbuka, atau memeriksa setiap koneksi sebelum dipakai,
• mencoba ulang sekali jika terjadi error koneksi, dan
• memakai pengaturan database yang disediakan platform di lingkungan, alih-alih membuat pool sendiri dengan mengurai DATABASE_URL.

Poin terakhir itu menutup lingkaran dengan bagian 1: aplikasi yang dibangun dengan pengaturan yang disediakan otomatis mendapatkan konfigurasi yang aman untuk tidur.

Hasilnya

Diukur di platform hosting tempat kami menjalankan aplikasi yang dipublikasikan, permintaan pertama setelah bangun turun dari 12,7 detik menjadi 2,3 detik.

Yang kami ambil dari ini

• Setiap lapisan yang tidur harus sepakat tentang apa yang bertahan. Aplikasi yang dibekukan dan database yang tidur masing-masing membuat pilihan yang masuk akal. Bersama-sama, aplikasi bangun dengan state yang sudah tidak benar.
• Default yang dirancang untuk server yang selalu aktif tidak cocok untuk aplikasi yang diskalakan ke nol. Menjaga koneksi tetap hangat adalah ide bagus sampai semua yang ada di sekitarnya menjadi dingin.
• Berikan data kepada framework dalam format mereka sendiri. Satu URL memang sederhana bagi kami, tetapi itu memaksa setiap aplikasi Spring membuat pool dengan tangan yang mengabaikan konfigurasinya sendiri.
• Uji bahwa sebuah pengaturan dieja sesuai cara framework membacanya. Nilai yang benar dengan nama yang salah tidak berbuat apa-apa, tanpa suara.

Jika Anda baru mengenal cara kerja database di Mythex, lihat dokumentasi database dan penjelasan kami tentang apa itu Postgres.