Apa yang Baru di API7 Enterprise 3.2.9: Peningkatan Konfigurasi Health Check

Pengenalan Fitur Pemeriksaan Kesehatan Baru

Dalam versi 3.2.9 dari API7 Enterprise, pengalaman interaksi konfigurasi untuk pemeriksaan kesehatan telah dioptimalkan secara menyeluruh.

1. Item konfigurasi yang sebelumnya tersebar telah dikelompokkan secara logis, seperti pengaturan probe, dan kriteria untuk menentukan node yang sehat dan tidak sehat, membuatnya lebih terstruktur.

2. Beberapa nama item konfigurasi yang abstrak telah diubah menjadi ekspresi yang lebih intuitif dan bermakna, memungkinkan pengguna untuk langsung memasukkan parameter terkait melalui format isian, sehingga lebih memahami efek praktis dari konfigurasi.

3. Selama proses konfigurasi node upstream dan pemeriksaan kesehatan, lebih banyak pesan prompt telah ditambahkan untuk membantu pengguna memahami hubungan intrinsik antara node upstream dan pemeriksaan kesehatan, sehingga memudahkan penyelesaian tugas konfigurasi.

Konsep Dasar Pemeriksaan Kesehatan

Di API7 Enterprise, pengaturan prioritas node upstream terkait erat dengan mekanisme load balancing dan pemeriksaan kesehatan. Ketika pengguna mengonfigurasi beberapa node upstream dengan prioritas berbeda untuk gateway, gateway akan memprioritaskan node dengan prioritas tertinggi selama load balancing. Ini berarti selama node dengan prioritas tertinggi tetap sehat, gateway akan terus mengarahkan lalu lintas ke node tersebut.

Hanya ketika semua node dengan prioritas tertinggi dianggap tidak tersedia karena pemeriksaan kesehatan gagal, gateway akan secara otomatis menurunkan prioritas, mengarahkan lalu lintas ke node upstream dengan prioritas berikutnya. Desain ini memastikan pemanfaatan lalu lintas yang efisien dan ketersediaan sistem yang tinggi.

Perlu dicatat bahwa jika beberapa tingkat prioritas node upstream dikonfigurasi dalam layanan, tetapi fungsi pemeriksaan kesehatan dinonaktifkan, maka semua permintaan klien akan selalu diarahkan ke node dengan prioritas tertinggi, terlepas dari status kesehatan aktual mereka.

Metode Konfigurasi Pemeriksaan Kesehatan

Konfigurasi Probe

Probe digunakan untuk mendeteksi kelangsungan hidup dan status layanan node upstream. Di APISIX, probe seperti "inspektur" yang secara teratur mengetuk pintu untuk memeriksa apakah layanan upstream berfungsi dengan baik. Jika menemukan masalah atau layanan "tidak tersedia", probe akan memberi tahu APISIX: "Layanan ini saat ini tidak tersedia, jadi tunda pengiriman permintaan ke sini." Proses "mengetuk pintu" ini dilakukan melalui probe.

Probe terutama mencakup item konfigurasi berikut:

• Skema Probe: Jenis protokol yang digunakan oleh probe pemeriksaan kesehatan, mendukung TCP, HTTP, dan HTTPS.

• Konkurensi: Item konfigurasi ini memungkinkan Anda mengatur jumlah permintaan pemeriksaan kesehatan yang bersamaan. Dengan kata lain, ini adalah jumlah kali Anda ingin "mengetuk pintu" secara bersamaan untuk memeriksa responsivitas layanan upstream. Dengan menyesuaikan konkurensi, Anda dapat mensimulasikan permintaan bersamaan yang mungkin terjadi dalam skenario nyata, sehingga lebih baik mengevaluasi kinerja dan stabilitas layanan upstream.

• Host: Menentukan alamat host server upstream yang akan diperiksa. Ini seperti menentukan rumah mana yang akan "diketuk pintunya".

• Port: Nomor port layanan upstream. Ini seperti mengetahui pintu mana yang akan diketuk selama probe.

• Path: Jika Anda menggunakan probe HTTP, item konfigurasi ini menentukan jalur URL yang ingin Anda akses. Ini seperti memberi tahu probe untuk memeriksa ruangan yang tepat setelah masuk.

Kriteria untuk Menentukan Node Sehat

Mengenai penentuan node sehat, sistem secara teratur memeriksa node yang sebelumnya ditandai sebagai tidak sehat pada interval yang ditetapkan oleh pengguna (dalam detik) untuk memastikan deteksi tepat waktu dan penanganan yang tepat terhadap anomali node sementara.

Jika probe menggunakan protokol TCP, node dianggap sehat setelah probe berhasil terhubung ke node upstream sebanyak jumlah yang ditetapkan oleh pengguna.

Jika probe menggunakan protokol HTTP/HTTPS, sistem menganggap node sehat hanya ketika secara terus-menerus menerima permintaan probe dengan kode status yang ditentukan (seperti 200 dan 302) dari node tersebut. Ini berarti node dianggap bekerja dengan baik hanya ketika secara terus-menerus mengembalikan kode status tertentu ini.

Kriteria untuk Menentukan Node Tidak Sehat

Mengenai penentuan node tidak sehat, metode konfigurasinya mirip dengan menentukan node sehat. Sistem secara teratur memeriksa node yang ditandai sebagai sehat pada interval yang ditetapkan oleh pengguna. Setelah node ini memenuhi kondisi tidak sehat yang telah ditetapkan, mereka diklasifikasikan ulang sebagai tidak sehat.

Sedikit berbeda dari menentukan node sehat, item konfigurasi tambahan, verifikasi permintaan klien, ditambahkan selama proses penentuan node tidak sehat. Ketika fitur ini diaktifkan, gateway tidak hanya mengandalkan hasil inspeksi probe tetapi juga mengamati dan menganalisis permintaan dari klien dan respons aktual dari layanan upstream. Berdasarkan data ini dan kriteria penilaian yang ditentukan pengguna, gateway dapat lebih akurat mengevaluasi status berjalan layanan upstream.

Praktik Terbaik untuk Pemeriksaan Kesehatan

Memilih Jenis Probe yang Tepat

• Probe TCP: Cocok untuk skenario yang hanya memerlukan konfirmasi apakah port layanan terbuka dan dapat diakses. Misalnya, layanan database mungkin hanya memerlukan probe TCP untuk mengonfirmasi pembukaan port.

• Probe HTTP/HTTPS: Lebih cocok untuk skenario yang memerlukan verifikasi bahwa tidak hanya koneksi jaringan normal tetapi juga layanan dapat menangani permintaan dengan benar. Misalnya, untuk server web atau layanan API, kita perlu memastikan bahwa layanan tidak hanya dapat menerima koneksi tetapi juga mengembalikan halaman atau data yang benar.

Konfigurasi Parameter Pemeriksaan Kesehatan yang Wajar

Saat mengonfigurasi pemeriksaan kesehatan, perhatikan beberapa parameter kunci:

• Interval Pemeriksaan: Tidak boleh terlalu pendek untuk menghindari overhead yang tidak perlu atau terlalu panjang untuk menghindari respons yang lambat jika terjadi masalah. Misalnya, untuk situs web e-commerce dengan lalu lintas tinggi, memeriksa setiap 30 detik adalah pilihan yang relatif wajar. Interval ini tidak terlalu membebani sumber daya sistem maupun menunda deteksi dan penanganan masalah di situs web.

  Tentu saja, interval ini tidak mutlak, dan penyesuaian perlu dilakukan berdasarkan situasi aktual situs web. Misalnya, jika situs web mengalami fluktuasi lalu lintas yang signifikan atau mengalami lonjakan lalu lintas selama periode tertentu (seperti selama kampanye promosi), mungkin perlu menyesuaikan interval pemeriksaan untuk mengakomodasi perubahan ini.

• Timeout: Waktu yang ditunggu probe untuk respons layanan. Jika layanan tidak merespons dalam waktu ini, probe menganggap layanan tidak sehat. Nilai ini harus disesuaikan dengan waktu respons aktual layanan.

• Jumlah Percobaan Ulang: Jumlah kali probe mencoba terhubung sebelum menentukan layanan tidak sehat. Nilai ini harus moderat untuk menghindari penilaian yang salah.

Menyesuaikan Strategi Berdasarkan Bisnis

Strategi pemeriksaan kesehatan harus disesuaikan berdasarkan situasi bisnis aktual. Jika layanan biasanya mengalami beban tinggi selama periode waktu tertentu, interval pemeriksaan kesehatan dapat ditingkatkan atau jumlah percobaan ulang dikurangi selama periode ini untuk menghindari tekanan tambahan pada layanan.

Mengaktifkan Verifikasi Permintaan Klien Secara Tepat

Verifikasi permintaan klien dapat secara efektif menentukan status layanan berdasarkan permintaan bisnis aktual, terutama untuk mengidentifikasi masalah yang terkait erat dengan logika bisnis. Namun, ini mungkin tidak cocok untuk setiap skenario bisnis.

1. Layanan dengan Lalu Lintas Rendah: Jika lalu lintas layanan rendah, pemeriksaan kesehatan pasif berdasarkan permintaan klien mungkin tidak memberikan cukup titik data untuk menilai status layanan secara akurat. Dalam kasus seperti ini, mengandalkan pemeriksaan probe aktif mungkin lebih dapat diandalkan.

2. Pertimbangan Kinerja di Lingkungan Konkurensi Tinggi: Pemeriksaan kesehatan pasif memerlukan pemantauan dan pemrosesan setiap permintaan klien, yang dapat meningkatkan overhead kinerja tambahan di lingkungan konkurensi tinggi. Jika kinerja adalah prioritas utama dan layanan telah dipantau dengan cukup melalui cara lain, pemeriksaan kesehatan pasif dapat dipertimbangkan untuk ditutup.

3. Keberadaan Sistem Pemantauan Lain: Jika sistem pemantauan yang matang sudah diterapkan di perusahaan, mampu menangkap dan menganalisis status layanan secara real-time, pemeriksaan kesehatan pasif mungkin tidak diperlukan untuk menghindari redundansi data dan kompleksitas tambahan.

Kesimpulan

Pemeriksaan kesehatan adalah aspek penting dalam memastikan ketersediaan tinggi gateway API. Dalam versi 3.2.9 dari API7 Enterprise, kami telah mengoptimalkan interaksi konfigurasi pemeriksaan kesehatan secara menyeluruh, menyederhanakan operasi dan meningkatkan pengalaman pengguna.

Dengan mengonfigurasi probe dengan benar, menetapkan kriteria untuk node sehat dan tidak sehat, dan menyesuaikan strategi berdasarkan kebutuhan bisnis aktual, pengguna dapat lebih efektif memantau status layanan upstream, memastikan bahwa lalu lintas selalu diarahkan ke node yang sehat. Ini tidak hanya meningkatkan stabilitas dan ketersediaan sistem tetapi juga memastikan bahwa permintaan pengguna mendapatkan respons yang tepat waktu dan akurat.